Improve your PageSpeed score: the complete method to go green

Measure, prioritize, fix, verify: the rigorous method to durably raise your PageSpeed Insights score, without chasing a meaningless 100/100.

A client sends you the red screenshot from PageSpeed Insights, a score of 38 on mobile, and asks you to "fix it by Monday". On WordPress, you install a cache plugin, enable compression, look again: 42. The client is not convinced. Neither are you.

This situation is probably the most frequent in the life of a web agency or a freelancer. Improving a PageSpeed score is not magic: it is a rigorous method combining measurement, prioritization, and corrections by decreasing impact. This article gives you the complete method, applicable whether you work on WordPress, a specific CMS, or a custom site.

What the PageSpeed score really measures (and what it does not)

The score displayed by Google PageSpeed Insights comes from two distinct sources, and confusing them explains most misunderstandings with clients.

Lab data, field data: two worlds often confused

Lab data is generated by Lighthouse, a tool that simulates a load under standardized conditions: fixed connection, throttled CPU, default mobile viewport. This measurement is reproducible but artificial. Field data comes from the Chrome User Experience Report (CrUX). It aggregates real Chrome user data from your site's last twenty-eight days.

It is this field data that counts for SEO, not the lab Lighthouse score. Many freelancers spend hours optimizing the lab score without understanding that Google only reads CrUX for ranking. The "Core Web Vitals" report in Search Console relies entirely on CrUX data.

The Lighthouse score is a weighted average

The 0 to 100 global score is calculated from five metrics that do not carry the same weight. The current weighting (Lighthouse 10+) assigns 25% to LCP, 25% to CLS, 30% to TBT (Total Blocking Time, lab proxy for INP), 10% to FCP, and 10% to Speed Index. Concretely, three metrics alone decide 80% of the final score.

This detail changes everything in optimization strategy. Working on FCP before fixing LCP means gaining two points while losing ten elsewhere. Prioritization is the first skill to acquire before touching any code.

The three metrics that decide the score

LCP, CLS, and INP form the Core Web Vitals triad and together represent almost all the weight of the score. Understanding them individually is a prerequisite for any optimization.

LCP, the heavyweight of perceived performance

Largest Contentful Paint measures the render time of the largest visible element above the fold, typically a hero image, a video, or a large text block. The "good" threshold is 2.5 seconds, and beyond 4 seconds LCP falls into "poor". On mobile, reaching this threshold requires particular attention to TTFB, loading priority, and image optimization.

On WordPress, LCP is almost always degraded by three elements: a heavy theme, unpreloaded Google Fonts, and a hero image not optimized in WebP or AVIF. The detailed fixes are described in our complete guide to improving LCP, which covers the four technical levers to apply in order.

CLS, the stability clients do not forgive

Cumulative Layout Shift measures the visual instability of the page during loading. A cookie banner that pushes content, a delayed ad, a custom font that changes paragraph height: all of this generates CLS. The "good" threshold is 0.1, and the slightest violation is immediately visible in use.

CLS is often neglected because it does not show in a static screenshot. Yet it is the most frustrating metric for the end user, and the one that generates the most mobile abandonment. To go further on the three main causes and high-impact fixes, see the guide to fixing your site's visual instability.

INP, the FID successor many still ignore

Interaction to Next Paint replaced FID as a Google Core Web Vital in March 2024. The responsiveness measured by INP covers all user interactions (clicks, taps, keyboard input), not just the first one. The "good" threshold is 200 milliseconds, and most poorly optimized WordPress sites sit between 250 and 500 ms.

Poor INP almost always comes from a main thread saturated by third-party JavaScript: analytics, chat, tag manager, retargeting scripts. The fix involves deferring or removing these scripts, never just minification.

Diagnose before optimizing: the non-negotiable phase

The most common mistake is touching code before understanding what weighs. The diagnostic phase conditions the ROI of all subsequent optimizations.

Measure on field data, not on a single lab run

The first methodological error is running a single Lighthouse measurement and drawing conclusions from it. A single measurement carries huge noise: current network connection, load on the Google server executing the test, different dynamic content. For reliable data, either average five or six lab measurements, or rely on CrUX if the page receives enough traffic.

On low-traffic pages, CrUX is not available and only lab data counts. In that case, set a protocol: same device, same connection, same time windows, and log each measurement in a table to track evolution. Methodological discipline matters more than instantaneous precision.

Identify the real bottlenecks

Once data is stabilized, the Lighthouse report provides an opportunities list ranked by estimated gain in milliseconds. This list is the compass of your optimization work. The three entries that come up most often in audits are: "Eliminate render-blocking resources", "Properly size images", and "Reduce unused JavaScript".

A rigorous diagnosis distinguishes what depends on the server (TTFB, configuration, HTTP cache), what depends on the theme or framework (critical CSS, fonts, global scripts), and what depends on the page content (uncompressed images, autoplay videos). This breakdown drives the priority of actions and the quote if you bill the work. A complete approach covering the five performance dimensions is detailed in our website performance audit.

Document the initial state to measure progress

Without a documented initial state, you cannot prove improvement to the client. Documentation must include mobile and desktop scores, Core Web Vitals detail, the opportunities list, and a dated screenshot. This file is what justifies the invoice once the work is delivered.

In audits run with Orilyt, we regularly observe that agencies automating this initial-state capture close their maintenance missions more easily than those who simply send a raw score. Dated proof is the simplest commercial argument to handle.

High-impact fixes, in order of priority

Optimizing in the order of decreasing marginal gains is the most profitable rule. Here are the levers ordered by return on effort on most WordPress sites.

Server and TTFB first

Before touching the front end, look at TTFB. As long as the server takes more than 600 milliseconds to respond, no client-side optimization will save your LCP. On WordPress, the classic levers are hosting (low-end shared to VPS or managed), full-page cache (WP Rocket, LiteSpeed Cache, Cachify), and PHP version (8.2 minimum, ideally 8.3).

A site that drops from 800 to 200 ms TTFB sees its LCP mechanically decrease by 600 ms, the difference between a "poor" and a "good" score on mobile. It is the best impact-to-effort lever in most cases.

Images, the second most profitable lever

Images often represent more than 60% of a page weight. Compression, the right format (WebP or AVIF), and responsive sizing via srcset alone fix a large part of the LCP delay. On WordPress, plugins like ShortPixel, Imagify, or EWWW handle this chain transparently.

The hero image deserves specific treatment: it must be declared with fetchpriority="high" and preloaded if known in advance. Without that, the browser loads it in competition with CSS and fonts, which can add a second to LCP.

Third-party JavaScript, the area degrading INP the most

Every third-party script added to your site costs parsing and execution time on the main thread. Google Analytics, Google Tag Manager, the Meta pixel, a chat widget, a cookie banner: stacked without thought, these scripts destroy INP. The rule is simple: every non-critical script must be loaded async or defer, and strictly marketing scripts should be triggered after user interaction when possible. Our article on render-blocking scripts that slow display details the detection and correction method.

Working on scripts demands rigor because it touches functionality: a poorly deferred GTM can break conversion tracking. This is typically the work where an agency's value is immediately visible in the before-and-after audit.

Critical CSS and fonts

The critical CSS describing render above the fold must be inlined in the <head> or loaded in priority. Web fonts must be preloaded and use font-display: swap to avoid FOIT (Flash of Invisible Text). These optimizations are details but can save 200 to 400 ms on LCP, which is often enough to flip the metric into green.

Mistakes that crash a score without you seeing it

Four recurring blind spots turn hours of optimization into marginal gain. Avoiding them is discipline, not technique.

The 100/100 race, counterproductive

Many freelancers and clients obsess over 100/100, when a score between 90 and 100 changes nothing for user experience or SEO. Reaching 100 on mobile often requires removing useful features (animations, custom fonts, background videos) to gain two symbolic points. The reasonable target is a lab score above 90 on desktop and above 75 on mobile, with all Core Web Vitals in the green on CrUX. Beyond that, the effort-to-benefit ratio collapses. Our article on why a score is not enough details how to communicate this point to the client without destroying perception of your work.

Optimizing without measuring mobile

Mobile is stricter than desktop on every criterion: simulated 4G connection, throttled CPU, narrow viewport. A page showing 95 on desktop can show 38 on mobile for the same resources. Google has indexed mobile-first since 2020, so only the mobile score counts for SEO.

Testing only on desktop is a frequent mistake, especially in agencies working on large screens all day. The minimum discipline is to always look at both scores and prioritize mobile for any optimization.

Stacking cache and performance plugins

On WordPress, plugin stacking is a classic performance killer. A cache plugin, an image optimization plugin, a minification plugin, a lazy loading plugin, a CDN plugin: each adds its script and rules, sometimes in conflict with others. The result is often worse than the initial situation.

The rule is to pick an integrated suite (WP Rocket covers cache, minification, lazy load, preload) or a coherent combo (LiteSpeed Cache if the host is on LiteSpeed Server) rather than stacking point solutions. Progressively disabling useless plugins is often the first gain of an audit.

Confusing Lighthouse score and SEO signal

Improving the Lighthouse score does not guarantee better Google ranking. The engine has used Core Web Vitals as a ranking signal since June 2021, but these signals are measured in the field via CrUX, not in Lighthouse. A page can show 100 in lab and have mediocre CrUX if real users load from slower connections than the simulated one.

Conversely, a page with an average lab score can show excellent field Core Web Vitals if the user base is mainly on fiber. The metric that counts is always CrUX, and it must be explained to clients comparing two Lighthouse scores as if they were absolute truth.

Industrialize score tracking across a portfolio

Point-in-time measurement is not enough for an agency managing multiple client sites. Standardization and historization turn one-off optimization into a recurring service.

Measuring is not enough, you need history

A freelancer managing five to ten client sites cannot relaunch Lighthouse manually each month. Automated monitoring is the only way to detect a regression before the client complains. A plugin update, a theme change, a new marketing tag can degrade the score with no visible alert. The history of measurements also allows proving the value of a maintenance contract, as we detail in our article on the history of audit scores. A six-month graph showing a stable score is the most effective commercial argument for annual renewal.

Distinguish client report from technical report

The report generated for the client must not be the raw technical report. The client wants a score, a before-after comparison, and a summary in plain language of the three priorities. The technical report contains the Lighthouse detail, the opportunities, and the server diagnostics, and stays internal to the provider.

This distinction separates a sales-ready report from an intimidating one. Orilyt produces a readable client report and a complete technical report from a single audit, which spares the agency from manually reworking the deliverable.

Standardize tracking across the portfolio

For an agency managing twenty sites, standardizing the measurement protocol and report format is a massive time saver. All sites measured at the same time, with the same criteria, with an identical deliverable format: that is the condition for maintenance to become a scalable and profitable activity. White-label multi-page monitoring, included from the Solo plan, automates this periodic capture across the portfolio.

Improving the PageSpeed score is not a sprint on a single metric, it is a continuous cycle of measurement, prioritization, correction, and verification. The three metrics that matter are LCP, CLS, and INP; the rest is secondary. Methodological discipline matters more than the quantity of optimizations applied: an agency that measures cleanly and corrects in order of impact systematically beats an agency that stacks plugins.

For freelancers and agencies managing multiple client sites, industrializing the tracking quickly becomes essential. An audit tool that automates measurement, generates understandable reports, and keeps a history turns a one-off engagement into a recurring maintenance contract. That is exactly the role Orilyt was designed for.

Your most frequent questions

Sources and references

• Google web.dev, Core Web Vitals — official reference for LCP, CLS, INP thresholds and their ranking integration
• Google web.dev, Interaction to Next Paint (INP) — official documentation on the metric that replaced FID in March 2024
• Google Developers, Lighthouse Performance Scoring — official weighting of the five metrics (FCP, SI, LCP, TBT, CLS)
• Google PageSpeed Insights — official operation of the tool, lab data vs field data
• Chrome User Experience Report (CrUX) — Google documentation on the field data used for ranking
• Google Search Central — Page Experience update, progressive rollout starting June 2021
• HTTP Archive, Web Almanac 2024 Performance chapter — annual overview of global web performance