Still waiting for pipe-lining to become mainstream

Sometimes I get a bit upset about a state a project I get to work on is in. Recently I came across a project which frontend served over 30 files that could be reduced easily to about 10. I got upset because to me it is like one of the basic things you have to be aware of as a web developer. I told the others working on the project that is a problem that should be fixed, to optimize speed. But later that day, in bed, I started wondering because the pages were served using HTTPS: was I actually correctin stating it as a problem? Well, currently still yes.

I started wondering because I remembered something about ‘pipe-lining’. A year ago I turned on the experimental SPDY protocol a year ago, which supports asynchronous pipe-lining. Pipe-lining allows browsers to request all files in one request, which diminishes the reason why a developer should try to reduce the numbers of files linked to in a page¹.

HTTP 1.1 already supported regular pipe-lining (and hence also ‘traditional’ HTTPS), but its synchronous nature led to problems (retrieval waiting for an earlier requested item to be received first) that led most browser manufacturers to disabling the feature. The new HTTP/2-standard also support async-pipe-lining but my server software (nginx) still lacks support for it.

To conclude: I was right that, given the current state of affairs, merging files (and minifying them) still matters with HTTPS (HTTP 1.1 over SSL).

As a side-note, something that I was suddenly getting doubts about: caching does work for HTTPS, but you’ve got to make sure you send a public cache-control directive along with it.

update (may 2017): This blog is now running on HTTP2, nginx and http2, and hence pipe-lining is possible.