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…

Some sensible defaults for your img elements: 1. Allow for fluid image sizing while maintaining aspect ratio governed by width/height attributes

⬅️ With : Without ➡️

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.

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.

🧵 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?

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

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

📊 I took the csswizardry.com homepage and tested it over a 3G connection. I then ‘improved’ bandwidth or latency by 10% until 2× change, then I did 4× and 8× changes. 📈 For every 10% improvement in bandwidth, we see an average 0.21% *increase* in FCP.
📉 An 8× improvement in bandwidth only yields a 1.64% improvement in FCP.

You WILL need a cast iron pan[1], a quick-read meat thermometer, and a high smoke point cooking oil[2]. Do not attempt this until you have all of these items. It will not work and you will be disappointed. 1. Cast iron can be heated up to crazy-high temps, and holds/spreads heat well. Mine was dirt cheap and I absolutely adore it. nisbets.co.uk/vogue-round-ca…
2. Do NOT attempt this with olive oil. It will burn before you can even get started. Avocado oil, beef fat, or clarified butter.

Want to view a single image on @imgur (literally its only job)? Good luck! You gotta successfully download (354KB) and run (1.21MB) of client-side React in order to get your image requested as resource 110 of 553. What should have been an IMG element became… this. • Total page weight: 5,961KB
• Image I wanted to view: 37.5KB

Put another way, this page was 158.96× heavier than it needed to be.

This is the first time I’ve knowingly seen the Battery Status API used for fingerprinting. Inevitable, really, but this is the first time I’ve spotted it in the wild. Any developers not familiar with browser/device fingerprinting, I encourage you to please read up on it: en.wikipedia.org/wiki/Device_fi…

✅ My very high-level performance checklist:

0. RUM and Analytics
1. Infrastructure
2. The Network
3. Assets and Payloads
4. Runtime
5. Monitoring and Budgeting 0. RUM and Analytics

• What do we know already?
• What issues exist?
• Where do we need to focus our efforts?

The issues are manifold. In theory, loading CSS anywhere in the BODY is 💯% a great idea in 2019. See here: csswizardry.com/2018/11/css-an… and, more thoroughly, here: jakearchibald.com/2016/link-in-b… by @jaffathecake.

https://twitter.com/andybelldesign/status/1133340055664250880

Loading CSS in-BODY allows for a progressive render, as almost all browsers will only block rendering of *subsequent* content (that is to say, content beneath the rel=styleheet), as opposed to the traditional behaviour of blocking of all content.