Why Your Website Is Slow — and What Actually Fixes It

It's okay if your website is slow. We can fix it!

Why Your Website Is Slow — and What Actually Fixes Core Web Vitals in 2026

Your site probably tested fine. On your laptop, on office wifi, on a fast connection, everything loads instantly.

Your customer is on a three-year-old Android phone, on a 4G connection that drops to something worse in a lift, with eleven other tabs open. That is the condition your website actually performs in, and it is why so many businesses are convinced their site is fast while their analytics quietly disagree.

Here is what Google actually measures, why most sites fail, and — more usefully — which fixes are worth your time.

The three metrics, in plain language

Google’s Core Web Vitals have settled into three metrics. They are not arbitrary: each corresponds to a moment where real people give up.

Largest Contentful Paint (LCP) — target: under 2.5 seconds. How long until the main thing on the page appears. Usually your hero image or headline. This is the “is anything happening?” metric, and it is the one most sites fail.

Interaction to Next Paint (INP) — target: under 200 milliseconds. When someone taps something, how long until the page visibly responds. This replaced the older First Input Delay metric because FID measured only the first interaction and flattered sites that got progressively worse. INP is harsher and much more honest.

Cumulative Layout Shift (CLS) — target: under 0.1. How much the page jumps around while loading. Everyone has experienced this: you go to tap a link, an ad or image loads above it, the page shifts, and you tap something else. That is CLS, and it is infuriating.

To pass, you need the target on all three for 75% of real visits. Not lab tests — actual visitors, on actual devices.

Why “my PageSpeed score is 92” doesn’t mean you passed

The most common confusion in this whole area.

The score you get from running a page through a testing tool is a lab test: a simulated device on a simulated connection, run once. Useful for diagnosis. It is not what Google uses.

What Google uses is field data — real measurements from real Chrome users on your site over the preceding 28 days. Your Search Console has this. It is frequently much worse than your lab score, because your real audience is not a simulated mid-tier device on a stable connection. They are on worse hardware, worse networks, and often arriving from a social app’s in-app browser, which is slower again.

Check the field data, not the lab score. If they disagree, the field data is right.

Why most sites fail — five causes, in order

Nearly every slow site we audit fails for the same handful of reasons.

1. Images that are far too large. Still, in 2026, the number one cause. A 4MB hero photograph exported straight from a camera or a stock library, served at full resolution to a phone that will display it 400 pixels wide.

The fix: serve modern formats (WebP or AVIF), size images to their actual display size, serve different sizes to different screens, and lazy-load anything below the fold — but never the hero image, because lazy-loading your LCP element makes it worse.

2. Too much JavaScript, running too early. Analytics, a chat widget, a heatmap tool, three marketing pixels, a cookie banner, a popup library. Each was added by a different person for a good reason and nobody has ever removed one.

Every script competes for the same single thread that also has to respond when a user taps something. This is the main cause of poor INP.

The fix: audit what is actually loading and delete what nobody uses. Defer everything non-essential until after the page is interactive. Be particularly suspicious of chat widgets and heatmap tools, which are among the heaviest things commonly installed.

3. Fonts. Three font families, six weights each, loaded from an external domain before any text can render. The result is either invisible text for a second or a visible jump when the real font arrives — hurting LCP and CLS respectively.

The fix: two families maximum, only the weights you use, self-hosted, preloaded, with font-display: swap and a fallback chosen to match the metrics closely so the swap barely shows.

4. No dimensions on images and embeds. The browser does not know how much space to reserve, so it reserves none, then shoves the content down when the image arrives. This is nearly all CLS, and it is entirely preventable.

The fix: width and height attributes, or a CSS aspect ratio, on every image, video, iframe and ad slot. Also reserve space for anything that appears dynamically — banners, cookie notices, injected offers.

5. The platform is doing too much. Page builders and heavy themes generate a great deal of code to render not very much. If your site is built on a stack of plugins each adding scripts and styles to every page, you are paying a performance tax on every visit.

The fix: this one is structural. You can trim, but if the platform is the problem, no amount of optimisation gets you to a good result. That is a rebuild conversation, and an honest developer will tell you so rather than selling you six months of tuning.

What actually moves the needle, ranked

If you have limited time, do these in order.

1.        Fix your images. Compress, convert, resize, lazy-load below the fold. Frequently halves load time on its own.

2.        Remove scripts nobody uses. Free, fast, and often surprising — most sites are carrying tools installed for a campaign that ended two years ago.

3.        Set dimensions on everything. Fixes CLS almost completely, usually in under an hour.

4.        Sort out fonts. Fewer families, self-hosted, preloaded.

5.        Defer what is left. Nothing non-essential should block the first render.

6.        Then, and only then, consider the platform. Rebuilding for performance alone is rarely justified. Rebuilding because the platform is also limiting everything else you want to do — that is a different conversation.

The part most articles skip: speed is a design decision

Performance work is treated as something developers do at the end. Most of it is decided much earlier, by designers, and the biggest wins are unavailable by the time anyone opens a profiler.

A full-screen autoplaying video background is a performance decision. A carousel of twelve high-resolution images is a performance decision. A page with four embedded third-party widgets is a performance decision. So is a design requiring six font weights.

None of these are wrong in principle. They are simply expensive, and the cost should be paid knowingly. The fastest sites we build are not the ones with the cleverest optimisation — they are the ones where the design did not ask for very much in the first place.

This is also why performance and conversion tend to improve together. A page that loads fast is usually a page with a clear hierarchy and one obvious thing to do — which is the same thing that makes it convert. We covered the conversion side of that in the twelve leaks we find on almost every site.

Does any of this actually affect rankings?

Yes, but modestly, and it is worth being precise because this area attracts a lot of exaggeration.

Core Web Vitals are a ranking signal, not a large one. Relevance and authority matter far more. A slow page with the best answer will usually still outrank a fast page with a worse one.

Where speed genuinely pays is everything after the click. Slow pages lose visitors before they see anything, and that is a direct revenue cost, unrelated to rankings. On mobile in India, where connection quality varies enormously between one part of a city and another, this effect is larger than most businesses assume.

So: optimise for the visitor, and take the ranking benefit as a bonus. That way round, the work is always worth doing.

Frequently asked questions

What are the Core Web Vitals in 2026? Three metrics: Largest Contentful Paint (under 2.5 seconds), Interaction to Next Paint (under 200 milliseconds) and Cumulative Layout Shift (under 0.1). You need to hit all three for 75% of real visits to pass.

Why is my PageSpeed score good but my site still fails Core Web Vitals? Because the score is a lab simulation and Google uses field data from real Chrome users over 28 days. Real visitors on older phones and variable connections perform worse than the simulation. Check the field data in Search Console.

How much do Core Web Vitals affect SEO rankings? They are a genuine but relatively minor ranking signal — relevance and authority matter considerably more. The stronger business case is conversion: slow pages lose visitors before they read anything.

What’s the single biggest cause of slow websites? Oversized images, still. Large uncompressed files served at full resolution to mobile devices. Fixing images alone often produces the largest single improvement available.

Can a Wix or WordPress site pass Core Web Vitals? Yes, with discipline — restrained design, few plugins, properly handled images and fonts. It is harder than on a lean custom build, and heavy page-builder themes make it considerably harder again.

How often should I check performance? Monthly in Search Console, and always after adding a new script, plugin or marketing tool. Performance degrades gradually through accumulation rather than suddenly, which is why nobody notices.

Want to know what’s actually slowing your site down? Our free website audit covers performance alongside conversion — you’ll get a Conversion Leak Report showing what’s costing you visitors and what to fix first. Request your audit →