Website Speed for Contractors: Core Web Vitals in Plain Language

The three Core Web Vitals

Google’s Search Central documentation names three metrics and what counts as a good score. Google’s web.dev site says to measure them at the 75th percentile of page loads, split by mobile and desktop, so most of your visitors get a good experience.

Thresholds from Google Search Central’s “Understanding Core Web Vitals” page, checked October 30, 2026.

How much do they matter for Google rankings?

Google’s page experience documentation is careful here, and it’s worth reading the exact points:

• Core Web Vitals are used by Google’s ranking systems, but there is no single “page experience signal.”
• Good Core Web Vitals scores don’t guarantee that a page will rank at the top. Google says it tries to show the most relevant content even if the page experience is below par.
• Google also lists other page experience questions: is the page served over HTTPS, does it display well on mobile devices, does it avoid an excessive amount of ads that distract from the main content, and does it avoid intrusive interstitials (pop-ups that block the content)?

So speed is not a magic ranking switch. It is part of a site that works for the customer, alongside clear service and contact information (see our trade business website basics).

How to check your own site for free

Google’s web.dev guidance separates two kinds of data:

• Field data comes from real Chrome users visiting your site, collected in the Chrome User Experience Report (CrUX). You can see it in PageSpeed Insights and in the Core Web Vitals report in Google Search Console. A small local site may not have enough visits to show field data yet.
• Lab data comes from a test run in a controlled setting, such as Lighthouse (built into Chrome’s developer tools) or the lab section of PageSpeed Insights. web.dev notes that lab tools can’t measure INP because there is no real user interacting, and suggests Total Blocking Time (TBT) as a lab stand-in.

A simple routine:

1. Run your home page and your most important service page through PageSpeed Insights. Look at the mobile result first.
2. If you have Google Search Console set up, open the Core Web Vitals report and note which group of pages is marked “Poor” or “Needs improvement.”
3. Fix the biggest issue, then check again. Field data comes from real visits over time, so expect improvements to show up gradually rather than the same day.

Common fixes for slow loading (LCP)

On most trade business sites, the largest element is a big hero photo of a truck, crew or finished job. Google’s web.dev guide on optimizing LCP points to these causes and fixes:

• Make the main image easy to find and load early. The hero image should be in the page’s HTML as a normal image, not added later by a script or slider. web.dev says to never lazy-load the LCP image.
• Make images smaller. Use a modern format such as WebP or AVIF, and size the file for the screen instead of uploading a 6,000-pixel camera photo.
• Give the hero image priority. web.dev shows a fetchpriority="high" hint on the main image so the browser fetches it sooner.
• Cut what blocks the page. Large stylesheets, many plugins and third-party scripts (chat widgets, tracking tags, review widgets) delay the first paint.
• Improve server response. Page caching and a decent host help the first byte arrive sooner. A content delivery network can help visitors far from your server.

Common fixes for jumping layouts (CLS)

web.dev’s guide on optimizing CLS lists the usual suspects:

• Images and videos without dimensions. Give every image and embedded video a width and height (or an aspect ratio in CSS) so the browser reserves the space.
• Content that loads in late above existing content, such as a banner, a cookie bar or an ad slot that pushes everything down. Reserve space for it, or place it where it won’t move what the visitor is reading.
• Web fonts that swap in and change the size of text. Preloading key fonts or using a fallback font with similar size reduces the shift.

Common fixes for slow taps (INP)

• Remove plugins and scripts you don’t need. Every extra script competes for the phone’s processor when someone taps “Call now” or opens your menu.
• Be careful with heavy page builders, sliders and animation effects on mobile.
• Test your own site on an older or mid-range phone, not only on a new laptop.

If you hire someone

Ask for results you can check yourself:

• A before-and-after PageSpeed Insights report for the same pages, on mobile.
• A list of what was changed (images converted, plugins removed, caching set up).
• Confirmation that your phone number, service list and contact form still work after the changes.

Be wary of anyone who guarantees a specific Google ranking. Google’s own page says good scores don’t guarantee top placement.