Upgrading from Drupal 10 to Drupal 11: what actually changes
Drupal 11 is a far smaller step than the Drupal 7 to 9 migration was. Here is what the upgrade touches, what breaks, and the order to do it in.
ZooBieDoo Infotech Engineering TeamRead
Key takeaways
- Measure before caching — most slow pages have one identifiable cause.
- Cache tags are what custom code most often gets wrong.
- Third-party scripts are frequently the single largest front-end cost.
- Track Core Web Vitals from real users, not just laboratory tests.
Measure first
Before adding a caching layer, find out where the time is going. Enable the Devel and Webprofiler tooling on a non-production copy, or use a profiler such as Blackfire or XHProf, and look at query counts and slow queries per page.
The common findings are unglamorous: a view without a proper index behind it, an image style being generated on request, a block that runs an uncached query on every page, or a contributed module doing something expensive in a preprocess hook.
The caching layers, in order
- Render cache and dynamic page cache — core, enabled by default, and dependent on correct cache metadata in custom code.
- Internal page cache — for anonymous traffic only, and very effective on content sites.
- Reverse proxy — Varnish or a CDN in front, honouring Drupal's cache tags where supported.
- Object cache — Redis or Memcached to take load off the database.
Cache tags are the part custom code most often gets wrong. If a custom block does not declare its dependencies, it will either serve stale content or defeat caching entirely.
Front-end weight
Server response time is only half the story. Aggregate and minify CSS and JavaScript, serve modern image formats through responsive image styles, and audit what the theme actually loads on a typical page.
Third-party scripts are frequently the largest single cost on a business site, and they are usually added without anyone measuring the effect. Review them periodically against what they actually deliver.
Keep it measurable
Set a performance budget as a release gate rather than a periodic clean-up. Track Core Web Vitals from real users through the Chrome UX Report or your own field data, because laboratory numbers on a fast connection hide most real problems.
Database and query hygiene
Beneath the caching layers sits the database, and a site that is slow with a cold cache will be unpleasant for the first visitor after every deployment or content change.
Enable slow query logging on a copy of production and look at what appears. The usual offenders are views filtering on unindexed fields, entity queries loading full objects when only a few values are needed, and custom code running queries inside a loop over nodes.
Adding an index is often a one-line change with a dramatic effect. Restructuring a query to fetch what it needs in a single pass rather than per row is usually the next largest win, and both are considerably cheaper than adding another caching layer to hide the problem.
Frequently asked questions
A CDN is worth it for almost any site with a geographically spread audience, and it is inexpensive. A separate Varnish layer earns its operational cost mainly on high-traffic sites with a large share of anonymous visitors. Start with Drupal's own caching configured correctly.
Because the internal page cache only serves anonymous traffic. Authenticated requests fall through to the dynamic page cache and render cache, which depend on correct cache metadata. Uncacheable blocks appearing on every page are the usual cause.
Often a great deal. Serving correctly sized responsive images in a modern format, with lazy loading below the fold, is usually the largest single improvement available on a content-heavy page.
