9

I've heard that to avoid render-blocking issues, it's good to inline critical CSS directly in the <HEAD> tag by including the actual CSS in <STYLE> tags, and then load the rest of the CSS asynchronously.

At the other hand, I read it's bad to inline too much CSS.

Is there some limit for critical CSS after which it becomes a negative performance impact?

Improve this question
0

1 Answer 1

Reset to default
20

As of 2011, you will see the first drop in page performance after 14.6 KB has been sent. For the speediest page, all of your HTML code from the first byte up to and including the critical CSS should fit within this amount of data.

14.6 KB is the size of an HTTP server's initial TCP congestion window assuming a default TCP IW value of 10 (which was agreed on for major web browsers in RFC 6928). This 14.6KB payload represents how much data the server can send to the client before hearing acknowledgement that the data was received (aka before waiting for the first network round-trip).

If you think of the HTTP connection as a series of boat expeditions from the server to the client, 14.6 KB is when the first explorer's ship is full, and the rest of the HTML has to sit around and wait for the cargo ships.

Illustration of boats on TCP

So if the beginning of your HTML - up until the end of your critical inlined CSS - is less than 14.6 KB, that is optimal. Due to the way TCP congestion control works (doubling the amount of data sent as each burst is acknowledged), you can send 98 KB (14 KB + 28 KB + 56 KB) within 3 round-trips - so Google recommends that all above-the-fold content should be renderable with the first 98 KB of the document for mobile page speed reasons.

In short, 14.6 KB is the upper limit for critical inlined resources to fit within the first RTT. To fit within three RTTs and Google's recommendation, the cutoff is 98 KB.

This answer applies to HTTP/1.1 and HTTP/2, as they are both TCP-based protocols. This answer does not apply to HTTP/3, as it is a UDP-based protocol with its own inbuilt ramp-up strategy that I believe may be different than the strategy used by TCP.

Improve this answer
10
  • 2
    Also, it would make sense to me that the 14.6 KB figure would be after gzipping, since the compression protocol is negotiated from the get-go in the Accept-Encoding request header sent with the initial HTTP request.
    – Maximillian Laumeister ♦
    Commented Oct 10, 2018 at 18:33
  • 1
    Amazing answer ;)
    – Emirodgar
    Commented Oct 11, 2018 at 7:10
  • 1
    @MaximillianLaumeister btw, does HTTP/2 without inlining anything completely eliminate the render-blocking issue or just reduce it?
    – stckvrw
    Commented Oct 25, 2018 at 11:31
  • 1
    @stckvrw On the contrary, single page performance-wise that's the same or worse than inlining (still better than 1.1 though). If you want more detailed responses I encourage you to ask a new question!
    – Maximillian Laumeister ♦
    Commented Oct 25, 2018 at 15:12
  • 1
    @MaximillianLaumeister one more question: if critical CSS enqueues a font with @font-face{src:url(...)}, is it the first round trip?
    – stckvrw
    Commented Dec 7, 2018 at 17:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.