If we think of a website as a restaurant, the dining room is the frontend: the tables, the lighting, the way the dish is presented; the kitchen is the backend: the servers, the database, the code running behind the scenes. The dining room handles the impression; the kitchen decides whether the food arrives, and when. And no matter how polished the dining room is, a slow kitchen keeps the customer waiting — and it's the customer who does the judging.

Google's metrics

Core Web Vitals are three metrics, each corresponding to a part of the user experience:

• LCP (Largest Contentful Paint) measures the time until the main content appears (the moment the dish reaches the table).
• INP (Interaction to Next Paint) measures how quickly the page responds to user interactions, such as a click or a tap.
• CLS (Cumulative Layout Shift) measures visual stability — whether elements jump around while the page loads.

There is, however, one point that shapes the entire strategy: Google evaluates based on real Google Chrome users over a 28-day window. It focuses on the 75th percentile — that is, on the experience of the slowest users, not on an average. That's why backend decisions carry so much weight: they affect every request, not just the test environment.

It all starts at the server

Before any content can be delivered, there's a time gap between the moment the request is made and the moment the browser receives that first response. This interval is called TTFB (Time to First Byte), and the recommendation is to keep it below 800 milliseconds. This is decisive, because TTFB is the first slice of LCP.

A high TTFB is almost always one of two things. The first is the database, when the application makes dozens of small queries instead of one (like asking the cook to go to the pantry once for every single ingredient they need). The second is a lack of caching — that is, storing ready-made responses instead of recalculating them on every request.

Then there's rendering, which means having the server deliver a page that's almost ready to display (good for LCP, but it requires caching). Doing it on the client relieves the server but forces more waiting time in the browser. There's no option that's better across the board — there's a right one for each page.

Interactions, stability, and SEO

INP and CLS live mostly on the frontend, but an interaction — a search, a filter, an item tossed into the cart — almost always depends on a server response. If that response is slow, the page becomes sluggish no matter how nimble the frontend is; and an oversized response has the same effect, forcing the browser to process more than it needs to.

In technical SEO, the backend is decisive: before ranking anything at all, Google has to be able to read the page — and what governs that reading is the server. A slow server, or one full of errors, makes the bot give up sooner and visit fewer pages: this is the so-called crawl budget.

What changes with AI

There's a new reason to take all of this even more seriously: AI-generated responses read the page's structure to decide whether to cite it. A backend that delivers clean, fast HTML is no longer just about performance — it's now about visibility.

The dining room still matters a great deal, but it's the kitchen that calls the shots, determining what can be served, and how fast.