Performance verification after a fix: a comparison for small businesses

What should you check before signing off a performance fix?

A setting being enabled is not proof that a fix worked. Performance verification means checking whether the intended change reached the page and whether it improved the problem you meant to solve.

ScanMySEO recommends three separate checks:

• Implementation: is the page actually receiving the new image, code or caching behaviour?
• Performance: does the relevant measure improve repeatedly under comparable conditions?
• Function: can visitors still navigate, send an enquiry, book or buy?

For a small WordPress site, start with the affected page and its most important customer task. Expand the checks to other pages using the same changed template or plugin setting.

Compare the methods: which evidence do you need?

Lab tests run a page under controlled conditions. Field data comes from real visits. Use the former to investigate a change now and the latter to follow its effect on visitors. Neither replaces checking that the website still works.

The PageSpeed Insights documentation explains the two data types. The Chrome DevTools Performance panel provides local measurements and recordings; Search Console’s Core Web Vitals report explains URL grouping and follow-up tracking.

Choose a success measure—not a ranking promise

Choose the measure that matches the original problem. The three Core Web Vitals describe different parts of the experience:

• Largest Contentful Paint (LCP): when the largest visible image or text block appears. Use it to investigate delayed main content.
• Interaction to Next Paint (INP): how promptly a page responds visually to clicks, taps and keyboard input.
• Cumulative Layout Shift (CLS): unexpected movement of page content. It is a score, not a time in seconds.

Google’s Core Web Vitals definitions and thresholds set “good” at LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less, evaluated at the 75th percentile: at least 75% of measured visits meet the relevant target. Assess mobile and desktop separately. These are field assessment thresholds, not a required improvement size for each fix.

A useful improvement can still leave a page outside those thresholds. Equally, a higher overall Lighthouse score does not prove that the specific problem is fixed. Google’s page experience guidance confirms that Core Web Vitals are used in ranking, but good scores do not guarantee top rankings. Do not use a change in bounce rate or rankings as proof that a technical fix worked.

Make the before-and-after comparison fair

Save the original reports before changing settings. Without a comparable baseline, you can verify today’s implementation and behaviour, but cannot substantiate a before-and-after speed gain. Record a baseline now; do not restore a known harmful configuration on the live site just to obtain one.

1. Record the change and scope. Note the URL, affected template, setting or code change, deployment time and intended result. Keep unrelated changes separate where practical.
2. Match the test conditions. Use the same tool, device profile, network settings and URL, including query parameters. Match login and cookie-consent state. Compare mobile with mobile, not a mobile “before” with a desktop “after”.
3. Confirm the changed version is being served. Ask the developer to check the actual response or asset, rather than relying on the plugin dashboard. Follow the host or plugin’s cache-purge procedure where needed.
4. Repeat, then compare the spread. ScanMySEO suggests five runs per version as a starting check. Compare the median—the middle result—and the range, not the best run. Five is a practical starting point, not a Google rule or statistical proof. Closely overlapping results may be inconclusive.

Chrome’s explanation of Lighthouse score variability identifies changing network conditions, devices, extensions and page content as sources of variation. A single improved run is weak evidence. Keep saved reports and test settings together so another person can reproduce the comparison.

Match the verification check to the fix

Caching: confirm what was cached

In Chrome DevTools, open Network, reload the page, select its main document request and inspect Timing. Compare the “Waiting (TTFB)” value using the same method before and after. Time to First Byte includes network delay as well as the server’s work; it is not a pure hosting-speed measure or a Core Web Vital.

Ask your developer to confirm a cache hit—serving a stored response—using the host’s documented headers or diagnostics. Compare an initial request after a purge with subsequent requests, recording which is which. Do not repeatedly purge the site cache and then describe those results as normal cached performance.

Browser cache and website cache are different. DevTools’ “Disable cache” disables browser caching; it does not empty your WordPress or content delivery network (CDN) cache. Keep browser-cache settings consistent and record the separate server/CDN state. See Chrome’s Network panel reference and MDN’s guide to browser and shared caches. Then check whether the main content appears sooner, not just whether TTFB fell.

Images: check the important image, not just fewer downloads

Identify the actual LCP element in the Performance panel. Do not assume it is the same image at every screen size. Check when its request starts, when it finishes and when the image appears. Google’s LCP optimisation guide explains why an LCP image should not be lazy-loaded: deferring it can delay the content visitors need first.

Hypothetical example: a WordPress setting applies lazy loading to both a gallery and the main image. The initial download total falls, but the main image starts loading later. That is not a successful fix for delayed main content. Exclude the LCP image from that setting, repeat the matched tests, and scroll through the gallery to check it still loads. For off-screen images, reduced initial transfer and reliable loading during scrolling may be the intended benefit; an LCP improvement is not the only valid outcome.

JavaScript: test the interaction that used to feel slow

Record the same task in the Performance panel before and after: opening the menu, choosing a product option or submitting an enquiry. Check both responsiveness and the outcome. A script that has stopped running might lower the test’s workload while also breaking the feature.

Lighthouse’s Total Blocking Time (TBT) measures blocking work during the measured period and can help diagnose responsiveness. However, TBT is not a substitute for INP. A better page-load result does not establish that a later interaction is faster. Test that interaction and follow real-user INP where data is available.

CSS and layout: watch beyond the first screen

After changing styles, fonts or reserved image space, inspect the affected layouts at relevant screen sizes. Reload, scroll and wait for embeds or other delayed content. Confirm the page still looks and works correctly, and use the Performance panel to inspect unexpected movement. A smaller stylesheet alone is not proof of a better experience.

Google’s guidance on post-load layout shifts explains why a clean initial-load test can miss movement later in a visit. Check the circumstances that triggered the original problem, not just the first few seconds after loading.

Check the live release and the customer task

Use staging to catch breakage before deployment, but repeat the relevant checks on the live site: hosting, caches and third-party services may differ. If the change is already live, begin with a functional check rather than waiting for more speed data.

For a WordPress business site, test as a logged-out visitor and in any relevant account or consent states. Open the mobile menu, follow the main call to action, test form errors and confirm a successful enquiry reaches its destination. Where payments are involved, use your agreed safe test procedure.

For a shop, WooCommerce’s caching guidance says Cart, Checkout and My Account need exclusion from page caching because they contain customer-specific information. Verify those exclusions and the purchase journey, rather than treating a faster cached homepage as evidence that the whole shop is safe.

If analytics or consent scripts were changed, also check that expected measurement still works. Otherwise a tracking change could be mistaken for a business result. A speed gain does not justify a broken booking, enquiry or purchase flow.

When should real-user data confirm the change?

PageSpeed Insights uses the Chrome User Experience Report (CrUX) for real-user measurements over a rolling 28-day period. Immediately after deployment, that window mostly describes the old version. Review the displayed collection dates: a wholly post-deployment window takes about four weeks to accumulate, and an improvement is not guaranteed to appear on a particular day.

Check whether the result is for This URL or the Origin, the broader website-level collection rather than that one page. PageSpeed may fall back to origin data when the page has too little data. That broader result cannot establish that this one page improved. No data means insufficient evidence, not a pass or failure. The PageSpeed Insights documentation explains these collection and fallback rules.

Search Console’s Core Web Vitals report describes fix tracking that monitors an issue over 28 days; it does not trigger a new live speed test or re-indexing. Check other affected URLs before starting tracking for an issue, rather than fixing only its example page.

When more detail is needed, ask a developer about measuring Web Vitals from your own visitors, also called real-user monitoring (RUM). Compare affected pages and similar device groups, keeping the release date and other changes visible. Small samples remain uncertain even with your own monitoring. For a low-traffic site, “verified in matched lab tests; field evidence pending” is an honest interim conclusion.

Decide: keep, retest, refine or roll back

Use this ScanMySEO decision framework after checking implementation, performance and functionality:

• Keep provisionally: the intended change is present, repeated matched tests support the intended benefit and customer tasks pass. Record the evidence and arrange the real-user follow-up.
• Retest: conditions differ, old assets are still served or the results overlap too much to distinguish a gain. An unchanged historical report alone is not a reason to undo the fix.
• Refine: one part improves but the original problem remains—for example, a faster document response but unchanged LCP. Investigate the remaining delay without automatically discarding a useful change.
• Roll back or disable the affected optimisation: it introduces a material, reproducible slowdown, broken layout or failed customer task. Restore the last known safe configuration with the responsible developer, then verify the recovery.

If careful comparisons still show no benefit, reconsider whether the extra configuration is worth maintaining. For an unresolved technical bottleneck, continue with our advanced Core Web Vitals troubleshooting guide.

Keep a short sign-off record: the change and deployment time; affected URLs; test settings; before-and-after results; customer-task checks; known limitations; decision; and follow-up owner. The developer confirms what changed, while the business owner confirms that the customer task still works. In a small team, one person may cover both roles.