Core Web Vitals are three speed and stability measurements Google uses to score every page on your site. A poor score can hurt your ranking, especially in competitive local categories where multiple businesses are all fighting for the same handful of spots on page one. The good news is that the fixes are well-understood and, for most service business websites, a handful of targeted changes move the needle most.
This post is part of the website foundation guide for service businesses. If you just received a warning in Google Search Console about "poor URLs" or "needs improvement," this is the right place to start.
Do Core Web Vitals actually affect Google rankings?
Yes. Google uses Core Web Vitals as a ranking signal through its Page Experience algorithm. A poor score does not automatically drop you off page one, but when two sites are otherwise equal in relevance and authority, the faster, more stable one tends to rank higher. For competitive local service categories, that tiebreaker matters.
Google started using page experience as a ranking factor in 2021. Since then, the specific metrics it tracks have been updated: in March 2024, Google replaced the older First Input Delay (FID) metric with a newer, more accurate one called INP. The three metrics it currently measures are LCP, INP, and CLS. Each one tracks a different dimension of how your page behaves for a real visitor.
Search Console can tell you which of your pages have issues, grouped into "good," "needs improvement," and "poor." A page marked poor is not automatically penalized, but it is a signal worth taking seriously, especially for your highest-traffic pages like your home page and your service pages.
What is LCP and what score do I need?
LCP stands for Largest Contentful Paint. It measures how long it takes for the biggest visible element on your page, usually a hero image or a large headline, to fully load. Google considers anything under 2.5 seconds a passing score. Between 2.5 and 4 seconds needs improvement, and above 4 seconds is considered poor.
For most service business sites, the LCP element is the hero image at the top of the home page. That image is often oversized, in the wrong file format, or loading from a slow server, and it almost always accounts for the majority of a slow LCP score. Converting hero images to WebP or AVIF format and serving them at the right display size can take a 6-second LCP down to under 2 seconds without changing a word of copy.
If your site runs on WordPress with a page builder, your LCP is also likely taking a hit from the builder's wrapper elements and from any scripts loading before the image. A Lighthouse report (free at pagespeed.web.dev) will show you exactly what the LCP element is and what is delaying it.
What is INP and why did it replace FID?
INP stands for Interaction to Next Paint. It measures how quickly your page responds when a visitor taps a button, opens a menu, or submits a form. Google replaced the older FID metric with INP in March 2024 because INP captures the full range of interactions during a visit, not just the first one. A good INP score is under 200 milliseconds.
FID only measured the delay before the browser began processing the very first user input. A site could pass FID while feeling sluggish every time a visitor tapped the navigation or tried to open a booking calendar. INP catches that. If a visitor clicks your "Book Now" button and nothing happens for half a second, that experience registers as a poor INP event.
The main driver of a poor INP score is JavaScript: too much of it, loading too early, blocking the browser from responding to taps and clicks. Third-party scripts from live chat widgets, booking plugins, and tag manager setups are frequent culprits on service business sites. Deferring or eliminating non-essential scripts at page load typically improves INP scores meaningfully.
What is CLS and what causes it?
CLS stands for Cumulative Layout Shift. It measures how much your page content moves around unexpectedly while loading. The most common causes are images without set dimensions, fonts that swap in after the page renders, and ads or embeds that push content down. A good CLS score is 0.1 or lower.
Layout shift is the experience of trying to tap a phone number or "Call Us" button, and having it jump down the screen the moment a banner ad loads above it. For service business sites, the two most common sources of shift are images missing explicit width and height attributes and Google Fonts loading after the page's fallback font, causing the text to reflow. Both are straightforward to fix and have a high impact on the score.
If your site uses a third-party booking embed or a chat popup that slides in from the bottom, those also contribute to CLS. Sometimes removing a plugin that was added three years ago and never used is the highest-value CLS fix available.
Why do so many service business sites fail Core Web Vitals?
The pattern we see most often is a WordPress site with a visual page builder, three or four third-party plugins injecting scripts at load, and images that were uploaded at full camera resolution without compression. Each problem is individually manageable. Together, they compound into a site that takes six or seven seconds to show anything useful on a phone.
After Google's Core Web Vitals ranking update rolled out, we pulled Lighthouse scores on every client site we managed at the time. The fastest sites were all server-rendered with next-gen images. The slowest were all WordPress with three or more third-party chat and booking plugins injecting scripts at page load. The score gap between the two groups was not close. Server-rendered sites consistently hit LCP under 1.5 seconds. The plugin-heavy WordPress builds were averaging over 5 seconds on mobile.
That pattern holds across audits we run today. It is not that WordPress is inherently too slow to pass. Plenty of WordPress sites pass Core Web Vitals. But it requires deliberate choices about what plugins load and how images are served. By default, most WordPress installs do none of that work automatically.
Google's LCP threshold for a "good" score. Pages above 4 seconds are rated "poor" and weighed against during ranking.
How do I check my Core Web Vitals score?
The fastest free way is Google PageSpeed Insights at pagespeed.web.dev. Enter your URL and it gives you both lab scores and, for sites with enough traffic, real-world field data from Chrome users. Google Search Console also has a Core Web Vitals report under Experience that groups your pages into good, needs improvement, and poor.
The distinction between lab data and field data matters. Lab data is a simulated test run by a tool in a controlled environment. Field data is aggregated from real Chrome users visiting your site over the past 28 days. Google's ranking signal is based on field data, not lab data. That means a site can pass a simulated Lighthouse test and still have poor field data if real visitors on slower phones are having a different experience.
If your site does not have enough traffic to generate field data, Google falls back to lab scores for ranking purposes. For most small service businesses, this means the PageSpeed Insights lab score is the most useful proxy to work from.
What actually fixes Core Web Vitals for a service business site?
Three changes account for the majority of Core Web Vitals failures on service business sites: compress and convert images to WebP or AVIF format, eliminate or delay third-party scripts that are not essential at page load, and make sure your hosting loads your HTML from a server geographically close to your visitors.
Image optimization alone often moves LCP from poor to good. A JPEG hero image uploaded at 4MB from a phone camera, displayed at 1200px wide, can be converted to a WebP at under 120KB with no visible quality difference. That single file-size reduction can cut LCP by two to three seconds on a mobile connection.
Script management requires more judgment. Not every third-party tool needs to load on page one. A live chat widget that is used by 3% of visitors does not need to load before the hero image that every visitor sees. Most platforms let you defer non-critical scripts to load after the page is interactive. If your web designer's list of fixes includes "defer render-blocking resources," this is what they mean.
Hosting matters too. A site on a shared hosting server in a data center in Texas will be slower for a visitor in Florida than the same site hosted on a content delivery network with nodes across the country. For service businesses targeting a specific metro, the distance between the server and the visitor is a real factor in LCP times.
An HVAC company owner who forwarded a Search Console notification to his web designer and got back a PDF of technical fixes he had no idea how to read is a situation we see regularly. The PDF was not wrong, but it was organized by fix type rather than by impact. In practice, fixing the hero image, removing two plugins that had not been used in two years, and switching to a CDN-backed host resolved the majority of the issues. The rest were diminishing returns.
For a broader look at what drives slow load times, the post on why service business sites load slowly covers the full picture, including hosting, image delivery, and script management in more detail.
Does improving Core Web Vitals actually get a service business more calls?
Faster pages retain more visitors long enough to reach your contact form or phone number. A visitor who lands on a page that takes seven seconds to load on their phone has already bounced before they read your headline. That is not a ranking problem or a copy problem. It is a delivery problem.
The ranking benefit is real but indirect. Google rewards faster pages with better placement, which means more people find you. But even before a ranking change, fixing a slow site means the visitors already arriving from ads, word of mouth, and existing rankings actually make it to your call-to-action. Both paths lead to more inquiries from the same amount of traffic or the same ad spend.
Core Web Vitals work sits inside the broader picture of why a service business stops showing up on Google. Speed is one factor. Content relevance, Google Business Profile completeness, and local signals all interact with it. A fast site with thin content still ranks below a moderately fast site with strong, relevant pages. Fix performance first because it is the most mechanical problem to solve, then layer the rest of your visibility work on top of a solid technical foundation.