The Critical Rendering Path: You’ve probably heard about it if you’re living in the front-end world. Against the do not mix HTML and CSS philosophy, it’s highly effective to put the render-critical parts of your stylesheet directly into the delivered HTML response. 1
But this article is not a pro and cons list of this technique — which will be deprecated if HTTP/2 is ready, rather a solution for one fundamental problem of the available tools: They are supposed to be used with static, highly predictable sites where deliverable HTML (generated by Jekyll or Middleman for example) files lying around, waiting to be analyzed.
Usually we build applications which are not static, but dynamic at a larger scale with varying layouts and templates, though. To extract the render critical CSS in those cases, we need to send actual HTTP Requests to evaluate what is critical on the pages in question.
We need three things in order to deliver the critical CSS based on the requested page:
- A build task which generates the critical CSS.
- Logic to find the page-matching critical CSS file.
- Output the critical CSS inline in the <head> section.
I skip the details on how your development environment might look like and go straight to the important parts, because the workflow is adaptable to almost any technology-stack. In my example, I’m using a WordPress instance served by Vagrant which resembles the later production environment.