A fast site is how you get read, machines included.

Here is the good news, the part I still enjoy. The handful of decisions that make a site genuinely fast are the same ones that make it legible to a machine, so you do not optimise once for people, again for Google and a third time for an AI crawler. Build the thing well and all three follow.

01What fast actually means now.

For a long time "fast" was a vague virtue. Google made it measurable. The three numbers it settled on are the Core Web Vitals. The dashboard above is a live read of one site against them.¹ Largest Contentful Paint is how fast the main content appears; good is under 2.5 seconds. Cumulative Layout Shift is how much the page jumps as it loads; under 0.1. Interaction to Next Paint is how fast it responds when someone uses it; under 200 milliseconds. To pass, at least three-quarters of real visits have to clear all three.

The site in that dashboard is good on two and needs work on the third, which is the one I watch most. Interaction to Next Paint is the honest metric. It measures responsiveness across a whole session rather than a single first click, so a page that feels snappy in a demo but bogs down once someone starts clicking has nowhere to hide. It replaced the old First Input Delay in 2024. And it is almost always a story about JavaScript: the more work you hand the browser's main thread, the worse it gets.

02The handful of things that actually move it.

Strip away the tool lists and almost everything that makes a site fast comes down to three habits.

The first is to send less. Most slow pages are simply too heavy: uncompressed images, scripts that ship a whole library to do the work of a few lines, fonts and tags nobody ever audited. Serve images in a modern format like WebP or AVIF, sized to the space they actually occupy rather than to the full resolution straight off the camera, then let anything below the fold load lazily. Compress and minify what is left. The biggest lever on most sites is the one nobody enjoys pulling: shipping less JavaScript, because that main-thread work is exactly what INP punishes.

The second is to serve it close and serve it once. A content delivery network puts your files near the visitor instead of a single origin a continent away. Sensible cache headers mean a returning reader downloads only what actually changed. Both are close to free and both move the numbers the day you turn them on.

The third is to stop running a serious site on infrastructure that is fighting you. A crowded shared host that slows down every time a neighbour gets busy is a false economy on anything that matters. You do not need the most expensive option. You need one that gives you the headroom and the access to fix things when they break.

03The new reader in the room.

Until recently everything above served two audiences: the person waiting for the page and the search crawler deciding where to rank it. There is now a third. It changes the stakes in a way I find genuinely interesting. The AI engines behind tools like ChatGPT, Perplexity and Google's AI overviews read the web, then answer a question by citing a handful of sources and ignoring the rest. Being one of the cited few is the new version of ranking. It rewards exactly the same discipline.

An engine that reads the web is, in the end, a very impatient reader. It wants content it can fetch quickly, parse cleanly and trust: a fast response, a clear structure, markup that says what each thing is, no wall of script standing between the crawler and the words. A site built well for a person and for Google is already most of the way to being legible to an AI. The work compounds rather than multiplies.

This is not theory for us. We build our own site this way on purpose: fast, cleanly structured, machine-legible, the method we describe rather than just recommend. When an engine comes to read it, there is nothing in the way.

Build it well once and people, search engines and AI all find it the same way.

04Telling the machine what it is looking at.

A fast page that a machine cannot make sense of is a missed opportunity. Speed gets the crawler in the door; structure tells it what it is looking at once inside. That is the job of metadata: the title and description a search result shows, the card a shared link unfurls into and, most underrated of all, the structured data buried in the page that says, in a language machines read, this is an article, by this named person, published on this date, answering these specific questions.²

Search engines have read that structured data for years. The AI engines read it too. They lean on it harder because it is the cleanest signal of what a page actually is amid a lot of ambiguous prose. I will not lay out the whole recipe here. But the principle is simple and most sites still ignore it: do not make a machine guess what you could simply tell it. The page you are reading announces to any crawler, in schema.org's vocabulary, exactly what it is and who stands behind it. That costs almost nothing and it changes how confidently a machine can use you.

05Why a machine decides you are worth citing.

Speed and structure get you read and understood. Neither makes a machine trust you. Trust is what decides whether you are cited or quietly skipped. Google has a name for the thing it is looking for: E-E-A-T, for experience, expertise, authoritativeness and trustworthiness.³ The AI engines are chasing the same quality with less ceremony. Faced with ten pages that could answer a question, both would rather quote the one that plainly knows what it is talking about and can be stood behind.

The uncomfortable part, if you were hoping for a shortcut, is that there is not one. You cannot mark up your way to authority. It comes from the things that are slow to fake: a named author with a real track record, claims backed by sources a reader can check, content that matches the expertise the rest of the site claims, a consistent identity across the web. Machines have become surprisingly good at reading those signals, precisely because they are the ones a careful human editor would have weighed too.

This is the part I find reassuring rather than daunting. The work that makes you genuinely worth reading is the same work that makes you findable. You do not optimise for the machine and separately earn a person's trust. You earn it once and show your work. The reader and the engine reach the same conclusion.

06Where this goes.

The temptation is to treat all of this as a checklist to run once before launch. It is not. A site is a living thing: every new feature, every added script, every well-meaning marketing tag is a small tax on the same numbers. The sites that stay fast are the ones where someone keeps watching.

The reward for that attention is bigger than it used to be. A site that is fast, legible and genuinely worth trusting does not just rank and convert a little better. It is the price of admission to the places where people and, increasingly, machines decide what is worth reading.

QUESTIONS ON THIS PIECE

What readers tend to ask.

01What are the Core Web Vitals?

Three measures of real-world experience. Largest Contentful Paint (LCP) is how fast the main content appears, with a good target under 2.5 seconds. Cumulative Layout Shift (CLS) is how much the page jumps around as it loads, target under 0.1. Interaction to Next Paint (INP) is how fast the page responds when someone uses it, target under 200 milliseconds. INP replaced First Input Delay in 2024. To pass, at least 75% of real visits have to hit the good thresholds.

02Does page speed actually affect SEO?

Yes. The Core Web Vitals are confirmed Google ranking signals as part of page experience, on top of the more obvious effects on bounce and conversion. Speed is not the whole of ranking, but it is a measurable part of it. Unlike most ranking factors, it is fully in your control.

03What is GEO (Generative Engine Optimisation)?

GEO is making your content reachable and trustworthy to the AI engines that read the web and answer by citing a handful of sources: ChatGPT, Perplexity, Google AI overviews. It rewards the same things as good technical work: fast responses, clean structure and machine-readable markup. A site built well for people and for search is already most of the way there.

04What slows a site down the most?

On most modern sites, JavaScript. Heavy scripts block the main thread and hurt Interaction to Next Paint, the responsiveness metric. Shipping less JavaScript, deferring what is not critical and serving lean, modern images are the levers that move the numbers most. A content delivery network and sensible caching do the rest cheaply.