A good friend of mine, @frontendphil recently asked:
If I put a 50KB SVG spritesheet inline in my HTML, will the gods of frontend smite me? This is actually a serious question.
It’s a good question.
As frontend developers who care about performance, we’re used to trying to reduce the number of HTTP requests we make. Each request carries with it latency, the time it takes for the server to respond to a request for a file. HTTP/2 will help reduce latency issues amongst other things, but we’ll still look to inline critical CSS and small images.
In this case though, Phil would like to inline a 50KB image in his HTML. This might not be such a great idea. To understand why, we need to look at how HTTP requests are processed.
When you land on a web page, your browser makes a TCP connection to the web server. TCP uses something called slow-start, which prevents network congestion. It does this by only sending 10 packets of data in the first round trip, it’s initial congestion window (initcwnd). After that it must wait for the client, your browser, to acknowledge that it has received those packets before more can be sent.
I should note that the initcwnd was increased to 10 packets in around 2010, from 4. Older servers may be running with these lower limits. It’s also worth noting that whilst most CDNs use an initcwnd of 10, some go upwards of 50.
Anyway, these first 10 packets equate to about 14KB of data. So to only have one round trip, we ideally want to keep our page size below 14KB. Otherwise we’ll need to make more trips, which will incur additional latency.
50KB of extra page weight could mean an extra ~150ms of latency on the request. Phil would need to balance this against the latency of serving a separate file, and the benefits he would get by doing that (caching etc), to see what would work best for him.
My advice though, is if in doubt, aim for 14KB.