61–69 of 69 posts
Earlier quoted context omitted.
What? As far as I know this feature is completely client-side.
I see.. but this would only make a difference for people who disabled JS, and these people can probably also disable lazy loading.
Earlier quoted context omitted.
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 onl…
Why does it download the 2kb if the image dimensions are specified?
- 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).
Earlier quoted context omitted.
You seem to be missing a few things: - data usage is correlated with battery usage, which is important on mobile - the http2 prioritization point is only half valid. Two big assumptions that probably don't hold in practice: whether the implementations actually implement priority correctly, all the way through the stack (e.g. perhaps some servers have a suboptimal implementation?), And whether having a bazillion low p…
Their own customers are using less than 15 GB per month, how much battery could they possibly save on the radio? A single video will use more radio time than days of image downloads in the browser. Furthermore, Google themselves didn't mention battery savings but just fewer bytes sent. And what delicious irony if they couldn't solve this with HTTP/2 because of servers not implementing the spec correctly or having wei…
Can you explain what you mean? Chrome does not have any customers.
> And what delicious irony if they couldn't solve this with HTTP/2 because of servers not implementing the spec correctly or having weird undocumented quirks (their reason for not enabling pipelining despite it working just fine).
How do you envison the browser to solve this when the server is not H2 capable?
Earlier quoted context omitted.
No we're talking about every website having to make this work because the default is to not require loading the resources or else be blamed for not being compliant with a spec forced on them by Google through their browser monopoly. Google should need some really good evidence to support this. What points do you disagree with, and why? Where are the metrics? If it's better performing than just priorities and flow con…
Then just don’t specify the loading=lazy tag...
Earlier quoted context omitted.
What? As far as I know this feature is completely client-side.
I see.. but this would only make a difference for people who disabled JS, and these people can probably also disable lazy loading.
Earlier quoted context omitted.
Why does it download the 2kb if the image dimensions are specified?
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).
Earlier quoted context omitted.
Why does it download the 2kb if the image dimensions are specified?
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).
Earlier quoted context omitted.
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).
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.
On Android Chrome with Data Saver turned on, elements with loading="auto" or unset will also be lazily loaded if Chrome determines them to be good candidates for lazy loading (according to heuristics). I don't agree with this design decision to make the default ("or unset...") allow for lazy loading, even if limited to Data Saver enabled phones. Doesn't this mean every site on the planet that deems Android >= 7.0 web…