Website speed, explained for people who don’t write code

You got a report with a red score, or a client told you the site “feels slow on the phone”. You open the page on your laptop, it loads right away, and you do not understand what the fuss is about. Meanwhile someone proposes a plugin, someone else a more expensive hosting plan, and a third person says you need a new site.

The problem is not that you do not know how to code. The problem is that “speed” means several different things, measured in different ways, and the people selling you solutions rarely say which one they mean. Without a shared vocabulary you cannot ask for something concrete and you cannot check whether you got what you paid for.

Below you will find what Google actually measures, why a desktop report says nothing about a client’s phone, what usually breaks speed, and the myths you hear most often.

What Google measures when it says a site is slow

For ranking, Google uses three measurements, grouped under the name Core Web Vitals. Each one answers a question every visitor asks.

LCP: how long until I see what I came for

Largest Contentful Paint measures the time until the largest visible element in the first part of the page appears: usually the main image, a large heading or a block of text. It does not matter when the whole site finished loading, but when the person sees the content they clicked for. The “good” threshold is under 2.5 seconds.

INP: how fast the page reacts when I tap something

Interaction to Next Paint measures the delay between a tap (on a button, a menu, a form field) and the moment the screen visibly reacts. If you tap “Add to cart” and nothing happens for a second, that is bad INP. The “good” threshold is under 200 milliseconds. INP replaced the older FID measurement in March 2024, because FID only looked at the first tap, while INP looks at all of them.

CLS: how much the page jumps while it loads

Cumulative Layout Shift measures how much elements move on screen after they have appeared. The classic example: you want to tap a link, a banner loads above it, everything moves down and you tap something else. The value is not in seconds, but a number that adds up all the jumps. The “good” threshold is under 0.1.

Lab or field: why two reports on the same site do not match

When you open PageSpeed Insights, you get two sets of data for the same address, and they say different things.

Field data is at the top of the report. It comes from the Chrome User Experience Report (CrUX): real values, measured on your visitors’ devices over the last 28 days. This is the data Google uses for ranking. If the site has too little traffic, the section is missing.

Lab data is further down, with the 0 to 100 score. It comes from Lighthouse, a test run once, on a simulated device, with an artificially slowed connection. It is useful as a diagnostic, because it tells you specifically what is blocking the page. But it is a single test, at a single moment, on a machine that belongs to none of your clients.

Why mobile is the only report that really counts

Google indexes the mobile version of your site. When it evaluates speed, it looks at what happens on the phone, not on the laptop in the office.

And on the phone things are different. The processor is weaker, the connection less stable. JavaScript suffers the most: the same code a laptop runs in an instant costs several times more time on an ordinary phone. That is why a site that looks fine on desktop can fail INP on mobile without anyone in the company noticing.

What usually breaks speed, in order of impact

There is no universal recipe, but in practice the same causes keep coming back, in roughly the same order.

1. Images: too large, in old formats, all loaded at once

The most common cause of bad LCP. A photo 4,000 pixels wide, displayed in a space of 800, is downloaded in full. Modern formats, WebP or AVIF, give the same image at a fraction of the size. Images below the first screen should be loaded lazily (lazy loading), only when the visitor reaches them. Watch out for a common mistake: the main image, the one that determines LCP, must not be lazy loaded. It has to start first.

2. Too much JavaScript, loaded too early

This is where INP is lost, along with part of LCP. The usual sources: page builders (visual page construction tools) that load their whole arsenal on every page, marketing scripts (pixels, tag manager, heatmaps) and chat widgets. Each one looks small. Together, on a phone, they block the page for whole seconds. The fix is not necessarily to remove them, but to load them after the page is usable, and only where they are actually used.

3. Fonts

Several font families, each in several weights, means dozens of files. Text appears late, or appears in one font and then switches to another and the page jumps. What matters is the number of fonts, whether the main font is announced early (preload) and how font-display is set, meaning what the browser does while the font has not arrived yet.

4. Server response time

TTFB (Time to First Byte) is how long it takes for the server to send the first byte of the page. If it is high, everything that follows starts late. What helps here is page caching (the page is served already built, not generated on every visit), correctly sized hosting and a clean database. This is the only area where hosting really matters.

5. CSS that blocks rendering

The browser draws nothing until it receives the styles. If the theme loads a huge CSS file for all pages, the visitor waits for rules their page does not need. The usual solution: the styles for the first part of the page placed directly in it, the rest loaded afterwards.

6. Elements that jump

CLS almost always comes from three places: images without declared width and height, banners or consent bars inserted after loading that push the content down, and fonts that switch on the fly. These are cheap fixes, but they have to be done on every page type.

If you want to see how this order looks applied to a WordPress site under monthly maintenance, the page about WordPress site performance describes exactly these steps.

The myths you hear most often

“A score of 100 is mandatory.” No. The score comes from the lab, and Google uses the field. A site with a lab score of 78 and all mobile field values in the green is fine. One with 100 on desktop and red field data on mobile is not.

“A caching plugin fixes everything.” Page caching helps TTFB, because the server no longer builds the page on every visit. It does not remove a single byte of JavaScript and it does not shrink a single image. If the problem is INP, caching does not touch it.

“A CDN makes the site fast.” A CDN brings the files closer to the visitor, so it helps with distance. It does not help with weight. A 6 MB page stays a 6 MB page, it just comes from closer.

“It’s the hosting’s fault.” Sometimes, yes: a TTFB of several seconds is a server problem. Most of the time, though, the server responds reasonably and the rest of the time is lost in the page, on the visitor’s phone. More expensive hosting does not change that.

“More optimization plugins means better.” Two plugins that defer the same JavaScript or minify the same CSS step on each other’s toes. The result is often slower than with none at all. One tool, configured with care, beats three installed at random.

How to measure correctly, without being a developer

You need three sources, and none of them costs anything.

PageSpeed Insights, run on the important pages, not only the home page: the product page, the category page, the contact form, the most read article. Write down the three mobile field values for each.

Search Console, the Core Web Vitals report. It shows you, by groups of pages, how many addresses are “good”, “need improvement” or “poor”, again from field data. It is the only place where you see the whole site, not one page at a time.

A real phone, on mobile data. Leave the office Wi-Fi, open the site on 4G, time how long it takes until you see the content and tap a button. It is not a scientific measurement, but it is the closest thing to what a client feels.

If you want a quick first look at speed, security and SEO together, the site check tool gives you a starting point in a few minutes.

What to ask from whoever maintains your site

Do not ask for “a fast site” and do not ask for “a score of 100”, because you get whatever is easy to deliver. Ask for:

• the three field values, on mobile, under the thresholds (LCP under 2.5 s, INP under 200 ms, CLS under 0.1);
• on the pages that bring in money: product, category, cart, contact, the most read articles;
• verified in Search Console, not in a single lab test;
• with a list of what was changed, so you know what to keep at the next design change.

Speed is not fixed once. Every new plugin, every campaign banner, every image uploaded without compression wears it down a little. Field data is recalculated over the last 28 days, so a problem introduced today shows up in the report a few weeks later. The values are worth checking monthly, not only when someone complains.

Checklist

• Run PageSpeed Insights on 3-5 important pages, not only the home page.
• Read the field section, on mobile; ignore the lab score on the first pass.
• Write down LCP, INP and CLS for each page and compare with the thresholds: 2.5 s, 200 ms, 0.1.
• Open the Core Web Vitals report in Search Console and see how many addresses are “poor”.
• Check the main image of each page: modern format, right size, no lazy loading.
• List the marketing and chat scripts and ask which ones are really used.
• Count the fonts loaded; more than two families deserves a conversation.
• Check TTFB; if it is high on all pages, only then talk about hosting.
• Make sure you have one optimization plugin, not three.
• Test a product or contact page on a real phone, on mobile data.
• Put a monthly check of the field values in your calendar.