3 ms·

Lazy-loading (the practice being somewhat criticized here) is actually halfway to that goal. The BBC (cited in this article) also uses a technique they call 'cu

by firasd 10y ago

Lazy-loading (the practice being somewhat criticized here) is actually halfway to that goal. The BBC (cited in this article) also uses a technique they call 'cutting the mustard', which checks which features are available on the browser to determine which JS to run. So bandwidth can be one of the things tested when doing JS-based optimization like this. I agree that CSS-based responsive design just comes up inadequate when we want real optimization. We have to use JS based methods like deferred/lazy loading, detecting features, bandwidth, etc. (With images you can also have a <noscript> tag that loads the image immediately in no-JS scenarios, but it's difficult to figure out alternatives for lazy-loaded fonts and other things.)

mattmanser 10y ago
Have you used the BBC site on a mobile? 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.
- firasd 10y ago
  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.)
  - zAy0LfpBZLC8mAC 10y ago
    > 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.
    - firasd 10y ago
      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.
      - stan_rogers 10y ago
        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.
        firasd 10y ago
        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.
        zAy0LfpBZLC8mAC 10y ago
        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.

by firasd 10y ago

mattmanser 10y ago

Have you used the BBC site on a mobile? 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.

firasd 10y ago
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.)
- zAy0LfpBZLC8mAC 10y ago
  > 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.
  - firasd 10y ago
    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.
    - stan_rogers 10y ago
      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.
      - firasd 10y ago
        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.
        zAy0LfpBZLC8mAC 10y ago
        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.