Web Development 4 min read

Why Is My Website Slow? Core Web Vitals Explained Without the Jargon

What LCP, INP and CLS actually measure, the five things that cause almost every slow site, and how to tell whether your agency is fixing the real problem.

A laptop showing lines of code beside a notebook and pen.

Slow websites lose customers before they ever see your offer. That is not a marketing claim, it is arithmetic: every additional second of load time gives a visitor another chance to hit the back button and click your competitor instead.

Google measures this with three numbers called Core Web Vitals. They sound technical, but each one maps to something a human being actually feels.

The Three Numbers, in Plain English

LCP — How Long Until the Page Looks Loaded

Largest Contentful Paint measures when the biggest visible thing — usually your hero image or headline — finishes rendering. Target: under 2.5 seconds. This is the "is anything happening?" metric, and it is the one visitors punish you for most.

INP — How Long Until the Page Responds

Interaction to Next Paint measures the delay between a tap or click and the page visibly reacting. It replaced the older FID metric in 2024. Target: under 200 milliseconds. A page that looks loaded but ignores taps for half a second feels broken, even when it is not.

CLS — How Much the Page Jumps Around

Cumulative Layout Shift measures content moving after it appears — the reason you tap the wrong button when a banner loads late. Target: under 0.1.

Important. Google judges you on field data — real visits from real people on real phones and real connections — not the lab score you get from a one-off test. A site can score well in a test tool and still fail in the Chrome User Experience Report. Ask to see field data, not a screenshot of a lab run.

The Five Causes of Almost Every Slow Site

  1. Unoptimized images. Far and away the most common. A 4MB photograph straight from a phone camera, displayed 600 pixels wide. The fix is resizing, modern formats like WebP or AVIF, and explicit width and height attributes so nothing shifts while loading.
  2. Too much JavaScript. Page builders and plugin stacks routinely ship hundreds of kilobytes of script that the page never uses. This is the usual cause of a bad INP: the browser is too busy parsing code to respond to a tap.
  3. Third-party scripts. Chat widgets, analytics, heatmaps, ad pixels, review badges, font services. Each one is a request to a server you do not control, and each one can stall your page when it has a bad day. Audit them annually and delete the ones nobody looks at.
  4. Web fonts. Custom fonts that block rendering, or swap in late and shove the layout around. Either self-host them with sensible font-display settings, or use the system font stack. This website uses no web fonts at all — every character you are reading is already on your device.
  5. Cheap or distant hosting. If the server takes 800ms to think before it sends a single byte, no amount of front-end work saves you. Check Time To First Byte, and host near the people who actually visit you. Our hosting plans let you pick US, European or Australian data centers for exactly this reason.

How to Check Your Own Site in Five Minutes

  1. Run your homepage and your most important landing page through PageSpeed Insights. Read the field data section at the top, not just the lab score.
  2. Open Google Search Console and look at the Core Web Vitals report. It groups your URLs into good, needs improvement and poor, using real visits.
  3. Test on an actual mid-range phone on mobile data, not your desktop on office wi-fi. This is the experience most of your customers are having.

What Good Looks Like When Someone Fixes It

A credible performance engagement starts with measurement, changes one class of problem at a time, and measures again. Be wary of anyone who installs a caching plugin, shows you a green lab score, and calls it done — caching hides a slow site from test tools without making it faster for the person who arrives on a cold cache.

Realistically, images and script weight account for most of the win on most sites. If someone proposes an expensive rebuild before they have measured, ask what the measurement said.

Every site we build has a performance budget enforced during development and Core Web Vitals measured at handover — not promised, measured. If your current site is failing, our SEO and web development work both start with the same technical audit, and you get the findings whether or not you continue with us.

Common Questions

What is a good page load time in 2026?

Largest Contentful Paint should be under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1, measured at the 75th percentile of real visits rather than in a lab test.

Do Core Web Vitals affect Google rankings?

Yes, but as a tiebreaker rather than a primary factor. Relevance and content quality matter more. Where two pages are otherwise comparable, page experience can decide which one ranks — and speed always affects conversion regardless of ranking.

Will a caching plugin fix my slow website?

It will improve repeat visits and flatter test tools, but it does not fix oversized images, excessive JavaScript or a slow server. Those are the underlying causes on most slow sites and caching only masks them.

How much does it cost to make a website faster?

Targeted performance work on an existing site is usually a small fixed-scope project rather than a rebuild. The first step should always be a measurement-led audit, so you are paying to fix the actual bottleneck rather than guessing.