Cloudinary Blog

Lazy Loading for Optimal Performance

By Ezequiel Bruni
Lazy Loading for Performance

Who doesn't love some striking imagery to drive your point home? Whether you're selling a product or service, trying to communicate complex ideas, or simply captivate the emotions of your users, pictures can do that. Everyone knows they work, and everyone loves them.

Well, everyone except the actual web servers. Thankfully, they have not yet gained sentience, so we don't have to worry about their feelings. Even so, there is a cost to having images take up around 70% of all bandwidth.

It costs us in terms of storage space, sure. More importantly, it cost both servers and users in terms of bandwidth and data caps.

A long time ago (in Internet Years) browser developers figured out they could load and render pages faster if they started loading more than one external resource at a time. So they did. Now, while scripts and CSS are still downloading, your browser will usually try to grab all of the images, too.

That way, in theory, it's all ready to go as soon as the CSS and JS tell the browser what to do with all of those images. Well, it's ready to go sooner, in any case.

But what if the user doesn't scroll all the way down the page? What if they never see many or most of those images? That's wasted data on both ends.

This is where we turn to lazy loading.

How this works

For the uninitiated, lazy loading is simply waiting to load the images until the user gets to them. Only the necessary images are ever loaded, saving potential gigabytes upon gigabytes of bandwidth. The more users your site has, the more you save.

Don't take it from me. Take it from Chris Coyier of CSS-Tricks fame.

On a high traffic site, say 2 million of 5 million users visit a blog post with a lot of images on it, but never scroll down. Below the fold, there is 750k of images. That’s going to save you a boatload of bandwidth (1.5 million megabytes…)

But even that is just a quote, though it comes from a pretty smart guy. If you want a real-world example, look at this post-mortem by NYStudio+107. They used lazy loading (and a few other important techniques, but we're focused on lazy loading right now) to drop from a page load time of 107.8 seconds to 2.8 seconds.

It's not a proof-of-concept either. It's a real-world site they built. Incidentally, the blog post itself uses lazy-loading, so there's another example.

Ok, that's awesome! Let's do it!

Okay, but there are a few things to think about:

  • This is only useful if you have a lot of images below the fold. If you just have a hero image and then a bunch of text... it's not worth it. Consider your content.
  • Lazy loading is not a built-in browser feature. It has to be done with JavaScript. Adding lazy loading will increase the overall complexity of any project. This will cost in terms of development time and testing.
  • Doing it wrong may result in users not seeing images at all.

Now, if you have all of that covered, and you still want to do this, here are a couple of tips:

  •  Load images just before they enter the viewport whenever possible. It won't always work, but it's the ideal.
  • Since the above tip won't always work, you're going to need to reserve space for the images. If you don't, you may see the rest of the layout jumping around, and that's never cool.
  • You can use background colors, loading animations, or even tiny image previews to let users know that something will be loading in that extra space.
  • Have a fallback solution. Always have a fallback solution.

Again, it would be better if they never saw it, but these things happen.

Tools

We would never end an article like this without telling you where to start. The library I'd recommend is called lazysizes. It supports both responsive and normal images, and can also work with other elements like iframes.

Even better, it can automatically generate the appropriate "sizes" attribute for your responsive images on the fly. So you'll never have to set those manually again.

It's designed to be fast, extendable, and play nice with other JS libraries. It's also designed to never hide content from search engines, so it shouldn't impact your SEO.

Conclusion

It's time to get lazy, people! (I couldn't resist.)

The only real downside is the JavaScript dependency. In the future, you may be able to skip the JS, once the IntersectionObserver API is implemented in all browsers. Right now, only Chrome and Opera support it fully, and out of the box.

That small issue aside, this technique could save you, and your site, a lot of data. Data is money, for both you and your users.

*This post was originally on Speckyboy.com

 

Ezequiel Bruni Ezequiel Bruni is a web/UX designer, writer, and aspiring e-sports commentator. When he's not up to his finely-chiseled ears in wire-frames and front-end code, or ranting about the same, he indulges in video games, beer, pizza, video games, fantasy novels, stand-up comedy, and video games..

 

Recent Blog Posts

Hipcamp Optimizes Images and Improves Page Load Times With Cloudinary

When creating a website that allows campers to discover great destinations, Hipcamp put a strong emphasis on featuring high-quality images that showcased the list of beautiful locations, regardless of whether users accessed the site on a desktop, tablet, or phone. Since 2015, Hipcamp has relied on Cloudinary’s image management solution to automate cropping and image optimization, enabling instant public delivery of photos, automatic tagging based on content recognition, and faster loading of webpages. In addition, Hipcamp was able to maintain the high standards it holds for the look and feel of its website.

Read more
New Image File Format: FUIF: Why Do We Need a New Image Format

In my last post, I introduced FUIF, a new, free, and universal image format I’ve created. In this post and other follow-up pieces, I will explain the why, what, and how of FUIF.

Even though JPEG is still the most widely-used image file format on the web, it has limitations, especially the subset of the format that has been implemented in browsers and that has, therefore, become the de facto standard. Because JPEG has a relatively verbose header, it cannot be used (at least not as is) for low-quality image placeholders (LQIP), for which you need a budget of a few hundred bytes. JPEG cannot encode alpha channels (transparency); it is restricted to 8 bits per channel; and its entropy coding is no longer state of the art. Also, JPEG is not fully “responsive by design.” There is no easy way to find a file’s truncation offsets and it is limited to a 1:8 downscale (the DC coefficients). If you want to use the same file for an 8K UHD display (7,680 pixels wide) and for a smart watch (320 pixels wide), 1:8 is not enough. And finally, JPEG does not work well with nonphotographic images and cannot do fully lossless compression.

Read more
 New Image File Format: FUIF:Lossy, Lossless, and Free

I've been working to create a new image format, which I'm calling FUIF, or Free Universal Image Format. That’s a rather pretentious name, I know. But I couldn’t call it the Free Lossy Image Format (FLIF) because that acronym is not available any more (see below) and FUIF can do lossless, too, so it wouldn’t be accurate either.

Read more
Optimizing Video Streaming and Delivery: Q&A with Doug Sillars

Doug Sillars, a digital nomad and a freelance mobile-performance expert, answers questions about video streaming and delivery, website optimization, and more.

Doug Sillars, a freelance mobile-performance expert and developer advocate, is a Google Developer Expert and the author of O’Reilly’s High Performance Android Apps. Given his extensive travels across the globe—from the UK to Siberia—with his wife, kids, and 11-year-old dog, Max, he has been referred to as a “digital nomad.” So far in 2018, Doug has spoken at more than 75 meetups and conferences!

Read more