CSS blocks rendering of a web page until all stylesheets load. As Harry Roberts put it, “your page will only render as quickly as your slowest stylesheet.”
So link to stylesheets in-body.
<link rel="stylesheet" href="/site.css">
<link rel="stylesheet" href="/site-header.css">
<link rel="stylesheet" href="/article.css">
<link rel="stylesheet" href="/comments.css">
<link rel="stylesheet" href="/about.css">
<link rel="stylesheet" href="/site-footer.css">
That’s Jake Archibald’s technique in “The future of loading CSS” (Feb 11, 2016). It’s a win for both performance for the user and workflow for the developer. Stylesheet
- Loads CSS at the component level, avoiding redundant rules and downloading
- Allows for stylesheets to be independently cached, minimizing impact of changes (“cache-busting”)
- Progressively renders (displays) the web page rather than blocking the entire page
- Avoids the need to decide what’s “above-the-fold” critical CSS
- Fits into modern component-based design systems (keeps styles with components or includes)
The plan is for each
<link rel="stylesheet"> to block rendering of subsequent content while the stylesheet loads, but allow the rendering of content before it. The stylesheets load in parallel, but they apply in series. This makes
<link rel="stylesheet"> behave similar to
- Pay attention to layout that may shift during progressive rendering.
- This technique works across all modern browsers (see Chrome Platform Status — Stylesheets activated after the body is started do not block paint). Without browser support, it simply falls back to old render-blocking behavior.
- Loading multiple stylesheets is only performant with the updated protocol, HTTP/2. Browser support for HTTP/2 is almost certain. HTTP/2 is already enabled on many host servers and CDNs. Secure connectivity (HTTPS) is required. This technique is still a good idea even if you avoid loading multiple stylesheets. Inline the CSS styles in-body instead of linking to the stylesheets.
When I’m asked the more existential question of how I’ve survived so long as a freelancer, my response is always the same: above all, be reliable.
Adam Coti, “Twenty Years as a Freelance Web Developer: Wisdom Gained and Lessons Learned” (Sep 18, 2018)
Small b blogging is learning to write and think with the network. Small b blogging is writing content designed for small deliberate audiences and showing it to them. Small b blogging is deliberately chasing interesting ideas over pageviews and scale. An attempt at genuine connection vs the gloss and polish and mass market of most “content marketing”.
And remember that you are your own audience! Small b blogging is writing things that you link back to and reference time and time again. Ideas that can evolve and grow as your thinking and audience grows.
Tom Critchlow, “Small b blogging” (Feb 23, 2018)
- [x] Reduce the file size (with subsetting and unicode-range)
- [x] Load key font files as early as possible (with preloading)
- [x] Manage FOUT and FOIT (with font-display)
Ollie Williams, “Three Techniques for Performant Custom Font Usage,” CSS-Tricks (Mar 5, 2018)
Time and practice really do help.
Except with the websites. They separate themselves from the others, because I don’t feel much better at making them after 20 years. My knowledge and skills develop a bit, then things change, and half of what I know becomes dead weight. This hardly happens with any of the other work I do. …
If knowledge about the web deteriorates quickly, it’s worthwhile to develop a solid personal philosophy toward change and learning. …
“Go slow and fix things.” …
The web also needs diligent people so that the idea of what the web is and what it does remains legible to everyone.
Frank Chimero, “Everything Easy Is Hard Again”