Performance Drupal Maintenance

Why does Drupal get slower over time?

Many Drupal sites are fast when launched, but become heavier over the years. The cause is usually not Drupal itself, but how the platform is maintained, extended and filled with content over time.

Slowness rarely comes from one change

A Drupal site does not usually become slow overnight.

It is usually a gradual process:

  • more content is added;
  • more images and files are uploaded;
  • new modules are installed;
  • small custom features are built;
  • analytics, marketing and chat scripts are added;
  • cache or server configuration falls behind;
  • old solutions remain in place next to new ones.

Each individual change may seem small. Together, they can make the site slower, harder to manage and more expensive to develop further.

Content growth has a bigger impact than expected

A large organisation's Drupal site is not a static brochure.

Over the years, it accumulates:

  • news;
  • service descriptions;
  • documents;
  • events;
  • campaign pages;
  • forms;
  • files;
  • translations;
  • archived content.

When the content model and listings are planned well, Drupal can handle large volumes. Problems appear when content grows without archiving rules, indexing logic and editorial governance.

For example, performance may suffer when:

  • a news listing queries too much data on every page load;
  • search indexes are not configured correctly;
  • an admin view shows thousands of items without filters or pagination;
  • a menu or taxonomy structure grows beyond its original design.

Drupal is not afraid of large content volumes. Large content simply needs proper architecture.

Editorial work can affect performance unintentionally

Performance is not only a developer concern.

Daily editorial choices can affect site speed as well:

  • very large original images are uploaded;
  • PDF files are added in sizes that are impractical for web use;
  • content is copied with excessive formatting;
  • too many embedded videos or iframes are added;
  • campaign pages are built with many blocks and scripts;
  • old content stays active even when it is no longer used.

This does not mean editors are doing something wrong. Often, they simply do not have the right tools and guardrails.

Drupal can support editors through:

  • image styles;
  • automated image processing;
  • field constraints;
  • clear content types;
  • better planned admin views;
  • workflows that help keep content organised.

A good admin interface does not only make editing easier. It also helps prevent technical and editorial clutter.

Cache configuration can drift over time

Drupal uses several cache layers. When configured correctly, caching is one reason Drupal works well for larger and high-traffic websites.

Problems appear when cache:

  • is disabled during development and never re-enabled;
  • is invalidated too often;
  • does not apply to dynamic blocks;
  • does not work well for logged-in users;
  • does not reach the CDN or Varnish layer;
  • does not account correctly for languages, roles or user contexts.

Cache is not a single switch that can simply be turned on.

A Drupal site often needs a separate review of:

  • Internal Page Cache;
  • Dynamic Page Cache;
  • render cache;
  • entity cache;
  • Redis usage;
  • Varnish or another reverse proxy;
  • CDN configuration;
  • cache headers;
  • cache invalidation logic.

If these layers do not work together, the site may feel slow even on powerful hosting.

Modules and custom code add invisible load

Drupal projects often gain new modules over time.

The reasons are understandable:

  • a new form feature is needed;
  • an integration is required;
  • a campaign function must be added;
  • a new admin view is requested;
  • content export or import is needed;
  • a separate permissions model is required.

A module is not automatically a problem. The issue begins when modules are added without later review.

Over time, a site may contain:

  • modules that are no longer used;
  • modules that duplicate each other's purpose;
  • modules that add CSS or JavaScript to every page;
  • modules that run expensive database queries;
  • custom code whose performance impact has never been measured.

The same applies to custom modules.

A custom feature can be entirely justified, but if it performs several heavy queries on every page load or bypasses Drupal's cache system, the whole platform starts to suffer.

Third-party scripts can make a fast page slow

Often, the reason for poor performance is not Drupal itself.

A page can be slowed down by:

  • analytics tools;
  • advertising scripts;
  • marketing automation;
  • chat widgets;
  • maps;
  • video players;
  • social media embeds;
  • consent management tools.

These are often added for valid business or communications reasons. Technically, however, they mean that the user's browser must load and process more external files.

The impact is especially visible on mobile devices.

If the page appears quickly but buttons and forms respond slowly, the cause may be JavaScript load. This affects user experience directly and can also affect Core Web Vitals.

Google's Core Web Vitals documentation describes these metrics as user experience signals, not only technical scores. That is why Drupal performance work should look at the server, caching, images and browser-side JavaScript together.

The admin interface may become slow before the public site

With Drupal sites, public page speed is often noticed first.

But for a large organisation, admin interface performance matters just as much.

If opening each content item takes several seconds, it affects daily work. If listings, filters and translation views are slow, content management becomes frustrating and error-prone.

Common causes include:

  • oversized admin views;
  • unfiltered content listings;
  • complex role and permission checks;
  • too many fields on one content type;
  • poorly optimised entity reference fields;
  • custom admin blocks that perform expensive queries;
  • missing or misconfigured cache for logged-in users.

The public website may be fast because of caching, while the admin interface remains slow. In that case, looking only at PageSpeed results is not enough.

Hosting, PHP and the database age together with the site

When a Drupal site runs for several years, the technical environment changes as well.

Performance problems may come from:

  • an outdated PHP version;
  • too low a PHP memory limit;
  • missing or misconfigured OPcache;
  • a slow database;
  • no Redis layer;
  • poor filesystem performance;
  • irregular cron execution;
  • backups or logs growing inside the same environment;
  • hosting that suited the original site, but no longer matches today's scale.

Changing hosting is not always the first answer. Often, better results come from reviewing the existing environment and fixing the actual bottlenecks.

At the same time, if the site has grown but the technical environment has stayed the same, a performance ceiling may eventually appear.

Slowness is often a symptom of maintenance debt

Performance problems are often the visible symptom of maintenance debt.

Maintenance debt means that small unfinished tasks accumulate:

  • modules are not updated regularly;
  • unused modules remain installed;
  • configuration is not cleaned up;
  • logs and recurring errors are ignored;
  • database tables are not reviewed;
  • old integrations are not removed;
  • media handling remains inconsistent;
  • performance is not measured regularly.

If maintenance only means applying security updates, some issues will remain invisible.

Good Drupal maintenance should also include monitoring performance, content volume, caching, errors and user experience.

How to find what is actually slowing the site down

Fixing a slow Drupal site should not begin with random modules or a larger server.

First, answer these questions:

  • is the public site slow, the admin interface slow, or both;
  • does the problem affect all pages or only specific views;
  • is the bottleneck on the server, in the database, in images or in JavaScript;
  • does caching work for both anonymous and logged-in users;
  • did the issue appear after a specific change;
  • is the problem related to traffic, content volume or external services;
  • do Core Web Vitals show a real user experience problem.

Only then does it make sense to decide what to change.

Sometimes image and cache cleanup is enough. Sometimes Views queries need optimisation. Sometimes part of the admin interface needs to be rebuilt. Sometimes PHP, database or hosting configuration must be adjusted.

What to review regularly

A Drupal site that supports a public-sector body, educational institution or larger organisation should be reviewed periodically.

A practical checklist:

  • is Drupal core up to date;
  • are contributed modules up to date;
  • have unused modules been removed;
  • does caching work correctly;
  • are Redis, Varnish or a CDN used where needed;
  • are images served in suitable sizes and formats;
  • are admin views fast enough for editors;
  • does cron run regularly;
  • are there slow database queries;
  • do logs show recurring errors;
  • are third-party scripts still justified;
  • do Core Web Vitals remain healthy;
  • do PHP, memory and OPcache settings match the site's current scale.

This does not always require a large development project. Regular technical maintenance often prevents small issues from becoming a visible performance problem.

Summary

Drupal does not become slow simply because a site is old.

Drupal becomes slow when:

  • content grows without architecture;
  • images and files become unmanaged;
  • modules are added but not reviewed;
  • custom code does not respect caching and query performance;
  • third-party scripts accumulate;
  • the admin interface is not optimised for editorial workload;
  • hosting and PHP configuration no longer match the site's needs;
  • maintenance focuses only on urgent fixes.

The good news is that most performance problems can be found and fixed.

WebPro supports Drupal sites through technical audits, maintenance and Drupal development, so the cause of slowness does not remain a guess. We measure, identify bottlenecks and improve the platform in a way that supports users, editors and long-term reliability.

Subscribe via RSS
Kaido Toomingas Kaido Toomingas WebPro Company OÜ

Need Drupal help?

If the article describes your situation, you do not have to read everything first. A real person will help you choose the next step.

Contact us