A Drupal performance audit is not a Lighthouse score with recommendations pasted underneath. It is a structured answer to three questions: where does the site actually lose time, which losses matter to real visitors, and what fixes the budget and hosting can support. Run it in that order and you avoid the most common failure mode of performance work — optimizing images on a site whose real bottleneck is an uncached Views query that fires on every page load.
Measure Before You Touch Anything
Start with evidence gathered under realistic conditions. Test the heaviest pages, not the homepage alone: a listing page with filters, a node page with twenty paragraphs and embedded media, a search results page. Record server response time, first contentful paint, largest contentful paint, and time to interactive for each, on both desktop and a mid-range phone over throttled connection. WebPageTest and Lighthouse both work; what matters is that the numbers are stable enough to compare after changes. Take a snapshot of Drupal’s own reports too — the Status report for obvious configuration problems, and the database log for slow query warnings that repeat.
Resist changing settings during measurement. A single cache flush or module toggle invalidates the baseline, and two weeks later nobody knows whether the site improved or the measurement changed.
Drupal Performance Audit Build Readiness Worksheet
This worksheet is the audit plan Drupal Pixels uses before touching configuration. Each layer gets one row; the worksheet forces the audit to look at every layer instead of the one the auditor already suspects.
| Layer | What to check | Cheap tell |
|---|---|---|
| Hosting and PHP | PHP version, memory limit, OPcache, web server config | PHP two or more minor versions behind current |
| Caching | Page cache, dynamic page cache, render cache, CDN or reverse proxy | Anonymous page cache disabled, or cache lifetime under 15 minutes without a reason |
| Views and queries | Uncached Views, N+1 queries, missing database indexes | A View rendering on every page with no cache tag or query aggregation |
| Images and media | Responsive image styles, lazy loading, derivative generation | Original 4000px uploads served directly into content |
| Frontend assets | CSS/JS aggregation, unused library weight, webfonts | 120+ requests and 2MB of JavaScript on an article page |
| Modules and cron | Debug modules left on, cron frequency, expired log spam | Devel or Twig debug enabled, or cron set to “never” |
Reading The Layers In Order Of Payoff
When the worksheet is filled, fix in the order of measured impact, not fashion. Hosting and PHP upgrades are boring and often the largest single win: a supported PHP version with OPcache routinely cuts server response time by a third before any Drupal-specific work. Caching comes next — enabling the anonymous page cache and giving it a sensible lifetime fixes more real-world slowness than any theme optimization. Views and queries are third; this is where the expensive fixes live, because query restructuring takes development time, so it should be reserved for layers the first two passes did not fix.
Images and frontend assets come last in the stack but first in visible effect, which is why they tempt people into starting there. Do them after the backend layers, because a 1.4-second server response makes even a perfectly optimized frontend feel broken. The Drupal maintenance checklist on this site keeps the audit cadence honest — performance drifts back between audits, and the checklist is what schedules the next one.
What To Do When The Audit Is Not Yours To Fix
Sometimes the audit happens on a site you maintain but do not fully control — a client’s budget holds the hosting upgrade, or a vendor owns the theme. In that case the report’s job changes: it becomes a negotiation document. Rank every fix by visitor impact and mark clearly which layer each fix belongs to, so the conversation is about the cheapest layer that unlocks the most speed rather than about blame. “The reverse proxy is adding 400 milliseconds” is a fact both sides can verify; “the site is slow” is an argument nobody wins.
And if the audit keeps reopening the same findings year after year, treat that as a finding itself. A site that regresses to slow every six months has a process problem — deployments that skip cache checks, content editors uploading unoptimized originals, modules accumulating without review. The fix then is the cadence, not another tuning pass: a standing quarterly slot where the worksheet above gets re-run and anything that regressed gets named.
Writing The Audit Report So A Client Acts On It
An audit that nobody acts on is worse than no audit, because it spends the organization’s attention. Write the report as three lists: fixes under an hour (cache settings, image styles, aggregation toggles), fixes under a day (View caching, module cleanup, font loading), and fixes that need a budget conversation (query restructuring, hosting migration, theme rebuild). Put the measured before/after numbers next to each item you completed, and the expected impact estimate next to each deferred item. A client who sees “server response 1.9s to 0.6s in twenty minutes of work” approves the next phase; a client who sees a wall of technical nouns approves nothing.
Close the report with a re-measurement date. Performance work without a scheduled re-check decays into folklore — “the site got faster last year” — and the next real audit starts from zero. Six to eight weeks after the fixes land is usually long enough for caches to stabilize and traffic to confirm the improvement. For the measurement methodology behind the numbers, the Core Web Vitals documentation defines the metrics Google actually rewards, and Drupal.org’s performance guidelines cover the platform-specific layers in official detail.