As part of our efforts to better understand the state of the web, sometimes it’s helpful to take a step back and look at the tools that enable us to understand how individual websites are built. For example, as we explored in an earlier episode, there are two things that make the HTTP archives so powerful their unique ability to analyze the breadth of hundreds of thousands of websites and the depth of information we can learn about each website. And that’s where WebPagetest comes in.
It’s the engine that drives the HTTP archive and tells us everything we need to know about each page. Let’s see how it works.
WebPagetest is a laboratory-like environment where you have fine-grained controls over every part of loading a web page– the device, browser, geographic location, connection speed, cache state, and more. This kind of testing lends itself really well to A/B testing. For example, you can test two versions of the same web page with and without some optimization to see exactly how it changes the composition of the page.
You could also test the same web page over time and track things like how many bytes it loads, a process known as synthetic monitoring. So let’s run our first test by going to the webpage test.
org and configure a few common parameters. Running both a first view and repeat view will show us the difference a good caching policy makes on reload. Capturing video will enable us to watch the visual progress of the page load just as a user would see. For example, it could show us the sequence of resources appearing on the screen in slow motion or the flash of unstyled text before the web fonts load. And now let’s enter the URL of the page and run the test.
When the results are ready, it may be overwhelming to try to take it all in, so let’s focus on the most important thing first– the waterfall chart.
This chart visualizes the entire network activity of the page load. Each row represents a request from the client to the server. Timings for every step from request to response are shown as different-colored bars, including DNS lookup, TCP connection, SSL negotiation, back-end response time, and download time. The biggest takeaway from the waterfall chart should be whether anything low priority is happening during the critical path, or the time during which the most important page resources are loading.
Looking at the waterfall for the repeat view we configured earlier, it should have much fewer requests. Most of the static resources should be loaded from cache this time, so they wouldn’t show up in the chart of network activity. If you see any requests highlighted in yellow with 304, this means that the browser had incomplete information about the freshness of the resource, and it needed to ask the server if it could reuse what it has in the cache.
This is an inefficiency that WebPagetest highlights to make it easier to identify and optimize. Another really useful section of the results is the film strip.
You can see exactly how the page UI was assembled onscreen and how long it took. You can even watch a replay of the page-load in real-time or in slow motion. But the best part is when you do this for multiple tests, either an A/B test of the same page or even competing websites. WebPagetest is an invaluable and amazingly powerful tool. This is just a quick look at some of its features, but there’s so much more it can do, like controlling the test with scripting using the API and even hosting your own private instance.
You can learn more about all of these features and more http://marketertoolbox.xyz/EverythingYouNeed/ Thanks for watching, and we’ll see you next time.
