3 ms·

This feature seems to be involved. In order to layout the html page you need to know the image sizes(unless they are explicit), and for that you still need to d

This feature seems to be involved. In order to layout the html page you need to know the image sizes(unless they are explicit), and for that you still need to download the image header, and the headers are of different sizes for different returned image formats. And some images change when you load them second time. So it seems the only way to correctly implement that is to open a connection to load an image and stall it after receiving the content-type and appropriate image header and hope that the server will not close the hanging connection(?) PS: Seems that chrome will download the first 2K if byte-ranges are supported. If there is no dimensions in the first 2kb or byte-ranges are not supported, the full image will be downloaded non-lazily https://docs.google.com/document/d/1691W7yFDI1FJv69N2MEtaSzpnqO2EqkgGD3T0O-pQ08/edit# https://docs.google.com/document/d/1691W7yFDI1FJv69N2MEtaSzp...

deleted 8y ago
[deleted]
mdale 8y ago
Not really .. you can just have the page / content duration bounce around a bit as you scroll down in rare cases where image size is dictating layout :/ .. we see that pretty frequently in post page display ad fill pushing thing around ( and in some cases ads loading when you scroll )
gkoberger 8y ago
There's a link explaining how it's done! It tries things in this order: 1. If the full image is present and fresh in the cache, then use that. 2. Otherwise, if the server supports range requests, and the image dimensions can be decoded from the first 2KB of the image, then generate and show an image placeholder with the same dimensions. 3. Otherwise, fetch the entire full image from the server as usual. So, it'll only lazy-load images if it's in the cache or certain criteria is met. Also, it seems like it's opt-in using an attribute, so the implementer of the website can avoid it if they're worried. But overall, there won't be any reflow issues. https://docs.google.com/document/d/1691W7yFDI1FJv69N2MEtaSzpnqO2EqkgGD3T0O-pQ08/edit# https://docs.google.com/document/d/1691W7yFDI1FJv69N2MEtaSzp...
- floatingatoll 8y ago
  They note that Android battery saver may enable this by default unless the HTML specifically says otherwise. (Search for “or unset”.) Once they have enough data, perhaps in a year or two, it is likely they’ll extend that to all platforms for memory and battery life savings.
- ec109685 8y ago
  Why does it download the 2kb if the image dimensions are specified?
  - pilif 8y ago
    the spec says "[…] the image dimensions can be decoded from the first 2KB of the image". It doesn't say anything about when the dimensions are known and I would assume it's using those in that case. However, loading 2KB of an image is enough for most image formats to determine the dimensions even if they aren't specified in the hosting document (because most image formats contain a header specifying dimensions).
  - zamadatix 8y ago
    The doc states 2 reasons: - If the image is fits in 2kb (icons/ui elements) then they can just do a full decode and not have to lazy load these ui items as the page scrolls. - It allows them to load low resolution versions of progressive image formats rather than stick up a generic placeholder (marked as a future improvement right now).
    - deleted 8y ago
      [deleted]
    - ec109685 8y ago
      For your first point, reading the specified dimensions from the page would be sufficient to tell the browser whether it's a small image to skip lazy loading.
      - 8y ago
Theodores 8y ago
Well, if you want to implement it optimally then you need to be doing srcsets and the easiest way to do them is to put the img width and height in the tag. Then run mod_pagespeed to tidy up the html. It then creates the srceset images. It will not be a solution to everyone's taste but it abstracts out the srcset bit to the server so you can have clean markup. If you are caching your pages at some level then it isn't going to be looking up image dimensions too often. Plus looking up image dimensions server side is a simple ask, no network needed. I am going with the explicit image dimensions, srcsets and no lazy loading, which happens to be a feature of mod_pagespeed. With figure elements or picture elements for the content images, populated with the srcsets, I see this new browser side lazyload as the missing feature needed to preserve document structure, not have any javascript cludges and serve images in a way that respects data saving and viewport size. Time to add the new 'lazy' attribute. Firefox and Safari users might not benefit yet but this is no need to wait.

deleted 8y ago

[deleted]

mdale 8y ago

Not really .. you can just have the page / content duration bounce around a bit as you scroll down in rare cases where image size is dictating layout :/ .. we see that pretty frequently in post page display ad fill pushing thing around ( and in some cases ads loading when you scroll )

gkoberger 8y ago

There's a link explaining how it's done! It tries things in this order: 1. If the full image is present and fresh in the cache, then use that. 2. Otherwise, if the server supports range requests, and the image dimensions can be decoded from the first 2KB of the image, then generate and show an image placeholder with the same dimensions. 3. Otherwise, fetch the entire full image from the server as usual. So, it'll only lazy-load images if it's in the cache or certain criteria is met. Also, it seems like it's opt-in using an attribute, so the implementer of the website can avoid it if they're worried. But overall, there won't be any reflow issues. https://docs.google.com/document/d/1691W7yFDI1FJv69N2MEtaSzpnqO2EqkgGD3T0O-pQ08/edit# https://docs.google.com/document/d/1691W7yFDI1FJv69N2MEtaSzp...

floatingatoll 8y ago
They note that Android battery saver may enable this by default unless the HTML specifically says otherwise. (Search for “or unset”.) Once they have enough data, perhaps in a year or two, it is likely they’ll extend that to all platforms for memory and battery life savings.
ec109685 8y ago
Why does it download the 2kb if the image dimensions are specified?
- pilif 8y ago
  the spec says "[…] the image dimensions can be decoded from the first 2KB of the image". It doesn't say anything about when the dimensions are known and I would assume it's using those in that case. However, loading 2KB of an image is enough for most image formats to determine the dimensions even if they aren't specified in the hosting document (because most image formats contain a header specifying dimensions).
- zamadatix 8y ago
  The doc states 2 reasons: - If the image is fits in 2kb (icons/ui elements) then they can just do a full decode and not have to lazy load these ui items as the page scrolls. - It allows them to load low resolution versions of progressive image formats rather than stick up a generic placeholder (marked as a future improvement right now).
  - deleted 8y ago
    [deleted]
  - ec109685 8y ago
    For your first point, reading the specified dimensions from the page would be sufficient to tell the browser whether it's a small image to skip lazy loading.
    - 8y ago

Theodores 8y ago

Well, if you want to implement it optimally then you need to be doing srcsets and the easiest way to do them is to put the img width and height in the tag. Then run mod_pagespeed to tidy up the html. It then creates the srceset images. It will not be a solution to everyone's taste but it abstracts out the srcset bit to the server so you can have clean markup. If you are caching your pages at some level then it isn't going to be looking up image dimensions too often. Plus looking up image dimensions server side is a simple ask, no network needed. I am going with the explicit image dimensions, srcsets and no lazy loading, which happens to be a feature of mod_pagespeed. With figure elements or picture elements for the content images, populated with the srcsets, I see this new browser side lazyload as the missing feature needed to preserve document structure, not have any javascript cludges and serve images in a way that respects data saving and viewport size. Time to add the new 'lazy' attribute. Firefox and Safari users might not benefit yet but this is no need to wait.