Performance work in 2021 is less about squeezing bytes and more about understanding what the browser actually does with them — that is the thread running through this conversation between Drew McLellan and performance consultant Harry Roberts. The episode coincides with Roberts' Web Performance Masterclass workshop for Smashing in May 2021, which still had earlybird discounts available at publication time.

Where to follow along

  • Harry Roberts on Twitter: @csswizardry
  • Consulting site: CSS Wizardry
  • Video course: Everything I Have Done to Make CSS Wizardry Fast — 15% discount
  • eBook: Questions for Consultants — 15% discount
  • Web Vitals reference: the Web.dev guide

From the weekly update

  • Web Design Trends 2021: The Report, by Suzanne Scacca
  • Using Grommet In React Applications, by Fortune Ikechi
  • How To Build A Node.js API For Ethereum Blockchain, by John Agbanusi
  • How We Improved SmashingMag Performance, by Vitaly Friedman
  • When To Say No To Freelance Projects, by Becca Kennedy

Measuring what matters

Roberts groups measurement approaches by how much effort an organization can put in. Off-the-shelf metrics are a reasonable start, but load time no longer tells you much — it is too obscure and not customer-facing. Core Web Vitals are a step in the right direction: they measure user experience while remaining grounded in technical inputs. Largest Contentful Paint, for instance, reduces to unblocking the critical path, getting hero images in early and having a decent web font strategy.

When clients have the lead time, the more interesting work is custom metrics. During a gap in his own schedule, Roberts will set a client up on a free trial of Speedcurve so data is already being captured by the time the engagement starts. A publisher would track how quickly the article headline or lead image rendered; an e-commerce client would track the probability of an add-to-cart against start render time. He is currently working with an e-commerce client on exactly that correlation — show a product sooner and people are more likely to buy it.

The stretch goal is to measure business KPIs rather than paint timings: did scroll depth correlate with First Input Delay, did lower CLS mean readers read more articles. Vitals suit this because they have become a normalized, industry-wide playing field.

The Lighthouse and Vitals disconnect

One inconsistency Roberts wants to raise with the vitals team: CLS contributes 33% of Core Web Vitals, but only 5% of a Lighthouse score. Marketing and analytics teams see vitals, which surface in Search Console and in the context of search results; developers work against Lighthouse because it is a lab metric that integrates into tooling. So marketing reports that CLS is terrible while developers point out it is a rounding error in the score they see in DevTools or Lighthouse CLI in CI. Lighthouse remains valuable, but that gap needs ironing out.

Smaller teams without budget can still work with what they have. Google Analytics has captured rudimentary performance data for years — DNS, TCP and TLS timings, time to first byte, page download time and load time. Clunky, but enough to proxy a situation when there is no New Relic, Speedcurve or Dynatrace in place. Custom metrics can be pushed to Analytics trivially: Roberts's own site captures when an article heading became readable, when the About page image rendered and how soon the call-to-action asking you to hire him appeared. In the Analytics UI these are first-class citizens, served in their own dashboard section with no report-building required.

When theory beats reality

Intuition about speed is frequently wrong, and Roberts offers preload as the canonical case. Preload exists because some assets are inherently slow to discover — background images referenced from CSS and web fonts, where the HTML must be fetched, then the CSS, before the asset is even known about. A single line in the document head tells the browser to fire the download early, so by the time CSS asks for the image it is already cached. Theoretically sound.

In practice, on a first visit to a domain, bandwidth is finite and the browser is already spending it well, scanning the HTML and building a priority list. Injecting preloads overrides that list: the same finite bandwidth is now spread across more assets, and everything gets marginally slower. Web fonts can be seen stealing bandwidth from CSS. Roberts has had clients refuse to remove preload even when he could demonstrate it was hurting them, because Lighthouse recommended it. On one large client project he insisted a head tag reorder based on how browsers work; the change went out to millions of users and got slower. They reverted it.

The lesson is to follow the numbers in the real world, which is why monitoring matters more than theory.

How to keep learning

Roberts is blunt about one-size-fits-all performance products. On AMP: there is no replacement for building a fast site, and anything non-standard puts you at the mercy of that team changing its mind. He cites a client who licensed a font from an AMP allow-listed provider, only to have AMP later blocklist that provider, forcing a choice between undoing the AMP work and wasting a substantial annual font spend. He offers Cloudflare's Rocket Loader as an AMP-esque endeavor — a purported switch that actually substitutes for building the site properly in the first place.

His alternative is to stay independent, understand how browsers work, and hold to fundamentals. Start from the design: identify what a user most wants to see, and put nothing in its way. Don't lazy load the main image. On an e-commerce page, lazy load reviews and Q&A, tucking them behind JavaScript, but not the product image.

For keeping current, he rates web.dev as a phenomenal framework- and stack-agnostic resource for vitals and PWAs. Calibre's fortnightly performance email is a good digest. The Performance Working Group publishes proposals on GitHub, and chromestatus.com shows what Chrome is working on, signals from other browsers, links to relevant bug trackers and milestone data — useful, technical detail that few people know about.

But the advice that recurs is to lean on subtraction. Every pound, dollar or euro Roberts has earned as a consultant has come from telling clients that the browser already does something, or that a given thing could not possibly be faster. He has never made money selling extra technology. He is currently in discussions with a large JavaScript framework about optionally removing something that harms performance across a vast number of sites; the counter-proposal on the table was to add more so teams could sidestep the problem. If you find yourself adding code to get a faster site, he argues, you are heading the wrong way.

Web performance as applied accessibility

Roberts frames performance as applied accessibility: it increases the chances that someone can access your content at all. Building for the web rather than an app is itself an access decision — a bid to reach more of an audience. That range runs from "could somebody even experience your site" to "was the experience delightful — did the button respond in time". It is also, in his reading, why Google has weight behind it: search results should not lead people to a site they will hate.

The store analogy recurs. Walk into a supermarket that is rammed and you buy the bare minimum; in a pleasant one you browse and add. Three decades in, people who build for the web still struggle to accept that what would annoy you in a physical store annoys you online, and the stats bear it out.

The cost of getting faster

Speed is a competitive advantage, but only one of several. If nobody wants the product, a fast checkout changes nothing; if someone truly wants the world's fastest website, you must delete the images, the CSS and the JavaScript — and then count the products you sold. Studies point to large returns, and Roberts has measured them first-hand with retail and e-commerce clients: one engagement valued a one-second improvement in Largest Contentful Paint at 1.8 million a year.

He also cites Scott Jehl: it is easy to make a fast website, but difficult to make a website fast. Speed competes for budget against other changes — adding Apple Pay to a checkout might be worth more — so it belongs inside a broader strategy. Faster sites are also cheaper to run: good caching keeps people off your servers, and optimized assets weigh less when they do have to come from them.

The long tail and who sits in it

Tim Kadlec's work on "the long-tail of web performance" comes up when Roberts discusses where to spend effort. His view is to invest in the worst 20% rather than only the median. The reasoning he offers comes from a GCSE product design class and a teacher he names as Mr. Brocklesby: if you design a doorway for the average person, someone unusually tall cannot use it — design for the extremities, and the door is useful to the most people. Raise the experience of the 90th percentile and the 10th percentile comes up with it. Assume your users are on 4G iPhones and anyone outside the 50th percentile falls further behind; set the bar high by setting expectations low.

There is a business dimension too. In Drew McLellan's current project, the slowest users turn out to be the most valuable customers — the largest organizations, with the most data to display, hitting bottlenecks on pages that need refactoring. So the long tail can contain the people who pay most. Roberts has a comparable anecdote: a client CEO who was effectively their richest user, flying first class between Australia and Estonia, using his expensive phone mostly over terrible airplane WiFi. His 95th-percentile user was also his wealthiest.

Telling two things apart

On the split between server and client rendering, Roberts recommends real awareness of context. He calls it a form of narcissism to assume your blog with an 89% bounce rate deserves its own runtime in the browser so subsequent navigations can be fast — nobody is clicking to the next article. He does acknowledge the murkiness of distinguishing a website from a web app, and describes his site as read-only, firmly a website, while his accountancy software is an app for which he will accept boot cost, because he knows he will be there for twenty minutes or an hour.

Client-side rendering suits lower sensitivity to churn. A 100% client-rendered e-commerce site shows an empty div id="app" with JavaScript disabled, and commerce is highly sensitive to any friction. By contrast, 45 seconds of Photoshop splash screen feels worth it if you are staying 45 minutes. Most people, in his assessment, land on the wrong side of that line and put work on the client that should not be there.

The static site generator and CDN-hosted approach gets his unqualified enthusiasm. He built CSS Wizardry on Jekyll back when, as he puts it, static sites were called flat files. The only cost is a slightly larger up-front compile, after which the CDN shields the application servers entirely. Anything interactive can be handled on the client, or with Edge Side Includes so a shopping cart stays server-rendered at the edge. It does not suit every site — for e-commerce you need realtime stock levels and serious search — but for publishing, he is a huge fan. A hybrid works: most commerce content rarely changes and can be static, filters can be client-side, while search and stock must call an API.

Where client-side migration goes wrong

Roberts has a concrete case. A client he worked with two years ago ran an already-fast, server-rendered .NET site on IIS, needing only a few hundred milliseconds shaved here and there. Midway through last year they moved key pages — product detail and product listing — to client-side React, and everything got markedly slower, to the point that they came back for help. One bullet point in their own case for reverting: projected annual hosting costs up by a factor of 10, as one application server and a database became many gateways, APIs and microservices. The surface area of the application expanded enormously.

His diagnosis is not about the developer, who chose React because it seemed like fun and was never asked to make a business case for cost, return or maintenance. It is that businesses keep financials away from engineering teams, so engineers cannot be informed. He is careful to call the 10x figure atypical while noting it is a real incident.

What to ask before you build

Asked who a developer should talk to before architectural change, Roberts's answer is everyone. Talk to marketing about what an A/B testing tool costs per year and what it nets per year. The company should make asking such questions possible — plenty of organizations will not even give their own developers access to Google Analytics, which makes building a site for an unknown audience near-impossible. For e-commerce the questions are average order value, conversion rate and revenue. Give a consultant those three numbers and they can calculate roughly what 100 or 500 milliseconds are worth per year; that is what let him derive the 1.8 million figure.

That sensitivity analysis is what he wants clients to reach: not to chase a mystical two-second LCP but to chase the optimal LCP, whether or not it is slower than assumed.

The reason "nobody wants a faster website" resonates is that if clients truly wanted the fastest possible site, they would let him delete the JavaScript, the CSS and the images and serve a Times New Roman stack. Fast for its own sake is not the goal; fast enough, defined by your context, is. Going from four seconds to two on First Contentful Paint might buy a 10% revenue increase, while two to one buys 1% — still twice as fast, with minimal gain. Returns are not linear and tail off, so engineering effort can double while returns halve. Businesses need a product people want, and a seamless mobile checkout, before speed can do its work.

Harry's own projects, and what he is learning

His video course, Everything I Have Done to Make CSS Wizardry Fast, deliberately avoids a rigid zero-to-hero curriculum — no "here is a browser and here is how it works", since that is a great deal of work and assumes time he was not sure he would have. Instead he screen-casts ready-to-go material, hacks, pro-tips and real examples, using his own site as a low-risk playground. Because it is not a single long course, he priced it low, and viewers can jump to whichever folder matches their problem without having watched preceding hours. Anyone using the discount code SMASHING15 gets 15% off.

On technical learning, QUIC and H3 are on his list. He wrote an e-book during the first UK lockdown and learned how they are made from HTML and CSS, plus rudimentary video editing for the course — workflow skills rather than the conceptual wrestling a programming language demands. Off the clock, it is cycling: power outputs, functional threshold power, a training programme and permanently tired legs, backed by the same obsessive relationship with data. He notes the parallel: limited bandwidth on the network, limited energy on the bike, and you cannot simply magic more of either into existence.

His parting thought, from something he heard recently, is that we are not all in the same boat — we are all in the same storm, and some people have better boats than others.