How to read PageSpeed Insights and choose what to fix first

Published by SOPIDOTECH LTD · 12 October 2026 · 3 min read

A slow website can make a visitor abandon an enquiry before they have read your offer. A performance report helps you investigate the cause, but the score alone does not tell you what your business should fix first. Begin with the page customers actually use: a service page, enquiry page or product page.

Run a useful baseline test

1. Open the SOPIDOTECH PageSpeed tool and enter the full public page URL.
2. Select Mobile and run the check. Save the report before changing anything.
3. Repeat with Desktop. Keep the reports separate so you do not compare different test environments.
4. Record the page, date, device setting and the change you intend to make. Test the same URL again after deploying that change.

Read the report in the right order

Google supplies a Lighthouse lab test and, when enough data exists, real-user measurements from CrUX. They describe different experiences. Missing field data does not mean the website is broken; the page may not have enough eligible samples. Performance, Accessibility, Best Practices and SEO are separate lab categories. A high SEO score does not guarantee search rankings.

Before choosing work, ask whether the delay is visible to a customer. Does the main image arrive late? Do buttons respond slowly? Does text jump when a banner loads? Use the report to locate the relevant resource or audit, then reproduce the problem on your own phone.

Choose changes that affect the customer journey

• The hero appears slowly: check image dimensions and transfer size. Serve an appropriately sized image, avoid lazy loading the main hero, and retest.
• The page moves during loading: reserve space for images, embeds and advertisements. Compare the layout before and after resources arrive.
• The page feels busy or unresponsive: review unnecessary scripts and third-party widgets. Remove only integrations you no longer need; confirm menus and enquiry controls still work.
• Everything waits for the first response: investigate hosting, caching and server work before repeatedly compressing already small images.

A practical before-and-after workflow

Suppose the main banner is much larger than its displayed size. Export a suitable version, keep the original available for rollback, and update one page first. Repeat the mobile check and manually confirm the image remains sharp. Check the contact path as well as the score. If the image was not the bottleneck, move to the next relevant audit rather than making increasingly aggressive quality reductions.

What to do when a check fails

An upstream quota error is different from a poor performance result. Try again later or use the optional free Google API key field. A login-protected page cannot be treated as a normal public test target. Avoid sharing API keys in screenshots. If you need implementation help, bring the saved report and the affected URL to a website improvement discussion.

Reading a report: a decision example

Example: suppose a service page shows a poor mobile lab score, but its contact button appears quickly. Do not begin by deleting the contact button. Inspect the waterfall and diagnostics first: is the hero image too large, a script blocking rendering or the host slow to respond? Choose one likely cause and record its effect on the user journey.

Create a tiny comparison log: tested URL, test date, mobile or desktop setting, reported issue, file or script changed, and the second report. Keep both reports because lab scores fluctuate between runs. If CrUX data is absent, write “field data unavailable” instead of assuming the page has perfect real-user performance.

Keep learning