I’ve spent a few days last week in Stockholm attending the HTTP Workshop, and taken part in many fascinating discussions. One of them revolved around HTTP push, its advantages, disadvantages and the results we see from early experiments on that front. The general attitude towards push was skeptical, due to the not-so-great results presented from early deployments, so I’d like to share my slightly-more-optimistic opinion. What can push do that preload can’t A recurring theme from the skeptics was “push is only saving 1 RTT in comparison to preload”.
There have been a lot of talk recently about the Network Info API. Paul Kinlan published an article about using Service Worker along with the Network Info API to send network information up to the server and let the server adapt its responses to these network info bits. There is also an intent to implement the downlinkMax attribute in the Blink rendering engine. Since I have Opinions™ on the matter, and Twitter and mailing lists aren’t always the ideal medium, I wrote them down here.
The Web platform is a wonderful thing. Its reach is unparalleled in human history. It enables people all over the world to access vital information, education and entertainment. People old and young, rich and poor. It makes their lives better than they would have been without it. It also enables commerce, banking, and improved supply chains. The world’s economy would have been very different without the Web platform. The Web platform has over 3 billion users and that number keeps climbing.
Mozilla have recently announced that they are planning to deprecate insecure-HTTP, which includes denying new features from sites that are served over HTTP connections. I believe that is a mistake. I tweeted about it, but a longer form is in order, so here goes. Why HTTPS everywhere is important Let me start by saying that I strongly believe that the Web should move to HTTPS, and serving content over plain-text HTTP is a mistake.
I owe you fine folks a blog post. I recently tidied up my blog and moved it to a new backend and in the process realized that I haven’t blogged in over 18 months. (!!!) Where did I disappear? A lot have happened during that time: The markup based responsive images solutions, which seemed to be facing a dead-end in September 2013, were revived and significantly improved. In order to defuse initial resistance from the Blink project, I started implementing required infrastructure in order to implement the features there.
It’s been a year since I last wrote about it, but the dream of the “magical image format” that will solve world hunger and/or the responsive images problem (whichever one comes first) lives on. A few weeks back I started wondering if such an image format can be used to solve both the art-direction and resolution-switching use-cases. I had a few ideas on how this can be done, so I created a prototype to prove that it’s feasible.
For the impatient Sizer-Soze is a utility that enables you to evaluate how much you could save by properly resizing your images to match their display size on various viewports. Basically it shows you how much image data you could save if you deployed an ideal responsive images solution. If you already have a responsive images solution in place, it enables you to see how far it is from that ideal, and improve it accordingly.
For a while now, the art-direction use-case have been treated by browser vendors as resolution-switching’s imaginary friend. When talking to people who work for browser vendors about that use-case, I’ve heard phrases like “that’s a really obscure use-case” and “No one is really doing art-direction”. This got me wondering — how big is that use-case? How many Web developers & designers are willing to go the extra mile, optimize their images (from a UI perspective), and adapt them so that they’d be a perfect fit to the layout they’re in?
I just read Jason Grigsby’s post, and tried to answer it in the comments, but saw that my response passed the limits of a reasonable comment. So here I am. This post is a proposal for a file structure that will enable browsers to fetch images encoded using a responsive image format. But which format? Regardless of the image format that will eventually be used, a large part of the problem is coming up with a way to download only the required parts of the responsive image, without downloading unneeded image data and without reseting the TCP connection.
Summary for the impatient Lossless compression with current formats can reduce image size on the web by 12.5%. PNG24 with an Alpha channel comprise 14% of images on the web. We can cut their size by 80% using WebP. Savings from lossless optimization can save 1.5% of overall Internet traffic!* Savings from conversion of PNG24 with an alpha channel to WebP can save 2.1% of overall Internet traffic!!! That’s 2.8 Tbps!!!
Can't be done? All along the responsive images debate, there were several people that claimed that the salvation will come in the form of a new image format that will enable images that are automagically responsive. My response to these claims was always that it can't be done. It can't be done since the browser needs to download the image in order for it to analyze which parts of the image it needs.
TL;DR Spoiler: If you have inline scripts that must be inside your page, adding an empty <div> before all stylesheet links will avoid a CSS bottleneck!!! Do we really need Async CSS? I've stumbled upon a post by Guy Podjarny called Eliminating the CSS bottleneck which talks about using async stylesheets in order to avoid external stylesheets from blocking the download of other resources. What bothered me about the entire post is that according to BrowserScope this issue is non existent in all modern browsers.
Responsive Images and cookies Jason Grigsby wrote a great post summarizing different approaches to responsive images and what sucks about them. Among other things, he discussed the problem of getting the first page load right. After a short discussion with him on Twitter, I decided to take a deeper look into the Filament group's cookie based method. Tests Testing their demo site using Firefox showed that the first browse brings in the smaller "mobile" image.
TL;DR Adding a media attribute that supports queries to the base tag is all that's required to have responsive images with no performance penalty. The thread After my last post Nicolas Gallagher pointed me towards a mail thread on html-public mailing list that discusses appropriate solutions to the responsive images problem.* There were a few suggested solutions there: Each image tag will have child source tags with a media attribute in each A new "image" format that will deliver the browser the real image URLs according to dimensions.