How Do You Check Page Speed in Google Analytics?

How Do You Check Page Speed in Google Analytics?

You open Google Analytics looking for the Site Speed report you used for years, and it is not there. There is no Page Timings tab, no Speed Suggestions, no average page load time sitting next to your pageviews.

This is not a permissions problem and you have not lost a setting. The report genuinely does not exist in the version of Google Analytics everyone now uses, and nothing was built to take its place.

That leaves two honest answers to the question. One is that you cannot check page speed in Google Analytics out of the box. The other is that you can get speed data into Google Analytics, properly, if you are willing to install something and write a little SQL. Which answer you want depends on what you are actually trying to learn.

The Direct Answer

Google Analytics 4 ships with no speed reporting of any kind. There is no built-in event for load time, no default metric for it, and no report in the left-hand navigation that will show you one.

To see speed data inside GA4 you have to send it yourself. The supported route is Google's own web-vitals JavaScript library, which measures the Core Web Vitals in the real browsers of real visitors and hands each measurement to you as a value you can forward to GA4 as a custom event.

If you only want to know whether your pages are fast enough for Google, skip GA4 entirely. Search Console's Core Web Vitals report and PageSpeed Insights both answer that question for free, with no code, using the same field data Google uses for ranking purposes.

Not sure whether speed is even your problem? Get a free SEO audit and see every issue on your site ranked by what it actually costs you.

Why the Site Speed Report Disappeared

What Universal Analytics used to show

The old Site Speed section was genuinely useful. It carried an average page load time, average server response time and average page download time, broken down by page, browser and country. A Page Timings tab let you compare individual URLs against the site average, a DOM Timings tab reported how fast the browser could parse the document, and a Speed Suggestions report pointed at specific fixes.

There was also a User Timings report, where a developer could instrument any individual interaction — an image load, a button response — and track it as its own timing.

What happened to those reports

All of it belonged to Universal Analytics, and Universal Analytics is gone. Google stopped processing data in standard Universal Analytics properties on 1 July 2023, and the 360 properties that received a one-time extension stopped on 1 July 2024. Google's own help article for the Site Speed report is now labelled as legacy documentation.

So the reports did not move or get renamed. The product they lived in was switched off, and the speed section was one of several things that did not get rebuilt.

Why GA4 was built differently

Universal Analytics sampled page timings from a slice of your pageviews and averaged them. By the time GA4 arrived, Google's own performance guidance had moved on from averages to the Core Web Vitals, which are assessed at the 75th percentile of real visits rather than the mean.

An average load time hides exactly the visitors you need to find. If most of your traffic is fast and a quarter of it is painful, the average looks acceptable and the quarter stays invisible. GA4 did not replace the old report with a better one — it left the job to the Web Vitals tooling, which was designed around percentiles from the start.

How to Get Page Speed Into GA4, Step by Step

Step 1 — Decide which metrics you actually need

There are three Core Web Vitals. Largest Contentful Paint (LCP) measures how long the main content takes to appear. Cumulative Layout Shift (CLS) measures how much the page jumps around while it loads. Interaction to Next Paint (INP) measures responsiveness, and it replaced the older First Input Delay metric in 2024.

Those three are what Google assesses. If you also want Time to First Byte or First Contentful Paint for diagnosis, the same library reports them.

Step 2 — Install the measurement code

Add the web-vitals library to your site. It is a small script maintained by the Chrome team, and it exposes one callback per metric that fires when the value is final for that page view.

If you would rather not touch the codebase, Google's marketing-solutions team publishes a Web Vitals template for Google Tag Manager that does the same job through a tag. Either route produces identical events.

Step 3 — Send each metric as a GA4 event

Google's own guidance is to send one event per metric, named for the metric: LCP, INP, CLS. Attach parameters alongside each one:

• metric_id, a unique identifier for that measurement, so you can deduplicate later
• metric_value, the measured number
• metric_start_time, so you can order repeated readings
• page_location, so you can group by URL
• debug_target, a CSS selector naming the element most responsible for the score — for CLS, the largest element in the largest layout shift

That debug_target parameter is the one people skip and later regret. Without it you learn that a page is slow. With it you learn which element made it slow.

Step 4 — Turn on the BigQuery export

In GA4, link the property to a BigQuery project and enable the export. Your events then land in BigQuery tables automatically, one row per event, with every parameter intact.

This step is the real unlock, and it is also where a GA4 speed setup stops being a five-minute job.

Step 5 — Query the 75th percentile, not the average

In BigQuery, select the last value per metric_id — a callback such as CLS can fire more than once per page, and the final value is the accurate one — then take the 75th percentile across page views.

This is the number that matches how Google grades your site. Use metric_start_time and metric_id together to keep only the latest reading for each measurement before you aggregate.

Step 6 — Put it somewhere you will look

Materialise the query into a partitioned, clustered table so your dashboard is cheap to refresh, schedule it to update, then point Looker Studio at it. Google also publishes a Web Vitals Connector that will generate a starting dashboard for you.

One audit, every fix, ranked by impact. Get your free SEO audit and stop guessing which change matters most.

The No-Code Routes That Need No GA4 Work At All

Search Console's Core Web Vitals report

Search Console groups your URLs into good, needs improvement and poor, split by mobile and desktop, using real Chrome field data. It is the closest thing to an official scorecard, and it costs nothing to look at.

Its weakness is lag and grouping: it reports over a rolling 28-day window and buckets similar URLs together, so you see page groups rather than individual pages.

PageSpeed Insights

Paste in a URL and PageSpeed Insights gives you both field data for that page and a Lighthouse lab test with specific recommendations. It is the fastest way to diagnose one important page.

It is also a single-page tool. You cannot see a trend, you cannot segment by traffic source, and a lab score run on a Google server is not what your visitors experienced.

The CrUX API and the Looker Studio connector

The Chrome User Experience Report is the dataset behind both tools above, and you can query it directly through its API or pull it into Looker Studio. That gives you a trend line and lets you compare yourself against competitors, which neither Search Console nor PageSpeed Insights will do.

The catch is granularity: CrUX reports at origin and URL level over monthly windows, and it cannot tell you anything about your own business dimensions.

When the GA4 Route Is Worth the Trouble

Build the GA4 and BigQuery version when you need to connect speed to something only your analytics knows.

That means questions such as: is LCP worse for visitors arriving from paid social than from organic search? Did the checkout step get slower for logged-in users after last Tuesday's release? Does INP correlate with abandonment on the pages that actually make money?

No external speed tool can answer those, because none of them know which of your visitors converted. This is the single reason to do the work, and if you do not have a question of that shape, the no-code tools are the better answer.

Speed is one input. There are usually others. A free SEO audit shows you what else is holding your pages back.

Limitations You Should Know Before You Build This

GA4's own interface will mislead you

Once the events are flowing you will be tempted to look at them in GA4 rather than BigQuery. Resist it. GA4's exploration tools lean on averages and sums, and an average Core Web Vital is close to meaningless. The percentile calculation is the point, and BigQuery is where you can do it.

Sampling, cardinality and quotas

Event parameters have cardinality limits, and high-cardinality values such as full URLs with query strings can get collapsed into an "other" bucket in GA4's reporting interface. The BigQuery export does not have that problem, which is another reason to treat BigQuery as the real destination.

Field data is Chrome data

The Core Web Vitals in Search Console and PageSpeed Insights come from Chrome users who opted into reporting. The web-vitals library measures whatever browser your visitor is using, but several of the underlying APIs are Chromium-only, so Safari and Firefox traffic will be thin or absent. Your numbers describe your Chrome audience.

None of this is a ranking report

Speed is a ranking input, not a ranking report. A page can pass every Core Web Vital and still not rank, and a slow page with genuinely better content will often beat a fast page without it. Treat these numbers as a user-experience check, not as an explanation of your positions.

How This Compares to the Alternatives

• Search Console Core Web Vitals — free, official, no setup, and the right place to start. Grouped URLs and a 28-day window make it unsuitable for debugging a single release.
• PageSpeed Insights and Lighthouse — best for diagnosing one page in detail. No trend, no segmentation, and the lab score is a simulation rather than your visitors' experience.
• GA4 plus the web-vitals library plus BigQuery — the only option that joins speed to your own conversion and traffic-source data. Needs code, a BigQuery project and SQL.
• A dedicated real-user monitoring product — gives you percentile dashboards, alerting and session-level traces without the SQL. Costs money, and adds another script to the page you are trying to make faster.

Want the whole picture, not one metric? Start with a free SEO audit — one pass, every issue listed.

Final Thoughts

The honest version of this answer is short. Google Analytics does not check page speed any more, and pretending otherwise sends people hunting for a report that was switched off in 2023.

What you do instead depends on the question. If you want to know whether your pages are fast enough, Search Console and PageSpeed Insights will tell you today, for free, with nothing installed. If you want to know whether slow pages are costing you conversions from a particular channel, that is a genuine GA4 project: the web-vitals library, one event per metric, the BigQuery export, and a 75th-percentile query you can trust.

Pick the second only when you have a question the first cannot answer. And if you are building out the rest of your GA4 reporting at the same time, our guide to building a Google Analytics SEO report covers the reports that are worth your time once speed is handled elsewhere.