Web performance is a lot like user experience. It's hard to just "sprinkle" in some UX and see the site get "pretty". User experience isn't an add-on, it's a series of fundamental decisions. User experience means you take time to understand the user's needs and you design your app to fit them. This isn't a one time study either. It's a continuous process. Web performance is the same way.
It's difficult to "sprinkle" in some performance to speed up a slow site. Yes, there's some easy wins. Compress images, minify files, use font-display: swap. But creating a performance focused site starts from the ground up. It's not enough to build a performant site and take a break. It's a continuous process. It takes continous monitoring.
WebpageTest allows you to test the performance of a website on real devices and real consumer speeds. Test on an iPad, iPhone, Galaxy S7, and even low powered devices like the Moto G4. Set network speeds from fast FIOS to slow mobile edge networks.
WebpageTest is built and maintained by the great Pat Meenan. Give him a follow or a thank you. He deserves it.
You might be confused by the many options provided by WebpageTest. Let's keep it simple. Test on the lowest denominator. Fast sites on slow networks are still fast sites on fast networks. The web's greatest asset is reach. No app stores, just links. Performant sites have better reach across the world.
Instead of messing with dropdowns and checkboxes just use the easy mode: webpagetest.org/easy.
This mode uses a Moto G4 on a "Slow 3G" network. What makes this setting so slow?
Don't focus on bandwidth. While 400kbps isn't ideal, it's an after thought compared to the latency.
Bandwidth is the measure of how much data the network can send at once. Latency is how long it takes to make a send the data roundtrip. Bandwidth is the width of the tube and latency is its length.
Mobile networks are notorious for high latencies. The "Slow 3G" setting contains a latency of 400ms roundtrip. This means that it takes 400ms for the client to receive data from the server regardless of its size. To make matters worse, the initial HTTP connection takes four roundtrips! That means it's your site can't begin to load other assets for at least 1.6 seconds.
Respect latency. Fight it with HTTP/2, CDNs, and reducing request chains. It's the killer of performance. Mobile networks are fraught with high latencies, make sure to test accordingly.
The "Easy Mode" test run gives you a summary and three test runs. The summary looks a bit like this:
This table presents a bunch of important metrics, my favorite ones are:
The metric that jumps out the most is the one I didn't mention: "Load Time". The "Load Time" is an paltry 5.8 seconds. However, it does not tell the whole story. According to the WebpageTest documentation: "The Load Time is the time from when the user started navigating to the page until the Document Complete event (usually when all of the page content has loaded)."
The "Document Complete" event refers to the window.onload event. According to MDN: "The load event fires at the end of the document loading process. At this point, all of the objects in the document are in the DOM, and all the images, scripts, links and sub-frames have finished loading."
While this metric is good to know, the page is possibly usable before this events fires. Deferred scripts and images inflate this number even though the site is likely usable.
To understand the real story of what's going, we'll need to look at the "Filmstrip View".
I rarely focus on the summary. I may glance at "First Byte" to make sure nothing funky is going on. But I'm quick to jump into the Filmstrip View.
To the right of each test run is a link to the "Filmstrip View". This is the page you'll use the most. The Filmstrip View provides you more than numbers. It gives you a visual play-by-play of what's happening during page load.
This collection of scrollable thumbnails shows you what it feels like waiting for the page to load. You can even change the interval between thumbnails. The default is 0.5s, but you can set it to 0.1s or even 60FPS. I usually pick 0.1s because it makes it much easier to consult the network waterfall below.
Below the filmstrip is a network waterfall. Notice that the vertical red bar moves across the waterfall as you scroll through the filmstrip.
This is how you can correlate visual changes to the loading of assets over the network. As you scroll past a loaded asset you'll see a specific change. Use this to find the series of formal page load metrics.
The sheer amount of page load metrics is sometimes overwhelming. Focus on the overall picture of page load instead of worrying about the importance of each metric. There's a series of formal metrics that are used to understand progression of page load:
This wonderful image was sourced from Web Fundamentals.
The network waterfall tells you when these metrics occur. It's easy to notice when just some content appears and when the main content appears. But how do you know when the page is interactive? The network waterfall also provides this information.
The very bottom of the network waterfall contains information about the activity of the browser's main thread. This main thread is responsible for handling UI updates. If the the thread is blocked there won't be able UI updates. This means the page is effectively frozen.
At just before 5.4 seconds a web font finishes loading. Then immediately after there's a bunch of purple which blocks the thread. This is because of font-display: swap. The browser had to layout the page to swap to the custom web font. This was an intensive, but brief process. Remember that we're on a Moto G4, modern devices wouldn't have this problem.
The main thread chart is clear after this point. This means we can consider the site interactive at 5.5s. This isn't a completely meaningful metric in this case however.
Time to Interactive is tricky. At first glance it can appear that a site isn't interactive until that meric. But that's not always the case. In the example above the thread is clear for several seconds before and after. This blocked section is a hiccup. What would be more concerning in an large chunk of red that starts early when content is visible. This is common in server side rendered sites like below:
If this guide has taught you anything, I hope it's that page load is not one metric. Looking at "Load Time" won't tell you when a user begins to see content. Focusing on First Meaningful Paint won't tell you if a user can actually use your site. Using Time to Interactive alone isn't a wise strategy either. It's up to you to understand metrics are most important to your site. It's up to you to continously monitor your site and make sure it's performing for your users.
NOTE! This section is curated my Maxim Salnikov! He's one of the most knowledgeable and passionate PWA developers out there. Give him a follow on Twitter.