16 ms·
The specification for native image lazy-loading is merged into HTML standard
- stevenwliao 7y agoThe first mainstream browsers with support: Chrome and Edge! https://caniuse.com/#feat=loading-lazy-attr https://caniuse.com/#feat=loading-lazy-attr
- dangoor 7y agoEdge is based on Chromium, so it's to be expected that they'll move in lockstep.
- cbhl 7y agoMakes me reminiscent of the days when Chrome and Safari were in lockstep (ish) because they were both based on Webkit. Imagine if Microsoft, Apple, and Google were all sharing the same browser engine.
- TwoBit 7y agoI don't like there being a single browser engine. At least Blink is somewhat open source.
- gjsman-1000 7y agoAnd Blink is based on WebKit, which is also open source, which is in turn based on KHTML, which is also open source. Of course, one rendering engine, it isn't great. But at least Microsoft can hopefully correct some of Google's baser impulses.
- dblohm7 7y ago> But at least Microsoft can hopefully correct some of Google's baser impulses. Good luck with that!
- loulouxiv 7y agoSVG-in-OpenType is a standard developped by Microsoft and Adobe. It was supported by every browser except Chromium, now it is not suported anymore by Edge. Do you really think Microsoft has a say on Google decisions for what should be in a browser or not ?
- loulouxiv 7y agorelated Chromium issue : https://bugs.chromium.org/p/chromium/issues/detail?id=306078 https://bugs.chromium.org/p/chromium/issues/detail?id=306078
- thrusong 7y agoHaving suffered through both browser wars and the Internet Explorer 6 era, I shudder at any meager suggestion of it.
- Dylan16807 7y agoIE6 was not releasing, which is not at all the same as getting the same features every month or two.
- floatingatoll 7y agoMicrosoft is maintaining a fork of Chromium, which they probably rebase against upstream quite often. It may seem like “lockstep” but that’s probably just because they have effective and time-efficient release processes - and employ a great deal of expertise in the field of upstream fork tracking.
- zelly 7y agoIt should happen. The web browser is not a particularly interesting problem to solve. Let's make the base layer the same and distinguish ourselves at a much higher level. It's like the JVM--would humanity really be benefited by having multiple competing implementations of the JVM? This argument may not make sense applied to an operating system/kernel. There are obvious benefits to having multiple competing operating systems. The crucial difference between a kernel and a web browser is that the kernel is a product, whereas the web (ECMA, W3C) is an international standard. So the only functional differences allowed to exist between implementations are at a very high level e.g. UX or privacy. The benefits of competing implementations are from innovation, but innovation in a way that violates the standard is not allowed, so innovation in functionality happens in the standards space. Where does innovation matter? In performance. Who can implement the standard with the best performance? It makes sense to have competition only up to such a point where a winner becomes 10x better than its competition. After that point it becomes useless to bet on the losers (save for extreme niches like lynx). There wouldn't be enough reward to heroically save the tied-for-last-place losers in a winner-take-all game. It has to happen eventually. I think it would be quite sad to have flying cars on Mars and still have people working on rendering HTML.
- thayne 7y ago> This argument may not make sense applied to an operating system/kernel. I don't follow your reasoning. If competing implementations makes sense for operating systems, wouldn't it also make sense for browsers, which are basically the equivalent of an operating system for web apps? Conversely, if there should only be one implementation of a browser, wouldn't it make even more sense for there to be only one implementation of the operating system, so there is only one platform for native applications to target? > whereas the web (ECMA, W3C) is an international standard. So the only functional differences allowed to exist between implementations are at a very high level e.g. UX or privacy. The benefits of competing implementations are from innovation, but innovation in a way that violates the standard is not allowed, so innovation in functionality happens in the standards space. Where does innovation matter? I think you might be a little bit confused about how web standardization happens. Browsers are very much allowed to innovate beyond what is specified in standards. And in fact most standards are based on features that at least one browser has already implemented. Innovation drives standards, not the other way around. After Internet Explorer won the last browser wars, both the winning implementation (IE6) and the web standards stagnated, until competition (in the form of Firefox and more importantly Chrome) came along. I don't want that to happen again. Maybe it will be different with Chrome as the winner since for Google uses the browser as a platform to deploy its own web apps, but it still means the direction of browser development is primarily decided on by Google, and will meet Google's needs, which may or may not be the needs of the internet community as a whole.
- Mattwmaster58 7y agoI could be reading this wrong, but it looks like Firefox Nightly will receive this capability in the next build, and Firefox stable will receive the upgrade in version 75: https://bugzilla.mozilla.org/show_bug.cgi?id=1542784 https://bugzilla.mozilla.org/show_bug.cgi?id=1542784
- amanzi 7y agoLazy loading can be frustrating when the connection between the website and your browser is slow. I come across this from time to time and the result is that every time you scroll down, you have to wait ages for the next set of images to load.
- scarejunba 7y agoBut that's why it's so important that it be part of the HTML spec. Previously, it would have to be implemented in Javascript. Now, you could configure your User Agent to ignore the attribute and eager load. That way you get the behaviour of always-load and the rest of us get fast loading pages. This is a Pareto move.
- taeric 7y agoDo we really expect people will be configuring their User Agent to ignore this attribute? Seems, wishful thinking.
- scarejunba 7y agoIf they're annoyed they'll go on the Internet and find out how to do it. Defaults should be useful to the many, and the few can reconfigure their UA. Think about all the use-cases you could build. Maybe you could later set "I'm on a metered connection" at the OS level, have your browser pick that up, and not overuse your metered connection, etc. etc. Maybe you could have that in a browser extension that you manually toggle. No, this is far too useful.
- taeric 7y agoI'm still skeptical. Is there any precedent for similar features that are used today? Closest I can think of is turning off JavaScript. Which this seems made to combat, honestly. And, honestly, I doubt that has penetration worth talking about. And again, just don't put so many giant graphics on a page. Problem mostly solved. With less tech and likely faster results.
- est 7y agoSo this means better user tracking capabilities are now native, even with Javascript disabled. You can learn what the user have read on the page before, and deliver more relevant ads next.
- manigandham 7y agoI'm an adtech veteran and I guarantee this kind of tracking is never used. Just because you have a signal available doesn't mean it's used or even useful for ads.
- taeric 7y agoThe cynic in me thinks if it was never used and that is useless, it wouldn't have been added as a feature. Because, I already feel that lazy loading should be rarely used and is itself mostly useless.
- manigandham 7y agoLazy loading is just another feature to improve performance, and browsers already used heuristics to load assets with prioritization by what would render first. Also in the last 5 years, every browser has added more functionality to block ads and tracking. Lazy loading is not going to somehow make up for that.
- taeric 7y agoHow does it improve performance? It is literally more work for the machine to (mis)manage. And most browsers already have viewport heuristics, no? What makes this more likely to succeed?
- manigandham 7y agoBy not loading images at all until you get to it instead of guessing if you will. It's already done by some websites using javascript. More work in milliseconds of CPU time is a worthwhile tradeoff for network bandwidth.
- toastal 7y agohttps://bugzilla.mozilla.org/show_bug.cgi?id=1542784 https://bugzilla.mozilla.org/show_bug.cgi?id=1542784 The bug is already closed in Firefox. Hopefully it'll be here soon.
- clementmas 7y agoThat's great news. Thanks for the link
- toastal 7y agodom.image-lazy-loading.enabled = true is the about:config flag
- coderheed 7y agoIt seems like this is bound to have security holes at least for a while, right?
- thewarpaint 7y agoCan you elaborate on what makes you think so?
- coderheed 7y agoOops, I just misunderstood.
- tgv 7y agoI can't see how. Perhaps it makes it easier for the page owner to track how far down a user has scrolled.
- Waterluvian 7y agoNow that this is in the spec we just need browsers to implement it and then I can make a "shaking your phone loads things faster" plugin. People will notice a slight difference just often enough where eager loading worked out better. They'll waggle their phones all the time. It's going to look hilarious.
- adventured 7y agoA fitting tribute to shaking your mouse in olden times to speed up page loading.
- nojvek 7y agoYeah back in the day UI was very single threaded. Moving the mouse faster meant more processing time for UI since it had priority and faster the experience.
- buboard 7y agohttps://www.extremetech.com/computing/294907-why-moving-the-mouse-in-windows-95-made-the-os-faster https://www.extremetech.com/computing/294907-why-moving-the-...
- Wowfunhappy 7y agoThis is exciting, because the sooner developers standardize on single method of lazy-loading, the sooner I'll be able to disable it with a userscript.
- gnull 7y agoI hope browser developers themselves will add an option to disable it.
- stkdump 7y agoExcept expect polyfills!
- naniwaduni 7y agoLazy loading seems like something that doesn't need a polyfill--the fallback behaviour is that it just works correctly... (This is not to say not to expect the polyfills, though)
- stkdump 7y agoIf lazy load isn't needed, then there is no need to apply it in the first place.
- Wowfunhappy 7y agoBut a lazy load is never truly needed, right? It's a way to save bandwidth.
- stkdump 7y agoWell, if saving bandwidth is valid a concern, then why isn't it also true for the polyfill?
- baybal2 7y agoI remember there was a huge protest from the ad industry over that. This is the time we live in now, web standards are set by the ad industry
- Cthulhu_ 7y agoGoogle is the ad industry, so your point is valid. Also the ad industry basically pays the majority of stuff on the internet. It makes sense that they get a say in the matter.
- baybal2 7y agoIt makes no sense whatsoever, they are free to discontinue chrome at any moment
- woodrowbarlow 7y agothe ad industry doesn't pay for shit. they extract value from users and give (some of) it to creators. the users (involuntarily) pay. so if the argument is "whoever pays for it gets a say" -- we do. ads don't.
- buro9 7y agoIf you are going to use this, keep in mind the advice given... set the height and width attributes of the image to prevent the page jumping around for lazily loaded images. Which means, if you accept user generated content or images from any CMS or other source you really should be obtaining the image dimensions and using them in the HTML.
- mrspuratic 7y agoThis. It's bad enough already, pages can jump around many times if you start scrolling before they're "done" (which is hard to tell nowadays anyway). News site main pages tend to be the worst. Clicking through to a different article because the page re-rendered under my finger really gets my dander up.
- StavrosK 7y agoIsn't that a thing of the past, with scroll anchoring being a feature of most major browsers?
- gmueckl 7y agoSadly, no. I experience many pages jumokng around wildly. Most often, the culprit seems to be ads that arrive late. Sometimes, it seems like pages are only requesting them when their intended position scrolls into view, so they pop up in the middle of the screen. So the browser must move either the upper half up or the lower half down to make space.
- entropicdrifter 7y agoIt's pretty depressing that so many otherwise modern UIs are totally broken whenever you're not using an ad-blocker
- cptskippy 7y agoI installed NoScript recently and was actually surprised by how many sites actually load low resolution placeholders and then swap them out with high res versions via Javascript. I'm assuming to avoid this jumping around.
- martin_a 7y agoWhile I think lazy loading is great in itself, I wonder why we haven't come up with something better before. There is progressive loading embedded directly into JPEG and if browsers would prioritize loading of assets through the DOM (order), we wouldn't need any other solutions. Or am I wrong here?
- chiefalchemist 7y agoLazy loading is helpful but if the img tags' sizes attribute is mucked up then less is gained. That is for example, due to the sizes the browser is led to believe it needs an image that's 100vw when the actual width is 25vw. This happen quite a bit with WordPress. Here's a great article on sizes and srcset. https://ericportis.com/posts/2014/srcset-sizes/ https://ericportis.com/posts/2014/srcset-sizes/ Editorial: Personally, my fear (based on history) is this will ultimately lead to more bloat, not less. The belief in "oh not to worry, we've got lazy load" is not a positive overall. LL is a good thing. But it will likely increase abuse, not mitigate it.
- goblin89 7y agoI wish browser vendors, instead of native lazy loading for images, focused on a universal mechanism to lazily render arbitrary elements, including custom ones. Browsers could profile how long rendering a particular type of element takes on a given website, and optimize render triggers to provide seamless experience while conserving bandwidth. Currently lazily rendering custom elements requires a fair chunk of IntersectionObserver boilerplate code, and beyond that any adaptability to user connection seems too complex to even consider.
- andy_ppp 7y agoI think you are conflating React elements (a blob of JS) and HTML elements (er the DOM?) in the comment to the point where I find it very difficult to reason about what an answer would look like. If you replace your use of element with "blob of javascript" how would the browser separate out the "element" blobs that are "slow" from the other Javascript?
- goblin89 7y agoI mean purely custom elements, no React at all (which should not be of concern to browser vendors anyway). The metrics that would matter are similar to what we see in browser developer’s tools profilers—ones that measure the approximate time from when script execution starts until the document is rendered, or others depending on how custom element is bundled. This is with a degree of imprecision overall, of course, but similar approaches I imagine could be used to profile individual element rendering times. Edit: Tried to clarify my idea, being away from any browser developer tools at the moment myself.
- Kaiyou 7y agoI hate lazy-loading so much, since it never keeps up with my scrolling speed. So I first have to scroll down slowly and wait for everything to load, then go back to the beginning and start for real. Tried some methods to stop lazy-loading but none worked reliably.
- chrismorgan 7y agoMe too, especially when images fade from blurry messes to the real thing once it’s on screen, which I find very disconcerting (more disconcerting than I think I should find it). This is exacerbated by living in Australia, so that latency on US-hosted sites is 200–400ms, which makes it worse. I’m honestly hoping that everyone quickly adopts the lazyload attribute, just so I can turn it off in one place.
- woodrowbarlow 7y ago> Tried some methods to stop lazy-loading but none worked reliably. all the more reason to make lazy loading a part of the language standards. if every site did lazy loading the same way, you could more easily disable it.
- brianzelip 7y agoI detest hard coding image sizes. I only want to add `img { width: 100% }` and that's it.
- wackget 7y agoThen you're part of the problem. Failing to add width and height attributes to images is what makes websites jump around while loading. It's infuriating.
- ksec 7y agoStatus on Safari [1]; >Rob Buis 2020-02-13 00:04:07 PST I was waiting for the spec to land before working again on this. First step is to fix the tests: https://github.com/web-platform-tests/wpt/pull/21773 https://github.com/web-platform-tests/wpt/pull/21773 I'll incorporate them into https://bugs.webkit.org/show_bug.cgi?id=200764 https://bugs.webkit.org/show_bug.cgi?id=200764, test a bit and hopefully put it up for review soon. This is exciting. We should have all major browser supporting it within this year. Fewer Javascript required. [1] https://bugs.webkit.org/show_bug.cgi?id=196698 https://bugs.webkit.org/show_bug.cgi?id=196698