This hamburger icon was costing me about 300ms of main thread time—AMA.
🧵 I’ve always had this suspiciously long Layout task on my site. Never quite knew why and never really thought to look into it—CWV are glowing regardless. But ~400–500ms in Layout for a simple page does feel off…
Time to dig deeper. By default, Chrome doesn’t expand on what it’s actually doing in Layout, so I turned on ‘show all events’:
Simple yet significant thing all developers should keep in mind: CSS resources (fonts, background images) are not requested by your CSS, but by the DOM node that needs them [Note: slight oversimplification, but the correct way to think about it.]
It’s not until the browser finds e.g. an H1 that needs Open Sans that it will dispatch the request. Ergo, it’s often the speed of the DOM that determines CSS-resource discovery, and not the speed of the CSS itself.
While there is no catch-all fix for this, it does help to explain why you might see waterfalls like this: It looks like the font was requested by the JS, right? But actually, the JS was blocking the discovery/construction of the DOM node that needed the font.
JS framework (developer)s inventing CSR, realising it was a misfire, and then *rebranding ‘websites’ as SSR* is a level of spin that a disgraced politician would kill for.
This absolutely is the case and it kills me. In performance audits I have to suggest ‘have we tried SSR?’ like it’s a step forward. Like it’s a groundbreaking development we’ve recently been gifted.
The fix is never ‘do SSR’; it’s ‘don’t do CSR’. The difference is significant. Selling SSR like it was invented after or in response to CSR is pernicious and disingenuous.
🧵 Two of my most- and first-used checks when doing a performance audit are surprisingly old school: 1) Validate HTML 2) Disable JS.
Validate HTML? Yep. We haven’t really cared about ‘valid HTML’ for valid HTML’s sake for about a decade, but certain errors can actually be pretty significant. What’s wrong with this picture?
It’s this lil’ fella right here. <span> isn’t allowed in the <head>, so when the browser encounters the <span>, it assumes the <head> should have been closed already.
🧵 A lot of my clients stress about Critical CSS. It’s very difficult and error-prone to retrofit to a site, yet a lot of tools make a huge deal of it. The thing is, it’s not always that effective…
Critical CSS only helps *if CSS is your biggest bottleneck*. Your HEAD is the single biggest render-blocking part of your page, so if your HEAD takes, for example, 1000ms, your Start Render will never be faster than that.
Put another way: getting your CSS time down from 250ms to 50ms will do nothing if you have a synchronous JS file that takes 250ms.
🖼 If you’re building hero-style content with background images—maybe even through a CMS—you can hugely improve rendering times (LCP) with one additional line of HTML.
With the before, the browser won’t request the image until it knows it needs it—when the Render Tree is built. The problem is that the Render Tree can’t be built until the CSSOM is built, which means the browser needs to download and (re)calculate all applicable stylesheets.
Your Render Tree is only as fast as your slowest stylesheet.