Tải bản đầy đủ - 0 (trang)
Chapter 27. A Simple Way to Measure Website Performance

Chapter 27. A Simple Way to Measure Website Performance

Tải bản đầy đủ - 0trang

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

mobile browsers.

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

business transactions.

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

JavaScript parsing. Tools like dynaTrace AJAX Edition are more suitable for such tasks.

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

David Calhoun


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

on JavaScript performance, a fact attested to by the popularity of jsPerf (http://jsperf

.com/) and the rise of JavaScript profilers.

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.

UI Profilers

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


Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Chapter 27. A Simple Way to Measure Website Performance

Tải bản đầy đủ ngay(0 tr)