Making the web better one site at a time, with a focus on performance, usability & SEO
· 5 min read · RSS Feed
While I think theory is useful, often the most compelling thing you can do is look at a real-world example to see how applied best-practices pay off. So here’s an example from a project where I was called in to help optimize the page speed loading.
We were specifically targeting the low-hanging fruit of optimizing the images on the website, because they were by far the biggest gain we’d achieve. Bang for the buck, so to speak. The techniques applied were largely those described in the Creating Optimized Images in Craft CMS article.
We’ll be using the WebPageTest.org performance benchmarking website. If you’re not familiar with it, get familiar! It’s a fantastic tool for seeing exactly how a website loads in-browser. You even get to pick the location, connection speed, and browser for each analysis.
So without further ado, here’s the website waterfall from before, and then after the image optimization work (get ready to scroll, because it’s a big one). Before optimization is on the left, after optimization is on the right:
Without even looking at the details, you can visually see that the difference is massive. We went from a 107.8s load time to a 2.8s load time. What kind of sorcery is this?
Well, it’s not magic. The page has a many images on it, there’s no getting around that. But instead of loading all of the images at once, we use lazysizes to load the below the fold images lazily. That results in the initial page load being nice and responsive!
Because the website is running http2 (courtesy of ServerPilot) this makes even more of a difference: all of those images are not contending with the stream bandwidth to download at once, and they make use of the persistent TCP connection from http2 to load the images lazily as people scroll down.
We also followed the maxim from the Creating Optimized Images in Craft CMS article, and no longer display any client-uploaded images. Instead, we convert the images to a sane responsive sizes via Imager, optimize the images server-side, and convert them into progressive JPEGs optimized for the web.
This means that when the images do load, they are optimized for the device viewing the webpage, and they are as small as possible in terms of file size, so they load quickly.
We went from a Start Render time of 29.8s down to just 1.4s, and we went from Visually Complete time of 35.5s down to just 1.7s. Wow.
Tangent: Astute readers will note the F for “Cache Static Content” on the after waterfall; this is just because it’s on a staging server.
Again, it’s not magic. It’s just optimizing the images you display, as well as how and when you load them.