Hacker News new | past | comments | ask | show | jobs | submit login

As 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).



Hmm, maybe if websites don't use lazy loading JavaScript anymore (guilty as charged btw) then you'll be able to configure it however you want in browser settings?


I imagine anti-lazyloading extensions will start appearing soon.


And that's exactly why common API for lazyloading is awesome. It's a PITA to write such extension when everybody is using custom approaches for lazyloading. Once there's a common API, there will be a common approach to override it.


whole extension:

    document.querySelectorAll("img[loading]").forEach(function(e){e.loading="";})


Lazy loading doesn’t have to mean waiting for user input to load a resource, or waiting for the viewport. It just gives the developer a way to break up their bundles and control over when they get loaded a fetched.

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.


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.


I think the first is what happened before this new feature (lazy loading) was implemented.


Ah yes, of course. Thanks.


> As a user, ... I like to ... and expect ...

Sorry, but the format made me laugh.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: