What is PageSpeed Insights? Average Score Benchmarks and 7 Ways to Improve It
Website loading speed is a critical factor that directly impacts both user experience and search engine evaluation. PageSpeed Insights, a free tool provided by Google, lets you diagnose a page's loading speed, interactivity, and visual stability — and presents concrete improvement suggestions — simply by entering a URL.
On the other hand, many practitioners ask: "I can't read the score," "Should we really target 90 points?" "Where do we start for the fastest improvement?" This article walks through the fundamentals of PageSpeed Insights and its relationship with SEO, the difference between field data and lab data, the Core Web Vitals pass thresholds, realistic score benchmarks by industry and site size, and seven improvement methods ordered by impact — all from a hands-on web operations perspective. It is written for both newcomers who are about to use PageSpeed Insights for the first time, and for those who already watch the score but cannot push past a plateau.
PageSpeed Insights (PSI) is a free web performance diagnostic tool provided by Google. Enter the URL of the page you want to measure, click "Analyze," and you receive a 0–100 performance score, actual Core Web Vitals measurements, and a list of improvement suggestions — for both Mobile and Desktop. It requires no account or login, has no usage limit, and works for competitor sites as well as your own.
Measurement is strictly page-level; you cannot enter a domain to analyze a whole site at once. A realistic approach is to start with the top page and main landing pages, then gradually expand to high-traffic and SEO-critical pages. Because PSI is wired to Google Search's page experience signals, in SEO practice it is treated as "Google's official health checkup tool for site display."
The first thing to grasp when reading a PSI report is the distinction between the two data types it shows: "Field Data" and "Lab Data." Field data is real-user experience data based on the Chrome User Experience Report (CrUX), reflecting the distribution of Core Web Vitals actually experienced by visitors over the previous 28 days. This is what counts for SEO evaluation.
Lab data, on the other hand, is the result of Lighthouse simulating the page in a standardized virtual environment (mobile-equivalent network and device performance). It is highly reproducible, which makes it useful for before/after comparison and for pages with too little traffic to generate field data. The standard practice is to "use field data to understand real user experience, and lab data to diagnose root causes and verify the impact of fixes." The 0–100 score is a lab-data result and is not, strictly speaking, a direct ranking factor. What is tied to SEO is the underlying Core Web Vitals measurements.
The PSI score itself is not a ranking signal that Google has publicly named. However, the Core Web Vitals it surfaces (LCP, INP, CLS) do influence search evaluation as components of Page Experience. When pages of comparable content quality compete, the one with better speed, responsiveness, and visual stability tends to be preferred — that's the closest description of reality.
Even where direct SEO impact is small, faster display improves SEO indirectly through user experience. Slow pages raise bounce rates and reduce conversion and pageviews; fast sites improve dwell time, return visits, and branded-search lift, which feed back into rankings. The correct way to use PageSpeed Insights for SEO is not to chase a perfect 100, but to find and remove bottlenecks that are degrading real-user experience.
The PSI performance score runs from 0 to 100 and is a weighted blend of several Lighthouse metrics. Color coding is: 0–49 red (Poor / Slow), 50–89 orange (Needs Improvement), and 90–100 green (Good). "Green" means "pass," but you don't have to chase 90+ — it's healthier to set realistic targets calibrated to your industry baseline and remediation cost.
What matters is that the score is calculated separately for Mobile and Desktop. Because Google uses mobile-first indexing, for SEO purposes the rule is to prioritize improving the Mobile score. Many sites comfortably hit around 90 on Desktop, while Mobile lingers in the 50–70 range due to network and CPU constraints — meaning the room for improvement is concentrated on the mobile side.
LCP (Largest Contentful Paint) measures the time it takes for the largest content element on the page — a hero image, a large heading, a video thumbnail, and so on — to be rendered. It is the metric closest to a user's sense of "the page has finally appeared," and is widely regarded as the highest-impact lever among Core Web Vitals.
Google's official thresholds, measured at the 75th percentile of field data, are: ≤ 2.5s = Good, 2.5–4.0s = Needs Improvement, > 4.0s = Poor. The typical causes of slow LCP are server response latency, oversized hero images, render-blocking CSS/JavaScript, and slow font loading — and most of the improvement methods discussed later in this article hit LCP directly.
INP (Interaction to Next Paint) was officially added to Core Web Vitals in March 2024, replacing FID (First Input Delay). FID measured only the responsiveness of the very first click or tap, whereas INP evaluates the responsiveness of every interaction throughout the page session. Think of it as "the lag between an action and a visual response": opening a menu, typing into a form, the screen stalling for a beat after a button press.
Pass thresholds at the 75th percentile are: ≤ 200 ms = Good, 200–500 ms = Needs Improvement, > 500 ms = Poor. INP is most often dominated by long JavaScript main-thread tasks, and is frequently hit by heavy third-party scripts (chat, ad tags, heatmaps) and by bloated first-party JavaScript bundles.
CLS (Cumulative Layout Shift) measures how much content unexpectedly moves during page load or interaction. It quantifies experiences like "I tried to tap a link, but an ad loaded and the layout shifted, and I tapped the wrong button." Lower is more stable.
Pass thresholds at the 75th percentile: ≤ 0.1 = Good, 0.1–0.25 = Needs Improvement, > 0.25 = Poor. Major sources of CLS are images, iframes, and ad slots without size attributes, web fonts that load late and push surrounding content, and banners or notification strips injected after initial render. The technical fixes are relatively simple, so the effort-to-impact ratio is high — making CLS a metric worth tackling early.
"What's the average PSI score?" is a common question, but the honest answer is that it depends heavily on what kind of site you run. Simple corporate sites and blogs commonly score around 80 on Mobile and 95 on Desktop. Image-heavy e-commerce sites, motion-rich media sites, and SaaS marketing sites realistically sit in the 40–60 Mobile / 70–85 Desktop range — and still feel plenty fast to users.
Sites built on dynamic CMSs like WordPress also see scores swing widely based on plugin count and theme quality. Rather than chasing a flat "industry average" number, set a realistic target by comparing against your own site type, scale, and primary competitors.
More important than the absolute score is whether all three Core Web Vitals (LCP, INP, CLS) clear the "Good" threshold at the 75th percentile of field data. Google defines passing Core Web Vitals as "75% or more of visits meet the Good thresholds on all three," and Search Console's Core Web Vitals report aggregates the same way.
Put differently, a 70-point PSI score is still well within the SEO-pass range as long as LCP, INP, and CLS are all in the Good band. Conversely, a 90-point score with CLS in the Poor band still counts as Poor for Core Web Vitals. Use "are all three metrics in the Good band?" as the primary judgment axis, ahead of the total score — that view is both pragmatic and consistent with Google's own design.
A recommended first target is to land all three Mobile Core Web Vitals in the Good band (LCP ≤ 2.5s, INP < 200ms, CLS ≤ 0.1). The total score then naturally climbs from the 50–70 range over time. Reversing this order tends to lead to misprioritized work. Treat the score as a "report card" that visualizes progress, but don't chase the absolute number too hard.
Even on legacy sites where structural changes are hard, it is realistic to move the dial in stages: from Poor to Needs Improvement to Good. For example, taking Mobile LCP from 4.5s down to 3.5s (into Needs Improvement), then to 2.3s (into Good) via image optimization and CDN adoption is a typical six-month improvement roadmap for a website improvement project.
The following seven methods are ordered by impact. The first three directly target LCP, the next two address INP and CLS, and the last two are about site-wide foundation and operations. Tackling them in order delivers the largest score gain for the least effort.
Image optimization is the most immediate, lowest-cost LCP improvement. There are three levers. First, modernize the image format: converting JPG/PNG to WebP (or AVIF where appropriate) typically cuts file size by 30–70% with no visible quality loss. Second, serve images at the display size: stop loading a 2400px source where the layout shows 800px, and use srcset for responsive delivery so each device gets an appropriate size.
Third, introduce Lazy Loading so off-screen images only load as they approach the viewport. At the same time, the hero image inside the first viewport — your LCP candidate — should be preloaded for priority delivery. The rhythm is "off-screen = lazy, first viewport = preload." On WordPress, image-optimization plugins do most of the work; on a headless CMS stack, the framework's built-in image component (Next.js, Nuxt, etc.) is the easiest path with minimal implementation cost.
Browsers parse HTML and pause to wait for CSS and JavaScript before painting. A bloated CSS file that has nothing to do with the first viewport, or a JavaScript file that could just as easily load later, pushes LCP back by exactly that amount. This is the "render-blocking resources" issue PSI surfaces so often.
Standard fixes are: inline the CSS critical to the first viewport (critical CSS) and load the rest asynchronously; attach defer or async to JavaScript wherever possible to delay it; and exclude unused CSS and JS from the build via tree-shaking. Especially on WordPress and similar environments where themes and plugins load massive amounts of CSS/JS, trimming to what each page actually uses can lift Mobile scores by 20–30 points.
Front-end optimization has limits if the initial server response (TTFB / Time to First Byte) is slow — LCP will not improve. Server response time is reduced along three axes. First, reconsider hosting: moving from shared hosting to a dedicated server or a managed service (VPS, managed cloud hosting) can deliver a major step-change.
Second, layer your caching strategy: server-side page caching (caching plugins for WordPress; SSG or incremental static regeneration on headless CMS stacks) combined with browser caching (HTTP Cache-Control headers) so the same user or the same page doesn't trigger redundant server work. Third, adopt a CDN (Cloudflare, Fastly, Akamai, etc.) to serve content from edge locations close to users, cutting the physical distance from origin. Sites with TTFB above 200ms often see LCP improve substantially from CDN adoption alone.
INP is overwhelmingly driven by JavaScript occupying the main thread. If your own JavaScript is bloated, apply code splitting to load only what's needed initially, tree-shake out dead code, and dynamically import code only when a screen needs it. If you use a modern framework like React, React.lazy and dynamic import make this concise.
The other major INP drag is third-party scripts — chatbots, heatmaps, A/B testing tools, ad tags, analytics, social embeds — that often occupy the main thread for tens or hundreds of kilobytes. PSI calls this out via the "Reduce the impact of third-party code" suggestion. Fixes are: delete scripts you are not actually using; for those you keep, defer firing via your tag manager (after DOMContentLoaded, or on user interaction); or isolate inside an iframe to limit blast radius. Just adding a quarterly tag-inventory ritual to verify "are we actually using every one of these tags?" significantly improves INP.
CLS rewards effort generously because the technical fixes are relatively simple. The single biggest move is to specify width and height attributes (or CSS aspect-ratio) on every image, iframe, video, and ad slot. Once the browser can reserve display space ahead of time, late-loading real content slots in without shifting layout.
Next, web fonts triggering FOUT/FOIT character swaps are a classic CLS source. Use font-display: swap to show a system fallback first and swap when the web font loads, and tune fallback font metrics (size-adjust, fallback font metrics) so the swap shifts text as little as possible. Also, banners and notification strips injected after load should either have a fixed height reserved upfront, or be placed somewhere that does not disrupt the flow — not pinned to the top above existing content.
Web fonts are important for design, but if poorly optimized they degrade both LCP (because text elements can themselves be the LCP element on text-heavy pages) and CLS (from the font swap shift). Fixes include: load only the weights and styles you actually use; subset large Japanese fonts to cut file size dramatically; preload them; and use modern formats like woff2.
Icons follow the same logic. If icon fonts (Font Awesome and friends) have bloated your global CSS/JS, extract the icons you actually use as SVG sprites or SVG components, or subset a dedicated icon font. The tradeoff between design requirements and load speed ultimately edges into business judgment, so options like "cut the number of fonts in use" or "swap in a lighter icon library" should be a shared conversation between the design team and the marketing team.
The seventh method is not technical — it's operational. PSI is not a one-shot measurement; you only get results by running the cycle of "measure regularly → identify bottlenecks → fix → re-measure → verify." The recommended cadence is a monthly check of the Core Web Vitals report in Search Console, tracking the trend of Poor and Needs Improvement pages over time. Search Console uses field data and aggregates across the whole site, so it complements the page-level analysis of PSI well.
Prioritize fixes by impact (high-traffic pages, important landing pages) and remediation cost (engineering effort, risk). If the top page or a key LP is in the Poor band, that's your top priority; a low-traffic article page can wait. Also, instead of shipping all seven improvements at once, release them in stages and measure the effect of each through PSI — that way you can attribute what actually moved the needle.
The most common failure mode is treating "90" or "100" as the goal in itself. Decisions like "strip out the web font we needed for design" or "remove the chat tool that was actually lifting conversions" buy you speed at the cost of CV and revenue — the textbook own-goal.
The fix is to switch to evaluating PSI "tied to business KPIs (conversions, revenue, bounce rate, dwell time)." Treat "all three Core Web Vitals in the Good band" as the floor, and judge any optimization above that by measuring its effect on user experience and business metrics. Sharing the "score is the means, business outcome is the end" hierarchy across the organization keeps decision-making aligned.
It's also common to declare a site "fast" based on a strong 90-point Desktop number while Mobile is languishing in the 60s. Google uses mobile-first indexing, and SEO evaluation prioritizes mobile-side Core Web Vitals. B2C, local, and media sites have an overwhelmingly mobile audience, and even on B2B sites decision-makers increasingly browse on mobile.
The fix is to always check both Mobile and Desktop, and to bias remediation priority toward Mobile by default. Knowing the real device mix from your analytics (Mobile vs. Desktop) makes the internal case for fixing Mobile straightforward. "More than half our users feel the mobile site is slow" — backed by data — is much more persuasive when securing engineering resources.
The PSI lab score can swing by several to a dozen-plus points between runs. Server load, network conditions at the test location, in-flight A/B test variants, third-party script latency — all of these contribute. Worrying that "we were at 85 last week, today we're at 72" is not meaningful signal.
Switch to using lab scores as "measure several times under identical conditions and take the median" and "a relative before/after comparison for a fix," rather than treating them as absolute. For long-term trends and real-user experience, read field data and Search Console's Core Web Vitals report. Field data is a 28-day rolling aggregate, so it smooths out short-term noise and reveals stable trends.
PageSpeed Insights is Google's official free tool for diagnosing a page's loading speed, responsiveness, and visual stability, with concrete improvement suggestions. The 0–100 overall score is a Lighthouse lab-data result. What is directly tied to SEO is the underlying Core Web Vitals (LCP, INP, CLS) measured against field data. Hitting LCP ≤ 2.5s, INP < 200ms, CLS ≤ 0.1 at the 75th percentile is the pass condition from both an SEO and a user-experience standpoint.
The improvement methods, ordered by impact, are: image optimization; eliminating render-blocking resources; reducing server response time and adopting a CDN; slimming JavaScript and auditing third-party scripts; suppressing layout shift; optimizing web fonts and icons; and operationalizing measurement and improvement. Start with the LCP-focused methods (1–3), then address INP and CLS (4–5), then site foundations and operations (6–7) — that order produces the biggest result for the least effort.
The key point is to stop treating "target 100 points" as the goal, and instead evaluate against "are we removing real-user bottlenecks and contributing to business KPIs?" Use this article as a starting point to measure your own site in PageSpeed Insights, design a roadmap to land all Core Web Vitals in the Good band, and run a continuous improvement cycle alongside Search Console.
A beginner-friendly guide to SEO Cheki (seocheki.net), the free Japanese SEO diagnostic tool. Covers what SEO Cheki is, ...
A practical guide to SEO on-page optimization (internal SEO): definition, how it differs from off-page and content strat...
A practical guide to marketing KPI design, covering the relationship between KGI, KPI, and KSF; how to build a KPI tree ...
