The site was fast in March. Someone spent a week on images and caching, the test results looked good, everybody moved on. By September an enquiry form takes a moment to appear, the home page feels heavy on a phone, and nobody can say when it started. Was it the plugin update in June? The new review widget? The banner the marketing team added for a sale and never removed?
That is what happens without a habit of checking. Speed is not something you fix once; it drifts as the site changes. To monitor website speed over time you need a few fixed pages, a few fixed measurements, a regular schedule and a record you can look back at. None of it has to be expensive or complicated. This post covers what to watch, where to get the numbers, and what to do when they move.
Why one test is not enough
A single speed test is a snapshot of one page load, under one set of conditions, at one moment. It varies from run to run, and it says nothing about yesterday or next month. Even a careful round of tests before and after a fix only proves the fix worked on that day.
Sites slow down gradually for ordinary reasons. Plugins update and add features. New pages get built with heavier blocks. Staff upload photos straight from their phones. A tracking script gets added for one campaign and stays for years. A host moves your account to a busier server. Each step is small; together they undo the original work. Regular measurement is how you catch the step that matters before the next ten pile on top.
If you have not yet settled on a reliable way to run individual tests, our guide on testing a website’s speed properly sets out the method, and everything below assumes you test that way.
What to track, and what to leave out
The temptation is to track everything. Resist it. A short list you actually look at beats a dashboard nobody opens.
A fixed set of pages
Choose four to six URLs and keep them for good: the home page, your busiest landing page, one example of each main template (a service page, a blog post, a product or category page), and the contact or checkout page. If a template changes, the example page will show it.
A handful of measurements
- Core Web Vitals from real users (LCP, INP and CLS), where your site has enough traffic for Google to report them. These are the figures that reflect actual visitors.
- Lab LCP, Total Blocking Time and CLS from a consistent lab test, median of several runs, mobile setting.
- Server response time for the HTML, which tells you early if hosting or caching has changed.
- Page weight and number of requests, which creep up quietly when content and scripts are added.
Keep the overall score in your sheet if you like, but do not let it be the only figure. It hides which part moved.
Where the numbers come from
Search Console: the free long-term trend
If your site is in Google Search Console, its Core Web Vitals report shows how groups of your pages perform for real Chrome users, on mobile and on desktop, as a chart over time. It is the easiest long-term view available, because Google collects the data for you. Its limits: it needs enough traffic, it groups similar URLs together, and it reacts slowly because the data covers a rolling window of recent weeks. Our post on the Search Console Core Web Vitals report explains how to read it, including the “not enough data” message.
PageSpeed Insights: field data per page
The top section of a PageSpeed Insights report shows the same real-user data for an individual URL or your whole domain, covering the previous 28 days. Checking it monthly for your fixed pages, and writing down the figures, gives you a page-by-page trend that Search Console’s groups do not.
Scheduled lab tests
Lab tests catch changes immediately, before they show up in real-user data. You can run them by hand on a schedule (simple, and fine for most small sites), or let a tool do it. Some testing services, GTmetrix among them, offer scheduled tests with alerts when results get worse; what is available depends on the service, so check its current details. Developers can also automate Lighthouse runs, either with the PageSpeed Insights API or with Lighthouse CI, and store the results.
Real-user monitoring on your own site
The most detailed option is collecting speed measurements from your own visitors. Google publishes a small open-source JavaScript library called web-vitals that measures Core Web Vitals in visitors’ browsers; the results can be sent to your analytics or a monitoring service. Several commercial monitoring tools do this as a feature. It is more set-up work and adds a small script of its own, so for most small business sites, Search Console plus scheduled lab tests is enough.
A monthly routine to monitor website speed over time
This takes under an hour once you are used to it:
- Open the Search Console Core Web Vitals report. Note the number of good, needs-improvement and poor URLs on mobile and desktop, and whether anything has changed since last month.
- For each of your fixed pages, open PageSpeed Insights. Note the field data verdict if shown.
- Run the lab test on each page several times on the mobile setting. Note the median LCP, Total Blocking Time, CLS and the score.
- Note page weight and request count from whichever tool you use, the same tool each month.
- In the notes column, write anything that changed on the site since last month: updates, new plugins, new pages, campaigns, host changes.
- Compare with last month and the month before. Look for a direction, not a single bad reading.
A shared spreadsheet is enough. The point is that the same person, or the same process, does the same thing each time.
Checks after updates and other events
Monthly checks catch slow drift. Some changes deserve an immediate check as well, because they are the usual cause of sudden slowdowns:
- A WordPress core, theme or major plugin update.
- Installing any new plugin, widget, tracking tag or embed.
- A redesign of a page template, or a new landing page built for ads.
- A hosting change, PHP version change, or new CDN or caching settings.
- The start of a busy period, such as a festival sale or a seasonal campaign.
After each, run your lab test on two or three key pages and compare with the last recorded figures. If something got noticeably worse, you know exactly what to suspect, and you can roll back or adjust while the change is fresh.
When a number moves
A single bad month is not an emergency. Lab results vary, and real-user data can shift with your audience: a campaign that brings more visitors on slow phones can lower your field figures without the site changing. Before acting, check whether the change shows up on more than one page, in more than one measurement, and in your next round of tests.
If it does, use your notes. Line up the date the numbers moved with what changed on the site around then. Then look at which measurement moved, because each points somewhere different:
- Server response up: hosting, caching or something running on the server.
- Page weight or requests up: new content, images, plugins or scripts.
- Blocking time up: a new or updated script, often a third party.
- Layout shift up: a new banner, embed, ad slot or font change.
That narrows a vague “the site got slower” into a specific thing to test and fix. The habits that stop the drift in the first place (upload rules for images, vetting plugins before installing, after-update checks) are covered in our post on keeping a website fast after optimisation.
Speed monitoring is not uptime monitoring
They are easily confused. Uptime monitoring checks, every few minutes, whether your site responds at all, and alerts you when it is down. Speed monitoring checks, less often and in more depth, how well the pages load when the site is up. A site can be up all month and still have slowed down badly. You want both, but they are different tools answering different questions; we cover the first in what to watch with uptime monitoring.
The ideas behind all these measurements, and how the fixes connect, are gathered in our page speed guide, which is the best place to go if a number moves and you want to understand why.
Frequently asked questions
How often should I check my website’s speed?
For most small business sites, a full round of checks once a month is enough, plus a quick test of key pages after any update, new plugin or design change. Busy stores or sites running paid ads may want weekly lab checks during campaigns. What matters most is checking the same pages the same way each time.
Why has my Search Console report not changed after I fixed the site?
The real-user data behind the report covers a rolling window of recent weeks, so improvements appear gradually as older, slower visits drop out of the window. It also needs enough visits to each group of pages. Keep checking lab tests for immediate confirmation, and expect the field data to follow over the next few weeks.
Do I need a paid monitoring tool?
Not necessarily. Search Console, PageSpeed Insights and a monthly spreadsheet cover most small business needs at no cost. Paid tools add automatic scheduled tests, alerts and real-user data from your own visitors, which become worth considering for larger stores, sites with many templates, or teams that change the site often.
Which pages should I monitor if my site has hundreds of them?
Monitor one representative page for each template rather than every page, because pages built on the same template usually behave alike. Add your highest-traffic landing pages and the pages that bring in money, such as product, cart, checkout or contact. Search Console’s grouped report then covers the rest of the site broadly.
Checking speed every month is easy to plan and easy to forget. If you would rather it were part of regular care, our WordPress monthly maintenance plans include a monthly performance and speed check alongside updates, backups and a monthly report of the work done.
Next in this series: What Is Page Size? Page Weight Explained Simply
