The site check: speed, mobile, SEO and security in a real browser

The site check opens your website the way most visitors do: in a real browser, on a mid-range phone, over a 4G connection. It loads your homepage and two more pages, records how long each part took and what the browser had to download, and turns that into a list of problems. Every problem says what is wrong, what is causing it, and how to fix it.

Where

• Web: open a domain and choose the Site check tab. Run a site check starts one; it takes two to four minutes. The Monitoring page's Page performance panel shows every domain's latest speed score and links to this tab.
• iOS: a domain's Site check module; the "site got slower" push opens it.
• API/MCP: POST /api/domains/:id/site-check, GET /api/domains/:id/site-checks, GET /api/site-checks/:id; tools run_site_check, list_site_checks, get_site_check.

The phone we use

The phone profile Lighthouse and PageSpeed Insights use for their mobile test: a Moto G Power sized screen (412 px wide), a processor slowed to match the server it runs on (about one and a half times on a typical one), and "slow 4G" (about 1.6 Mbps with a long round trip). Each load is a fresh browser with nothing cached and no cookies, like a first-time visitor.

One load is noisy, so the homepage is loaded three times (plus a first pass that reads code use and accessibility) and the middle run is the one reported, the way Lighthouse picks its median run. The other two pages are loaded once. The speed score is the homepage's.

How this differs from PageSpeed Insights. PageSpeed Insights loads the page unthrottled and then calculates what a slow phone would have seen. A Worker cannot do that calculation, so we slow a real load down instead (Lighthouse's "applied" throttling: 562.5 ms of latency per request, 1.47 Mbps down, 0.68 Mbps up). The metrics and the scoring are Lighthouse's own, but the numbers are not the same, so use the score for trends and for the specific findings, not to match PageSpeed Insights to the point.

How the processor is slowed. Lighthouse slows the CPU four times, assuming a fast desktop. Our test browser is a shared server that runs script-heavy pages several times slower than a laptop before any slowing, so four times made WordPress and gallery sites score far below PageSpeed Insights. On 2026-09-28 we loaded 17 sites (our own and well-known WordPress, Shopify, Wix and Squarespace sites) three times each at slowdowns of 1x, 1.5x, 2x, 3x and 4x and compared them with Lighthouse 13.5 run PageSpeed-style, three runs per site, median. Averaged over the 17 sites, the score was off by 16.2 points at 4x and 11.1 at 1.5x; Total Blocking Time was off by a factor of 3.9 at 4x and 1.3 at 1.5x. The speed of the test server also swings by about two times from one minute to the next, so each load first runs Lighthouse's own CPU benchmark on a blank page and scales the slowdown to it: 1.5x on a typical server, more on a faster one, less on a slower one, never under 1x or over 4x. Read right before a load, that benchmark tracks how long the page's scripts take to run (correlation -0.73 within a site). Read once and compared across sites or at another time it does not (-0.43), which is why it is taken before every load.

What is left is mostly not the processor. PageSpeed Insights estimates paint times from a model, and for some sites (wix.com, headshotsneo.com, neweradesigns.net) its estimate of when the main content appears differs from a real slow-phone load by more than any processor setting changes. Lighthouse itself moves from run to run (petesautollc.com scored 72 and 93 under identical settings on a laptop).

The six sections

Speed is scored the way Lighthouse scores a mobile run: the same five metrics (first paint 10%, Speed Index 10%, main content 25%, blocking time 30%, layout shift 25%) on the same curves. The other sections start at 100 and lose points for each problem: 20 for one marked "Fix first", 10 for "Worth fixing", 4 for "Minor".

Reading a finding

Each finding opens to show:

• What we measured, in numbers, against Google's thresholds where there is one.
• What is causing it: the specific image, script, element or setting, with the evidence we saw (file sizes, selectors, headers).
• How to fix it, in steps, and where a fix has a measurable payoff, roughly how much faster or smaller the page gets.
• The pages it was seen on.

Findings are ordered with "Fix first" at the top and, within that, the biggest savings first.

When checks run on their own

Anyone can run a check by hand, six an hour per account; checks cost no credits. A domain with its automatic checks paused is skipped.

Alerts

When a scheduled check finds a site has got slow on phones, you get an alert in the feed and a push: the main content now takes over 4 seconds where it used to be quicker, or the speed score fell 15 points or more to under 50. The comparison is against the middle of the last three checks, so one slow run does not set it off. The first scheduled check of a slow site says so once. Turn it off with the Site speed switch in the web dashboard's Settings, Notifications.

Limits

• Up to three pages per check: the homepage, then pages from different parts of the site, taken from the sitemap or, if there is none, from the homepage's links. A one-page site (a landing page whose links are all anchors, phone and email) is checked in full and says so.
• The check follows the domain's own redirects (including to www or another host of the same domain) but will not measure a different website the domain sends visitors to. That case shows as Skipped, not as an error, and the same goes for a site that does not answer (Unreachable). Only "could not finish" means the checker itself failed.
• A very slow site is not loaded three times, and a check stops starting new page loads after seven minutes, keeping what it has.
• Alerts compare a check only with earlier checks measured this way.
• A page that does not start loading within 60 seconds is reported as not loading; a page still downloading after 30 more seconds is measured as it stands and flagged.
• Pages behind a login are not checked.