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.

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.

Step 2: record field and lab baselines

• ✓
  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.
• ✓
  Serve an appropriately sized, compressed asset 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.

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.

Step 6: stabilize layout

• ✓
  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.

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

• ✓
  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.

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.

Primary sources

• Chrome: Lighthouse performance scoring
• Chrome: Lighthouse performance audits
• Google Search Central: Core Web Vitals
• PageSpeed Insights documentation
• web.dev: optimize LCP
• web.dev: optimize INP
• web.dev: optimize CLS