#ASKTHEINDUSTRY 08: Should you really compress all your initially rendered content into 14KB of data?

Yes. If you care — and you should! — about having your content rendered on your user’s mobile device in under a 1000ms you basically have not many other options.

First of all, in that 1000ms of time your user’s browser needs to:

• Perform a DNS lookup
• Perform a full network roundtrip to perform the TCP handshake
• Send the HTTP request (which takes another full roundtrip)

On average, on a 3G connection, this leaves you just 400ms to:

• Compute the response on the server
• Layout and render the content on the browser

In such a scenario, it is vital that you minimize the additional roundtrips needed to perform the first render, in order to hit the 1000ms mark. Optimally you’d want no additional roundtrip, which brings us to the 14KB.

It is vital that you minimize the additional roundtrips needed to perform the first render

Indeed, due to how TCP works, the server can initially send only 10 packets (circa 14KB) before it needs to wait for the client to ACKnowledge the data (so that the congestion window can be widen). Long story short, all the information that the browser needs to render at least the visible (Above The Fold) content, typically markup and styles, should be compressed in those first 14KB of HTML data. Then, while your user starts to mentally process what you have displayed so far, you can deliver the rest of the page.

This piece is part of the #ASKTHEINDUSTRY project, a series of daily conversations with the Web Dev industry. You ask, I’ll answer, or find someone who can.