What makes a website fast, and why Google cares

Most conversations about website speed end up in the wrong place: a score out of 100, a colour, an argument about hosting. The useful version is simpler. Three numbers describe how a page feels to the person holding the phone, and Google has published what counts as good for each.

Three numbers: loading, responding, staying still

The Core Web Vitals are three measurements, each answering a question a visitor would recognise.

• Largest Contentful Paint (LCP) — how long until the main thing on the screen appears. Usually a hero image, a product photo or a block of headline text.
• Interaction to Next Paint (INP) — how quickly the page responds when someone taps, clicks or presses a key.
• Cumulative Layout Shift (CLS) — how much the page moves about while it settles. A score, not a time.

Between them they cover loading, responsiveness and visual stability. Nothing else on the list is a stand-in for a visitor's patience in the way these three are.

The thresholds and how they are measured

The published thresholds for a good experience are these:

Two details change how you should read those numbers.

First, each metric is assessed at the 75th percentile of page loads. Your own visit on good office Wi-Fi is not the measurement. Three quarters of visits need to hit the threshold, which means the slower end of your audience — older phones, weak signal — is doing the deciding.

Second, mobile and desktop are assessed separately. A site can pass on desktop and fail on mobile, and that distinction matters because Google uses the mobile version of a site's content for indexing and ranking. Google's guidance is that mobile and desktop should carry the same content; a stripped-back mobile version is not a shortcut to a better score.

What slows the largest element down

LCP is the one most people can feel. The Chrome team breaks the time before the largest element appears into four parts:

1. Server response time — how long the server takes to send the first byte of the page.
2. Resource load delay — the gap between the page starting and the browser even beginning to fetch the important image.
3. Resource load duration — how long that image takes to download.
4. Element render delay — the gap between the image arriving and it actually being painted on screen.

The common failure in practice is the second one. The browser cannot start downloading the hero image until it knows the image exists, and on a page assembled by a builder or loaded through script it can find out late. Add an oversized photograph straight off a camera and you have a long download on top of a late start. The published advice is direct: prioritise the LCP image so the browser discovers and fetches it early.

This is where hand-built pages and considered art direction, content and imagery do real work. Choosing which single image carries the top of the page, sizing it properly and making sure it is the first thing requested is design and build working together, not an optimisation applied afterwards.

Why pages jump, and how to stop it

Layout shift is the thing that makes someone tap the wrong link. You go to press a button, an advert or a banner loads above it, and the button moves out from under your thumb.

The two usual causes are documented plainly. Images inserted without dimensions force the browser to guess how much space to reserve; when the image arrives, everything below it jumps. And late-loading content — a cookie notice, a review widget, an embedded map, a web font swapping in — pushes existing content down after the visitor has already started reading.

Both are preventable at build time by reserving the space these elements will occupy before they arrive. Retro-fitting that on a template you did not write is harder, which is one of the reasons a website redesign often produces a larger improvement than another round of patching.

Why taps feel slow

A page can look finished and still be unresponsive. INP measures the gap between a visitor's interaction and the next paint on screen — the moment something visibly changes in response to what they did.

The usual cause of a poor INP is long JavaScript tasks. While the browser is occupied running a long piece of script, it cannot paint anything, so the tap appears to do nothing. The visitor taps again. This is why script-heavy sites — a builder, several plug-ins, a handful of third-party trackers — feel sticky on a mid-range phone even when they load quickly on a laptop. The fix is almost always less JavaScript, or JavaScript broken into smaller pieces, which is a decision taken when the site is designed and built, not a setting you switch on later.

How much Google weighs it

Google states that Core Web Vitals are used by its ranking systems and recommends that site owners achieve good Core Web Vitals for success with Search. It also states that page experience is one consideration among many, and that great content still matters most.

So the honest position is this. Speed is not a substitute for having something worth reading. If a competitor has answered the question better than you have, a faster page will not fix that. But where two pages serve the searcher equally well, the one that loads, responds and holds still is the one Google's own guidance tells you to build — and the one more likely to be read rather than abandoned. No one can promise a ranking position, and anyone who does is not quoting Google. Speed belongs alongside the content and structure work described under SEO in Malta, not instead of it.

Checks you can run on your own site

You do not need a tool to notice most of these. Use your own phone, on mobile data rather than Wi-Fi, and open your site cold.

• Count the seconds until the main image or headline is actually visible. Two and a half seconds is the published target.
• Watch the page for five seconds after it looks finished. Does anything push the content down? That is layout shift.
• Tap the menu, then a product or service link. Does the screen change immediately, or do you wait and wonder whether it registered?
• Do the same on an older phone, or ask a member of staff to. The 75th percentile of your visitors is not using your device.
• Check that your mobile pages carry the same content as desktop, not a reduced version.

If the answers are uncomfortable, the fixes usually sit in how the site was assembled rather than in a plug-in you have not tried yet. You can see the full range of services, or start a project and describe what your visitors are experiencing.