Tải bản đầy đủ - 0trang
Chapter 27. A Simple Way to Measure Website Performance
tion built on Pylons and MongoDB. It allows extracting detailed metrics from HAR
files, storing test results, and visualizing all gathered data.
The key advantage is high flexibility. With BrowserMob Proxy, you can test a website
in any modern browser that supports custom proxy settings. You can even deal with
Selenium in turn makes it possible to simulate any sophisticated user scenario. Therefore you can analyze both the speed of single page and the performance of complex
HAR Storage has cool features too. For instance, you can compare results of different
tests. This is a great help for analyzing third-party party content or for investigating the
relationship between site speed and network quality (Figure 27-1).
Figure 27-1. Performance Trends
At least with HAR Storage you can continuously track the performance of your website
or application at any development phase.
Nothing is perfect in this world. BrowserMob proxy runs outside the browser and on
the one hand has minimal impact on its performance; on the other hand, internal
browser events are inaccessible. Thus you can’t estimate performance of rendering or
This approach may seem too complicated to some people. In fact it isn’t. WebPagetest.org lets you simply put in the URL and enjoy the result. But if you need real crossbrowser testing, measurements over time, and implementation of complex use cases—
this method will work for you.
152 | Chapter 27: A Simple Way to Measure Website Performance
Web performance is still critical aspect, and performance testing is still a challenge.
Frameworks based on Selenium, BrowserMob Proxy, and HAR Storage may become
an ultimate solution for many growing projects.
To comment on this chapter, please visit http://calendar.perfplanet.com/
2011/a-simple-way-to-measure-website-performance/. Originally published on Dec 27, 2011.
Conclusion | 153
Beyond Bandwidth: UI Performance
Traditionally, older performance studies were concerned with speeding up things on
the server side, but a few years back, Steve Souders famously started research on the
idea that the main performance bottleneck happened on the client side. In particular,
in the way bytes were pushed to the client from the server. “Reduce HTTP requests”
has become a general maxim for speeding up frontend performance, and that is a concern that’s even more relevant in today’s world of mobile browsers (often running on
networks that are an order of magnitude slower than broadband connections).
These studies have been concerned with latency and bandwidth, and this still continues
to be the focus of performance research today. You are probably already familiar with
the standard HTTP waterfall chart (Figure 28-1).
However, we’re slowly starting to see a shift to other frontend concerns for each component of the frontend stack (HTML/CSS/JS). In particular, there’s been a great focus
After the Page Loads: The UI Layer
This is all well and good, but we're missing something equally important: the presentation (UI) layer. Although some UI performance tips have been disseminated throughout the community for years, they are often as an aside, with bandwidth and latency
concerns much more at the forefront of research. For instance, where CSS is even a
concern, the focus is on reducing CSS filesize (http://www.stevesouders.com/blog/2010/
07/03/velocity-top-5-mistakes-of-massive-css/). But what about expensive CSS selectors? Or CSS that may cause the page to lag horribly as the user scrolls?
Figure 28-1. HTTP waterfall chart
One of the reasons UI performance has been downplayed is perhaps because of its
inability to be quantified. As engineers, it's a bit disconcerting to say that as a result of
many hours of improvements, a website “feels” more responsive, or scrolls more
smoothly. Without some sort of metrics, it's difficult to determine where the rendering
bottlenecks are, or even if we're making progress when trying to smooth them out.
Luckily we're just now beginning to get access to tools that let us measure these UI
bottlenecks. “Reflows” and “repaints” are now more than abstract mysterious happenings—they are now something we can point to on a chart.
At the time of writing, CSS profilers are available in Chrome's Developer Tools, as well
as Opera's debugger (Dragonfly). Figure 28-2 shows the new face of performance
Other than targeting expensive CSS selectors with these new profilers, we also have
access to a few more useful tools for UI performance debugging. The following is just
a few of these.
CSS Stress Test
CSS Stress Test (by Andy Edinborough) is a bookmarklet that figures out which CSS
declarations are slowing down the page by selectively removing each one, then subse156 | Chapter 28: Beyond Bandwidth: UI Performance