It sucks ass and has done for a while. Blank spaces where pictures should be, suddenly fading in a few seconds too late, pixelated pictures that later resolve, elements change height and jump around the screen as it loads. Even though the text is there, you shouldn't bother starting to read it as it's just going to jump around in a few seconds.
It's precisely the sort of shitty site that the article is complaining about.
The guardian is another terrible site that's "mobile optimised" and have the cheek to give other developers advice on how to code for mobile, even though the site is an absolute nightmare to use. They have expanding sections on the homepage. You click a story, read it, and go back and the page takes 10 seconds jumping around to sort itself out. And worse still is the shitty adverts suddenly popping in after 20 seconds and causing you to lose position I the story you're reading.
HN and its basic style are much more useable than either the BBC or the guardian mobile sites.
It's like the developers don't understand that the reason I'm there is for the text and the pictures, not for the UI. So treat them as king and load them first and never, ever move them once they're loaded.
But blank and pixellated images that get filled out later are what I'd recommend. The alternative is looking at a blank screen while your browser makes upfront HTTP requests for images, which can delay render-blocking resources like a stylesheet from loading quickly (thus seeing no text on the page until everything loads.)
I understand what you mean about if the layout changes while reading then there's little value in rendering text upfront. But the solution is to reduce layout reflow, not to go back to the bad old days where we don't optimize/defer resources.
So for example, if an image is 200px in height and is lazy-loaded, we should let the placeholder be 200px in height. If the placeholder has 0 height and then the image loads and reflows the page, that messes up the UX. Same with other elements that change page layout. (Also caching things once they are loaded, so the example you mention of hitting the back button and waiting for everything to reflow again doesn't happen.)
> So for example, if an image is 200px in height and is lazy-loaded, we should let the placeholder be 200px in height.
No, you should simply specify the size in the IMG element. People who care about this stuff have been doing this correctly for 15 years or more. Just as people have been advocating for what now has been labeled with the buzzword "responsive design" since then. People who cared told you 15 years ago that fixed-width layouts are stupid because they won't display properly on phones (among many other reasons which were more relevant back then). This has all been a solved problem for a long, long time, if only people cared. But they still don't, still piling on more complexity and more bloat in an attempt to "fix" things.
Yes, by "placeholder" I mean the IMG element that loads with an initial low-res/default "src" attribute. Then the actual, higher-bandwidth image will load by updating the "src" attribute.
No, you don't use an initial low-res/default source that you later switch; you specify the actual damned image in the source and use the width and height attributes.
That makes the end device have to download a large image, which isn't particularly optimal for bandwidth, data cap, CPU usage, and battery life. It's not as simple as one-size-fits-all, because it really doesn't.
Please follow the thread of the conversion. I'm talking about how to mitigate the page reflow issues that the posted article is talking about when lazy loading images and other resources.
Except it actually makes the problem worse, whereas the age-old solution actually solves it.
If you specify a placeholder, that placeholder still has to be loaded, and as long as it hasn't been loaded, the dimensions are unknown, leading to reflow when the placeholder has been loaded. Plus, it adds even more bandwidth usage (for the placeholder and the javascript code), more CPU/battery usage (you have to execute javascript and decode an additional image (the placeholder)). Plus, it doesn't work without JS. Lazy loading of images in JS is just a dumb idea.
If anything, that might be a sensible feature of mobile browsers, which would only have to implement it once for it to work on all sites (instead of bloating each and every website with it), which could more easily have access to information about available connectivity, and which could also do it so much more easily, as the browser's rendering engine has a lot more clue which images currently are in the viewport.
Nope. On real world websites, deferring images, fonts, and making other optimizations can reduce time-to-first paint significantly. That drives real UX and business results (imagine clicking a link and waiting for 7 seconds to see the heading on the page vs. waiting 1.5 seconds.) There's a reason all these websites practice lazy-loading and Google takes time-to-first-render seriously enough to impact search ranking.
If anything, that might be a sensible feature of mobile browsers
Sure, I would be happy if browsers introduced something like a "lazyload" attribute on images/JS/fonts etc. There is something like that for <script> tags (defer, async) but it still downloads the script ASAP. I need something that gets the text and CSS, shows it on the page, and then opens the HTTP connections for other stuff.
It sucks ass and has done for a while. Blank spaces where pictures should be, suddenly fading in a few seconds too late, pixelated pictures that later resolve, elements change height and jump around the screen as it loads. Even though the text is there, you shouldn't bother starting to read it as it's just going to jump around in a few seconds.
It's precisely the sort of shitty site that the article is complaining about.
The guardian is another terrible site that's "mobile optimised" and have the cheek to give other developers advice on how to code for mobile, even though the site is an absolute nightmare to use. They have expanding sections on the homepage. You click a story, read it, and go back and the page takes 10 seconds jumping around to sort itself out. And worse still is the shitty adverts suddenly popping in after 20 seconds and causing you to lose position I the story you're reading.
HN and its basic style are much more useable than either the BBC or the guardian mobile sites.
It's like the developers don't understand that the reason I'm there is for the text and the pictures, not for the UI. So treat them as king and load them first and never, ever move them once they're loaded.