How the speed test works
We load your page in headless Chrome and run Google Lighthouse twice: once with mobile settings (a mid-range phone on a throttled network) and once with desktop settings. Lighthouse records when content first appears, when the largest element finishes rendering, how long the main thread is blocked and how much the layout moves, and turns this into a performance score from 0 to 100.
Because the mobile run is deliberately throttled, its score is usually lower than desktop. That is expected: it reflects what a client sees on a phone in a train, which is where many first visits to a firm's website happen.
The metrics, in plain English
Core Web Vitals measured from real Chrome users are part of Google's page experience signals. Lighthouse is a lab test, so your field data may differ, but the causes it finds are the same ones that slow real visitors down.
- Largest Contentful Paint (LCP): when the main content — usually the hero image or headline — is visible. Google considers 2.5 seconds or less good.
- Cumulative Layout Shift (CLS): how much the page jumps around while loading. 0.1 or less is good.
- Total Blocking Time (TBT): how long scripts block the page from reacting to taps and clicks. It is the lab stand-in for Interaction to Next Paint.
- First Contentful Paint and Speed Index: how quickly something, and then most of the page, appears.
- Page weight and request count: how many bytes and files the browser had to download.
Common causes on professional-services sites
Heavy page-builder themes, large uncompressed hero photos, sliders, several web fonts, chat widgets and tracking scripts loaded on every page are the usual suspects. The report lists Lighthouse's opportunities with their estimated savings, so you can start with the change that saves the most time rather than guessing.
Typical fixes are serving images in WebP or AVIF at the size they are displayed, lazy-loading images below the fold, self-hosting fonts, removing unused plugins and scripts, and enabling caching and compression on the server.
Reading the filmstrip and screenshot
The filmstrip shows frames captured during the mobile load. A long run of blank frames points to a slow server response or render-blocking CSS and JavaScript; a page that appears quickly but then shifts points to images or banners without reserved space. Compare it with the final screenshot to check that what loads last is not the thing your visitors came for.