Why your Drupal admin is slow — an Admin Toolbar maintainer’s guide

“The site is fast, but the admin is unusable.” I hear this from editorial teams constantly — and as a co-maintainer of Admin Toolbar (running on roughly 290,000 sites), I also read the issue queue where those complaints eventually land. The uncomfortable truth: the toolbar gets blamed first, and is rarely the main culprit. Here is what actually makes Drupal back offices slow, ranked by how often I find it in audits.

Why admin pages are structurally slower

Anonymous pages fly because they come out of the page cache. Admin pages can’t: they are personalized (your permissions, your menus, your drafts), so every request does real work — routing, access checks on every element, form building, entity loading. That baseline is fine. What turns “not cached” into “painful” is everything below.

The real culprits, ranked

1. Hosting tuned only for anonymous traffic

The classic: a CDN and page cache hide a slow origin from visitors, so nobody notices PHP is under-provisioned — until editors, who bypass every cache, feel it on each click. Check the boring things first: OPcache sized correctly, PHP workers not saturated, database on fast storage, and no Xdebug extension enabled in production (I have found it there more than once — it alone can double response times).

2. Expensive entity forms

The node form is the editor’s workplace, and it is where seconds die: a dozen entity-reference fields, each loading options; nested Paragraphs or inline entity forms building entire sub-forms; media widgets rendering previews. Fixes that pay immediately: trim the form display to what editors actually use, prefer autocomplete widgets over select lists on large reference fields, and split monster content types — a form with 60 fields is an information architecture problem wearing a performance costume.

3. Admin views without limits

Content and media overview pages built on Views, listing tens of thousands of rows with sorts on unindexed columns and exposed filters that trigger full scans. Add database indexes for the columns you sort and filter on, keep pagers small, and avoid rendering entities in admin rows when fields will do.

4. The menu tree — where Admin Toolbar earns its reputation

The drop-down admin menu is built from the full menu tree with access checks on every link — and modules keep adding links. On sites with large menu trees the cost is real; it is exactly the kind of report we work through in the issue queue, and recent releases moved toward lazier loading and better caching of the tree. Maintainer advice: run the latest release (performance work lands continuously), review what contrib injects into the admin menu, and if a site has thousands of menu links, question the site architecture before blaming the module that renders it.

5. Cache-hostile custom code

One custom block or access hook with max-age: 0 (or a user-context cache without granularity) can drag whole sections of the authenticated experience out of the Dynamic Page Cache. Audit your custom code’s cacheability metadata — I wrote about the same mechanism from the visitor side in my Core Web Vitals guide; it bites editors twice as hard.

6. Contrib pile-up on admin routes

Environment indicators, dashboards, admin themes with heavy assets, “helper” modules injecting JavaScript on every admin page. Each is small; together they are why the admin loads two megabytes of assets. Twice a year, uninstall ruthlessly.

The 30-minute diagnosis

1. time drush status on production — if the CLI is slow, it’s infrastructure, not Drupal.
2. Open the slowest admin page with the browser’s network panel: is the time in TTFB (server) or in assets/JS (front)?
3. Enable Webprofiler on staging, replay the page, read the database and cache panels: the culprit query is usually embarrassing once visible.
4. Check the toolbar last. If everything else is clean and the tree is huge, now we can talk.

A fast back office is not a luxury — editors use it eight hours a day, and every second on the node form is multiplied by every save of every editor. That multiplication is usually the cheapest performance ROI on the whole platform.

Want your editors to stop sighing? A back-office performance pass is part of my audit offering — diagnosis with numbers, fixes included.