Website speed test: Lighthouse on mobile, with the fixes

Lighthouse runs on a mobile profile with a throttled connection, the same way the PageSpeed Insights report does, so the score matches what Search Console shows. Performance, accessibility, best practices and SEO, each out of 100.

Largest paint, layout shift and interaction delay are the three signals Google ranks on. Lab values from the run, and real-user values from the Chrome report where the page has enough traffic to have them.

Every audit comes with an estimated saving in seconds or kilobytes. The list is sorted by that saving, so the first fix is the one that moves the number most, not the one that is easiest to list.

Preload tags, cache headers, image sizes, the CSS to split: written for your page, not as a general tip. Where we host the site they apply with one click.

Paste the page that converts, not the home page. The product pages and the checkout are where speed costs money.

Speed drifts with every deploy. The agent re-measures the target pages every night and tells you when a number moves.

Most tests default to desktop. Most visits are on phones on mobile data. The checker measures on a mobile profile only.

A clean lab run can pass while real users on old phones fail. Where Google has field data for the page, it is shown beside the lab run.

Speed matters most on the pages people buy or sign up on. Test those; the home page is usually the fastest.

A list of audits is a list of problems. Each one here carries the edit, so the next step is to apply it, not to search for how.

Add a preload link for it in the head, and serve the display size. Usually a one-second gain on largest paint.

Preload the font file and set font-display to swap so text shows in a fallback first.

Defer every script the first screen does not need. Analytics and chat widgets go last.

Width and height on every image so the page does not jump as they load. The usual cause of layout shift.

Fonts, images and stylesheets fetched on every visit. One header line gives them a year.

Maps, videos and social widgets load their whole app. Lazy-load them, or replace with an image that loads the embed on tap.

Booking and contact pages on phones, often on mobile data. Speed here is the difference between a call and a bounce.

Pricing and sign-up pages. A second of delay on the page where people decide costs more than anywhere else.

Product pages full of images. Right-sized WebP and lazy loading below the fold are the usual two fixes.

They carry most of the saving. Where we host, one click; elsewhere copy the edit.

Run the page once more after the fixes land, not before. A real deploy changes the number; a guess does not.

The agent re-measures target pages nightly and reports moves in the morning digest, so a slow deploy is caught the next day.

Google's open-source audit engine, the same one behind PageSpeed Insights and Chrome's developer tools. It loads the page on a simulated phone and scores what it finds against fixed thresholds.

Numbers from one controlled run on a throttled connection. Repeatable, comparable between pages, and not the same as what any one visitor sees.

Numbers from real Chrome users over the last 28 days, where the page has enough visits for Google to publish them. This is what rankings use.

The moment the biggest visible element has rendered. Usually a hero image or a heading. Under 2.5 seconds passes.

How long the main thread was busy with scripts during load, so taps did nothing. Under 200 milliseconds passes.

An audit with an estimated saving attached. The list is sorted by saving; the top one is the one to do first.

The last ten points cost more than the first fifty and change nothing a visitor feels. Pass the three vitals, then stop.

It is usually the lightest page. Test the pages where people decide: pricing, product, checkout.

Each optimisation plugin loads its own script. Remove weight before adding tools that promise to hide it.

A product page on a five-page site. Score 58 on mobile. Largest paint 4.1 seconds, blocking time 410 milliseconds, layout shift 0.14. The hero image was a 1.8 MB PNG served at full size to a phone. Three tracking scripts loaded in the head before anything rendered. A web font arrived late and swapped in, which moved the heading.

The image was resized to the width it displays at, converted to WebP, and preloaded: 1.8 MB became 94 KB. The three scripts were moved to load after the page was interactive. The font was preloaded and told to swap without a reflow. Each change was one line, written by the checker, pasted by the owner. Nothing was rebuilt.

Measured again the same afternoon: score 91, largest paint 1.7 seconds, blocking time 90 milliseconds, layout shift 0.02. The field data caught up over the next four weeks as real visits accumulated. Rankings for the page moved from the second page to position six over the same period, with the links work running beside it.

About an hour, once. The slowest item on most sites is one oversized image on one important page, and the test names it. Pass the three vitals, then move on to the work that compounds: the pages you are missing and the links you have not asked for yet.