What Google grades your website on

Google does not tell you directly how it ranks your website. What it does publish is the set of measurements it takes from every site that enough people visit using Chrome. It calls these measurements Core Web Vitals. Three numbers. Plain definitions. Thresholds that have not changed since 2023.

This page explains the three numbers, how Google collects them, and what passing looks like. Google publishes the definitions and thresholds in its own guide to the three measurements. Each outside study below is named, with the size of its sample where it gives one. None of this costs anything.

Why Google measures websites at all

Google's core business is sending people to pages they will find useful. A page that loads fast and answers the question is more useful than a slow one, even if the words say the same thing.

Outside research points the same way. In 2010, Liu, White, and Dumais at Microsoft Research measured 205,873 page visits. Visitors who stayed for ten seconds tended to stay for more than two minutes.

Visitors who left in the first ten seconds almost never came back to that page. That study is old, and the web has changed since, so read it as a direction, not a measure of today.

Core Web Vitals are Google's way of turning "user experience" into numbers its ranking system can use. Three measurements that come from real users on real devices. Thresholds any developer can look up. A tiebreaker when two pages cover the same topic equally well.

The three measurements

LCP: how fast the page loads

LCP stands for Largest Contentful Paint. It measures the moment when the biggest visible element on the page finishes loading. On most business websites, that is the big photo at the top of the page. On a text-heavy page, it might be the main headline.

The logic is simple. If the biggest thing on the page has loaded, the visitor can see something meaningful. A page where text loads instantly but the photo takes four more seconds does not feel fast, even though some content appeared. LCP measures what the visitor actually sees.

The thresholds (Google, 2023):

• Good: under 2.5 seconds
• Needs improvement: 2.5 to 4.0 seconds
• Poor: over 4.0 seconds

What slows LCP most on small-business websites: large, uncompressed images. A photo uploaded from a phone at full resolution can be 3 to 8 megabytes. That takes the same time to download as a short video clip. Request Metrics measured 300 million real page visits and found that images are the most common cause of slow load times. The same study found that the visitor's browser, downloading and drawing the page, accounts for 67% of total load time, while the computer that sends your page accounts for only 12%. That 67% figure covers many site types; a specific small-business site may differ.

A passing site keeps its images small. A photo resized for the web and saved in a modern format such as WebP is often a fifth of the size or smaller, and looks the same.

CLS: does the page jump around

CLS stands for Cumulative Layout Shift. It measures how much the visible content moves unexpectedly while the page loads.

You have experienced high CLS. You start reading a paragraph, an advertisement loads above it, and the paragraph jumps down. You tap a button and the button moves at the exact moment your finger makes contact. That movement is a layout shift. CLS is the sum of all such movements that happen while the page loads.

The unit is not seconds or pixels. It is a score from 0 (nothing moved) to 1 (everything moved significantly). Google defines "significant" as movement that covers a large fraction of the screen. A page where one paragraph shifts two centimeters as a font loads might score 0.05. A page where an ad loads and pushes all the content down might score 0.3 or higher.

The thresholds (Google, 2023):

• Good: under 0.1
• Needs improvement: 0.1 to 0.25
• Poor: over 0.25

What causes high CLS on most small-business websites: images with no size set, fonts that push text down when they arrive late, and outside widgets that push into the page after it looks ready. Chat boxes, booking tools, and review badges are the usual suspects. A passing site sets each image's size, loads its fonts early, and saves room for widgets.

INP: how fast the page responds when you tap something

INP stands for Interaction to Next Paint. It measures how long a page takes to respond visually after a visitor clicks, taps, or types something.

This is the newest Core Web Vital. Google made it an official ranking factor on March 12, 2024. It replaced an older measurement called FID (First Input Delay). FID measured how fast the page responded to the first interaction only. A page could pass FID and still feel sluggish on the second tap, the third, and every one after that. INP measures all interactions across the entire visit and reports the worst one, ignoring only the single most extreme outlier.

In plain terms: if your contact form takes 800 milliseconds to answer a tap on Submit, INP fails, even if the rest of the page is instant. Older phones feel delays a developer's laptop never shows. INP is measured on real devices in real conditions, so those phones count.

The thresholds (Google, 2024):

• Good: under 200 milliseconds
• Needs improvement: 200 to 500 milliseconds
• Poor: over 500 milliseconds

What causes high INP: heavy scripts, the small programs on a page, that run when a visitor taps something. Outside tags (tracking pixels, chat widgets, visitor counters) can block the page's response. They share the phone's attention with your own page.

A page with eight outside scripts loading in the background may feel instant on the builder's own computer. In the real world, it may take 600 milliseconds to respond. Those scripts have arrived and are competing for the browser's attention.

How Google collects these numbers

This is the part most explanations skip. It matters for understanding what your score actually means.

Google does not send a robot to your website and measure it. It collects data from real Chrome users who visit your site as part of their normal browsing. When someone using Chrome visits a page, Chrome measures LCP, CLS, and INP on that device. With the user's consent through Chrome's settings, it sends the results back to Google with names removed. Google combines the results from all visits in the past 28 days and publishes the summary. Google calls this the Chrome User Experience Report, or CrUX.

Three things follow from this that are not obvious:

Your score reflects your real visitors, not a test. A speed testing tool measures your site on one machine in one data center on one network connection. CrUX measures your site on whatever devices your actual visitors use, on whatever connections they have. If your visitors are mostly on older phones on mobile data, your CrUX score will show that. A perfect score on a speed testing tool does not guarantee a good CrUX score.

Changes you make today take about four weeks to show fully. The score covers the last 28 days of visits. A fix you make on a Monday is fully counted four Mondays later. If you check the day after a fix and nothing has changed, this is why. Wait 30 days and check again.

Your site needs enough traffic to have a CrUX report. Google only publishes data for pages that receive enough Chrome visits to protect individual users' privacy while still producing a meaningful summary. Many small-business websites do not have enough traffic for a page-level report. They may have one at the domain level (all pages combined). If no report exists, Google is still collecting measurements. It just has not published them yet because the sample is too small. No CrUX report is not the same as a bad score. It means the system does not yet have enough data to publish a verdict on your site specifically.

What Google grades besides the Core Web Vitals

Core Web Vitals are part of what Google calls Page Experience signals. They are not the whole picture.

Google also grades HTTPS, the secure connection. A site without the padlock in the address bar gets a visible warning in Chrome. Most hosting companies now include the certificate free; ask yours.

Google grades mobile usability. Since 2019, Google has primarily used the mobile version of every page for ranking, not the desktop version. A site that only works on desktop is being graded on a version of itself that may look broken on a phone.

Google grades full-page popups that block the content when a visitor arrives from a search result. A cookie notice at the bottom of the screen is not penalized. A popup that covers the entire page is.

Google grades the content itself. Core Web Vitals measure how the page is delivered, not what it says. A page that passes every Core Web Vital and contains thin or unhelpful content will still rank poorly. Google has stated that Core Web Vitals are a tiebreaker: content quality and relevance outweigh page experience when the two conflict. Passing them will not move a bad page to the top. It means a good page gives up nothing to a rival that passes too.

What this means for a local business in Southwest Florida

A national retailer with 50 engineers watching their checkout page has a different relationship to Core Web Vitals than a Cape Coral plumber. The measurement system is the same. The competitive context is not.

Local search is a filtered competition. Google is choosing among sites it considers relevant to a location and a category. There are fewer rivals than in a national search. We expect a site someone looks after to do better than a neglected one, which tends to collect slow add-ons, big images, and old scripts.

BrightLocal's Local Consumer Review Survey 2026 found that 45% of consumers now use conversational search tools (such as Perplexity) to find local businesses, up from 6% the year before (a survey of 1,002 US consumers). That is a self-report survey, so stated behavior may overstate actual usage. But the direction is clear: the ways people find local businesses are changing fast, and a well-maintained site is better placed for all of them.

Reading level: the thing Core Web Vitals cannot measure

Core Web Vitals measure how a page is delivered. They say nothing about whether anyone can understand it.

Unbounce measured 41,000 landing pages and 464 million visitors. Pages written at a 5th-to-7th grade reading level converted at 11.1%. Pages written at a professional reading level converted at 5.3%. So the simpler pages converted about twice as often.

The study compared different pages, so other differences between them may account for some of the gap. This was a landing-page study; a service-business homepage may behave differently. But the direction holds across every reading-level study we have seen.

Hemingway App (hemingwayapp.com) measures reading level free. Paste your page's text. It tells you the grade level. Grade 6 or 7 is the target.

A plumbing page that says "We provide comprehensive residential and commercial HVAC and plumbing system installation and remediation services" is writing to a graduate student. "We fix leaks, unclog drains, and install new pipes for homes and businesses in Lee County" writes to a sixth grader.

Both sentences are true. In the Unbounce study, pages written like the second one converted about twice as often as pages written like the first.

How to check your own scores

Three free tools, in the order we recommend trying them.

1. CrUX Vis, at cruxvis.withgoogle.com: Google's own viewer for its published Chrome data. If a report exists, it rates your LCP, CLS, and INP good, needs improvement or poor, from real Chrome visits, week by week. If none exists, your site does not yet get enough Chrome traffic for Google to publish one.

2. PageSpeed Insights, at pagespeed.web.dev: It shows two kinds of results. The real-visitor results (field data) are the same Chrome data as above, when it exists. The test results (lab data) come from a test on a simulated phone and network.

Lab scores help find specific problems, but they are not the scores Google's ranking system uses. A 95 in the lab is not the same as a passing Chrome report. They measure different things.

3. Google Search Console: If you have verified your site in Search Console (free), the Core Web Vitals report shows page-level data. It lists specific pages that need work. It also sends email alerts when your site's status changes.

One thing to remember: when you make improvements to your site, schedule a follow-up check 30 days later. The scores will not change until the old visits age out of the window. Checking the day after a fix and concluding the fix did not work is the most common mistake in Core Web Vitals work.

The free inspection on this site measures what can be checked without a real browser: how your page is built, the signals in the code, the things Google reads before a visitor arrives. Core Web Vitals need real visitors to measure. Anyone can read their own CrUX report in CrUX Vis, now and again 30 days later. Two reads: a before and an after. Run the free inspection on your site here.

The honest summary

Core Web Vitals are a tiebreaker in a race you are already in. A site that loads fast, holds still, and answers taps in under 200 milliseconds has removed one reason to pick a rival.

The more important question is whether the page is worth visiting once it loads. A fast, stable page that says nothing useful about what the business does or where it is will rank for nothing. Core Web Vitals help a good page. They cannot rescue a bad one.

Other posts in The Insider go deeper on each piece. The day we took our headline number down, and why. Five small findings, and how long each one takes to fix. What your business looks like in a Google search result.

---

The one thing you can check right now: Go to cruxvis.withgoogle.com and type your site's address. If no report appears, run your homepage through pagespeed.web.dev and look at the real-visitor results. Write down whether LCP, CLS, and INP each read good, needs improvement or poor. That is your baseline.

If neither tool shows a report, your site does not get enough Chrome visits for Google to publish one. That is not a bad score. Use the test results in PageSpeed Insights to find specific problems, knowing they are not the score Google uses.