3 ms·

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 up

by 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.
    - firasd 10y ago
      Except it actually makes the problem worse 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.
- Twirrim 10y ago
  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.

by 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.
  - firasd 10y ago
    Except it actually makes the problem worse 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.
Twirrim 10y ago
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.