Chrome to get lazy load below-the-fold images and iframes

  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 traffic important and makes use of pixel-based or iframe-enclosed tracking will have to go through testing and potential modification?

I've had the idea of doing a similar thing in application code for XHRs. For example, if you have a React app and you structure your code so that components declare their own data dependencies, then you can have a framework-level solution where you measure component positions on mount and give priority to data fetching for components above the fold.

I never actually implemented it, though, just seemed like a nice idea. Anyone know if existing data fetching frameworks (e.g. Apollo Client) can do anything like that?

The new attribute’s value names look poorly chosen. “Lazy” and “eager”. Why don’t they use existing vocabulary like “deferred“ for lazy, and a new, equally professional word for eager.

"lazy" and "eager" are the pre-existing widely used terms for this.

Why they say they are pushing this:

* "Speed up the load of above-the-fold content, since there will be less competition for network resources during the initial page load"

Why don't they just set a low priority for offscreen images and resources? Isn't this the entire premise for HTTP/2, that multiplexing with priorities and flow control would load the important data first? Do servers not implement the spec correctly? So this reason is BS as the data saved is immaterial.

* "Reduce memory usage."

Even commodity phones come with several gigabytes of RAM, the memory may have to be used anyway if the user scrolls, and if you have unlimited scroll or massive scroll something will need to unload data anyway. So this reason is marginal at best.

* "Save network data by avoiding downloading any deferred content that the user doesn't end up scrolling to"

Most phone plans are unlimited or have data capable of watching movies. On Google's own Fi plan "less than 1% of individual Fi users ... use above 15 GB". So this is another BS reason as the data saved is immaterial.

So why are they actually pushing this?

Under "privacy considerations": "so slightly more information about the user's scrolling position on the embedding page is exposed" and "a deferred cross-origin image gets an additional piece of information about the user's scrolling position".

This is not hard to figure out - they are barely even trying to hide it. Same thing as pushing HTTP/2, which I contend was at least partly to track people using socket IP:port address (for instance by keeping a single connection to google-analytics open that all domains' data goes through and boosting the connection keep alive from a few minutes to like half an hour, which they did).