Fast at launch, slow by spring
The site passed every speed test the day it went live. A year later a customer mentions it is slow, the owner checks on their phone, and it is. Nobody redesigned anything. The developer swears it was fast. Both are right: it was, and it is not, and the gap between the two is a year of small changes that nobody measured.
Performance is not a property a site has. It is a property a site keeps, or does not.
The five ways speed drifts
1. Images. The site launched with thirty images, sized and compressed by the developer. Then the owner added a news post with six photos straight from a phone, at four megabytes each. Then a staff page. Then a gallery. Eighteen months of uploads, none of them optimised, and the home page is now carrying more weight than the whole site did at launch. This is the most common cause and the most invisible, because each upload was small and reasonable.
2. Plugins and scripts. A chat widget added in March. A review widget in June. A new analytics tool, a heat-mapping script, a pop-up plugin, a social feed. Each was a two-minute install and each is a little slow. Twelve months later there are nine of them, loading on every page, and the page takes two seconds longer to become usable than it did.
3. The database. WordPress databases grow: post revisions, spam comments, expired transients, logs from plugins that were removed but left their tables. A database that was ten megabytes is two hundred, and queries that were instant take a noticeable fraction of a second.
4. Updates that change behaviour. A theme update adds a font. A plugin update starts loading its script on every page instead of the one that needs it. A builder update changes how it outputs CSS. None announced as performance changes; each a little slower.
5. Hosting decay. Shared hosting gets more crowded. A host changes its caching layer. A CDN configuration is reset during a support ticket. The server that responded in 200 milliseconds now takes 800, and nothing on the site changed at all.
Any one of these is small. Together, over a year, they turn a fast site into a slow one, and no single moment looks like the cause.
Why a one-time test cannot catch it
A speed test is a photograph. It tells you how the site performed at one moment, on one page, from one location, under lab conditions. It is exactly the right tool for confirming a fix or comparing two versions.
It is the wrong tool for catching drift, because drift is a trend. You would need to run the test monthly, on the same pages, under the same conditions, record the results and compare them. Nobody does that by hand for long. So the test is run at launch, passes, and is never run again until someone complains.
What monitoring looks like
Real-user data, watched. Google's Core Web Vitals report in Search Console aggregates the actual experience of your visitors over 28 days. A page slipping from Good to Needs improvement shows there before any customer complains. Checked monthly, it is the trend line a single test cannot give.
Synthetic checks on a schedule. An automated test of the key pages, weekly, from a fixed location on a mobile profile, with results stored. When the home page's load time steps up by half a second in a given week, you can look at what changed that week.
Page weight and request count tracked. Two numbers, per key page, per month. Total kilobytes and number of files. When either climbs, something was added. This catches the images and the scripts before they show up in load time.
Alerts on thresholds. Not "the site is slow" but "the home page exceeded 2.5 seconds on mobile for the third week running". Something a person acts on.
A quarterly look at what loads. A list of every script and stylesheet the site loads, from where, and why. Removing the three that nobody remembers adding is often the biggest single speed win of the year.
What is done about drift
When monitoring shows a step change, the fix is usually small because the cause is recent: compress the last month's uploads, move the new widget to load on interaction, clean the database, restore the caching configuration. Ten minutes to an hour, monthly. Compare that with the alternative: a year of drift, a slow site, a customer complaint, and a half-day performance project to undo twelve months of accumulation.
Monitoring also enforces a habit on the owner's side. When the report says "the news post from the 14th added three megabytes to the home page", the next post's images get resized before upload. The site stays fast partly because someone is watching it.
Where this fits
Speed monitoring is one of the lines on our care plan reports: the real-user grades for key pages, the page weight trend, and what was done when either moved. It is the reason sites on the plan are as fast in year three as at launch, and why the phrase "it was fast when we built it" is one we try never to have to say.