Created: 2017.04.14
Stefanov talks about what is critical when viewing a page. He concludes that the HTML is the only critical component and everything else is sugar.
Unfortunately, many sites load the `` up with CSS, with the following results:
- Browsers (except Opera) block rendering until all screen CSS arrives. With the worst possible experience: white page.
- Browsers download CSS they don't need, e.g. print, tv, device-ratio... And most browsers (except Opera and Webkit) block rendering because of these too
- Sometimes CSS blocks the other downloads too (not just block rendering, but block images and scripts that follow):
So if you worry about performance, you should get the CSS out of the way as soon as possible. Get off the critical path. Make CSS small, minify, compress, load from the same hostname even (no DNS) and inline, if small enough. Yup, inline.
Kyle Simpson says that all subsystems in the browser share a single thread:
- the CSS rendering engine, repaints etc
- the DOM
- the JavaScript engine
- the garbage collector
This means that any of the systems can affect any of the other systems. There are limited resources to go around, and each component must be proactively optimised, to produce a fast rendering and responsive UI.
Delivering a fast web experience requires a lot of work by the browser. Most of this work is hidden from us as web developers: we write the markup, and a nice looking page comes out on the screen. But how exactly does the browser go from consuming our HTML, CSS, and JavaScript to rendered pixels on the screen?
Optimizing for performance is all about understanding what happens in these intermediate steps between receiving the HTML, CSS, and JavaScript bytes and the required processing to turn them into rendered pixels - that's the critical rendering path.
By optimizing the critical rendering path we can significantly improve the time to first render of our pages. Further, understanding the critical rendering path also serves as a foundation for building well-performing interactive applications.
This generator accepts a URL and a CSS file, to create a block of inline CSS for a single page.
With the use of sidebars and widgets, above the fold content can change. If inline-css is generated manually, this can quickly become outdated and incorrect.
This plugin is great and concatenating and minifying, and also offers an Inline and Defer CSS? option. But, it accepts one block of CSS for all templates.
While someone could run each unique template through the suggested tools, making this small and DRY quickly becomes a maintenance headache, and it quickly becomes out of date if the content/widgets change.
But how can one find out what the “above the fold CSS” is?
There’s no easy solution for that as “above the fold” depends on where the fold is, which in turn depends on screensize. There are some tools available however, which try to identify just what is “above the fold”. This list of tools is a great starting point. http://jonassebastianohlsson.com/criticalpathcssgenerator/ is a nice basic solution and http://criticalcss.com/ is a premium solution by the same developer. Alternatively this bookmarklet (Chrome-only) can be helpful as well.
This plugin has some good reviews, but users warn that one has to read the manual carefully - TODO.