Post-Mortem: Applied Image Optimization

While I think the­o­ry is use­ful, often the most com­pelling thing you can do is look at a real-world exam­ple to see how applied best-prac­tices pay off. So here’s an exam­ple from a project where I was called in to help opti­mize the page speed loading.

We were specif­i­cal­ly tar­get­ing the low-hang­ing fruit of opti­miz­ing the images on the web­site, because they were by far the biggest gain we’d achieve. Bang for the buck, so to speak. The tech­niques applied were large­ly those described in the Cre­at­ing Opti­mized Images in Craft CMS article.

We’ll be using the Web​PageTest​.org per­for­mance bench­mark­ing web­site. If you’re not famil­iar with it, get famil­iar! It’s a fan­tas­tic tool for see­ing exact­ly how a web­site loads in-brows­er. You even get to pick the loca­tion, con­nec­tion speed, and brows­er for each analysis.

So with­out fur­ther ado, here’s the web­site water­fall from before, and then after the image opti­miza­tion work (get ready to scroll, because it’s a big one). Before opti­miza­tion is on the left, after opti­miza­tion is on the right:

With­out even look­ing at the details, you can visu­al­ly see that the dif­fer­ence is mas­sive. We went from a 107.8s load time to a 2.8s load time. What kind of sor­cery is this?

Well, it’s not mag­ic. The page has a many images on it, there’s no get­ting around that. But instead of load­ing all of the images at once, we use lazy­sizes to load the below the fold images lazi­ly. That results in the ini­tial page load being nice and responsive!

Because the web­site is run­ning http2 (cour­tesy of Server­Pi­lot) this makes even more of a dif­fer­ence: all of those images are not con­tend­ing with the stream band­width to down­load at once, and they make use of the per­sis­tent TCP con­nec­tion from http2 to load the images lazi­ly as peo­ple scroll down.

We also fol­lowed the max­im from the Cre­at­ing Opti­mized Images in Craft CMS arti­cle, and no longer dis­play any client-uploaded images. Instead, we con­vert the images to a sane respon­sive sizes via Imager, opti­mize the images serv­er-side, and con­vert them into pro­gres­sive JPEGs opti­mized for the web.

This means that when the images do load, they are opti­mized for the device view­ing the web­page, and they are as small as pos­si­ble in terms of file size, so they load quickly.

We went from a Start Ren­der time of 29.8s down to just 1.4s, and we went from Visu­al­ly Com­plete time of 35.5s down to just 1.7s. Wow.

Tan­gent: Astute read­ers will note the F for ​“Cache Sta­t­ic Con­tent” on the after water­fall; this is just because it’s on a stag­ing server.

Again, it’s not magic. It’s just optimizing the images you display, as well as how and when you load them.

Obvi­ous­ly, this is an extreme exam­ple, but it is a real-world project. These things real­ly do make a qual­i­ta­tive dif­fer­ence, so go forth and opti­mize!