Launch day is the fastest most websites will ever be. The content is lean, the images are the ones the designers chose, the code is fresh, and everyone has just spent weeks paying attention to speed. Then real life begins. Content grows, features get added, a marketing tool gets embedded, and eighteen months later someone notices the site feels heavier than it used to, without being able to point at any single thing that changed.
Nothing went wrong in that story. That is simply what happens to a living website, in the same way a garden does not stay weeded because it was weeded thoroughly once. The sites that stay fast are not the ones with the most heroic launch optimization. They are the ones where someone keeps paying attention afterwards. So we treat performance as a habit, a recurring practice woven into how a site is looked after, rather than a project with an end date. Here is what that habit actually consists of, month to month.
Why speed drifts, even when nobody makes a mistake
It helps to understand the drift, because it is nobody's fault and it is completely predictable. Content accumulates: more pages, more menu items, more images uploaded by more people, not all of them sized the way the original art direction assumed. Features accumulate: each new module or integration is individually reasonable and collectively heavier. Third-party scripts accumulate fastest of all, because they arrive from outside the development process; an analytics snippet here, a chat widget there, each pasted in for a good reason and each loading its own code from its own servers on every page view.
Every one of these is a small, defensible decision. Speed is lost in grams, not in kilograms, which is exactly why no one notices at the time and why a launch-day optimization effort cannot be the whole answer. The question that matters is not how fast was the site when it launched but who is watching it now.
Continuous scans, so drift has nowhere to hide
Our answer to that question starts with automation. The sites we look after get scanned for performance on an ongoing schedule, using the same kind of measurements the search engines care about: how quickly a page becomes visible, how soon it responds to input, how stable the layout is while loading. The scans run whether or not anyone is worried, which is the point. Drift does not announce itself, so something has to be listening for it.
What the scans give us is a trendline instead of a snapshot. A single measurement tells you almost nothing; pages have fast days and slow days. A history tells you the truth: this template has been getting gradually heavier for three months, or that page got suddenly slower the week a new embed went in. With a trendline, performance conversations stop being vague impressions and start being specific questions with findable answers. And because the scans watch the site continuously, we usually get to have those conversations while the change is small, which is when fixes are cheap.
A look at every release
The second part of the habit is attached to change itself. Every release that goes out to a site we maintain gets a look at its performance footprint, in the same spirit that its functionality gets a look. Does the new feature pull in scripts or styles that load everywhere but are needed on one page? Do the new images have proper sizes and modern formats? Does the new listing page hold up when the content behind it is plentiful, not just with the handful of test items it was built against?
Catching these at release time costs minutes. Catching them a year later, tangled together with everything else that shipped in between, costs an investigation. This is the quiet economy of the habit: it front-loads small attention to avoid large archaeology. It also keeps a useful culture alive on the team, because when every release gets this look, speed stays part of what done means, instead of becoming a special effort someone has to argue for.
Caching is maintained, not installed
Caching deserves its own section, because it is the layer people most often treat as fire-and-forget. A well-set-up Drupal site has several layers of it: pages served whole to anonymous visitors, fragments reused across pages, queries and computations remembered instead of repeated. Done well, this is invisible and enormously effective, and modern Drupal is genuinely good at it.
But a cache is a set of assumptions about what can be reused and for how long, and the site those assumptions were made about keeps changing. New content types, new blocks, new logged-in functionality: each can quietly change what is cacheable. The failure modes point in both directions, too. Cache too little and the site slows down; cache too much and someone sees stale content, which tends to get fixed in a hurry by caching even less. So we revisit the caching layers as the site evolves, checking that pages which should be served from cache actually are, and that the fast path visitors experience is the path we think they are on. A cache that is checked stays an asset. A cache that is merely trusted becomes a rumor.
Content habits, because editors shape speed too
Not all of performance lives in code. A meaningful share of it is decided in the admin, by the people publishing content, which is why the habit extends to them. The site itself should do the heavy lifting: images uploaded at any size get resized and compressed automatically, and embeds should be built to load politely. But we also make sure editorial teams know the few things that genuinely matter, like what happens when a page accumulates a dozen heavy embeds, and we would rather build guardrails than distribute rules. When the fast way is also the easy way, editors keep the site quick without ever thinking about it, which is how it should be.
What month to month actually looks like
Put together, the habit is unglamorous, which is its virtue. Scans run on their schedule and their trendlines get read by someone who knows the site. Releases go out with their footprint checked. Caching gets revisited when the site changes shape. Third-party scripts get reviewed occasionally, because the fastest code is the code you remove, and embeds have a way of outliving the campaigns that justified them. None of these steps is dramatic, and no single month looks impressive. The result only shows over years: a site that feels in its third winter the way it felt in its first week.
If your own site has picked up that heavy feeling, the encouraging news is that drift runs in reverse just as well. The same practice that keeps a fast site fast will walk a slowed-down site back, usually in ordinary maintenance-sized steps rather than a rebuild. We are happy to take a look, tell you plainly where the weight crept in, and set up the habit that keeps it from creeping back. The first conversation is on us, always has been, always will be.