From 2.4 MB down to 400 KB

It’s been fairly well documented that the average size of webpages has been growing by leaps and bounds, with images making up the majority of the size. Based on my own stats for 160+ HigherEd responsive sites, images account for 73% of the total download. And when you’re dealing with a long-form page like, images can account for even more (92% to be exact). In a situation like this, finding ways to cut down on the number of images, or deferring the loading of images, can result in a huge impact on not just the download size, but load-time as well. was built (good or ill) with three major breakpoints in mind: mobile, tablet, and desktop. We did this so we could really focus during our two month deadline on optimizing for our mobile users. So from day one, our mobile payload has been pretty light:

  • 260 KB
  • 25 Requests (13 Images)

The Problem

In the year and a half since we launched this version of, we had limited time to optimize as much as we’d like. Initially we focused on the two carousels at the top, only loading the front-most image and delaying the rest until the user chose to interact with them. But that still left us with a lot of content images. So when the time came to really get into optimizing, we were working from the following baseline for our desktop size:

  • 2.4 MB
  • 132 requests (117 images)

Potential Areas to Optimize

We’ve made a habit of tracking everything on our sites using Google Analytics Event Tracking. Because of this, we know how many of our visitors were seeing which images. So if we start at the top of the page and start scrolling down, naturally visitors start dropping off.

News and Events


24 images (646.5 KB total) viewed by 21.4% of visitors



6 images (208.3 KB total) viewed by 8.9% of visitors



14 images (406.9 KB total) viewed by 6.5% of visitors



4 images (140 KB total) viewed by 4.1% of visitors

Faith & Service

Faith & Service

9 images (328.1 KB total) viewed by 3.5% of visitors

Tour Flyout


Now heading all the way back to the top of the page to the feature location sidebar (click on “Learn More” below the location name in the top right).

26 images (169 KB total) viewed by 0.25% of visitors

The Solution

So obviously we need to lazy-load these images instead of penalizing so many users that never see them. We ended up using base64 encoded gray inline images. We did this because it was fairly easy for us to switch to them and get the added benefit that the replacements are the exact same size as the actual image, and they’ll behave exactly like the image they’re replacing. This is important because of the way clicking on a top-level nav item scrolls a user quickly down the page. If the placeholders weren’t exactly the same dimensions, then as we replaced the placeholders with the real images, our content would shift and users wouldn’t end up in the right spot. For those concerned about users with javascript turned off, we have the real images linked in noscript tags, so they get images, but not the optimization.

The Results

As you may recall from above, we started with 132 requests and 2.4 MB. We also had a loadtime that averaged 4.9s and a WebPagetest score that looked like this: Pre-optimization webpage test of C A A B F B

After the optimization, we were down to 39 requests and 364 KB (changes by the day). The loadtime also dropped to an average of 1.8s. Additionally, our WebPagetest score improved to this: Post-optimization webpage test of A A A A A A

Wrapping Up

Natually, if a user decides to scroll all the way down the homepage, as well as interact with every section of the page, they’ll still end up with the full payload. But for those that don’t, they get a much improved experience. Our next step is to update our lazy-loading script to better handle mobile images. Currently we’re passing most of them through a server-side image optimization service by Sencha. Similar services include imgble and

If you’re interested in trying your hand at lazy-loading images, here’s a handy case study on Smashing Magazine by Anders Andersen and Tobias Järlund. You may also want to check out this post by the BBC News developers on how they handle images.

Good luck and happy optimization.

NOTE: The total size on depends a lot on the primary feature image. Since this article was originally posted, we updated to a new image that refuses to compress well, which is resulting in larger than 400 KB total download size. So as that image changes, so will these results.