11–20 of 69 posts
How is this only now getting implemented? I’m very surprised. Also, do we yet unload images (from memory) after a user scrolls far past them? I’m always surprised how slow “long” webpages become.
Last time I looked, the answer was no for images but yes for background images. I implemented a lazy-loader which did the latter for a pretty significant measured improvement on gallery pages.
The downside of this is that it assumes that I am always online, and I can never know if a page has finished loading. Say I load an article in a background tab to read later, then go somewhere without WiFi like, say, an airplane. I read the first page, hit the space bar, and see gray boxes. Now I need to either scroll all the way through any article I want to read later (unless "infinite scroll" happens), or save it…
The downside of this is that it assumes that I am always online, and I can never know if a page has finished loading. Say I load an article in a background tab to read later, then go somewhere without WiFi like, say, an airplane. I read the first page, hit the space bar, and see gray boxes. Now I need to either scroll all the way through any article I want to read later (unless "infinite scroll" happens), or save it…
Tons of web pages (especially e-commerce sites where initial visible page load time is critical) already do this, just with more complicated code.
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 stal…
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…
How will this affect analytics with tracking pixels, etc?
I would be curious if this would also be apply to email clients that render using Chrome.
The downside of this is that it assumes that I am always online, and I can never know if a page has finished loading. Say I load an article in a background tab to read later, then go somewhere without WiFi like, say, an airplane. I read the first page, hit the space bar, and see gray boxes. Now I need to either scroll all the way through any article I want to read later (unless "infinite scroll" happens), or save it…
Earlier quoted context omitted.
Tons of web pages (especially e-commerce sites where initial visible page load time is critical) already do this, just with more complicated code.
And mobile browsers randomly purge and reload pages when they're low on memory, and news sites do lazy image loading with miscellaneous Javascript. It all sucks, and it's too bad that Google wants to (i.e. will) "make it official."
Thanks, I'll take Google's solution.