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.
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.
- 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).
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.
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).
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/1691W7yFDI1FJv69N2MEtaSzp...