Blog 8 min *

* Publication times use Tampa, Florida local time (Eastern Time).

Three clean measurement instruments arranged in a row on a dark surface, precise and professional.

Three Free Google Tools That Prove Your Speed Problem Is Real

By Gabriel Lopez-Seco

Most Tampa Bay business owners who want to know how their site performs get shown a Lighthouse score.

That number: 0 to 100, color-coded from red to green, feels authoritative. It is not what Google uses to assess your Core Web Vitals. It is a lab simulation: a synthetic device on a throttled connection, run at a single moment in time, measuring no actual customers. A Lighthouse score of 90 tells you the simulation went well. It tells you nothing about the experience 400 real people had visiting your site last Tuesday on their phones.

Field data does that. And you can get it, right now, for free, using three tools Google has published. Here is the exact sequence.

Why the Lab/Field Distinction Matters Before You Touch Any Tool

Before you open a browser tab, one concept needs to be clear, because every misdiagnosis in this space flows from conflating two things.

Lab data is what tools like Lighthouse produce. They simulate a device, throttle the connection, and run a test on demand. The result is reproducible and useful for catching problems in development. It is not a record of what happened.

Field data is a record of what actually happened. The Chrome User Experience Report: CrUX (pronounced “crux”), collects real performance readings from Chrome browser sessions across millions of actual users who have opted into sharing that data. It aggregates those readings at the 75th percentile over a rolling 28-day window. This is the data Google uses when it assesses your Core Web Vitals. It is why your site feels fast to you and slow to customers, your own impression, tested on a fast machine on a good connection, is not a measurement.

The three tools below are how you access your field data without paying for anything.

Tool 1: PageSpeed Insights: Your Field Data in Two Minutes

Go to pagespeed.web.dev. Enter your URL. Hit Analyze.

The top section of the results page shows a Lighthouse performance score. Ignore it for compliance purposes. Scroll past it.

Below the Lighthouse section, find the panel labeled “Discover what your real users are experiencing.” This is your CrUX data. It shows the 75th percentile readings for three Core Web Vitals metrics:

  • LCP (Largest Contentful Paint), how long before the biggest visible element on your page appears. In business terms: when does the page look loaded to a visitor?
  • INP (Interaction to Next Paint), how quickly your page responds when someone taps a button or fills in a form field. In business terms: does your site feel broken when people try to use it?
  • CLS (Cumulative Layout Shift), how much your page jumps around as it loads. In business terms: are visitors accidentally tapping the wrong things because the page keeps rearranging?

According to Google Developers’ documentation on PageSpeed Insights (2024), PSI field data “is updated daily, while the BigQuery dataset is updated monthly. Both data sources represent trailing 28-day periods.” That means the numbers you see today reflect the prior 28 days of real visits, understand how long before a fix appears in the data before you interpret results after a recent change.

Origin vs. URL. If your page has enough traffic for URL-level data, you will see readings specific to that page. If traffic is low, PSI falls back to origin-level data, aggregated across your entire domain. Origin-level data is still real CrUX data; it just represents your whole site rather than a single page.

The INP exception. Google Developers (2024) also documents that if your site has insufficient data for INP, the Core Web Vitals assessment uses only LCP and CLS to determine pass or fail. If you see no INP reading, that is why, it is not a problem with the tool.

Competitor check, free. Enter a competitor’s URL into PSI. You will see their field data, if they have enough Chrome traffic. This is free competitive benchmarking that most owners have never run.

A worked reading: PSI shows LCP at 4.2 seconds, INP at 310 milliseconds, CLS at 0.04. LCP of 4.2 seconds is in Google’s “Poor” range (the “Good” threshold is under 2.5 seconds). INP of 310 milliseconds is in “Needs improvement” (the “Good” threshold is under 200 milliseconds), visitors are noticing a lag on every tap. CLS of 0.04 is passing (under 0.1). The business implication: your main content is loading slowly enough to lose visitors, and your page interactions feel sluggish on mobile. The layout is stable, one thing working in your favor.

Tool 2: Google Search Console: Your Site-Wide Picture

PageSpeed Insights shows one URL at a time. Google Search Console shows your entire site.

Log into search.google.com/search-console. In the left navigation, find Experience and click Core Web Vitals. You will see two reports: mobile and desktop. Open both.

The unique feature here is template grouping. According to web.dev’s Core Web Vitals workflows guide (2025), “Search Console groups similar pages (for example, pages that use the same template) into a single group assessment.” That means instead of seeing 90 individual URLs, you see: “Service pages: 43 URLs: Poor on mobile.” That is actionable. The problem is structural, and fixing the template fixes all 43 pages at once.

Drill into any failing group and you will see a sample of the specific URLs. Click one URL from the group and open it in PSI from there, now you can cross-reference the systemic finding with the specific field data for one example page.

The mobile and desktop reports are separate because Chrome collects them separately. A site can pass CWV on desktop and fail on mobile, or vice versa. Given that mobile accounts for a majority of search traffic, a mobile failure is the one to prioritize. Check how your mobile site compares to real benchmarks before deciding which failing group to address first.

Tool 3: The web-vitals JavaScript Library: Real-Time Monitoring

The two tools above read CrUX data, which lags by up to 28 days. If you need to confirm that a fix is working before the CrUX window rolls over, you need a way to collect your own field data in real time.

The web-vitals JavaScript library is Google’s official answer. It is approximately 2KB, free, and open-source. According to web.dev’s measurement guide (2025): “If you’re implementing your own RUM setup for Web Vitals, the easiest way to collect Web Vitals measurements is to use the web-vitals JavaScript library.”

RUM stands for Real User Monitoring, collecting performance readings from actual visitors as they happen. Once installed and sending data to a destination you control (GA4 or any analytics backend), you can see within hours whether a deployed fix improved your LCP or INP, rather than waiting 28 days for CrUX to catch up.

For most SMBs, a developer can install this in an afternoon. It supplements PSI and Search Console by closing the feedback gap between when you ship a fix and when the official field data reflects it.

A note on CrUX Vis. If you have been using the CrUX Dashboard, be aware that Google launched CrUX Vis in October 2024 as a replacement. Per the Google Chrome Developer Blog’s CrUX Release Notes (2024), CrUX Vis is “moving toward general availability” as the dashboard is deprecated. Use CrUX Vis for trends, PSI for URL-level readings, and Search Console for template-level diagnosis.

How These Three Tools Work Together: A Medical Practice Scenario

Consider, hypothetically, a Tampa Bay medical practice running the full sequence in one afternoon.

They start with PSI on their appointment booking page. The field data shows LCP at 5.1 seconds (Poor), INP at 420 milliseconds (Needs improvement), and CLS at 0.02 (Good). The Lighthouse score at the top of the same page is 72, which is why no one had flagged a problem before. The lab score looked acceptable. The field data tells a different story.

They open Search Console and navigate to Experience → Core Web Vitals → Mobile. Their “Service pages” template: 43 URLs, is flagged as Poor. The problem is not limited to the booking page; it is the entire service section.

They ask their developer to add the web-vitals library to confirm fixes in real time. Understanding how third-party scripts eat your load time turns out to be the first fix, the audit finds four scripts loading on every page before any content appears.

Three tools, 90 minutes, no paid software. They now have a specific problem, a template-level scope, and same-day validation.

What “My Site Looks Fine” Usually Means

When an owner says they already checked their speed, nine times out of ten they ran Lighthouse, or GTmetrix, which also runs a Lighthouse-based lab test by default. Both tools are valuable for finding what to fix. Neither is evidence of what your visitors experienced.

If you have not opened the field data section of PageSpeed Insights and checked your Search Console Core Web Vitals report, you have not checked your speed. You have checked what a simulation produced.

The three tools in this article are how you check what actually happened.

If you want someone to run this sequence for you and interpret what the data means for your business specifically, a free assessment from iServU does exactly that. Gabriel Lopez-Seco pulls your field data, maps it against Google’s current thresholds, and tells you which failures are costing you the most. No account manager, no handoff.

Schedule a free assessment at iServU.

Sources

  1. Google Developers (2024). About PageSpeed Insights. https://developers.google.com/speed/docs/insights/v5/about
  2. web.dev / Google (2025). Core Web Vitals workflows with Google tools. https://web.dev/articles/vitals-tools
  3. web.dev / Google (2025). Getting started with measuring Web Vitals. https://web.dev/articles/vitals-measurement-getting-started
  4. Google Chrome Developer Blog (2024). CrUX Release Notes: CrUX Vis launch and CrUX Dashboard deprecation. https://developer.chrome.com/docs/crux/release-notes