Short answer first: most slow business websites are slow for ordinary reasons. A hero image that weighs several megabytes. Half a dozen third-party scripts for chat, analytics, heatmaps and ads. A server that takes a second to think before it sends anything. None of these are exotic problems, and most can be fixed without rebuilding the site.
Google measures page speed and stability with three metrics it calls Core Web Vitals. Once you know what each one measures, you can read your own reports, ask your developer sharper questions and tell a real fix from a cosmetic one.
Core Web Vitals in plain English
Each metric answers a question a visitor asks without thinking about it. The thresholds below come from Google's Web Vitals documentation on web.dev.
- Largest Contentful Paint (LCP): "Has the page actually shown up?" It measures when the largest image or text block in view finishes rendering, which on most business sites is the hero image or the main headline. Good is 2.5 seconds or less. Over 4 seconds is poor.
- Interaction to Next Paint (INP): "Does it respond when I tap?" It measures how long the page takes to visibly respond after a tap, click or key press, across the whole visit. Good is 200 milliseconds or less. Over 500 milliseconds is poor.
- Cumulative Layout Shift (CLS): "Does the page jump around?" It scores how much visible content moves unexpectedly. Good is 0.1 or less. Over 0.25 is poor.
Two details matter when you read reports. First, Google assesses each metric at the 75th percentile of real page loads, separately for mobile and desktop. In practice, a page passes only if at least three out of four real visits meet the "good" threshold. Your experience on office Wi-Fi is not the test; a customer on a mid-range phone with patchy mobile data is. Second, INP replaced an older metric, First Input Delay (FID), on March 12, 2024. If an audit you have been sent still talks about FID, it is out of date.
Where to find your real numbers
There are two kinds of performance data, and mixing them up causes most of the confusion we see.
Field data comes from real Chrome users visiting your site, and it is what Google uses. You can see it at the top of a PageSpeed Insights result and in the Core Web Vitals report in Google Search Console, which groups your URLs into good, needs improvement and poor based on the last 28 days of visits.
Lab data comes from a single simulated test, such as a Lighthouse run. It is useful for debugging because you can repeat it after every change. But the 0 to 100 Lighthouse performance score is not a Core Web Vital, and a lab test cannot measure INP at all, because nobody is actually tapping anything. Lighthouse uses a stand-in metric, Total Blocking Time, instead.
One catch for smaller businesses: field data only appears once a page, or the site as a whole, has enough real visitors. Google's Chrome UX Report only includes pages that are publicly discoverable and sufficiently popular, and Search Console leaves out URL groups that do not have enough data. If your site gets modest traffic, you may see lab numbers and nothing else. In that case, test on a real mid-range Android phone over mobile data and trust what you see.
The usual culprits, metric by metric
When LCP is slow
Google's guide to optimizing Largest Contentful Paint splits LCP into four parts: the time until the server sends its first byte, the delay before the browser starts loading the main image, the time that image takes to download, and the delay before it is drawn. On business sites, the causes we most often find are:
- A hero image exported straight from a camera or design tool, several megabytes, served to phones at full size.
- That same hero image set to lazy-load. Lazy-loading is right for images further down the page and wrong for the one you want first; the guide says plainly never to lazy-load the LCP image.
- A slow server response on cheap shared hosting, or pages rebuilt from scratch on every visit because nothing is cached.
- Slider and carousel plugins that load their JavaScript before showing the first slide.
When INP is poor
INP problems are almost always JavaScript: too much of it, running at the wrong moment. Chat widgets, tag managers firing a dozen marketing tags, cookie consent tools and heavy page builders all compete for a phone's processor. A React or Vue site that renders everything in the browser can also feel frozen for a moment after it appears, while its code wires up the page. The usual fix is to remove scripts nobody uses, delay the rest until after the page is usable, and break long-running code into smaller pieces.
When CLS is high
Layout shift is the easiest to spot: you go to tap a button and the page moves under your finger. Common causes are images and videos without a set width and height, cookie banners or promo bars that push content down instead of sitting on top of it, ads and embeds that load late, and web fonts that swap in at a different size. Most of these are small fixes once someone looks for them.
A worked example
Imagine a home-services company with a WordPress site. Its mobile field data shows LCP at 4.8 seconds, INP at 350 milliseconds and CLS at 0.18. All three fail. Here is how we would approach it, cheapest and highest-impact first:
- The hero image. It is a 3.2 MB JPEG, lazy-loaded, inside a slider plugin. Replace the slider with a single static image, export it as WebP at the sizes phones actually need (often well under 200 KB), remove lazy-loading from it and mark it with
fetchpriority="high". On a page like this, that change usually moves LCP more than anything else. - Caching and server response. Turn on full-page caching and put a CDN in front of the site, so pages are served from a location near the visitor. If the host still takes over a second to respond, it is time to move hosts.
- Scripts. Audit the tag manager. On a site like this it is common to find tags for tools nobody has logged into for a year. Remove them, and load the chat widget only when someone clicks the chat button.
- Layout shift. Give every image its dimensions, reserve space for the booking widget before it loads, and change the cookie banner so it overlays the bottom of the screen.
None of this needs a redesign. It is a few days of careful work followed by a few weeks of patience, because the Search Console report looks back over 28 days and will lag behind the fix. Keep a dated note of each change so you can match it to the reports later.
Do Core Web Vitals affect Google rankings?
Yes, but less than many sales pitches suggest. Google's page experience documentation says its ranking systems look at a variety of signals, that it will still show the most relevant content even when the page experience is sub-par, and that good results in Core Web Vitals reports do not guarantee top rankings. Where many pages are equally helpful, a better experience can make a difference.
So treat speed as a business problem first and an SEO problem second. A slow page loses people whether they came from Google, an ad, or a link your sales team sent on WhatsApp. If you pay for ad clicks, every visitor who gives up before the page appears is money spent for nothing.
Questions to ask your developer
- What are our mobile field values for LCP, INP and CLS, and which one is failing?
- What is the LCP element on our key pages, and how large is it?
- Which third-party scripts load on every page, and does each one still earn its place?
- Is full-page caching on? Is there a CDN in front of the site?
- How will we notice if a plugin update or a new marketing tag makes things worse?
The last question matters most. Speed decays quietly: every new plugin, tag and widget adds a little weight. A sensible website maintenance plan checks performance after changes, not just uptime.
When the fix is a rebuild, and when it is not
Most sites can reach passing scores without starting over. A rebuild starts to make sense when the problem is the foundation itself: a page builder theme that loads hundreds of kilobytes of code on every page, or a single-page application that renders everything in the browser and shows a blank screen until the JavaScript arrives. For content and marketing sites built with React, rendering pages on the server, for example with Next.js, removes much of that delay. Our React development team works on both sides of that choice, and sometimes the better recommendation is to keep and fix what you already have.
If your site is a simple brochure and it already passes on mobile, leave it alone. Chasing a perfect lab score beyond the "good" thresholds rarely pays for itself.
A practical next step: run your homepage and your most important landing page through PageSpeed Insights, note which metric fails on mobile, and start there. One metric properly fixed beats a long list of half-done suggestions.
If you would like help with that diagnosis, our website care team can look at your field data, find the specific causes, and tell you which fixes are worth the effort for your site and which are not.
