If you enable "lazy loading" in chrome://flags, your DEV browsing experience will be moderately more efficient πŸ˜„

ben profile image Ben Halpern Updated on ・1 min read

Update: Lazy loading shipped in Chrome recently

I just merged this PR, which adds loading="lazy" to a bunch of images around dev.to.

Add loading='lazy' attribute to some images #2776

What type of PR is this? (check all applicable)

  • [ ] Refactor
  • [x] Feature
  • [ ] Bug Fix
  • [ ] Documentation Update


This will get get us ready to benefit from the loading="lazy" feature when it ships in Chrome. Shouldn't cause any problems to have it live now. This will mean on pages like lists the user won't get images loaded that are way below the fold.

I figure getting this in early will only help our SEO as I'd guess Google will be looking to reward this attribute when it ships.


You can turn it on now with chrome://flags

TODO: Implement on more images and iframes.

This functionality is expected to ship with Chrome 75 in early June, but this flag will let you play with it right now.

Will this have a major affect on anything in your life? No. You probably won't notice anything. But some images will defer loading until you are close to needing themβ€”which is nice.

This was an easy change and we'll now be guaranteed to have the functionality ready the first day it ships generally.

Happy coding!


Editor guide

Would love to know if you notice a measurable difference in bandwidth since adding the change.


We'll make sure to track the difference to the extent we can. It will be a while until a substantial amount of people are actually being impacted by this.

We're probably serving a solid 3-4 TB of images/month these days and it's not getting any cheaper!


We're probably serving a solid 3-4 TB of images/month these days...

Wow, I figured you would serve a lot but that is greater than I imagined! Would love an article going into the "issues at scale" that the site faces as it grows, things like how maybe a year ago bandwidth was X with Y users compared to now. Or even like how code you thought would be fine is needing to be improved because of the scale of traffic etc.

Will do! We are lucky in this regard to have made some choices for scale early on because I was so hell-bent on performance. And perf and scaleability are highly correlated.

But scale absolutely makes changing things more of an orchestration. We can’t just flush the cache after a design change so easily. And it can be hard to account for how a new thing will work under load.

However, our scale is still pretty much chump change compared to some scale... so we’ll see about real scale in maybe a year.

But yeah, I can still write that post. πŸ˜„


Awesome! Does anyone know if/when browsers other than Chrome are going to follow suit?


I'm not sure. But since this is a pretty quiet change, I'm not too concerned about it.

Unlike Portals, which would radically affect which browsers can do what.


Can I ask if the best combination for integrate a blog using Vue.js it's using Gridsome + NetFly CMS

I want to leave WordPress and use Vue.js and I'd like to know how to have a blog without problems of indexing, or crawling, or tags...

thank you guys

PS: This is the page 89 Transfers I want to drive with traffic through the blog and I need the design to meet a number of requirements that make WordPress not the best to use.

By the way, what do you think about Contentful?


Building a blog from scratch is not a big deal nowadays. I have some experience on Gatsby, which is a lightweight, blazing fast framework, and very well documented. I would highly recommend, it works with GraphQL and React and you can wire up nearly any CMS.


Hello Adam,

I will take a look to Gatsby.

Ps: Are there templates prepared to readapt your design? Even if they are paid. I mean blog templates.

Thank you.


Have a look at Gridsome, you'll love it