Google's published targets are that the main content appears within 2.5 seconds, the page responds to a tap or click in under 200 milliseconds, and layout shift stays below 0.1, measured at the 75th percentile of real visits. Common causes of a slow business site are oversized images, too many scripts, slow server responses, and content that waits on JavaScript before it appears. Speed supports a site; it does not replace relevant content.
Speed complaints usually start as a vague feeling: the site seems sluggish on a phone, or a test tool shows a red score. Turning that feeling into a fix means knowing which number is off and what tends to cause it.
This page is for owners and marketing leads planning a build. It explains Google's published metrics and common causes, and it is not a performance audit of your site. For the build approach behind it, see how Hudson South builds websites.
The three numbers and what they measure
Google describes Core Web Vitals as "a set of metrics that measure real-world user experience," and web.dev recommends measuring them at the 75th percentile of page loads, split between mobile and desktop.
| Metric | What it measures | Good target |
|---|---|---|
| Largest Contentful Paint (LCP) | Loading: when the main content appears | Within 2.5 seconds |
| Interaction to Next Paint (INP) | Interactivity: how quickly the page responds | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | Visual stability: how much things jump around | 0.1 or less |
INP is the metric owners feel without naming. It covers the pause between tapping a menu or a form button and anything happening on screen, and on a business site that pause tends to land on the moments that matter most, such as opening the menu on a phone or sending a contact form.
Where the numbers come from matters. Lab tools such as Lighthouse load a page in a simulated setting, while field data from the Chrome UX Report reflects real visits and powers PageSpeed Insights and the Core Web Vitals report in Search Console. A lab score is not a field result, and web.dev says lab measurement "is not a substitute for field measurement." Lab tools cannot measure INP at all, because no one is clicking.
Keep speed in proportion, too. Google says it highly recommends good Core Web Vitals and that its core ranking systems look to reward good page experience, but also that "Google Search always seeks to show the most relevant content, even if the page experience is sub-par." A fast page that answers nothing still answers nothing.
What usually slows a business site down
Web.dev breaks LCP into four parts: time to first byte, the delay before the main resource starts loading, the time to load it, and the delay before it renders. Each points to a different fix.
| Symptom | Likely cause, per web.dev | Where to look |
|---|---|---|
| Slow main content | A slow server response; web.dev says a high TTFB can make a 2.5 second LCP "challenging, or even impossible" | Hosting, caching, page generation |
| Blank screen, then everything at once | Style sheets or synchronous scripts in the page head that are still loading, or a main element waiting on JavaScript before it is added to the page | Theme files, scripts in the page head |
| Page jumps while loading | Images, ads, embeds and iframes without dimensions, injected content, web fonts | Hero images, chat widgets, embedded maps |
| Taps feel ignored | Long tasks on the main thread; script evaluation during load extends input delay | Tracking tags, widgets, sliders |
Images deserve particular attention, because owners often upload photos straight from a camera or phone. Web.dev's LCP guidance includes reducing the size of the resource, and its CLS guidance lists images without dimensions as a cause of layout shift. Resizing, compressing and declaring the dimensions of each image addresses both.
How platform choice affects speed
Pages that arrive as finished HTML avoid one whole category of delay. Google's JavaScript documentation says server-side or pre-rendering "makes your website faster for users and crawlers." Hosting matters as well, since time to first byte depends on how quickly the server answers. Hudson South's own guidance points businesses that want speed, security and low upkeep toward hand-coded static sites on Netlify. WordPress and Squarespace sites can be fast too; the risk is that each added feature can bring scripts of its own, and on WordPress many features arrive as plugins. The plugin side is covered in how many WordPress plugins is too many.
Whatever the platform, scripts pile up quietly. A chat widget, two analytics tags, a heatmap tool from a trial nobody canceled, a review carousel. Each was added for a reason, and few are ever removed. An audit starts with one question to whoever manages the site: "Which scripts load on every page, and who asked for each one?" Anything without an owner is a candidate for removal.
A fictional example: the slow homepage
Here is a fictional example. A senior living community in Virginia notices that its Core Web Vitals report in Search Console lists most mobile URLs as poor. The homepage opens with an autoplaying video, a chat widget, three tracking tags, a tour-booking pop-up, and a photo gallery of full-size camera images. The text families need, such as levels of care and how to schedule a visit, sits below all of it.
The rebuild replaces the video with a sized, compressed photo, removes the tags nobody uses, loads the chat widget only on the contact page, and moves the tour offer to a small banner. The care descriptions move up and are written from what the community's staff confirmed, so the writer should not have to invent what the community knows about its own services. After launch, the team watches the field data rather than a single lab test. For the first screen itself, see what a homepage should say in its first screen.
What to measure after launch
Check field data in the weeks after launch, not only on launch day. Search Console's Core Web Vitals report and PageSpeed Insights both draw on Chrome UX Report data, which reflects real visits. Lighthouse is useful for catching obvious problems before launch, though it cannot measure INP. Recheck whenever a new script, widget or tool is added, since a page that was fast at launch can slow down one addition at a time, and keep a note of what was added and when so a change in the numbers can be traced.
Speed is one part of a build that also needs something worth loading. Hudson South runs every build in the same order. Authority Asset gathers approved business knowledge and evidence. Hudson Twenty-One records how the business communicates across 21 dimensions, so the pages sound like the people who answer the phone. Market Intelligence researches the questions buyers ask and how the market answers them. AEO Creation turns those inputs into answer-first pages. Every Hudson South build also includes mobile layout checks before launch.
Compare your site with the ones buyers also open
On a free 30-minute call, we look at how your site and your competitors' sites answer buyer questions, so speed work goes to the pages that matter.
Get your free competitor analysisSources
- Understanding Core Web Vitals and Google search results. Google Search Central. Read 2026-10-17.
- Web Vitals. web.dev. Read 2026-10-17.
- Understanding Google Page Experience. Google Search Central. Read 2026-10-17.
- Optimize Largest Contentful Paint. web.dev. Read 2026-10-17.
- Optimize Cumulative Layout Shift. web.dev. Read 2026-10-17.
- Optimize Interaction to Next Paint. web.dev. Read 2026-10-17.
- Understand JavaScript SEO Basics. Google Search Central. Read 2026-10-17.