PageSpeed Insights: How to Read Your Score and Act on It

⠀

Slow pages cost you visitors, conversions, and rankings. PageSpeed Insights (PSI) is the most direct window into why your pages are slow and what to fix first. But most people run the tool, look at the score, panic or celebrate, and close the tab — without extracting the actual value from the data.

This guide explains how PSI works, what the different sections mean, and how to build a realistic action plan based on what you find.

⠀

⠀

What Is PageSpeed Insights?

⠀

PageSpeed Insights is a free Google tool that analyzes the performance of a web page. You enter a URL, and PSI returns a performance score along with a detailed breakdown of metrics, opportunities, and diagnostics.

What makes PSI unique is that it combines two types of data: field data and lab data.

Field data comes from the Chrome User Experience Report (CrUX) — real performance measurements collected from actual Chrome users who visited your page over the past 28 days. This data reflects genuine user experience under real-world conditions (variable network speeds, device types, geographic locations). Field data is what Google uses for ranking signals.

Lab data comes from a controlled Lighthouse simulation run in a fixed environment (throttled network, emulated mobile device). Lab data is reproducible and useful for debugging, but it doesn't reflect real user experience. Two runs of the same URL can produce slightly different lab scores.

The key distinction: if your field data shows poor performance, that affects your rankings and your users. If only your lab score is low but field data is good, that's less urgent — though still worth addressing.

⠀

⠀

What the Score Means

⠀

PageSpeed Insights shows a performance score from 0 to 100 for both mobile and desktop. The scoring thresholds are:

• 0–49 (red): Poor — significant performance issues impacting user experience
• 50–89 (orange): Needs Improvement — noticeable issues that should be addressed
• 90–100 (green): Good — the page loads quickly for most users

⠀

The score is a weighted composite of six performance metrics, not a simple average. Largest Contentful Paint (LCP) and Total Blocking Time (TBT, the lab proxy for INP) carry the most weight. Improving LCP alone can move your score significantly.

Don't chase a perfect 100 — it's largely meaningless in isolation. A score of 85 on mobile with green field data is far more valuable than a 100 score with no real-world data collected yet.

⠀

⠀

Mobile vs. Desktop Score — Which Matters More for SEO?

⠀

PSI displays separate scores for mobile and desktop. For SEO purposes, mobile is what matters. Google uses mobile-first indexing — it crawls and ranks your site based on the mobile version. Your desktop score is useful for UX and conversion rate purposes, but Google's ranking signals derive from mobile performance.

It's normal for mobile scores to be significantly lower than desktop scores. Mobile devices have less processing power, and PSI simulates a mid-range Android device on a 4G connection. If your desktop scores 85 but your mobile scores 45, focus on mobile first — that's what's affecting your rankings.

⠀

⠀

The Core Web Vitals Section

⠀

The Core Web Vitals section in PSI is the most important part of the report. These are the metrics Google officially uses as ranking signals, and they're measured from real user data (CrUX) when available.

Largest Contentful Paint (LCP) measures how long it takes for the largest visible element on the page to load. This is usually a hero image, a large text block, or a banner. Target: under 2.5 seconds.

The most common LCP killers are unoptimized images, render-blocking resources above the fold, slow server response times, and lazy-loaded images that shouldn't be lazy-loaded (your LCP image must load eagerly).

Cumulative Layout Shift (CLS) measures visual instability — how much elements move around as the page loads. When an image loads without reserved dimensions and pushes text down, that's CLS. When a font swap causes reflow, that's CLS. Target: under 0.1.

Fix CLS by adding explicit width and height attributes to all images and video embeds, using font-display: swap or optional for web fonts, and avoiding injecting content above existing content after load.

Interaction to Next Paint (INP) replaced First Input Delay (FID) as a Core Web Vital in March 2024. INP measures the latency of all user interactions (clicks, taps, key presses) throughout the entire page visit, not just the first one. Target: under 200 milliseconds.

Poor INP is usually caused by heavy JavaScript execution on the main thread. Long tasks that block the browser from responding to user input are the primary culprit.

⠀

⠀

Opportunities vs. Diagnostics — What's the Difference?

⠀

PSI's recommendations are split into two sections: Opportunities and Diagnostics.

Opportunities are items with a calculated potential time savings. They directly impact your performance score and include an estimated reduction in page load time. These are the items to fix first because the benefit is measurable and significant.

Diagnostics are best-practice checks that don't have a direct time savings estimate but affect reliability, accessibility, or long-term performance. Failing a diagnostic might not reduce your score today, but it signals deeper issues worth investigating.

When prioritizing, work through Opportunities in descending order of estimated savings, then move to Diagnostics.

⠀

⠀

Top Actionable Opportunities

⠀

Eliminate Render-Blocking Resources

⠀

Render-blocking resources are CSS and JavaScript files in the <head> that prevent the browser from displaying any content until they're fully downloaded and parsed. Every millisecond spent waiting on these is time the user sees a blank page.

Fix: Add defer or async attributes to non-critical JavaScript. Move non-critical CSS to load asynchronously or inline critical CSS in the <head> and defer the rest. Use <link rel="preload"> for resources needed early.

Defer Offscreen Images

⠀

Images below the fold don't need to load immediately. Lazy loading defers their download until the user scrolls near them. Add loading="lazy" to all <img> tags that aren't visible on initial page load. Critically: do not add loading="lazy" to your LCP image or any above-the-fold image.

Efficiently Encode Images

⠀

Images are the largest contributor to page weight on most sites. Efficient encoding means compressing images without visible quality loss. JPEG quality settings of 75–85 are visually indistinguishable from 100 for most photos. Use tools like Squoosh, ImageOptim, or automated build pipelines (Sharp, Cloudinary) to compress before upload.

Serve Images in Next-Gen Formats

⠀

WebP is smaller than JPEG or PNG at equivalent quality — typically 25–35% smaller. AVIF is smaller still. Modern browsers support both. If your CMS or CDN supports automatic WebP conversion, enable it. If not, generate WebP versions of all images and serve them via <picture> tags with fallbacks.

Reduce Unused JavaScript

⠀

Modern JavaScript bundles often ship code that isn't executed on a given page. Unused JavaScript wastes download time and parse time. Use code splitting to load only what's needed per route, tree-shake your bundles, and audit your dependencies for bloated libraries (e.g., importing all of Lodash when you only need one function).

Reduce Unused CSS

⠀

Similarly, many sites load global stylesheets with thousands of rules, most of which don't apply to any element on the current page. Use PurgeCSS or the CSS coverage tool in Chrome DevTools to identify and remove unused rules. CSS frameworks like Bootstrap or Tailwind ship large files that need aggressive pruning.

Minimize Main Thread Work

⠀

The main thread is where the browser parses HTML, runs JavaScript, and handles user interactions. When it's overloaded with long tasks, the page becomes unresponsive. Break up long JavaScript tasks into smaller chunks using setTimeout, requestIdleCallback, or web workers for heavy computation. Audit third-party scripts — analytics tools, chat widgets, and ad networks often contribute significant main thread work.

⠀

⠀

How to Prioritize Improvements

⠀

Not every fix has equal impact. Use this prioritization framework:

1. Fix Core Web Vitals failures first — LCP, CLS, and INP are ranking signals. If field data shows any of them in the red or orange zone, they're your top priority.
2. Attack the highest estimated savings in Opportunities — Sort by estimated time savings and work top to bottom.
3. Start with images — Images are usually the biggest win with the lowest implementation complexity. Compress, lazy-load below the fold, convert to WebP, and add proper dimensions.
4. Audit third-party scripts — Remove any script that doesn't serve a clear, current purpose. Every unnecessary tag is wasted load time.
5. Address JavaScript and CSS bloat — This requires more development effort but has compounding benefits across your entire site.

⠀

At Blakfy, we run PSI audits at the beginning of every technical SEO engagement and again after each round of changes. Tracking score and field data over time is the only way to confirm that optimizations are actually working for real users.

Re-run PSI after making changes and allow at least 4 weeks for new CrUX field data to reflect your improvements in the report.

⠀

⠀

FAQ

⠀

My desktop score is 90 but mobile is 42. Is that normal?

Yes, it's extremely common. Desktop devices have faster processors and PSI simulates a throttled 4G connection and mid-range device for mobile. Focus on the mobile score — it's what Google uses for ranking. Improving mobile almost always improves desktop too.

Why does my PSI score change every time I run it?

Lab data (the simulated Lighthouse test) has inherent variability because network timing and CPU conditions fluctuate slightly between runs. Run the test 3-5 times and look at the average. Field data, on the other hand, is stable — it's based on 28 days of real user measurements.

I got a 90+ score on PSI but my site still feels slow. Why?

PSI tests a single URL in isolation, simulating one user's experience. Real page slowness can stem from server load under concurrent traffic, slow-loading content after the initial page load (API calls, dynamic content), or issues specific to certain geographies or devices not captured in the test.

Does improving PSI score directly improve Google rankings?

Only Core Web Vitals (LCP, CLS, INP) measured from field data are confirmed ranking signals — and they're one signal among many. A page with poor Core Web Vitals will be at a disadvantage, but strong content, backlinks, and relevance still dominate. Treat performance as a foundation, not a silver bullet.