Posts tagged

“The future of loading CSS” Is Good for User and Developer /

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">
    <section class="comments">…</section>

    <link rel="stylesheet" href="/about.css">
    <aside class="about">…</aside>

    <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 <link> in <body>:

  • 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
  • Avoids asynchronous loading of stylesheets which are complicated or JavaScript-dependent
  • 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 <script src="…"></script>.

Some notes:

  • 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.

We waste far too much time writing and maintaining styles with JavaScript, and I think it’s time for a change. Which is why it’s my pleasure to announce an emerging web standard called CSS. …

A good sign that a technology is not fit for purpose is how much we have to rely on workarounds and best practices to get by. Another sign is just how much code we have to write in order to get simple things done. … CSS solves JavaScript’s styling problems, and elegantly.

Heydon Pickering, “CSS: A New Kind Of JavaScript” (Jul 11, 2018)

Apple System Fonts /

Update: Newer browsers use system-ui as a font name alias for the system font. For example, this will display “San Francisco” on macOS, “Segoe UI” on Windows, and “Roboto” on Android in supported browsers.


font-family: -apple-system, sans-serif;

There are other names to access the system font on older macOS versions (when it was OS X). See, for example, WordPress’s or GitHub’s CSS for a full stack of system fonts. For my use case — local Markdown preview and export — -apple-system is enough.

The San Francisco font family is versatile, having italics, all weights, small-caps, and a wide Unicode range.

There’s also other San Francisco fonts for watchOS that you can call in your CSS:

  • ".SF Compact"
  • ".SF Compact Rounded"
  • ".SF Compact Text"

Some of the fonts are available for download at the Apple Developer site.