Edge will pick this up going forward as it is based on Chromium.
been using the beta version for the last week or so. pretty solid, imo.
Native lazy loading has landed in Chrome
21–30 of 49 posts
Re: Native lazy loading has landed in Chrome
#22Re: Native lazy loading has landed in Chrome
#23I'm happy to see this. So many websites with lazy loading never implemented a fallback for noscript. And most of the popular libraries didn't account for this accessibility.
just curious -- in what situation would your average user not have javascript turned on?
Your average user? Almost never.
Re: Native lazy loading has landed in Chrome
#24Earlier quoted context omitted.
I think the previous poster was referring to the unnecessary `=== true` part.
It's quite common to compare against "true" using "===" in JavaScript.
I wouldn't say it's common. Most JavaScript developers (who aren't familiar with JS coercion rules or the difference between == and ===) wouldn't even be able to tell you for certain what the code does, exactly.
Using === to compare against "true" makes only sense if the variable can be something other than boolean (undefined, null, string etc). Or if you are programming defensively – by choice or because the codebase is messy.
Re: Native lazy loading has landed in Chrome
#25One watch out is that the lazy loading only grabs the first 2048 bytes. That gives you the dimensions of an image, which is a plus, but not the whole image, unless the image is tiny. That likely means more total connections. Probably fine for http/2 sites, maybe not so for non-http/2 sites. Would be interesting to see perf stats for that case.
Re: Native lazy loading has landed in Chrome
#26Good. I hate lazy loading. I hope they add an option in the browser so I can disable it globally.
Chrome? Google Chrome and options?
Hah! Good one!
Re: Native lazy loading has landed in Chrome
#27Re: Native lazy loading has landed in Chrome
#28Earlier quoted context omitted.
It's quite common to compare against "true" using "===" in JavaScript.
I wouldn't say it's common. Most JavaScript developers (who aren't familiar with JS coercion rules or the difference between == and ===) wouldn't even be able to tell you for certain what the code does, exactly. Using === to compare against "true" makes only sense if the variable can be something other than boolean (undefined, null, string etc). Or if you are programming defensively – by choice or because the codebas…
> Or if you are programming defensively – by choice or because the codebase is messy.
This accurately describes the majority of JavaScript projects I have worked on.
The last web agency I worked at even had linters checking against '=='.
See this table https://dorey.github.io/JavaScript-Equality-Table/ which displays how unsure you can end up when using '=='.
> Most JavaScript developers (who aren't familiar with JS coercion rules or the difference between == and ===)
It rings strange to me that you would believe that developers who focus on one language ("JavaScript developers") wouldn't know the quirks of that language. Not all JS devs are juniors.
I prefer to follow this rule, "never use == and != unless you need type coercion". You know that your expected results is 'true' then why not test for that only?
Re: Native lazy loading has landed in Chrome
#29Earlier quoted context omitted.
It's quite common to compare against "true" using "===" in JavaScript.
I wouldn't say it's common. Most JavaScript developers (who aren't familiar with JS coercion rules or the difference between == and ===) wouldn't even be able to tell you for certain what the code does, exactly. Using === to compare against "true" makes only sense if the variable can be something other than boolean (undefined, null, string etc). Or if you are programming defensively – by choice or because the codebas…
The `in` operator always returns a boolean, though.
Re: Native lazy loading has landed in Chrome
#30As a developer and systems architect, I really like this. As uset, I hate this so much. On slower connections, I like to load a page, swap tabs, come back later and expect the page to be loaded. This mechanism will now break (and is already brokrn by the usr of these lazy loading libs).
The article contradicts itself a little bit. It says "Currently the images are fetched with different priority in Chrome, the ones which are not in the viewport have less priority. But they're fetched as soon as possible regardless."
But it also says: "lazy: Defer loading of resources until it reaches a calculated distance from viewport."
If a lazy image is only loaded when within a distance of the viewport, then your "come back later" strategy stops working. But if instead off screen images are just bumped down in priority and still download after higher priority stuff finishes, then your strategy should still work.