What are Core Web Vitals and do they matter for a service business site?
Core Web Vitals are three metrics Google uses to measure how a page loads, responds and holds still, and they matter because a slow page on a phone loses the enquiry before the follow-up system ever sees it.
What are Core Web Vitals?
Core Web Vitals are three page-experience metrics defined by Google: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). Google’s web.dev documentation sets the passing thresholds at 2.5 seconds for LCP, 200 milliseconds for INP and 0.1 for CLS, measured at the 75th percentile of real page loads.
For a service business the metrics matter because the website is the first step of the enquiry. A visitor who taps an ad on a phone and waits four seconds for the page leaves before the form loads, and the lead follow-up automation behind the form never gets a lead to answer. Speed is not a ranking trick here; it is the cost of getting the enquiry at all.
Google uses the metrics as part of its page experience signals in search. Google’s own guidance describes them as a tie-breaker among pages with similar content, not a substitute for relevant content, which is why we treat passing them as a baseline rather than a strategy.
What does each Core Web Vital measure?
| Metric | What it measures | Good (web.dev) | Typical cause of failure on service sites |
|---|---|---|---|
| Largest Contentful Paint (LCP) | Time until the largest visible element, usually the hero image or headline, is painted | 2.5 seconds or less | Uncompressed hero images, slow hosting, render-blocking page-builder CSS |
| Interaction to Next Paint (INP) | Delay between a tap or click and the next visual update, across the whole visit | 200 milliseconds or less | Heavy JavaScript from chat widgets, sliders and tag managers loading before content |
| Cumulative Layout Shift (CLS) | How much visible content moves while the page loads | 0.1 or less | Images without width and height, late-loading fonts, banners injected above content |
How are Core Web Vitals measured?
Core Web Vitals are measured two ways: from real visitors (field data) and in a simulated test (lab data). Field data comes from the Chrome User Experience Report and appears in Google Search Console’s Core Web Vitals report and in PageSpeed Insights when a site has enough traffic. Lab data comes from a tool such as PageSpeed Insights or Lighthouse running the page once on a throttled connection.
Field data is what Google uses. A page can pass in the lab and fail in the field when real visitors are on slower phones and networks than the test assumes. New or low-traffic sites have no field data, so we test on a mid-range Android phone over a 4G connection, which is closer to a real visitor than a desktop test.
How do you pass Core Web Vitals on a WordPress service site?
These are the changes that move the three metrics most often, in the order we apply them.
- Serve the hero image as WebP or AVIF at the size it is displayed, with width and height attributes
- Load the page’s own CSS inline or in one file, and drop page-builder modules the page does not use
- Defer every third-party script (chat widget, pixel, tag manager) until after the content paints
- Use system fonts or one preloaded font file, with font-display: swap
- Reserve space for embeds and banners so nothing pushes content down after load
- Use server caching and a CDN, and keep time to first byte under 800 milliseconds
- Lazy-load images below the fold, never the hero
- Re-test after every plugin install, because plugins are the usual source of regressions
Do GoHighLevel embeds hurt Core Web Vitals?
GoHighLevel forms, calendars and the chat widget add JavaScript and iframes to a page, and each one can raise INP or shift layout if it loads before the content. They do not have to. We load the calendar and form iframes with fixed heights so nothing shifts, and the chat widget after the first interaction or a short delay, so the page paints first and the widget arrives second.
The LeadConnector WordPress plugin is one way to add these embeds; direct embed code is another. We prefer direct embeds on landing pages because they load only what the page uses. The details are in how to connect GoHighLevel to WordPress.
Common questions about Core Web Vitals
Will passing Core Web Vitals make my site rank first?
No. Google describes page experience as one signal among many and content relevance as the main one. Passing keeps you from losing ground and keeps paid visitors on the page; it does not replace the content and follow-up system that earn the enquiry.
My PageSpeed score is 60. Is that a fail?
The score is a lab summary, not the metric Google uses. Check the three field metrics in the same report. A page can score 60 and pass all three thresholds, or score 90 and fail INP for real visitors.
Which page matters most?
The pages that receive paid traffic and the pages that rank. A slow landing page wastes ad budget directly; a slow service page loses organic visitors. Fix those first and the homepage second.
How often should Core Web Vitals be checked?
After every change to the site and monthly otherwise. Search Console’s Core Web Vitals report shows failing URL groups once the site has enough traffic; PageSpeed Insights works for a single page at any time.
Does Elementor or another page builder fail Core Web Vitals automatically?
No, but builders load more CSS and JavaScript than a hand-built page, so passing takes more care. We strip unused modules, keep one widget per section and test on a phone after each build.
Find out whether your pages pass on a phone
Book a free strategy call. We test your landing and service pages on a real device and show you what to fix first.
Book a Free Strategy Call