A slow Drupal site is almost always slow for one of four reasons — uncached pages, oversized images, unaggregated front-end assets, or a slow origin — and you can identify which before changing anything.
Generic speed advice sends people optimising the wrong layer. This page is Drupal-specific and ordered by impact, so you can stop when the numbers are good enough rather than working through a checklist.
Measure first, and measure the right thing
Google's Core Web Vitals are the three metrics that matter, and one of them changed. First Input Delay was retired and replaced by Interaction to Next Paint. Guidance still naming FID is out of date, and so is any audit built on it.
- Largest Contentful Paint — good at 2.5 seconds or under.
- Interaction to Next Paint — good at 200 milliseconds or under.
- Cumulative Layout Shift — good at 0.1 or under.
Test the page as an anonymous visitor, not logged in. Logged-in users skip the anonymous page cache and carry extra toolbar and contextual-link assets, so their numbers are not comparable with what a visitor gets. Aggregation and the dynamic page cache do still apply to them — neither is switched off for authenticated users the way the internal page cache is. Use a private window or the command line.
1. Check page caching is actually on
This is first because it is the biggest single difference and it is frequently off. Drupal's page cache serves an anonymous visitor a stored response without building the page at all.
Drupal's internal page cache is a module, not a setting: check it is installed at Extend, under Internal Page Cache. Without it there is no stored response for an anonymous visitor and no X-Drupal-Cache header to look for, whatever the performance settings say. Separately, cache.page.max_age in the system.performance configuration object sets the max-age sent to browsers and proxies. Core ships it at 0, which means no browser or proxy caching until somebody changes it. Set it from the Performance page, or override it in settings.php for a value the interface does not offer.
Then verify rather than assume. Request a page as an anonymous visitor and look at the response headers for X-Drupal-Cache or X-Drupal-Dynamic-Cache. A MISS on every request means something is defeating the cache — commonly a block or a module attaching a per-user cache context to every page.
2. Turn on CSS and JavaScript aggregation
Also in system.performance: css.preprocess and js.preprocess. Both default to true in core's shipped configuration, but they are routinely switched off during development and left off.
Check the page source. Twenty separate stylesheet links means aggregation is off, and turning it back on is one setting.
3. Fix the images
Uploading a 4000-pixel photograph and letting CSS scale it down means every visitor downloads the full file. Drupal has two core modules for this and neither needs contrib:
- Image styles, from the
imagemodule, generate derivatives at defined sizes. Configure the field's display to use a style rather than the original. - Responsive image styles, from the
responsive_imagemodule, output a<picture>element with asrcset, so the browser picks a size that fits the viewport.
Both ship with core in Drupal 11.4.6. Add loading="lazy" for images below the fold, and leave it off the largest image above the fold — lazy-loading your LCP element makes that metric worse.
4. Look at the origin
If a cache MISS takes two seconds to generate, caching hides it from most visitors and does nothing for the first one. Two things dominate:
- PHP version. Core 11.4.6 sets its minimum at PHP 8.3.0 and recommends 8.4. Older runtimes are measurably slower.
- Views doing too much. An uncached View with several relationships and no pager limit is the most common single slow query on a Drupal site.
BigPipe is in core and enabled in the standard install. It streams the cacheable shell of the page immediately and fills in the personalised parts after, which improves perceived speed for authenticated users considerably. If it has been disabled, ask why before leaving it that way.
Once the origin is fast, a CDN in front of it is what turns fast into consistently fast everywhere — how long edge TTLs and purging fit together is the next step, and Drupal services covers the whole chain if you would rather not.
5. Remove what you are not using
The cheapest performance work is deletion. Uninstall modules nobody uses, remove tracking scripts from campaigns that ended, and cut web font weights you never call. Every one is bytes and execution time on every page load, forever.
Use the browser's Coverage tool to see how much of your CSS and JavaScript is actually used on a typical page. The number is usually uncomfortable.
Common questions
Why is my site fast when I test it and slow for visitors?
You are almost certainly testing while logged in, or testing a page already warm in cache. Test anonymously, and test a page you have not just visited.
Do I need a CDN?
Not to be fast. To be fast for people far from your server, yes. Fix caching and images first — a CDN in front of a slow origin just distributes the slowness.
Will a caching module fix a slow site?
Only if the slowness is repeated page builds. If a single uncached request is slow, caching hides the problem from most visitors and leaves it in place.
How much does hosting matter?
A lot for time to first byte, and not at all for image weight or unused JavaScript. Fix what is yours before paying more for hosting.
Does page speed really affect rankings?
Core Web Vitals are a ranking signal, but a small one next to content relevance. The stronger argument is behavioural: people leave slow pages.
Where to start tomorrow
Run one anonymous test, note the LCP, and then work down this list in order until it is under 2.5 seconds. Most Drupal sites get there at step two or three.
If the numbers do not move, the problem is usually in the render pipeline rather than the settings, and that needs someone to read the code — Drupal development services covers it, or send me the URL and I will tell you which of the five layers is costing you the most.
