In my continuing quest to learn more about web performance, I just finished reading Using WebPageTest by Rick Viscomi, Andy Davies, and Marcel Duran. As I learned in a recent project, WebPageTest is super useful and I was eager to learn more about it, especially since the book came recommended by a trusted source.
I set about to go through the book and while reading I also played around with some tests and digging into the features. And this book goes in depth into all the things you can do with the tool, which I gotta say: it’s impressive. All the ways in which you can test a site to get so much data about performance is great.
But the strength of the book is also helping you think about the best ways to test given specific user data. The authors go through how you can collect that data to make sure you are using WebPageTest in as much the same way your users use your website as possible. This book is worth the read. The final section gets extremely technical, so I will admit I skimmed through that as I don’t know that I’ll ever set up my own instance of WebPageTest, but the first two sections were so great. I feel much better equipped to use the tool and help clients see where problems are happening in their sites.
I read the epub version of the book and since page numbers change depending on your font settings and screen size, I have things broken up by chapter for my highlights. Since this is a more technical book I didn’t highlight as much as usual, but this will definite be a reference I return to when on client projects.
Tools like WebPageTest are considered to be synthetic because of their artificial testing environments. Akin to a clean room in a laboratory, WebPageTest gives its testers granular control over many of the variables that contribute to performance changes, such as geographic location and type of network connection. By making these variables constant, the root causes of poor frontend performance can be more easily identified and measured.
For attempting to determine the overall speed of a page, it’s clear that RUM is the appropriate solution because it accurately represents the performance of actual users. When starting out with WebPageTest, one pitfall is to assume that the synthetic results are like real-user metrics. The reality, however, is that synthetic tools are deliberately designed to focus on the performance of a web page under strict conditions that are otherwise highly volatile in real-user performance.
As easy as it is to see network silence in a waterfall diagram, WebPageTest is not equipped to identify the underlying problem by default. As with the problem of a long first-byte time, the tool is great at showing that there is a problem but additional tools are necessary to determine what the problem actually is. In the case of network silence, a profiler is required.
The WebPageTest grades, on the other hand, are a set of web performance must-haves to which most, if not all, pages should adhere.
Summary of Part 1
In the web performance testing version of “show and tell,” the filmstrip and video serve as the tangible parts of the performance story. They can’t do it alone, though, so we use these tools in addition to the cold hard metrics and waterfall charts to tell the complete story.
By linking user data like IP address with page data, the services are able to interpolate patterns such as navigation flow through a website. RUM services are also capable of handling application-specific data.
Adding a RUM service to your website gives you the ability to not only monitor performance but also capture valuable information about who your users are. And because RUM constantly ingests live data, you can see how users change the way they access your site over time.
By leveraging software that aggregates real-user demographics, you’re able to determine the most accurate settings to represent your visitors.
Optimizing the synthetic experience will more likely translate to an optimized real-user experience when you’re able to focus on the issues that actually affect them.
This has become the universal truth of web development; users can and will access the web however they are able. In recent years, the freedom of accessibility has become less about “taking back the Web” by choice of browser and more about convenience of access with mobile devices.
Despite these limitations, there is still something to be learned from emulation. Especially when mobile tests are compared against straightforward desktop tests, egregious “mobile-unfriendly” anti-patterns can be spotted.
WebPageTest accommodates this discrepancy by changing the way the desktop test agent is able to communicate over the network. This technique, called traffic shaping, allows test agents to simulate slow connection speeds.
It’s worth noting that when you run a SPOF test, nothing may actually go wrong. This is a good thing! This means that your page is adequately prepared to handle the sudden failure of a third-party resource.