Website speed and SEO
Speed and SEO are two things almost every website proposal promises. So how does it actually work?
Google PageSpeed Insights
Three primary values that Google calls Core Web Vitals:
- LCP, how long it takes to render the largest element. Good is under 2.5 seconds, bad is over 4 seconds.
- INP, how quickly the page responds to a click. Good is under 200 milliseconds.
- CLS, how much the content jumps around while loading. Good is below 0.1.
A lab number versus real visitors
This is worth keeping in mind, because a lot of proposals are built on it. PageSpeed Insights works with two sources of data at once. One is data from real browsers, the so-called CrUX, that is, what the people who came to the site actually experienced over the last twenty-eight days. The other is Lighthouse, a lab test in which a robot loads the page once on a simulated slow phone.
But Google only returns the data from real browsers for sites with enough traffic. For a typical company presentation all you get instead is a note that there is not enough data. So one number is left, the lab one, and the supplier's entire work then gets judged by it.
In practice this is what it means: a green score from a simulation means the site has no gross technical faults. It does not mean it is fast for a customer opening it on a five-year-old phone on a tram. And the other way round, a somewhat worse number on a site with a lot of traffic is more honest information than a hundred out of a hundred on a page ten people a day visit.
That is why on every project I ask how many people come to the site, where from and on what devices. Until those numbers exist, I treat Lighthouse as a hint, not as a result.
What hurts speed most often
When I see a slow company website, it is almost always one of these four things:
- Unoptimised images. A photo 4000 pixels wide displayed at 400 pixels. The fix is converting to modern formats and several sizes for different screens.
- Third-party scripts. Chats, heatmaps, review widgets, three different analytics tags. Each one is somebody else's code blocking the render.
- Fonts. Five weights downloaded before the first text is drawn. The ones the site genuinely uses are enough.
- Video in the hero. The most common silent killer. A video can be made tens of percent smaller with no visible loss of quality. Or the hosting and the way it starts playing can be changed.
How I handle technical SEO
I do not think about SEO after launch, but from the first page. Four things a site should have finished on the day it goes out:
- One first-level heading that says what the page is about.
- Its own title and description for every page, not one for the whole site.
- A sitemap that matches the actual content.
- Structured data, that is, a machine-readable description of what is on the page.
On a site that replaces an earlier one I add redirects from the old URLs. It is the most common reason traffic drops after a redesign, and it is dealt with before launch, not depending on what happens afterwards.
Speed and SEO in the age of AI
Language models do not read content the way a person does. What they care about is structure, clear answers to specific questions and a machine-readable description of who is behind the site. Sites with their headings and structured data in order show up in AI answers more often, even with less traffic. I wrote a separate article about optimising for AI answers.
A summary of what I deal with on every project is in the article on web development standards, and specifically for Webflow in the article on SEO in Webflow. How it all runs on an actual job is described on the custom web development page.
