A slow Drupal site is rarely slow for one reason. A page cache switched off by a single block, an image served at the size it was uploaded, a web font that holds back the first paint, a view that runs a query for every row: each costs a fraction of a second, and together they fail Core Web Vitals. Drupal speed optimization starts there: we measure the pages that matter, trace the time to its causes, fix them in order of effect, and leave a budget that keeps the site fast after we are gone.
Who this is for
- Search Console reports failing Core Web Vitals. Groups of your URLs are marked poor or in need of improvement, and you need to know which fix moves which group.
- Pages are slow on a phone. The site feels fine on the office network and heavy on a mid-range phone over a mobile connection, which is how many visitors meet it.
- The site slows down under load. Enrolment day, a campaign or a news story, and the pages that matter most are the ones that stall.
- Editors wait for the admin. Saving content or opening a listing takes long enough that people work around it.
- It got slower after a change. A new module, a theme update or a marketing script, and nobody measured before and after.
If speed is one of several questions about the site, such as an upgrade or a handover, the Drupal site audit covers it alongside the others. If the site is being rebuilt anyway, performance belongs in the build: see enterprise website development. If the look is dated as well as slow, a new theme is the moment to fix fonts, images and scripts at their source; we redesigned sprep.org and rebuilt its Drupal theme in 2024, and that kind of work is described on Drupal website redesign.
What you get
- Measurements of each main page type on a mid-range phone, from lab tools and, where the site has enough traffic, from Chrome's field data
- A findings list that ties each slow metric to its cause, with the expected effect of fixing it and the effort
- The fixes, applied in order of effect and released through your normal deployment process
- A second measurement after each fix, on the same page and connection, so every change is checked
- A performance budget for each page type, with a check in the deployment pipeline that fails a release which breaks it
Example budget Performance budget for a listing page Mid-range phone, mobile connection
- LCP
- ≤ 2.5 s Largest Contentful Paint
- INP
- ≤ 200 ms Interaction to Next Paint
- CLS
- ≤ 0.1 Cumulative Layout Shift
The Core Web Vitals limits are the ones Google publishes as good. The byte limits are an example: yours are set from your own pages once they have been measured.
An engineer reads it and replies within one business day.
How performance work runs
How Drupal performance work runs
- Scope The page types that matter, the devices and the targets, agreed before anything is measured. You keep the scope statement
- Measure Lab runs on each page type, field data where there is traffic, and the server side: cache hits and slow queries. You keep the baseline
- Report Every slow metric tied to a cause, with the effect of fixing it and the effort. You keep the findings
- Fix Changes applied in order of effect, each released on its own so its effect can be seen.
- Verify The same pages measured again, and the budget added to your deployment checks. You keep the budget
The checklist we start from is written up in how to improve page speed on a Drupal website. The audit is what turns that general list into the few changes that matter on your pages.
Where the time goes on a Drupal site
Drupal has good performance tools built in, and most slow sites have switched one of them off without knowing. The table follows a request from the edge of the network down to the database.
| Layer | What we look at | Usual fix |
|---|---|---|
| CDN and reverse proxy | Whether pages and files are served from the edge, and whether a content change clears the right pages | A CDN or Varnish in front of Drupal, purged by cache tag |
| Page cache | Which block or field marks a page uncacheable and switches the cache off for everyone | Correct cache tags and contexts, with the personal part built separately |
| Images | Upload sizes, image styles, formats, and whether the largest image loads first | Responsive image styles in WebP or AVIF, dimensions on every image, the main image never lazy |
| Fonts and CSS | Web fonts and stylesheets that block the first paint | Fonts self-hosted and preloaded, unused CSS kept off the critical path |
| JavaScript | What runs on every page, what blocks a tap, and which third-party tags load | Libraries attached only where used, scripts deferred, tags loaded after interaction |
| Database | Queries per page, views without caching, missing indexes, a query for every row | Views caching, entities loaded in bulk, indexes where the queries need them |
| PHP and server | PHP version, OPcache, the cache backend and when cron runs | A current PHP, cache bins in Redis or Memcache, cron moved off visitors' requests |
Only the first and last rows of that table belong to hosting. On the Drupal hosting we run, those rows are part of the standard setup: a CDN that honours Drupal's cache tags, Redis or Memcache where it earns its place, and cron and queue workers, as drawn on managed Drupal hosting. The rows between are code and configuration, and they are fixed wherever the site is hosted. When the slow code sits in a contributed module, we fix it on your site and offer the fix upstream as well; we maintain modules on drupal.org ourselves, such as WE Mega Menu, so we know that side of the issue queue.
Core Web Vitals, in plain terms
Google measures page experience with Core Web Vitals, collected from real Chrome visits and reported in Search Console and PageSpeed Insights. A page passes when the 75th percentile of visits meets each limit.
- Largest Contentful Paint (LCP). How long the main content takes to appear; good is 2.5 seconds or less. On Drupal sites the usual cause is the hero image or a font that blocks rendering.
- Interaction to Next Paint (INP). How quickly the page responds to a tap or a click; good is 200 milliseconds or less. It replaced First Input Delay in March 2024, and heavy JavaScript is what fails it.
- Cumulative Layout Shift (CLS). How much the page jumps while it loads; good is 0.1 or less. Images without dimensions, late banners and swapped fonts cause most of it.
Lab tools such as Lighthouse show one run on one device. Field data shows what visitors actually had over the previous 28 days. We use the lab to find causes and the field to confirm a fix reached people, which is why a change can take weeks to show in Search Console.
What performance work costs
The audit is priced from the number of page types to measure and how much of the stack is in scope, and it is quoted at a fixed price before it starts. Fixes are quoted against the findings, so you can take the ones with the largest effect first and stop when the numbers are where you need them.
On the pricing page, a performance audit sits under maintenance and support, as one piece of work rather than a monthly fee; longer engagements are priced from the QA, Security and Accessibility Engineer rate on the rate card. Holding the budget after the work ends is part of maintenance: a release that breaks it is caught before it ships.
Terms that hold
These terms hold across our services; where a service starts differently, its page says how. The full wording is on the warranty page and in why you own the source code.
- A prototype before you sign a build Before a build project is signed, we build a prototype at no charge: a design, a clickable prototype or a working demo on real code, so you decide against something real.
- You receive the system and its source code Custom work is yours from the first commit: the repository, custom modules, theme and deployment configuration. When we build your system on one of our platforms, you receive the whole system and its source code as well.
- A warranty on development work Development projects carry a 1-year warranty by default, up to 3 years. It covers defects in what we built, and applying the security releases of Drupal core and contributed modules while the warranty runs. Maintenance picks up where the warranty leaves off.
- Response targets we publish A first response in 4 hours for critical issues, 1 business day for high priority and 3 business days for normal. Support runs in business hours; cover outside them is an option, priced separately.
Questions we get asked
Will faster pages improve our search rankings?
Core Web Vitals are one of the signals Google uses, and they matter most between pages that are equally relevant. They do not outweigh relevance, so we do not promise a ranking. What you can check is the measured change on the pages we worked on, before and after each fix.
Why does Search Console still show failures after the fixes?
Its figures come from real visits over the previous 28 days, so a fix released today takes weeks to work through. The lab measurement confirms the change the same day; the field data catches up as new visits replace old ones.
Do we need to change hosting?
Usually not. Most of the time on a slow Drupal page is spent in code and configuration, and that is fixed wherever the site runs. If the server is the limit, the report says so, and the change can be made with your current host or through managed hosting.
Can the site be fast without removing our marketing scripts?
Often, by loading them after the page can be used, or only on the pages that need them. Where a tag cannot be deferred, the report shows what it costs on each page type, so keeping it becomes a decision rather than an accident.
Is caching safe for logged-in users and personalised pages?
Yes, when it is set up the way Drupal intends. The Dynamic Page Cache stores the parts of a page that are the same for everyone, and the personal parts are built separately for each visitor. The fix for a slow member area is usually to mark those parts correctly, not to switch caching off.
What about slowness that only editors see?
The admin is measured the same way: content listings, edit forms, the media library. The causes are usually familiar ones: a query for every row in a listing, a form loading more than it shows, or cron running while someone saves their work.
Not covered here? Ask us directly.
Ask for a performance auditAn engineer reads it and replies within one business day.
Send us the pages that feel slow
Tell us the address and the pages that matter most: the ones people land on, search from or buy through. We will say what we would measure first and quote the audit.
An engineer reads it and replies within one business day.