Google removed dedicated page speed reporting when Universal Analytics was retired — but slow pages don't disappear quietly. They leave measurable shadows in your GA4 data: unusually short engagement times, high exit rates on pages that should hold attention, and mobile engagement metrics that collapse while desktop stays healthy.
None of these signals are conclusive on their own. GA4 is not a speed tool, and a short engagement time can mean a hundred things. But used systematically, the four methods below give you a working suspect list — pages worth running through PageSpeed Insights to get an actual Largest Contentful Paint score and Time to First Byte measurement. That's the workflow: GA4 surfaces the candidates; the speed tools confirm them.
Why GA4 No Longer Has a Speed Report
Universal Analytics included a dedicated Site Speed section that sampled a percentage of sessions and measured page load time directly. GA4 does not. Google's reasoning was that browser-level performance APIs are more accurate than what a JS tag can capture, and that tools like Search Console's Core Web Vitals report (which uses Chrome User Experience Report field data) and PageSpeed Insights (which uses Lighthouse lab data) are better suited to the job.
That's a defensible decision — but it means the speed signal in GA4 is indirect. You're reading the behaviour of people on slow pages, not measuring the pages themselves. The distinction matters for how you interpret what you find.
Method 1: Sort Pages by Average Engagement Time
Go to Reports › Engagement › Pages and screens. Sort the table by Average engagement time ascending. What you're looking for is content pages — blog posts, long product descriptions, resource articles — that show engagement times well below your site average.
A 1,500-word article that averages 18 seconds of engagement time is telling you something. Either the content isn't relevant to the people landing on it, or users are bouncing before the page has finished loading. Speed is a common cause of the second pattern.
Filter out short-form pages first. Contact pages, thank-you pages, and single-CTA landing pages will always show low engagement time — they're designed that way. Add a secondary dimension or use a page path filter to isolate content pages before drawing conclusions.
Once you have a list of underperforming content pages, take them to PageSpeed Insights. Test each URL on mobile (the default). Any page with a Largest Contentful Paint above 2.5 seconds or a Total Blocking Time above 300ms is genuinely slow and should be treated as a speed problem, not a content problem.
Method 2: High Exit Rate on Pages That Should Hold Attention
In the same Pages and screens report, look at the Exits column alongside Views. A high exit percentage on a page that sits in the middle of a natural reading or purchase flow is a warning sign.
If people are landing on a page and leaving without a single interaction, they probably didn't wait for it to load.
Combine this with average session duration. A page with a 70% exit rate and average session duration under 10 seconds is almost certainly losing people before they've seen any content. On a well-built page with relevant traffic, that pattern doesn't happen by accident.
We walked through a real version of this pattern in our case study The Checkout That Loaded Too Slowly — a checkout page with a cascade of third-party payment scripts that inflated load time and caused measurable drop-off in GA4's funnel data before anyone ran a speed test.
Method 3: Device Breakdown — Mobile vs Desktop
Go to Reports › User › Tech › Tech overview, then switch to the Device category dimension. Compare engagement rate and average engagement time between Desktop, Mobile, and Tablet.
Healthy sites typically show modestly lower engagement on mobile — smaller screens, more distractions, shorter sessions. What you're looking for is a disproportionate gap: desktop engagement rate at 65%, mobile at 28%. That kind of divergence points to a page that works acceptably on a fast wired connection and breaks down on a 4G signal.
| Device | Engagement Rate | Avg. Engagement Time | Interpretation |
|---|---|---|---|
| Desktop | 62% | 2m 14s | Healthy baseline |
| Mobile | 24% | 0m 22s | Speed problem likely |
| Mobile | 51% | 1m 38s | Acceptable mobile gap |
If you drill further into the Browser dimension and find that Chrome on Android is particularly bad while Safari on iOS is fine (or vice versa), that's a more specific clue — it may point to a script or resource that behaves differently by browser rather than a pure network speed issue.
Method 4: Connect Search Console and Check Core Web Vitals
If you've linked Google Search Console to GA4, go to Reports › Acquisition › Search Console › Google organic search traffic. This integration surfaces landing page performance data alongside your GA4 behaviour metrics.
More directly, open Search Console itself and navigate to Experience › Core Web Vitals. This report uses real-world Chrome field data — actual users loading your pages on their actual devices and connections. Pages flagged as "Poor" or "Needs Improvement" for Largest Contentful Paint or Cumulative Layout Shift are confirmed slow in the way that matters for both user experience and search ranking.
Core Web Vitals thresholds to know: Largest Contentful Paint should be under 2.5s (good) or above 4s (poor). Interaction to Next Paint should be under 200ms. Cumulative Layout Shift should be under 0.1. Pages failing two or more of these thresholds will typically show the engagement patterns described above.
The connection between Core Web Vitals and Google's ranking system means slow pages often have a double problem: they lose users immediately and they don't rank as well as faster competitors. The two effects compound each other over time.
What to Do Once You've Found Your Suspect Pages
The GA4 investigation gives you a shortlist. The next steps are:
- Run each suspect URL through PageSpeed Insights on mobile. Note the Largest Contentful Paint, Total Blocking Time, and any specific diagnostics (render-blocking resources, oversized images, unused JavaScript).
- Check Search Console › Core Web Vitals to see if these URLs are flagged there too.
- If you have a developer available, use Chrome DevTools (Network tab, throttled to "Slow 4G") to watch the page load frame by frame and identify exactly what's holding it back.
- Common fixes: compress and serve images in WebP format, defer non-critical JavaScript, enable browser caching, reduce third-party script load (chat widgets, tag managers, advertising pixels).
Speed improvements tend to produce measurable GA4 results within two to four weeks — enough time for the engagement time and exit rate numbers to stabilise at the new baseline. Set up a date comparison in GA4 before and after any speed work so you can document the change.
Frequently asked questions
What happened to the GA4 page speed report?
Google removed dedicated Site Speed reporting when Universal Analytics was retired. GA4 does not include a native page speed section. Instead, you diagnose slow pages indirectly using engagement time, exit rates, and device comparisons in GA4, then verify with PageSpeed Insights or Google Search Console's Core Web Vitals report.
How do I find slow pages in GA4?
Open Reports › Engagement › Pages and screens. Sort by average engagement time ascending to surface pages users leave quickly. Filter to content pages (exclude checkout, thank-you pages) and look for pages where engagement time is unusually low compared to similar content. Cross-reference those URLs in PageSpeed Insights to confirm a speed problem.
What's a good average engagement time for a blog post?
A typical 1,000-word blog post should hold readers for at least 90–120 seconds on average. Pages under 30 seconds average engagement time warrant investigation, especially if the page has substantial content. Short engagement on long content is one of the clearest indirect signals that something — speed, layout, or relevance — is driving people away before they can read.
Why does my mobile engagement rate keep dropping?
Mobile devices load pages on constrained networks and processors, so speed problems that desktop users barely notice become deal-breakers on mobile. If your GA4 device report shows desktop engagement rate staying healthy while mobile engagement rate falls, the most common cause is a page too heavy for mobile connections — large uncompressed images, blocking third-party scripts, or a slow server response time.
How WebSignalytics helps
Hunting through GA4 for speed signals manually is effective — but it requires knowing which reports to check, which comparisons to run, and what patterns to look for. WebSignalytics reads your GA4 data each week and surfaces exactly these patterns in plain language: pages where engagement time dropped significantly, device divergence that looks like a speed issue, exit rate spikes on pages that should perform better.
Instead of building the analysis yourself every time, you get a weekly email that flags the pages worth investigating — with the specific numbers. You take it from there with PageSpeed Insights and Search Console. The diagnostic loop stays fast.
Stop hunting for slow pages manually
WebSignalytics reads your GA4 data every week and emails you the pages where engagement signals suggest a speed problem — before it compounds.
Start your 14‑day free trial