Make your site fast for real visitors

Speed is how it feels, not how it scores

A visitor does not care about your total page weight. They notice three things: how long before they see something real, how long before the page responds when they tap, and whether things jump around while they read.

Google names these the Core Web Vitals:

• Largest Contentful Paint (LCP): how long until the biggest thing on the screen, usually a hero image or headline, is visible. Good is 2.5 seconds or less.
• Interaction to Next Paint (INP): how quickly the page reacts after a tap or click. Good is 200 milliseconds or less.
• Cumulative Layout Shift (CLS): how much the page moves unexpectedly while loading. Good is 0.1 or less.

The pass mark is judged at the 75th percentile: a vital passes when at least three of four visits are good. That is deliberate. A site that is fast for half its visitors is not fast.

Speed in Growth Score reads page speed measured by your pixel on real visits, so it needs the pixel installed. Until then, you can still find the blockers by hand.

Lab data and field data

Lab data is one controlled test: one device, one connection, one moment. It is repeatable, which makes it good for debugging. It also lies by omission, because it cannot see your slowest visitors.

Field data is measured from real people as they use the site. It captures old phones, patchy mobile networks, far-away countries and heavy pages after cookies, and it is what Google's ranking signal uses.

Use both, in this order:

1. 1Field data tells you whether you have a problem and which page.
2. 2Lab data tells you why, on that page, while you try fixes.
3. 3Field data again, a few days after you ship, tells you whether it worked.

A lab score that improves while field data does not means you fixed the wrong thing. Real-user measurement needs a little traffic and a little time, so a new site should expect a week or more before the numbers settle.

Fix 1: images, the big win

Images are most of the weight of most pages and, very often, the largest element that LCP waits for.

• Compress them. A photo exported at full camera size rarely needs to be over a few hundred kilobytes on the web.
• Use modern formats such as WebP or AVIF with a fallback.
• Serve the right size. A phone should not download a 3000 pixel wide image to show it 400 pixels wide. Use responsive image attributes.
• Do not lazy-load the hero image. Lazy loading is for images below the fold. The one at the top should load first, and you can mark it as high priority.
• Set width and height on every image so the browser reserves the space and nothing shifts.

One oversized hero image is the most common single cause of a slow LCP, and the easiest one to fix: it is one file and one afternoon.

Fix 2: scripts, the quiet tax

Every script has a cost: it downloads, it runs on the main thread, and while it runs the page cannot respond. Third-party scripts are the worst offenders because you did not write them and cannot easily change them.

Go through them:

• List everything your page loads. The tracker check shows every third party and what each is for.
• Remove what nobody uses. Old chat widgets, abandoned A/B tools and duplicate analytics are common.
• Load what remains late. Add defer or async so a script does not block the first paint, and load non-essential ones after the page is usable.
• Split big bundles so a page loads only the code it needs.
• Watch your tag manager. It is a door through which people add scripts without a developer, and it tends to fill up.

Fewer, later scripts improve INP most, because INP suffers when the main thread is busy.

Fix 3: stop layout jumps

Layout shift is the page moving as you read it: you go to tap a button and an ad loads above it and pushes it down. It is infuriating and it is measurable.

The usual causes and fixes:

• Images and video without dimensions: set width and height or an aspect ratio.
• Ads, banners and embeds that load late: reserve a box of the right size for them.
• Web fonts that swap after load and change the text width: preload your key fonts and choose a fallback font that matches the metrics.
• Content injected above what the visitor is reading, like a cookie banner pushing the page down: overlay it or reserve its space.

A good test: load the page on a throttled connection and watch the first few seconds. If anything moves, you have found a shift.

Fix 4: the slow start

A page cannot paint before the first byte arrives. If your server takes a long time to respond, every other fix starts from behind.

Three changes help most:

• Put a content delivery network (CDN) in front of the site so files are served from near the visitor.
• Cache pages and assets, and set sensible cache headers so a returning visitor does not download everything again.
• Turn on text compression (gzip or Brotli) for HTML, CSS and JavaScript.

Also check redirects. Each hop adds a full round trip, and chains like http to https to www to a trailing slash add up. The address check finds the patterns, and fixing them to a single redirect saves time on every first visit.

Set a budget so it stays fast

Sites do not get slow in one release. They get slow by a hundred small additions, each of which seemed fine.

A performance budget is a limit you agree in advance and check on every change. Keep it simple:

1. 1Pick the three pages that matter most (home, a product or pricing page, and the page where people sign up or pay).
2. 2For each, write down the vitals you are targeting.
3. 3Add a rule: a change that pushes a page past the budget needs a reason, or it does not ship.
4. 4Review the field numbers weekly for a month, then monthly.

Tie speed to the outcome. Slow pages cost you at the step that pays, so check conversion on the pages you speed up. If it moves, you have a business case for the next fix. If it does not, the bottleneck was elsewhere.

A two-hour speed pass

For your slowest important page:

1. 1Run the speed blockers check and write down the top two items.
2. 2Replace the hero image with a compressed, correctly sized one.
3. 3Set width and height on images.
4. 4Remove one unjustified script.
5. 5Defer the scripts that do not need to run first.
6. 6Retest in the lab, then check real-visit numbers after a few days.

Install the pixel and Growth Score reads speed from real visits, so you see the effect of each fix with a date on it. The free Growth Diagnosis shows where your site stands today.