Interview with CSS Wizardry’s Harry Roberts

Harry Roberts is one of the web’s leading performance specialists, with nearly two decades of experience helping organisations understand why their websites are slow and what to do about it.

Best known through CSS Wizardry, his work spans front end architecture, Core Web Vitals, performance strategy, developer education and consultancy for large scale websites.

In this interview, Harry explains:

• Why faster devices have not made performance problems disappear
• Where teams most often go wrong
• How to make the business case for speed
• Why performance budgets fail
• What developers should focus on in an AI assisted future

He also shares his advice on public speaking, consultancy and the one change he believes organisations should make if they want a faster, more durable website.

You’ve been working in the industry for nearly 20 years. What are some of the biggest changes you’ve seen in the way websites are built, run and maintained?

I had to check the maths twice, but yes, it is getting on for 20 years. That’s a bit mad!

The web as a ‘place’ has changed enormously, but the useful thing about it is how little has actually changed underneath.

Its foundations and protocols have evolved without being endlessly replaced.

Most of the change has come from the layers we chose to pile on top.

React, single-page applications, client-side rendering, and client-side runtimes marked a major shift about 10 years ago.

Over the last two to five years, the industry has started moving back towards sending less work to the browser ,  sending an entire runtime to the end user is not faster than not doing that.

Familiar ideas have returned rebadged as server-side rendering or static site generation, and they are given new names despite the underlying ideas are often older than the framework itself.

I spoke about this recently with Build for the Web, Build on the Web, Build With the Web.

That history is why I place more trust in the web as a platform than in any one era or generation of tooling.

With devices and networks becoming increasingly capable, why does web performance still matter so much?

That premise is only true in a very local sense. Globally, device capability can still lag the West by years.

You and I may carry recent iPhones and expect 5G almost everywhere, but progress is not distributed evenly.

I looked into Low- and Mid-Tier Mobile for the Real World only last month, and I identified a Samsung Galaxy A17 5G as a practical low-powered global baseline.

But in parts of the Middle East, Africa, or Latin America, even that is too powerful; a Galaxy A07 4G may be a better test.

As an aside YouTube Feather makes for an amazing case study into the phenomenon of optimising to assumptions,  give it a read.

Give teams more CPU and bandwidth and they will build larger websites.

Things that couldn’t have worked 15 years ago can work now, so we ship them. The available capacity increases, and then sites expand to consume it.

Core Web Vitals have given businesses a shared language for performance. Have they also created a risk that teams optimise for scores rather than the user experience?

Core Web Vitals are excellent user-centric metrics and give teams a useful shared language.

The risk with any metric is that teams start improving the number rather than the experience it is meant to represent — Goodhart’s Law at its finest.

That risk only increased once Google promised better rankings for faster sites.

I have seen figures window-dressed and tools serve selected bots a different, faster version of a site before, purely to massage the figures; the reported number improves while the user experience stays exactly where it was.

Doctoring the numbers is like wanting to lose weight, then adjusting the scales to make yourself read 25 kilos lighter. You get a nicer answer, but the original problem hasn’t moved.

Thankfully, my clients overwhelmingly want to improve the experience itself.

Performance is often treated as a front-end issue. Where do back-end systems, product decisions and organisational culture have the greatest influence?

Yes, the idea that performance belongs only to front-end developers is too narrow, because it leaves out the product, platform, and back-end decisions that shape what users actually receive.

Features are scoped for delivery, security, and, hopefully, accessibility; their performance cost should be discussed at the same time.

Product decisions create technical work, while developers on powerful machines can easily lose sight of how customers experience the result. Responsibility lies on both sides.

I’ve always said that the average software engineer doesn’t know enough business analysis, and the average business analyst doesn’t know enough engineering, for either to bridge that gap alone.

As for the back end, I’d say it actually has a much larger part to play now than a few years ago.

One page request may trigger calls to personalisation, ecommerce, and CMS services before returning HTML.

Those distributed dependencies can compound latency, while increasingly heavy client-side payloads also punish the device afterwards.

Modern performance problems span the entire gamut.

Steve Souders said that 80–90% of slowdowns happen on the front end, and that was probably true of traditional LAMP-style websites.

Once one page request becomes three back-end requests, often across separate services, the old split looks much less likely. In my work, back-end times are going up.

How do you make the case for performance improvements in terms that senior decision-makers will value?

Speak in the language the other person wants to listen to. The C-suite probably doesn’t care about time to first byte, and nor should it.

Show them what each additional 100 milliseconds does to sales and the underlying technical metric suddenly becomes a business interest.

Also, the sensitive metric may differ by organisation. One client may show conversion decay against INP; another may respond to LCP.

Only today, I found an ecommerce client in the Netherlands converting at exactly twice the rate when it achieved a CDN cache hit.

Suspiciously clean, but it was exactly double.

Nobody actually wants the fastest website. They want the website that performs its job most effectively.

Speed matters because business outcomes move with it. If CDN cache hits reliably predict conversion, then perhaps cache status should be treated as a KPI rather than hidden in an engineering dashboard?

You’ve worked with organisations at very different stages of performance maturity. What do the strongest teams do consistently?

They have senior sponsorship. When the C-suite backs or commissions the work, teams have permission to take performance seriously rather than squeeze it around feature delivery.

Strong organisations then give developers the problem, not a solution. Good developers enjoy solving worthwhile problems and thrive when trusted to do so.

These organisations also buy the tools and licences needed to measure reality, and while the investment may only be modest, it gives teams the information they need to make informed decisions.

Most developers already know performance matters; sponsorship gives them room to exercise it.

Performance budgets have been discussed for years. Why do they so often fail to stick, and what makes them effective in practice?

Most performance budgets fail because they are treated as targets instead of backstops.

A budget is a guardrail: a formal agreement that performance will not become worse than a known point.

If conversion peaks around an LCP of 1.4 to 1.5 seconds, but decays sharply beyond 1.8 seconds, then 1.4 is a target and 1.8 is the performance budget. The target is where you want to be; the budget is the point you agree not to cross.

Set the first budget using a sensible recent release period. Find the worst acceptable result and agree never to become slower. If a regression breaches the line, don’t redraw the line around it — that’s how a small slip becomes part of the norm.

Enforcement also needs timeframe. A release might purge caches and cause a 5% regression for a few hours, which may be acceptable. A 200% regression might mean an immediate incident. Define the threshold, allowable duration, alert, and response before the breach occurs.

When working with development teams, which misconceptions about web performance do you encounter most often?

Web performance is not a property you can pin entirely on a website. It happens somewhere between the site and the customer.

An exceptionally well-built site can feel awful over a dreadful cellular connection.

A badly built site can feel fine on fibre and a powerful MacBook Pro. The relevant question is not how fast the site is; it is how fast the site was experienced.

This is why headline averages are so dangerous. Segment the data by device, geography, user context, and more.

Use histograms to expose bi or multimodal populations and percentiles to understand how severity relates to frequency.

If one person records a 70-second LCP while 10,000 don’t, that is not the same problem as a smaller regression experienced by everybody.

However convenient the dashboard makes it feel, one number cannot describe an entire customer base.

What skills or ways of thinking would you encourage an early-career front-end developer to develop today?

I would focus on the fundamentals, particularly if you plan to work in the browser: understand browser APIs, HTTP, the web platform, and the protocols beneath it.

Framework knowledge is useful, but the fundamentals will remain useful long after individual tools have disappeared.

Every dollar I have made as a consultant is because I read the specification a little more closely than my client.

It sounds trite, but it is true. Browser-native solutions are generally faster, more accessible, more secure, and maintained by somebody else. They’re usually a pretty safe bet.

React and Next.js are already beginning to fall out of favour after years as the industry’s golden children.

➡️ Know the tools and their trade-offs, but keep yourself close enough to the web that the tools don’t become the career.

AI can now generate working front-end code remarkably quickly. How can teams avoid creating bloated, poorly understood websites, and ensure it helps them build better ones instead?

Even if AI generates the code, the person steering it still needs to recognise good design, choose appropriate patterns, know when to refactor, and take responsibility for the result.

Developers may spend less time typing every line and more time guiding an LLM to produce code in their image, so to speak, but the need for sound engineering judgement remains.

We’ve been abstracting lower-level work away for decades; I have never written a single line of assembly or machine code because better ergonomics made that unnecessary a long time ago. AI is just the next step in that evolution, in my opinion.

But juniors still need to learn what good software looks like, even if they produce it through a different means. AI doesn’t remove their need to learn when to refactor or which design pattern suits the job.

AI won’t replace developers, it’ll replace typists.

As an independent consultant, how do you balance client delivery with marketing, administration and running the business?

Honestly, sometimes not very well! I love the technical work, difficult problems, and learning what clients need.

I love meeting new clients — and continuing to work with old ones — because every organisation presents a different problem.

Paperwork and administration are the bane of my life, so I offload them to somebody who is both better at them and happier doing them: my accountant.

I still prefer long-form writing as marketing, although audiences increasingly favour video.

I have experimented with LinkedIn, video courses, and a private subscriber community without finding the perfect mix.

Fortunately, client work has left little time to worry about it this year!

What advice would you give to someone with no public speaking experience who wants to get started?

Start locally. Meetups need speakers and give you a more familiar place to develop before you step onto a larger conference stage.

If you need to submit a CFP, keep it true to the talk you can deliver while tailoring it to the specific event. When you get accepted, nail the introduction. Know the first couple of minutes well so that you can settle in, find your cadence, and trust yourself with the remaining 30 or 45.

On the actual day, stick to a bit of a drill to keep you as close to autopilot as possible. Have a checklist of things to do that you can run through repeatably — that calms the nerves a lot.

Everybody in the room wants you to succeed, so don’t feel vulnerable. Decide what you want speaking to do for you, too: improve your employability, lead towards developer relations-type roles, or become a career in its own right.

I never intended to speak at all. I was invited, said yes, and nearly 200 events later, here I am.

Finally, if an organisation could take only one step towards building a faster, more durable website, what should it be?

Step away from the front-end framework.