
Every time I’ve worked on improving website performance, I’ve wanted to share the numbers with everyone to show just how big a difference even simple measures can make. But I always forgot to keep records while making adjustments.
“Next time, I’ll take those screenshots…”
The Experiment
Well, this time I did. I recently created a quick single-page static website for a client. Once I had the page ready, I turned to improving performance. My workflow for this relies heavily on the Audit feature in Chrome’s dev tools, which generates a very nice report with graphs. (It simulates page load on a smartphone on a 3G network.) I compare the performance values with those from a previous step to gauge the effectiveness of each tweak I make. This time I took screenshots of the best results at each stage:
But there was a problem. The graphs in these reports are not all on the same scale. This means that though the first-paint time went down from 2.9s to 0.7s (down by 1/4th), the graph went down only by 2/5th. The actual full-paint times are not even listed. They have to be determined from screenshots. So of course I went and made some graphs of my own 🙂.
NOTE: If you’re unable to make out some of the smaller text in the images, you can click/tap on them to view full-res ones.
Results
This would be the time when I remind everyone about my previous post on website performance. It discusses in detail the optimizations talked about in this post, as well as other WordPress-specific ones.
So anyhow, here’s the first graph demonstrating the change in first-paint times and perf scores after each optimization step.
As you can see, first-paint times went down by a whopping 77%. And these are just the first-paint numbers.
The perceptual scores are even more impressive:
I had to deduce the fully loaded perceptual scores from the screenshots. This is the stage at which the site no longer appears to change. The load times here went down by 86%.
Analysis
So what did I learn from this experiment?
Even a simple single-page, static, bare-bones website can benefit from these simple performance improvement measures. And massively so. It had less than 500 words and just one image (a banner). Yet it would have taken 4 seconds to load on 3G. This was brought down to less than a second.
Also, the biggest jumps in performance seem to be CSS-related: cleanup of bootstrap.css
and animate.css
, critical CSS separation, concatenation and minification, inlining critical CSS, and making linked CSS non-blocking. This is probably because the website didn’t have many interactive elements (JS) or images. A more interactive website would have seen even bigger performance gains. Similarly, if this had been a WordPress website, we’d have seen greater relative improvement between what was available out of the box and the result after implementing these changes.
Conclusion
What Google says is the new good load time over 3G, is 3 seconds.
The average time it takes to fully load a mobile landing page is 22 seconds, according to a new analysis. Yet 53% of mobile site visitors leave a page that takes longer than three seconds to load.
— from this report by Google.
You get SEO points for being fast. A simple, single-page, static website clocks in at 4 seconds if you don’t take the steps to make it fly. Performance tuning is essential.
Credits
Banner image modified from a photo by Joshua Hoehne on Unsplash