Why Website Speed Matters (and What Slows Yours Down)

People who build a site rarely feel how slow it is. They open it on office wifi on a recent laptop, with half the files already cached. A customer opens it for the first time on a mid-range phone with a weak signal. Those are two different websites, and only the second one matters.

Speed affects two things. Visitors who wait leave before they see your offer. And Google uses page experience signals, including loading speed, in its ranking systems, though with a clear limit we’ll come to.

What Google actually measures

Google’s speed and experience metrics are called Core Web Vitals. There are three, and the current “good” thresholds from web.dev are:

• Largest Contentful Paint (LCP), 2.5 seconds or less. How long until the main content, usually the hero image or headline, appears.
• Interaction to Next Paint (INP), 200 milliseconds or less. How quickly the page responds when someone taps or clicks. INP replaced First Input Delay on 12 March 2024, so any guide still talking about FID is out of date.
• Cumulative Layout Shift (CLS), 0.1 or less. How much the layout jumps around while loading. The classic case is the button that moves just as you tap it.

Each is judged at the 75th percentile of real visits, separately for mobile and desktop. In practice, three out of four visits need to hit the threshold, not just your own.

On rankings, be precise. Google says Core Web Vitals “are used by our ranking systems”, but also that good scores don’t guarantee top positions, and that it “always seeks to show the most relevant content, even if the page experience is sub-par.” Speed helps most when several pages are equally relevant. It won’t rescue a page that doesn’t answer the search, and a fast site with nothing useful on it won’t rank.

How to read PageSpeed Insights

Run your most important pages through PageSpeed Insights, not only the homepage. You’ll see two sections that often disagree, and that confuses people:

• Field data at the top comes from real Chrome users over the previous 28 days (Google’s documentation). This is how actual visitors experienced the page. Low-traffic sites may not have enough data to show it.
• Lab data below comes from a single simulated load by Lighthouse, on an emulated mid-tier phone with a throttled connection. It’s for diagnosing problems. The 0 to 100 score belongs to this section.

If field data says your LCP is fine, a lab score of 70 is not an emergency. If field data says it’s poor, the lab section’s diagnostics tell you why. For a whole-site view, the Core Web Vitals report in Google Search Console groups your pages by status.

What slows sites down, and the fix for each

Slow main content (LCP)

• Oversized images. A photo straight from a phone can be several megabytes when the page needs a fraction of that. Resize to the size it’s shown at, serve modern formats like WebP or AVIF, and give phones smaller versions than desktops.
• The hero image is lazy-loaded. Lazy loading is good for images further down the page. On the main image it delays the very thing LCP measures. web.dev’s advice is blunt: never lazy-load your LCP image.
• Slow server response. On cheap, crowded hosting, or a site that builds every page from scratch on every visit, the browser waits before receiving anything at all. Page caching and a CDN help. So does better hosting.

Slow responses to taps (INP)

INP problems usually come from JavaScript keeping the browser’s main thread busy, though a very large, complex page can also be slow to redraw (web.dev). Every chat widget, tracking pixel, slider plugin and page builder adds script. List what loads on your page and remove anything nobody would miss. For what stays, ask whether it needs to load immediately or can wait until after the page is usable.

Jumping layout (CLS)

• Images and videos without dimensions. Set width and height so the browser reserves the space before the file arrives (web.dev).
• Banners, embeds and cookie bars that push content down. Reserve their space in advance or show them as an overlay.
• Web fonts that swap late and reflow the text. Preload the main font and choose a fallback with similar proportions.

Where to start

1. Open PageSpeed Insights on your three most important pages and note which of the three metrics fail in field data.
2. Work on the failing metric with the matching list above, starting with whatever the diagnostics show as the biggest saving.
3. Wait for the 28-day field data to catch up before deciding whether it worked.

You don’t need a perfect lab score. You need the three Core Web Vitals in the green for real visitors, on phones especially. If you’re not sure what’s dragging your site down, send us the address and we’ll tell you what’s worth fixing. Performance is a fixed requirement in the sites we build, and the same checks apply on mobile, where most of these problems get worse.