#270: Where’s your head at?

[Robin]: Harry Roberts has been doing a ton of interesting work when it comes to the <head> element and—no! stop yawning!—there’s good reason for that; it’s the place where all performance problems begin. Or, as Harry says in “Get Your Head Straight”:

The <head> is the biggest single render-blocking part of a page.

I’d venture a guess and say that the <head> is one element that front-end folks pay the least attention to. But it’s super important! How you load your styles, how you load fonts, how your scripts are loaded; it all directly affects the user experience. And all that goes in the <head>. And Harry, in that talk, suggests to…

Remove as Much as Possible

  • Move low-priority scripts to the closing body tag
  • Utilise in-body CSS
  • Reduce in-head payloads—external or inlined
  • Kill any inefficiencies such as redirects

All that advice is handy and all but the most handiest of things is this tool that Harry built called ct.css. Once you drag and drop a link into your bookmarks bar and click it, it runs a series of tests and highlights all the problems with your website’s <head>.

Here’s me running it on CSS-Tricks where it injects a list of suggestions to the top of the page:

The red boxes highlight stuff that you should probably fix—third-party scripts and stylesheets, for example—and the good stuff is highlighted in green. It’s a nifty tool that I’m going to keep in my back pocket since I find that performance fixes in the <head> are often some of the easiest to fix (sometimes).


motion.dev sure looks neat. Putting aside the fancy animations and the lovely design of the website for a sec, it’s an animation library with a tiny file size and great performance. Can’t wait to check this out in a project or two.


The most exciting blog post I read this week was from Bramus Van Damme where he wrote about CSS Cascade Layers:

Cascade Layers is about structuring your CSS Code and controlling the CSS Cascade.

…excuse me, what? Bramus continues:

With Cascade Layers coming, we developers will have more tools available to control the Cascade. The true power of Cascade Layers comes from its unique position in the Cascade: before Selector Specificity and Order Of Appearance. Because of that we don’t need to worry about the Selector Specificity of the CSS that is used in other Layers, nor about the order in which we load CSS into these Layers — something that will come in very handy for larger teams or when loading in third-party CSS.

The idea is that you can name and declare @layer first in CSS, like this:

@layer override;

(I’m stealing this example from Miriam Suzanne’s demo here as I walk through this code to try and understand what the heck is going on.)

So it looks like the order of these layers is important (sorry for the pun) because if you have multiple layers then each one declared will be more important (sorry!) than the next.

After we name our layers, we can then put styles in them:

@layer override;

@layer override { 
  h1 {
    color: green;

Any h1 element that isn’t in a CSS @layer will then be overridden by the @layer, even if it looks like this:

@layer override;

@layer override { 
  h1 {
    color: green;

#h1 {
  color: red;

In this example, the <h1> is green (if the browser supports @layer, which none do today). So even though it takes a little thinking, this is… kind of amazing? But how is it going to be used?

Bramus reckons it could be used like this:

@layer reset;     /* Create 1st layer named “reset” */
@layer base;      /* Create 2nd layer named “base” */
@layer theme;     /* Create 3rd layer named “theme” */
@layer utilities; /* Create 4th layer named “utilities” */
/* Or, @layer reset, base, theme, utilities; */

@layer reset { /* Append to layer named “reset” */
  /* ... */

@layer theme { /* Append to layer named “theme” */
  /* ... */

@layer base { /* Append to layer named “base” */
  /* ... */

@layer theme { /* Append to layer named “theme” */
  /* ... */

…the idea here being that you can create CSS styles that are more or less important (this time, I’m not sorry) than other styles. Reset styles would be declared first, for example, and theme styles would be declared afterwards so as to override them. Quoting Bramus here again:

Once a winning declaration has been determined via Layer Order, the Cascade won’t even check Specificity or Order of Appearance for those declarations anymore. This is because Layers is a separate and higher ranked criterion of the Cascade.

Interesting stuff. And although it’s not officially supported in any browsers just yet, Miriam points out that you can use @layer in Chrome Canary and Firefox Nightly today.

Side note: Does anyone right now have as much of an impact on the future of CSS as Miriam Suzanne? Each week, I hear about a new and incredible CSS feature coming down the pipeline, and I realize that she’s been working on it in the background. My point is this: please stop it, Miriam. You’re making us all look bad. 😎


Chris asks a question: “What is Your Page Title on a Google Search Engine Results Page?” My first thought was the <title>, right? But nope. Google has been using alternative ways to make that list of blue links but they recently changed it. Reading this post was a bit of a bummer:

HTML title tags don’t always describe a page well. In particular, title tags can sometimes be:

• Very long.

• “Stuffed” with keywords, because creators mistakenly think adding a bunch of words will increase the chances that a page will rank better.

• Lack title tags entirely or contain repetitive “boilerplate” language. For instance, home pages might simply be called “Home”. In other cases, all pages in a site might be called “Untitled” or simply have the name of the site.

I’m sort of sad about this. Not that Google did something about this problem, but that they had to improve this at all. I feel like making writing accessible and good should be the responsibility of us web developers, not some obtuse program that parses our words and then takes out all the junk. Chris made this point pretty clear here:

Part of me connects this kind of work to AMP. AMP was basically saying, “Y’all are absolutely horrible at building performant mobile websites, so we’re going to build a strict set of rules such that you can’t screw it up anymore, and dangling a carrot of better SERP placement if you buy into the rules.” This way of creating page titles is basically saying, “Y’all are absolutely horrible at providing good titles, so we’re going to title your pages for you so you can’t screw it up anymore and we can improve our SERPs.”

Static WordPress in one click

Deploy WordPress as headless & static in one click on Strattic’s end-to-end hosting platform. Get the speed, security and scalability of headless while your marketing team uses WP as usual.

Get started with your 30-day free trial

We speak your language: three days of learning, CSS, design, and more

Spanning the spectrum from climate-conscious development to design beyond the screen, and from advanced CSS to inclusive design and development, An Event Apart Online Together: Fall Summit 2021 will give you deep insights into where we are now, and where things are going next.

Join us online October 11–13.

Save $100 on any multi-day pass with promo code AEACSST21.

See the detailed three-day agenda and register now →

[Chris]: I bet a lot of you saw this going around the other week:


It’s one of those laugh-but-also-cry kind of experiences. Well done, Guangyi Li.

If you look on a desktop computer, it’s pretty bad. It’s infinitely worse on mobile, because you literally can’t even get through the second “step”:

It’s the ultimate irony. At first I was like, aw bummer a bug, I wanted to see all the ridiculous popup garbage action, barely able to see the content at all, they should get that fixed up. But instead, it’s actually a more accurate representation of the horribleness of some web experiences: it’s just entirely unusable. There is supposed to be some cookie banner thing at the bottom of the screen, but it’s fixed position and offscreen such that I can’t even see it. Sounds familiar.

Also, this whole thing is akin to Brad Frost’s:


Which I feel is worth pointing out because Brad was trying to call out these garbage web experiences half a decade ago and, to nobody’s surprise, it hasn’t gotten any better.

It seems like a problem of incentives to me. As long as building these awful experiences makes people more money than what you or I would consider a better experience, things will just stay the way they are.

Sometimes I think about it in terms of CSS-Tricks itself. I’ve got ads on the site. I keep it tasteful, in my opinion, but I’m sure it exceeds the bar of tastefulness for some people.

What if I dialed it up to 11? Pop-ups, pop-unders, fixed-position megabars, scroll-triggered ads, tracking JavaScript galore… literally anything the ad industry would want to slug on this site to maximize every possible penny. Would I, at the end of say five years, have made more or less money than what I’m doing now? Part of me thinks it would actually be less. That there would be so much backlash and people avoiding the site altogether that it would impact the advertising earnings in the form of diminished traffic. So maybe the revenue chart would look like quick, early, big growth, and then a nosedive, compared to the slow steady chart of today. Not as big of growth, but no dips, and thus ultimately more money long term.

All I can do is guess though. And don’t worry — while I make plenty of money-related choices, building abhorrent web experiences is never in the cards. Just not in my DNA.