How to Reach 90+ PageSpeed Without Chasing a Screenshot

The field metrics behind those thresholds are set out in our guide to Core Web Vitals, and the relationship between performance and search in how website speed affects SEO. This page is about the work itself.

Run the test before you read the rest

Step 1: define representative pages and journeys

Group the site by template and behavior: homepage, long service page, article, location, product, collection, cart, form, calendar and authenticated state. Pick pages that represent the accepted scope and important visitor journeys. The homepage alone does not prove the rest of the site. If you are still working out which routes hurt, our walkthrough of why a website loads slowly narrows the list first.

"A Lighthouse score is one lab test on one day. It is not a permanent property of your site.

Step 2: record field and lab baselines

A mobile cold-cache run with consent accepted is not comparable to a desktop warm-cache run before tags load. Keep profiles separate and report variation instead of selecting the best run. Four things go in the baseline, and the run count is the one that makes a later comparison mean anything.

• ✓
  Save PageSpeed Insights field origin and URL data where available, including assessment date.
• ✓
  Record exact URL, release, device profile, network, CPU, location, cache, consent and login state.
• ✓
  Run each agreed lab profile at least three times and retain the raw reports.
• ✓
  Capture server timing, request waterfalls, performance traces, coverage and the rendered page.

Step 3: reduce document and server delay

Follow redirects, inspect DNS, connection, CDN, cache and origin timing, and profile the backend when the document is slow. Cache only where content, identity and invalidation rules permit it. A faster host can help an origin bottleneck; it cannot remove client-side media, script or layout work. The wider sequence for that work is laid out in our guide to speeding up a website.

Step 4: make the LCP resource discoverable and efficient

Identify the actual LCP element in the trace instead of assuming it is the hero image. Once you know what it is, the work is making it discoverable early and delivering it efficiently: right size, modern format, never lazy-loaded when it is above the fold, and nothing render-blocking sitting in front of it.

• ✓
  Identify the actual LCP element in the trace instead of assuming it is the hero image.
• ✓
  Serve an appropriately sized, compressed asset in a modern format such as AVIF or WebP, and preserve visual quality.
• ✓
  Avoid lazy-loading the above-the-fold LCP image and ensure the browser can discover it promptly.
• ✓
  Reduce render-blocking work that delays the element and verify responsive candidates.

Render-blocking is worth measuring rather than guessing at. Open the Coverage panel in devtools, record a reload, and read the unused-bytes column for each stylesheet and script. That gives you your own number for your own page, which is more useful than any published average: it tells you whether the win is splitting a stylesheet, inlining what the first screen actually needs, or deleting a file nobody has referenced in a year. Re-record after the change and compare against the figure you wrote down.

On WordPress the LCP element is usually decided by the theme or the page builder, which is where fixing a slow WordPress site and the Divi theme performance diagnostic pick the work up.

Step 5: reduce long tasks and interaction delay

Profile JavaScript execution, event handlers, hydration, layout work and third-party tasks. Remove unused code, split non-critical work, yield during long processing and keep interaction handlers small. Test the real menu, form, filter, cart and modal, not only initial load.

• ✓
  Code splitting: ship the JavaScript this route needs, not the bundle every route needs.
• ✓
  Tree shaking: drop library exports the build can prove are never reached.
• ✓
  Dynamic imports: load a modal, editor, map or carousel when it is opened, not on first paint.
• ✓
  Server rendering: send HTML for anything that does not need to be interactive on the client.

Each of these is checkable in your own build output rather than on someone's word. Print the per-route bundle sizes your framework reports at build time, note them, make one change, and print them again. If the number did not move, the technique was not applied where you thought it was.

Step 6: stabilize layout

Layout shifts come from space that was not reserved and content that arrived late. Reserve dimensions for images, video, embeds and dynamic components, never insert banners or consent UI above existing content without reserved space, and exercise the late states deliberately while recording CLS.

• ✓
  Reserve dimensions or aspect ratio for images, video, embeds and dynamic components.
• ✓
  Do not insert banners, consent UI or errors above existing content without reserved space.
• ✓
  Use stable font-loading behavior and verify fallback-to-final font changes.
• ✓
  Exercise late content, validation, loading, success and error states while recording CLS.

Fonts are worth checking yourself rather than taking on trust. Open the Network panel, filter to Font, and reload. If the request goes to an origin you do not control, the browser has to resolve and connect to that host before a single glyph arrives, and it cannot start until the stylesheet referencing the font has parsed. Self-hosting the file removes that dependency chain and lets you preload it. Then watch the text on a throttled reload: if it is invisible until the font lands you have a flash of invisible text, and if it appears in a fallback and then reflows you have a layout shift. Which of the two you get is decided by font-display, and the second is usually the better trade, provided the fallback is metric-matched.

Step 7: govern third parties and consent

Inventory analytics, pixels, chat, heatmaps, video, maps, reviews, calendars, tag managers and experiments. Record owner, purpose, consent category, load condition, transfer, performance cost and failure behavior. Defer or remove only when business and compliance requirements permit it. On a WordPress build the same inventory usually starts with the plugin and script audit.

Step 8: repeat, regress and release

Re-run the unchanged acceptance profiles three times per named page before anything ships, then check that the score work did not break functionality, accessibility, analytics or consent. Record the release version, the tool version, the reports, the exclusions and the known variance, because a number without those is not reproducible.

• ✓
  Run the unchanged acceptance profiles three times for every named page and profile.
• ✓
  Test functionality, accessibility, analytics and consent so score work did not break the journey.
• ✓
  Record release SHA or version, tool version, reports, exclusions and known variance.
• ✓
  Add budget or regression checks appropriate to the project and monitor field data after release.

Is 70 good enough? And is the tool even reliable?

The two can disagree in both directions, which is the part that confuses people. A page can sit at 70 in the lab and pass its field vitals, because the simulated device and network in the test are harsher than what your actual audience uses. A page can also score in the nineties and fail in the field, because the lab run never met your cookie banner, your logged in state, your third-party chat widget or your slowest market. If you have to choose which number to act on, act on the field data and use the lab score to find out why.

That also answers the reliability question. The tool is reliable at what it does, which is running one simulated test and telling you what it found. It is not measuring your visitors, and it will move between runs on the same unchanged page, which is why this guide asks for three runs per profile and reports the variation rather than the best result. A single score screenshot, yours or a vendor's, is one sample of a distribution presented as a fact.

Why 100 is not the right universal promise

Lighthouse weights and implementations evolve. Third-party response, experiments, visitor state and content change. A stable 96 can provide the same useful experience as a selected 100 run, while a 100 tested page can still have accessibility, security, content or business defects. Optimize the bottleneck until the accepted requirement is met, then spend effort where users and the business need it most.

How automated browsing agents encounter a page is a separate question, covered in our note on agentic browsing and the PageSpeed score, alongside the answer-engine playbook we build into a site.

PandaCodeGen's 90+ acceptance method

When accepted project terms include the target, PandaCodeGen tests the named representative pages under named mobile and desktop profiles and requires three passing runs per page and profile. The terms record environment, exclusions and remedy. No target applies to unspecified routes, changing third-party behavior or a different test profile unless the scope says so.

The target does not guarantee rankings, traffic, conversions or revenue. Those outcomes require separate property-level measurement, and search engines and users control them.

Scope tiers are listed on the pricing page, delivery sits under custom engineering, and finished builds are on the work page.

Where the constraint is the platform rather than the page, a WordPress migration is scoped separately, and what migrating does to search visibility is covered on its own page.