How to Improve PageSpeed Insights: A Guide to Scoring 100/100

Introduction: Can you really score 100 on Google PageSpeed Insights?

A 100/100 score in Google PageSpeed Insights is possible, but getting there on a real website with analytics, navigation, consent management, product listings and third-party scripts is a different challenge from perfecting an empty test page. The aim should be to deliver the useful part of the page immediately, keep the interface stable and allow visitors to interact without delay.

This guide shows the order in which to diagnose and fix performance problems, with implementation examples covering responsive images, LCP fetch priority, render-blocking CSS, JavaScript, fonts, analytics, layout shifts and server response times. It also explains when chasing the last few Lighthouse points is less valuable than improving actual visitor experience.

The short answer: render meaningful HTML quickly, make the LCP resource discoverable and high priority, load the right-sized image, minimise critical CSS and JavaScript, reserve space for dynamic elements and measure real-user LCP, INP and CLS. A green score is the outcome of those changes, not the optimisation strategy itself.

What is a good PageSpeed Insights score?

Google PageSpeed Insights combines a Lighthouse laboratory test with real-user performance data from the Chrome User Experience Report (CrUX), where sufficient field data exists. These are different measurements and should not be conflated.

A 100 score is a perfect result for that particular Lighthouse run, not proof that every visitor will load the page instantly. Test variability, devices, networks, page state, cookies and A/B tests can change the result. Mobile and desktop use different test conditions.

Crucially, Lighthouse's performance score is not the same thing as the Core Web Vitals assessment. Lighthouse includes metrics such as Total Blocking Time (TBT), whereas the field Core Web Vitals assess actual user interactions through INP. Equally, Accessibility, Best Practices and SEO are separate Lighthouse categories: a green performance score does not automatically make those categories green. See Chrome's explanation of Lighthouse scoring.

Core Web Vitals: LCP, INP and CLS targets

Google's Core Web Vitals use the 75th percentile of real-user measurements, assessed separately for mobile and desktop where data is available.

LCP is about when the largest visible content element paints. INP measures the responsiveness of interactions throughout a visit. CLS measures unexpected visual movement, excluding qualifying shifts shortly after user input. Use web.dev's Core Web Vitals guidance for the exact definitions and measurement considerations.

Why a 100 Lighthouse score can still fail Core Web Vitals

A controlled test may run before consent banners, third-party personalisation, logged-in content or later user interactions expose problems. CrUX reports are aggregated across real visits, while Lighthouse captures a synthetic page load. Both are useful: lab tests tell you where to investigate; field data confirms whether your improvements matter.

How to improve PageSpeed Insights: start with a repeatable audit

Do not begin by installing a caching plugin or removing scripts at random. Establish a baseline and identify the bottleneck.

1. Test the same canonical URL, once on mobile and once on desktop, using PageSpeed Insights.
2. Record the performance score and the actual LCP, FCP, Speed Index, TBT and CLS metrics; separately record available CrUX LCP, INP and CLS data.
3. In Chrome DevTools Performance, inspect the LCP element, network requests, long tasks and layout shifts. In Network, check the first document's time to first byte and the request waterfall.
4. Repeat tests under comparable conditions rather than trusting one run. Test consent states, common templates and any logged-in or personalised pages.
5. Fix in this order: slow response → late LCP discovery → render blocking → oversized imagery → excessive JavaScript → CLS and INP defects. Re-test after each meaningful change.
6. Monitor real users over time; CrUX's trailing 28-day period will not instantly reflect a deployment.

For large websites, group findings by shared template and component. Fixing one global header or shared stylesheet can improve hundreds of URLs; tuning a single page score may not.

How to improve Largest Contentful Paint (LCP)

LCP is often the biggest opportunity on image-led pages. First identify which element is actually LCP: it may be a hero image, product image, heading or large text block. Optimising the wrong resource wastes time.

A useful diagnostic is to break LCP into: server time to first byte (TTFB), resource load delay, resource load duration and element render delay. The biggest portion tells you what to fix. Google's LCP guide explains why early discovery and sensible prioritisation matter.

Give the LCP image high fetch priority

Use a real image element in the initial HTML wherever possible. Do not lazy-load your LCP image. If the hero is the principal LCP candidate, an appropriate implementation is:

<img
  src="/images/hero-960.webp"
  srcset="/images/hero-480.webp 480w,
          /images/hero-960.webp 960w,
          /images/hero-1440.webp 1440w"
  sizes="(max-width: 600px) 100vw,
         (max-width: 1100px) 85vw,
         1100px"
  width="1440" height="900"
  alt="A meaningful description of the hero image"
  loading="eager" fetchpriority="high" decoding="async">

The sizes values are illustrative: they must reflect the actual rendered slot widths of your layout. The browser chooses the source based on the slot width and device pixel ratio, not simply the screen width. width and height should express the image's intrinsic aspect ratio so layout space is reserved.

Preload LCP images only when discoverability requires it

A normal <img> in the initial HTML is often discovered early enough without preloading. If the LCP image is a CSS background or inserted later by JavaScript, consider a carefully targeted responsive preload:

<link rel="preload" as="image"
  imagesrcset="/images/hero-480.webp 480w,
               /images/hero-960.webp 960w,
               /images/hero-1440.webp 1440w"
  imagesizes="(max-width: 600px) 100vw,
              (max-width: 1100px) 85vw,
              1100px"
  fetchpriority="high">

Do not preload several formats or multiple competing hero images: unnecessary requests can make LCP worse. A preload must match the actual image selection and should be tested in DevTools. Read Google's responsive preload advice.

Reduce LCP element render delay

When an image downloads quickly but paints late, investigate CSS visibility, entrance animations, client-side hydration, fonts and JavaScript execution. For an SPA, ensure the meaningful content is present in server-rendered HTML when practical, rather than waiting for application bootstrap to insert it. Prioritising the network request cannot fix a late-rendering component.

How to optimise images for web performance

Correctly sized image assets are more important than simply changing everything to WebP or AVIF. A 2,000-pixel file displayed in a 350-pixel-wide mobile column can waste bandwidth, even if compressed.

Responsive image sizes with srcset and sizes

• Create a small set of useful widths based on actual image slots, such as 480, 960 and 1440 pixels, rather than an arbitrary variant for every device.
• Use srcset to list source widths and sizes to describe the CSS slot at different viewport widths. The browser can choose larger assets for high-density screens.
• Use modern formats such as AVIF and WebP where appropriate, with a JPEG/PNG fallback if necessary. Compare actual quality and encoded byte size; newer is not automatically better for every image.
• Set accurate width and height or CSS aspect-ratio to prevent layout shifts. Preserve subject matter when cropping images.
• Lazy-load below-the-fold content using loading="lazy"; avoid lazy-loading your LCP candidate.

For product grids or blog cards, ensure the image CDN or build pipeline generates variants that correspond to the component's real dimensions. If a desktop grid displays four 280-pixel cards, downloading a 1500-pixel image for each card is rarely justified.

Image compression without sacrificing quality

Use visual comparisons: fine typography, diagrams and products with sharp edges may require different encoding settings from photography. Strip unnecessary metadata where allowed and verify that image transformations do not break URLs, accessibility text or image-search indexing. Read Google's responsive images guide.

Eliminate render-blocking resources: CSS, JavaScript and fonts

A fast server and small hero image still cannot produce fast rendering if the browser must download and process enormous stylesheets or synchronous scripts first.

Reduce unused CSS and keep critical CSS small

Inspect Coverage in Chrome DevTools to find styles not used by the tested page. Split global bundles by template where it makes sense, remove obsolete selectors and avoid shipping large third-party styling libraries to pages that do not need them. Small, stable critical CSS can be inlined for above-the-fold layout, with non-critical styles loaded appropriately; do not inline hundreds of kilobytes into every HTML response.

Be careful: deferring essential CSS can cause unstyled content and CLS, so any CSS delivery change needs visual regression tests. CSS for the header, hero, first viewport and their reserved dimensions is usually critical.

Defer JavaScript and reduce long tasks

Use defer for classic external scripts that depend on the document and need ordered execution, or async for independent scripts that can execute as soon as downloaded. ES modules are deferred by default. Neither attribute magically eliminates the cost of executing JavaScript.

<script src="/js/navigation.js" defer></script>
<script src="/js/independent-widget.js" async></script>

Audit large frameworks, carousels, form libraries, icon packages and duplicate tag loaders. Use code splitting and load route-specific features only when needed. Breaking up long main-thread tasks helps both TBT in the lab and INP in real use. Do not defer a critical control until it becomes unusable: performance needs to preserve functionality and accessibility.

Optimise web font loading

Keep font families, weights and subsets to what the design actually uses. Serve compressed WOFF2 files, use font-display intentionally and consider preloading only the font required for prominent above-the-fold text. Where swapping fonts changes text width and causes CLS, align fallback metrics using size-adjust, ascent-override, descent-override and line-gap-override where supported. System fonts can be a useful option, but a branded web font is not automatically a mistake.

See web.dev's web-font loading guidance.

How to prevent Cumulative Layout Shift (CLS)

A page can appear to load quickly yet still feel broken when elements move underneath a user's finger. Common causes include images without dimensions, late web-font swaps, expanding headers, consent banners, adverts and components injected above existing content.

Reserve space for images, banners and dynamic modules

.product-image { width: 100%; height: auto; aspect-ratio: 4 / 5; }
.ad-slot { min-height: 250px; }

The reserved area must match the intended layout. A fixed 250px advert slot is only appropriate where that is genuinely the expected size; different breakpoints may need different reservations.

Fix header and font-related layout shifts

Give headers and navigation a stable initial height, including the mobile state. Avoid collapsing the header after the first paint. Preload necessary fonts carefully and use metric-compatible fallbacks so text lines do not reflow dramatically when fonts arrive.

Make consent and accessibility components stable

A consent panel should not unpredictably push the content down; choose an accessible overlay or reserve the necessary space. Ensure focus, keyboard controls, contrast and dismiss actions work. Do not hide essential notices merely to inflate the score. In Chrome DevTools, inspect the Layout Shifts track to identify the actual shifting nodes rather than assuming the highlighted paragraphs are the underlying cause.

Improve Interaction to Next Paint (INP) without breaking the website

INP reflects responsiveness to interactions such as tapping a menu, adding to basket or opening an accordion. A site with fast initial paint can still fail INP if its main thread is occupied by scripts or expensive DOM work.

Reduce JavaScript execution and long tasks

• Profile interactions on realistic lower-powered mobile devices, not just a fast desktop.
• Remove duplicate listeners and unnecessary re-renders; avoid heavy synchronous DOM measurement and rewriting in the same frame.
• Split work into smaller tasks and yield to the browser where appropriate, especially around user interactions.
• Keep the DOM manageable and avoid huge third-party widgets on every template.
• Validate important journeys after optimisation: menus, search, forms, accessibility controls and checkout flows.

TBT is a helpful lab proxy for main-thread blocking, but it does not replace field INP. A 100 laboratory score does not certify every possible interaction on a real website.

Google Analytics, GTM and third-party scripts: do they slow down PageSpeed?

Analytics, consent management, advertising and customer-service integrations can compete with critical rendering resources. However, simply removing GTM or GA4 from the test page proves little if the site needs reliable measurement in production.

Load analytics after critical rendering where appropriate

Classify scripts by purpose: essential consent and functionality, measurement, marketing and optional embellishments. Keep non-critical scripts asynchronous, reduce the number of containers and tags, and prevent unnecessary synchronous work during LCP. Depending on consent requirements and measurement design, some tags can initialise later — but delaying tags can lose events, attribution or consent signals. Test trade-offs with analytics and legal stakeholders.

Audit consent management and duplicate scripts

Consent platforms can introduce CSS, overlays and event listeners. Check that they are not shifting content, delaying hero visibility or launching duplicate page views during SPA navigation. Monitor whether tags behave correctly across initial loads, route changes and consent updates.

Beware of artificial Lighthouse optimisation

Blocking third-party scripts only for Lighthouse user agents, disabling analytics for tests, or serving a stripped-down test version may raise a score without improving the actual visitor experience. The objective is a fast fully operating website, not a misleading report.

Improve server response time, caching and delivery

If the HTML document arrives late, downstream resource optimisations start from a disadvantage. Investigate TTFB using real-user data and traces, and distinguish server processing from network latency and redirects.

• Use appropriate full-page or fragment caching for public content, with clear invalidation rules.
• Deliver static assets through a CDN where beneficial and set long-lived immutable caching on content-hashed files.
• Enable Brotli or gzip compression for compressible text resources.
• Remove redirect chains and review slow database queries or expensive server-side rendering.
• Use modern transport protocols when supported, but measure before assuming HTTP/3 alone will solve performance.
• Preserve cache correctness for logged-in, personalised and consent-dependent responses.

Server-side rendering can make useful HTML and LCP resources discoverable early, but a heavy server render or hydration process may simply move the bottleneck. Optimise the entire request-to-render sequence.

PageSpeed Insights mobile vs desktop: why scores differ

Mobile Lighthouse testing represents constrained device and network conditions, so mobile performance often exposes weaknesses that a desktop run conceals. Do not treat the mobile score as a scaled-down version of desktop: it is a separate test configuration.

Evaluate responsive breakpoints, mobile-only menus, image slot widths, script execution and touch interactions. A 1200-pixel hero may be sensible for a large desktop container but unnecessarily heavy for a 360-pixel mobile layout. Conversely, high-density devices may legitimately need more image pixels than the CSS width suggests.

Measure both experiences, prioritising the devices your real visitors actually use while ensuring everyone gets a stable, accessible page.

A practical website speed optimisation checklist

Use this checklist as an implementation sequence, not as a promise that ticking every box guarantees 100.

Run tests across representative templates, devices and states. Document each change and its before/after metrics so regressions can be identified later.

Is a 100/100 PageSpeed score worth it for SEO?

Page experience matters, but a perfect Lighthouse number is not a separate Google ranking requirement. Google's ranking systems use Core Web Vitals as part of page-experience considerations, while relevance and helpfulness remain fundamental. A page can be fast and still fail to satisfy search intent.

If a site scores 95 in Lighthouse and passes field LCP, INP and CLS comfortably, removing essential functionality just to reach 100 is usually the wrong priority. If it scores 100 in one lab run but real visitors experience slow product interactions or consent-related CLS, there is still meaningful work to do.

Treat 100/100 as an ambitious engineering benchmark; treat stable, accessible, fast real-world experiences as the business objective.

Conclusion: make a fast website, not just a fast test

Getting into the green on PageSpeed Insights is usually the result of disciplined prioritisation: make useful content available early, give the true LCP resource the attention it deserves, send appropriately sized images, keep CSS and JavaScript from blocking rendering, and prevent unexpected movement.

For a fully functional website, the final stages require judgement. Keep analytics accurate, maintain consent and accessibility, and measure interactions that occur after the initial load. The best PageSpeed optimisation is one that improves real user experience and survives the next release.