A well designed web app would have a small start up bundle so the user can get something useful quickly, and then it would start prefetching and loading the rest of the bundles.
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.
Sorry, but the format made me laugh.
The main idea is that some pages use a lot of cellular data to load images that are further down the page, out of the viewport. If the user glances at the page and decides it’s not relevant and exits, then those offscreen images were just a waste of cellular data. loading=“lazy” addresses this problem by deferring the image loads until the user has scrolled the page and the image is soon to be in the viewport.
Disclosure: I write the Chrome DevTools docs
I wish there was a middle ground... detect I'm on WIFI and go ahead and load in the lazy stuff after the above the fold stuff.
/rolleyes
It make polyfills way easier, and makes it drop-dead simple to programmatically toggle lazy-loading on existing elements.
You always want to have the image loaded before you actually use it. You don't want to wait until you actually use the image. For instance in a carousel, you'll want to load the next and previous image, not just the current displayed one.
I'd much rather have a "loading order" than lazy loading. Sure, I don't want to load first the big images that I'll want to display later, but I definitely don't want them to appear while I scroll down...
There's an FAQ about carousels, too:
https://web.dev/native-lazy-loading#how-does-the-loading-att...
> How does the loading attribute work with images that are in the viewport but not immediately visible (for example, behind a carousel)? > > Only images that are below the device viewport by the calculated distance load lazily. All images above the viewport, regardless of whether they're immediately visible, load normally.
document.querySelectorAll("img[loading]").forEach(function(e){e.loading="";})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.
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?
A bool can be expected today. But why about 10 years from now? Defensive programming isn't a bad thing. Making assumptions is why we had the Y2K mess.
We're not talking about an unstable API here, we're talking about an operator.
It would be just as unreasonable to "defend" your code against `1 + 1` suddenly returning a boolean rather than a number.
Ignore the symbols and use the words. Which makes more sense to you?
"[My test] strictly equals true." or "[My test] loosely equals true."