Speed rarely breaks in one go. A new tracking script here, an uncompressed hero image there, a plugin update that loads three more files. Each change costs a few hundred milliseconds, nobody notices, and six months later the mobile score has halved. Visitors on phones leave before the page has finished loading, and the shop loses sales without a single outage.
Page speed monitoring measures the same pages the same way every day, so you see the day a change made things worse, not months later.
What is measured
Once a day, Google PageSpeed Insights runs Lighthouse on the start page and up to 4 more pages you choose, twice: as a mid-range phone on slow 4G and as a desktop. You get:
- The performance score, from 0 to 100, as Lighthouse calculates it. 90 and above is good, under 50 is poor.
- Lab metrics from that run: Largest Contentful Paint, First Contentful Paint, Total Blocking Time, Cumulative Layout Shift, Speed Index and time to first byte. Measured the same way every day, so they are comparable from day to day.
- Real visitors: what Chrome users actually experienced over 28 days, from Google’s Chrome UX Report, including Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. These are the Core Web Vitals Google uses in search, shown once a page or site has enough visits.
- What to fix first: Lighthouse’s suggestions, with the biggest gain first.
An alert when a page gets slower
Choose a score of 90, 75, 50 or 30, and you get an alert when a page’s mobile score falls below it. Mobile is where speed hurts most, and where the score moves first. The alert goes to the same channels as your outage alerts: email, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhooks and push notifications.
A typical case
On Tuesday, the marketing team adds a chat widget to northwind.shop. On Wednesday morning, the daily run shows that the product page’s mobile score has dropped from 84 to 71, below the 75 the team chose, with Largest Contentful Paint up from 2.2 s to 3.1 s. The alert reaches the web team’s Slack channel, and “What to fix first” points at the new script. The widget is loaded later, and Thursday’s run is back above 80.
Which pages to measure
The start page is measured by default. Add the pages that earn money or bring in visitors: a popular product page, a category page, the cart, a landing page from your ads. Pages that share a template usually share their speed, so one product page tells you a lot about the rest. Our tips for a faster-loading website cover the usual fixes.
Part of site health
Page speed is measured by the same daily site health scan that finds broken links and mixed content, so one monitor covers both. For response times every minute, from the server’s side, use uptime monitoring: it splits every check into DNS, connect, TLS, server and download, and shows percentiles.
Lab data and real visitors
Lab data tells you what changed and why: the same device, the same network, every day. Real-visitor data tells you what people actually experienced, on the devices and networks you did not test. Use the lab numbers to catch a regression the day after it ships, and the real-visitor numbers to see whether a fix made a difference over the following weeks.
Each site health monitor counts as one uptime monitor: 15 on Start, 100 on Professional and 250 on Business. Look at page speed for a made-up shop in the live demo.
Plans start at €9 per month billed yearly or €12 billed monthly, excl. VAT. See the pricing page, or start a 14-day free trial without a card.