How does HTTP compression factor into image optimization? Is it possible to optimize an image but the HTTP compressed size ends up being greater?
You should release a monthly report with this same algorithm. You should also put in a column for competitors algorithm (not the just ones you beat, all of them).
Don't forget that some images are loaded after the page and content load, so they have very little impact on user experience (and all these sites make heavy use of CDNs).
That obnoxious spinner is used for Mr. Tinkles, the Asshole Of Notification. Because even after Mr. Tinkles starts ringing out, he has no idea what to say. So when you click on him to make him shut the hell up, he still hasn't loaded the hundred bytes of your notification, and you have to look at that stupid spinner while all of Google's horrifying social storage infrastructure lurches into action. And because Mr. Tinkles is part of Google's all-in Social Death Pact, you have to load that image on every Google property: Gmail, Maps, Drive, Search, everything.
At first I assumed Google's reduction was so high because they'd scraped the site on a day when the logo was a doodle. But I just manually checked Google's main logo and was surprised to see a 40% lossless reduction. I would assume they dogfood PageSpeed (or at least use some internal version of it) which does image optimisation automatically for them. So is Kraken just better or is it just an oversight from Google?
There might be a browser support issue that prevents doing it.
The bandwidth and mobile loading might not be an issue because of their massive amount of data-centers to serve content from.
It seems like it to would be easy to test the new image to see if anyone reports any issues, but there might just not be any benefits to reducing the homepage image by 40%. Make sure you consider that the homepage image is being scaled smaller than the actually image is, some optimizers take this into account and will give you a scaled image.
I don't know much about the technical side of things, but as someone studying SEO and UX this seems like a huge win. Not only by cutting down on page load size / speed but so much better fo rUX.
> I don't know much about the technical side of things, but as someone studying SEO and UX.
I felt a great disturbance in the Force, as if millions of developers suddenly cried out in terror...
Joking aside it is usually a win to reduce page load sizes from a speed and bandwidth point of view (which on a heavily tracked site can add significantly to costs) occasionally you have to be careful as some of the compression methods result in non-standard or "technically standard but the client doesn't really do it that way" files which can render corrupted or more slowly.
How does HTTP compression factor into image optimization? Is it possible to optimize an image but the HTTP compressed size ends up being greater?
You should release a monthly report with this same algorithm. You should also put in a column for competitors algorithm (not the just ones you beat, all of them).
Don't forget that some images are loaded after the page and content load, so they have very little impact on user experience (and all these sites make heavy use of CDNs).