Speed Tests You Can Actually Compare

Do not test only the homepage. Select a small set that represents the real site: the homepage, the main conversion page, and one page from each heavy template.

For https://www.n-g.be, that could mean the homepage, one guide, and the tools page. A site with a map, configurator, or editor should include the page where that feature actually runs.

Write the URL list before the first audit and keep it stable during one optimisation round. Otherwise, a better result may only mean that you tested an easier page.

Start with mobile PageSpeed Insights and a mobile Lighthouse run. Mobile constraints expose large images, startup JavaScript, and rendering work quickly. Add desktop after the mobile baseline, especially when your own analytics shows a desktop-heavy audience.

For local comparisons, keep the browser, machine, device setting, audit mode, and storage choice consistent. Chrome warns that machine load, extensions, and stored settings can influence Lighthouse, so reports from different machines are not directly comparable.

When a small movement will decide whether work is accepted, run the audit more than once. Look for a repeatable change that also makes sense in the underlying metrics.

PageSpeed Insights can show two views. Field data comes from the Chrome UX Report and summarises real Chrome-user experience over the previous 28 days when enough data exists. It does not reset immediately after today's deployment.

The Lighthouse section is a controlled lab test. Use field data to understand the audience over time and the lab test to diagnose and compare a focused change now. Lighthouse cannot measure INP, because there is no real visitor to interact with the page; it reports Total Blocking Time as the lab proxy.

The current Core Web Vitals are Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. Google's good thresholds are 2.5 s, 200 ms, and 0.1 at the 75th percentile.

Do not flatten these signals into one unexplained score. Loading, responsiveness, and visual stability can move in different directions.

One more limit is worth knowing before you celebrate a jump: a lab test never scrolls, taps, or clicks. If a change delays scripts until the visitor's first interaction, the lab result improves more than the visit does. Check afterwards that analytics still records the same sessions and sources it did before.

After every run, save the complete Lighthouse report. Chrome supports saving the report as JSON, which can be reopened in the Lighthouse Viewer. A screenshot may help a quick review, but it should not be the only record.

Use a predictable path such as performance/2026-09-17/home/mobile/baseline.lighthouse.report.json.

Place a short record beside it with the date, URL, environment, composite score, key metrics, planned change, and decision. For PageSpeed Insights, state whether a value came from field data or the Lighthouse lab section.

The archive should answer three questions without relying on memory: what did we test, what changed, and did we keep it?

Images are often a practical first target. Use SVG for suitable logos and line art. For raster images, compare WebP or AVIF with the current file, resize to the displayed dimensions, and inspect the final result at its real display size.

The Built by meN-G.BE PNG to WebP Converter processes PNG, JPG, JPEG, and WebP files locally in the browser. It lets you choose compression settings, compare savings, and download files individually or as a ZIP.

A smaller file is not automatically better. Reject the conversion when text becomes soft, edges break, or the product image loses useful detail.

A heavy interactive map, visualiser, or editor may not belong in the initial bundle of the homepage. If the feature is secondary, move it to a dedicated page or load it only when the visitor needs it.

This follows the same principle as code splitting: send less JavaScript at startup so the browser has less work before it can respond. Third-party tags, chat widgets, and analytics belong in the same review, because they cost startup time you did not write.

Retest navigation and the main mobile flow after the move. A faster homepage is not a win when an important feature becomes difficult to find.

Do not ban animation by default. Remove an animation that adds little value, rerun the test, and keep the change only when it improves performance without weakening the interface.

For animations that remain, prefer transform and opacity when they create the same effect. Google's animation performance guide explains why properties that trigger layout or paint need closer inspection.

Add, measure, simplify, and measure again. Keep the useful motion and drop the cost that the visitor never needed.

Do not compress every image, remove three animations, and split a large component before the next audit. The score may rise, but the team will not know which change caused it.

Make one focused change. Run the same URL with the same settings. Save the new report beside the baseline and record the code version or pull request.

Keep the change when the gain repeats and the user experience still works. Reverse it when the gain disappears, the page looks worse, or the main flow becomes harder. A rejected experiment remains useful when its evidence stays in the archive.

The numbers above come from one homepage I built and maintain, magicbetting.be. It was measured against twelve comparable Belgian sites in the same category on 19 September 2026, then rebuilt, then measured again on 23 September under identical conditions: one machine, one session, a fresh browser profile, median of five runs per device.

The first reports named the cost precisely. The tag manager and the analytics tag together blocked the main thread for 790 ms on mobile. The chat widget arrived late and pushed the layout, which is where the 0.103 desktop layout shift came from. The rest was startup work in the page's own components: scroll-reveal observers, a clock that re-rendered its parent every second, and interactive wrappers around content that never needed them.

Three changes followed, one per commit: load the tag manager after the page instead of during it, replace the chat widget with a fixed launcher that loads the real widget on click, and move interactive wrappers back to server-rendered markup. Desktop reached 100. Mobile gained eleven points and still has further to go, which the reports say plainly rather than hiding.

The evidence pack is the deliverable, not the score. Dated JSON reports for every run, the same twelve competitors measured on both dates, and a written verdict per metric. That is what makes a second round comparable, and what lets anyone check the claim.

The performance score is not the launch decision. Reopen the page at common mobile widths and check text wrapping, navigation, tap targets, image crops, sticky elements, forms, and the main conversion path.

Run the remaining Lighthouse categories for accessibility, best practices, and SEO. Then check broken links, console errors, failed requests, metadata, canonical rules, consent behaviour, and important redirects.

Finish with a short evidence pack: stable URL list, baseline reports, after reports, change log, accepted fixes, rejected tests, and the next priority.