Website Speed and Core Web Vitals: The 2026 Guide to a Site That Loads Fast and Converts

Almost every business owner has been told their website should be faster. Very few have been told what that actually means, which parts of it matter commercially, or what to do about it beyond installing a caching plugin and hoping.

Here is the part that makes it worth your attention: speed is only a modest ranking factor, but it is a substantial conversion factor. A site that takes six seconds to become usable on a mid-range Android phone on a mobile connection loses a large share of its visitors before they see the offer at all. Those people do not bounce because your service is wrong. They bounce because nothing happened.

This guide explains what Core Web Vitals actually measure, how to diagnose your own site honestly, and the fixes that produce real improvement — ordered by how much difference they make, not by how often they get mentioned.

The Three Metrics That Matter

Google reduced page experience to three field metrics, measured from real Chrome users rather than from a test on a fast laptop. That distinction matters more than anything else in this guide.

LCP — Largest Contentful Paint

How long until the largest visible element in the viewport renders. Usually your hero image, a big headline block, or a video poster. It is the closest proxy for “when does the page look like it has loaded”.

Target: under 2.5 seconds. Above 4 seconds is classified as poor.

LCP is dominated by two things: how fast your server responds, and how heavy the largest element is. Most failing LCP scores trace back to an oversized hero image, a font that blocks text rendering, or a slow server.

INP — Interaction to Next Paint

How quickly the page visibly responds when a user taps, clicks or types — measured across the entire visit rather than only the first interaction. It replaced First Input Delay in 2024, and it is considerably harder to pass.

Target: under 200 milliseconds. Above 500ms is poor.

INP failures are almost always JavaScript. Long tasks block the main thread, so when someone taps a menu button nothing happens for half a second. The usual culprits are third-party scripts: chat widgets, heat maps, multiple analytics tags, ad pixels, A/B testing tools, and the four plugins nobody remembers installing.

CLS — Cumulative Layout Shift

How much the layout jumps around as the page loads. If you have ever gone to tap a link and had an ad push it away at the last instant, you have experienced bad CLS.

Target: under 0.1. Above 0.25 is poor.

CLS is the easiest of the three to fix and the most annoying to users. It is caused by images and iframes without declared dimensions, content injected above existing content (cookie banners, promo bars), and web fonts that swap in at a different size to the fallback.

Field Data vs Lab Data: Why Your 98 Score Is Lying

This trips up almost everyone. PageSpeed Insights shows two sections, and they mean completely different things.

• Field data (CrUX) — at the top, labelled “Discover what your real users are experiencing”. This is aggregated from actual Chrome users over the previous 28 days, on their actual devices and connections. This is what Google uses for ranking.
• Lab data (Lighthouse) — the big colourful score below. A single simulated load on Google’s test conditions. Useful for diagnosis, meaningless as a verdict.

A site can score 98 in the lab and fail its field metrics badly, usually because real users are on slower devices, worse networks, and with browser extensions running. It can also have no field data at all, which simply means not enough real traffic yet — not that everything is fine.

Practical rule: diagnose with lab data, judge with field data. If they disagree, the field data is right.

How to Diagnose Your Own Site Properly

1. Search Console, Core Web Vitals report. Start here. It groups your URLs by template and tells you which page types fail, which is more useful than testing one URL at a time. Fixing a failing template fixes hundreds of pages at once.
2. PageSpeed Insights on three representative URLs — homepage, a service page, a blog post. Read the mobile tab, not desktop. Almost all your traffic and all your problems are on mobile.
3. Chrome DevTools, Performance panel with CPU throttled to 4x and network set to Fast 3G. This simulates the mid-range phone your customers actually use. Record a load and look at what occupies the main thread.
4. Check TTFB directly. curl -o /dev/null -s -w "%{time_starttransfer}\n" https://yoursite.com/ tells you how long your server takes to start responding. Anything above 600ms is a hosting or backend problem that no front-end optimisation will fix.
5. Open the site on a real phone on mobile data, not office wifi, and try to complete your primary conversion action. Ninety seconds of this reveals more than most audits.

The Fixes, Ordered by Impact

1. Images (still the biggest single win)

On most business websites, images account for the majority of page weight and the majority of the LCP problem. What to do:

• Serve modern formats. WebP typically saves 25-35% over JPEG at the same visual quality; AVIF saves more again. Every current browser supports WebP.
• Size images to their display dimensions. Uploading a 4000px camera file and letting CSS shrink it to 600px means the visitor downloads roughly forty times more data than they needed. This is the single most common performance mistake on business sites.
• Use responsive images — srcset and sizes — so phones get phone-sized files.
• Lazy-load below the fold with loading="lazy", but never lazy-load the LCP element. Lazy-loading your hero image actively makes LCP worse, and this mistake is everywhere.
• Declare width and height on every image so the browser reserves space. This alone fixes most CLS.
• Preload the LCP image with <link rel="preload" as="image"> so it starts downloading immediately rather than after CSS parsing.

2. Third-party scripts

Usually the largest INP contributor and the easiest thing to cut, because much of it is not delivering value.

Open DevTools, reload, sort the Network panel by size and by blocking time, and list every third-party domain. Then ask, for each one, whether anyone has looked at its output in the past three months. Chat widgets that nobody staffs, heat maps installed for one project two years ago, three analytics tools measuring the same thing, abandoned A/B testing scripts — all of it runs on every page load for every visitor.

For what survives the cull: load it asynchronously, defer it until user interaction where possible, and self-host what you legitimately can.

3. Server response time and hosting

If TTFB is above 600ms, nothing you do in the browser will save you. Cheap shared hosting with hundreds of sites per server is the usual cause. Options, in order of cost:

• Enable full-page caching so repeat requests never touch PHP or the database.
• Add a CDN so static assets are served from a location near the visitor. Essential if your audience is spread across countries.
• Upgrade to hosting with dedicated resources — the difference between $3/month shared hosting and $25/month managed hosting is frequently the difference between a two-second and a five-second page.
• Optimise the database. On WordPress, that means clearing post revisions, expired transients and orphaned metadata, which accumulate for years.

4. CSS and JavaScript delivery

• Inline the critical CSS needed to render the first screen, and load the rest asynchronously. Removes the render-blocking round trip.
• Defer non-essential JavaScript with defer or async.
• Remove unused CSS and JS. DevTools’ Coverage panel shows exactly how much of each file is never executed. On a page-builder site it is frequently over 60%.
• Minify and compress. Brotli where available, gzip otherwise. This should be automatic; check that it actually is.
• Split large bundles so each page loads only the code it needs.

5. Fonts

• Use font-display: swap so text renders immediately in a fallback rather than staying invisible.
• preconnect to the font host, or self-host the font files to remove the extra DNS and TLS round trip entirely.
• Subset to the characters and weights you actually use. Loading nine weights when the design uses three is common and wasteful.
• Match fallback font metrics to reduce the layout shift when the real font swaps in.

WordPress-Specific Advice

Most small business sites run WordPress, and its performance problems are predictable.

• Audit your plugins. Every active plugin loads code on every request. Twenty plugins is not automatically bad, but twenty plugins where four are unused is. Deactivate and delete rather than deactivate and forget.
• Choose a lightweight theme. Multipurpose themes bundled with sliders, portfolios and demo importers carry weight you will never use. A clean theme plus a page builder is usually faster than a heavy theme.
• Page builders cost performance. Elementor, Divi and WPBakery all generate substantial CSS and DOM overhead. They are a legitimate trade for build speed and client editability — just budget for the cost and use their performance settings.
• One caching plugin, configured properly. WP Rocket, LiteSpeed Cache (if your host runs LiteSpeed) or FlyingPress. Running two caching plugins at once causes conflicts rather than double speed.
• Convert your media library to WebP in bulk, and set new uploads to convert automatically.
• Watch out for the cache lying to you. After optimisation work, test in an incognito window or with a cache-busting query string. A cached page can look fast to you and slow to everyone else — and the same caching layer can also serve stale XML sitemaps, which quietly delays indexing of new content.

eCommerce: Where Speed Is Worth the Most

Online stores feel performance problems more sharply than any other category, because there are more steps between arrival and revenue and each one leaks visitors.

• Category and listing pages are the usual disaster area. Thirty product images, a filter widget, a review script and an infinite-scroll library on one screen. Paginate rather than infinite-scroll where you can, lazy-load everything below the fold, and serve small thumbnails rather than full product images scaled down in CSS.
• Product pages should prioritise the main product image as the LCP element — preloaded, correctly sized, never lazy-loaded. Image galleries, zoom libraries and 360-degree viewers should load after the first render, not before.
• Checkout is where every millisecond has a directly measurable price. Strip everything non-essential from checkout pages: no chat widgets, no marketing pixels beyond what conversion tracking genuinely needs, no upsell carousels loading third-party scripts.
• Apps and plugins accumulate silently. Shopify stores in particular collect apps that each inject scripts into every page, including ones that were trialled and abandoned. Audit the installed list quarterly and remove what is not earning its place.

The commercial arithmetic is unusually clean here: if you know your conversion rate and average order value, you can price a one-second improvement directly. That makes speed work easier to justify to whoever controls the budget than almost any other marketing project. Our eCommerce SEO guide covers the ranking side.

Speed Is Relative to Your Audience’s Devices

“Fast” is not an absolute. It depends entirely on who is loading the page and on what.

A site serving affluent urban customers in Canada on modern iPhones over 5G has a very different performance budget from one serving small-town customers in India on three-year-old Android phones over patchy 4G. The second site can be doing everything right by lab standards and still be slow in the field, because the constraint is CPU time parsing JavaScript on a weak processor rather than download bandwidth.

Two consequences worth acting on:

• Look at your own analytics before setting targets. GA4 will tell you the device models and connection types your visitors actually use. Test on the median device, not the best one in the office.
• JavaScript weight hurts low-end devices disproportionately. A 400KB bundle downloads in a moment on any connection but can take several seconds to parse and execute on a budget Android phone. If your audience skews that way, cutting JavaScript matters far more than cutting image bytes.

If you serve several countries, a CDN stops being optional. Serving every asset from a single origin server means visitors on the other side of the world pay a latency penalty on every request, which compounds across dozens of resources.

Monitoring Speed Over Time

The most common pattern we see is a site that was optimised once, eighteen months ago, and has been quietly regressing ever since — a tracking pixel here, a new plugin there, a redesigned hero section with an uncompressed background image.

Set up something that tells you before your customers do:

• Search Console’s Core Web Vitals report — free, and it emails you when a template moves from Good to Needs Improvement. Check monthly.
• A scheduled PageSpeed Insights run against your three main templates, logged somewhere you will see it. The API is free if you want to automate it.
• Real user monitoring if you have the traffic to justify it — the web-vitals JavaScript library reports LCP, INP and CLS from actual visits into GA4, which gives you segment-level data (by device, country, page type) that Search Console does not.
• A pre-launch check in your process. Before any design change or plugin install goes live, test the affected template. Catching a regression before deployment costs minutes; catching it three months later after rankings have drifted costs a great deal more.

What Speed Is Actually Worth Commercially

Two separate arguments, and it is worth keeping them separate because they behave differently.

Rankings. Core Web Vitals are a confirmed ranking signal, but a light one and a tie-breaker rather than a driver. A faster page will not outrank a substantially more relevant, more authoritative one. If your pages sit at position 60, speed is not why. Fix speed because it is cheap and within your control, not because you expect it to move you to page one on its own.

Conversion. This is where the money is. The relationship between load time and abandonment is steep and well documented across industries: each additional second in the first few seconds costs a meaningful share of visitors, and mobile users are least patient. Every visitor who leaves before the page renders is a visitor you already paid to acquire — through ads, through content, through time.

Put crudely: speed optimisation is usually a better conversion-rate project than an SEO project, and it should be budgeted from whichever pot has money in it.

Speed and AI Search

A newer consideration. AI crawlers are less patient and less capable than Googlebot. Many of them do minimal JavaScript rendering and time out faster. A page whose content only appears after several seconds of client-side execution may simply be recorded as empty.

The practical implications overlap heavily with good performance practice: server-render or statically generate your main content, keep it in the initial HTML, and do not make crawlers execute a framework to see your headings. If you want to be quoted by AI answer engines, being fast and being server-rendered are prerequisites, not refinements. Our technical SEO guide covers the crawling side in detail.

A Realistic Optimisation Sequence

Week 1 — measure and cut

• Record baseline field data from Search Console and PageSpeed Insights for three representative templates.
• Check TTFB. If it is above 600ms, deal with hosting and caching before anything else.
• List every third-party script and remove the ones nobody uses.
• Deactivate and delete unused plugins.

Week 2 — images and layout stability

• Bulk-convert the media library to WebP and resize anything oversized.
• Add width and height attributes sitewide.
• Preload the LCP image; make sure it is not lazy-loaded.
• Reserve space for cookie banners and promo bars so they stop shifting content.

Week 3 — delivery

• Enable full-page caching and a CDN.
• Inline critical CSS, defer the rest.
• Defer non-essential JavaScript and remove unused code.
• Fix font loading: swap, preconnect, subset.

Week 4 — verify

• Re-test in an incognito window with cache-busting.
• Test on a real mid-range phone on mobile data.
• Wait for the 28-day field data window to catch up before judging the result — this is the step people skip, then conclude nothing worked.
• Set a calendar reminder to re-check after every significant design or plugin change, because regressions are the norm.

Reading a PageSpeed Report Without Getting Lost

PageSpeed Insights produces a long list of opportunities and diagnostics, most of which are noise for any given site. Knowing which items are worth acting on saves a great deal of wasted effort.

Almost always worth fixing:

• Properly size images and Serve images in next-gen formats — these two usually represent the largest available saving on a business website.
• Largest Contentful Paint element — not an opportunity but a diagnostic, and the most useful line in the whole report. It tells you exactly which element you need to make faster.
• Eliminate render-blocking resources — genuine, and fixed by inlining critical CSS and deferring the rest.
• Reduce unused JavaScript — usually points straight at third-party scripts and page-builder bundles.
• Avoid large layout shifts — names the exact elements causing CLS.

Usually not worth chasing:

• Reduce initial server response time when it is already under 600ms — the remaining gain is small relative to the effort.
• Serve static assets with an efficient cache policy when the flagged assets are third-party scripts you do not control.
• Avoid enormous network payloads on its own — it restates what the image and JavaScript items already told you.
• Minify CSS/JS when the saving is a few kilobytes. Real but negligible.

The report also flags accessibility, best-practice and SEO items in separate sections. Those are worth reading — particularly missing image alt text and unlabelled form fields — but they have nothing to do with speed and should not be mixed into a performance workstream.

Speed as Part of a Redesign, Not a Retrofit

Optimising an existing site has a ceiling. If the theme loads nine font weights, the page builder emits 400KB of CSS, and the hero is a full-width video, there is a limit to how much a caching plugin can save you.

When a redesign is on the table anyway, performance decisions made at the start cost nothing and are worth more than months of retrofitting:

• Set a performance budget before design begins — a maximum page weight and a target LCP that the design must fit within. This converts speed from an afterthought into a constraint, which is the only way it survives contact with a hero-video mockup.
• Choose the stack deliberately. A lightweight theme, or a statically generated front end, avoids problems rather than mitigating them.
• Design for the first screen. Whatever is above the fold determines LCP. A text headline renders far faster than a large photograph, and often converts just as well.
• Limit the font set to two families and three weights at design stage. Adding them later is easy; removing them after the brand guidelines are signed off is not.
• Agree the third-party stack up front — which analytics, which chat, which pixels — rather than accumulating them one request at a time over two years.

Rebuilding a site purely for speed is rarely justified on its own. Building performance into a redesign you were already doing is nearly free, and it is the difference between a site that is fast on launch day and one that needs an optimisation project six months later. We cover the wider planning questions in our website cost and planning guide.

Mistakes That Waste the Most Time

• Chasing a perfect Lighthouse score. Going from 85 to 100 in the lab often changes nothing for real users. Going from 4.5s to 2.4s LCP in the field changes everything.
• Installing a second caching plugin because the first one did not fix it.
• Lazy-loading the hero image. Makes the one metric you most need to fix worse.
• Testing only on desktop, only on office wifi. Your customers are not on either.
• Optimising before measuring. Without a baseline you cannot tell whether anything you did helped.
• Treating it as a one-off project. Speed regresses with every new plugin, tracking tag and design change. It is maintenance.

None of this requires being a developer. The image work, plugin audit, script cull and caching configuration cover most of the available gain and are all achievable by someone comfortable in a WordPress admin. Bring in a developer for server configuration, JavaScript debugging and INP work, once the easy wins are already banked.

Frequently Asked Questions

What are Core Web Vitals?

Core Web Vitals are three metrics Google uses to measure real-user page experience: LCP (Largest Contentful Paint, how long until the main content renders, target under 2.5 seconds), INP (Interaction to Next Paint, how fast the page responds to taps and clicks, target under 200 milliseconds) and CLS (Cumulative Layout Shift, how much the layout jumps while loading, target under 0.1).

Does website speed affect Google rankings?

Yes, but modestly. Core Web Vitals are a confirmed ranking signal that acts mainly as a tie-breaker between pages of similar relevance and authority – a fast page will not outrank a substantially more relevant one. The larger commercial effect is on conversion rate, since slow mobile pages lose visitors before they ever see the offer.

Why is my PageSpeed score 95 but my site still feels slow?

Because the big score is lab data – one simulated load on Google’s test conditions. The section above it, labelled field data or CrUX, is aggregated from real Chrome users on real devices and networks, and that is what Google actually uses. Real users have slower phones, worse connections and browser extensions, so field data is routinely worse than lab data. Trust the field data.

What is a good page load time in 2026?

Aim for LCP under 2.5 seconds on mobile field data, INP under 200 milliseconds and CLS under 0.1. In practical terms that means the main content visible in under two and a half seconds on a mid-range phone using mobile data, not on a desktop connected to office wifi.

How do I fix a slow WordPress website?

In order of impact: convert images to WebP and size them correctly, remove unused plugins and third-party scripts, enable one properly configured caching plugin and a CDN, check that server response time is under 600ms and upgrade hosting if it is not, then inline critical CSS and defer the remaining JavaScript. The image work alone usually produces the largest single improvement.

What causes Cumulative Layout Shift?

Images and iframes without declared width and height attributes, content injected above existing content such as cookie banners and promo bars, and web fonts that swap in at a different size to the fallback font. Declaring image dimensions and reserving space for injected elements fixes most CLS problems, and it is the cheapest of the three metrics to fix.

Does page speed matter for AI search engines?

Yes. Many AI crawlers do minimal JavaScript rendering and time out faster than Googlebot, so a page whose content only appears after several seconds of client-side execution may be recorded as empty. Server-rendering your main content and keeping it in the initial HTML is a prerequisite for being cited by AI answer engines, not an optimisation.

How long after optimising will I see improved Core Web Vitals?

Lab scores change immediately, but the field data Google uses is a rolling 28-day average of real user visits. That means Search Console will take several weeks to reflect your improvements even when the work is done correctly. Do not judge the result before that window has passed – this is the most common reason people conclude optimisation did not work.