Drupal Hosting Compared: Speed Data From 424 Government Sites

Most Drupal hosting comparisons are built from vendor pricing pages and a handful of test installs. This one is built from production traffic: every Drupal site in the United States federal and state .gov registry, measured three times each.

The registry is public, so the sample is not ours to bias. We took all 2,742 federal and state domains from the CISA .gov dataset, requested each one, and found that 424 of the 1,347 that responded run Drupal — 31.5 per cent of the live US government web. Then we measured how fast each one answers.

What follows is what the numbers actually support, including the parts that contradict what we expected to find.

The number most benchmarks get wrong

Time to first byte is the usual yardstick, and on its own it is close to useless for comparing hosts. TTFB includes DNS resolution, the TCP handshake and the TLS negotiation before the server has done a single thing. Measured from our location, the median pre-transfer time across these sites was 0.897 seconds. That is nearly a full second of network that has nothing to do with the host’s performance and everything to do with the distance between the prober and the nearest edge.

So we report two numbers. TTFB is the whole journey. Server time is TTFB minus pre-transfer — the gap between “connection ready” and “first byte arrives”. Server time strips out geography and is the only one of the two that fairly compares one host against another.

Across all 424 Drupal .gov sites, median server time is 0.239 seconds. The quartiles are 0.162s and 0.438s, the 90th percentile is 0.721s, and only 3.6 per cent of sites take longer than a second to begin responding. As a population, government Drupal is not slow.

Pantheon and Acquia are not the same, and the gap is real

Origin platform is detectable on about a third of these sites; the rest sit behind a CDN that strips the headers that would identify it. Of the 424, we could attribute 97 to Acquia and 47 to Pantheon, with 271 unattributable and grouped as self-hosted or unknown.

Platform	Sites	Median server time	90th percentile
Pantheon	47	0.176s	0.351s
Unknown / self-hosted	271	0.239s	0.658s
Acquia	97	0.306s	0.828s

Acquia’s median is 0.130 seconds slower than Pantheon’s. We bootstrapped that difference across 4,000 resamples and the 95 per cent confidence interval runs from +0.074s to +0.241s. It does not cross zero, so the gap is not an artefact of sample size — in this population, Acquia-hosted Drupal takes roughly 1.7 times as long to start responding as Pantheon-hosted Drupal.

That is an association, not a mechanism. We are not controlling for page complexity, traffic volume, agency budget or how well each site is built. Acquia’s federal footprint skews towards large, heavily integrated departmental platforms; Pantheon’s skews smaller. A fair reading is that the kind of site that ends up on Acquia is slower, not that Acquia makes sites slower.

We should also say plainly that our first pass showed no difference at all. A single measurement per site put all three platforms within 15 milliseconds of each other and we nearly published that as a null result. Three passes and a median per site is what separated the signal from the noise. One measurement is not a benchmark.

The spread inside a platform dwarfs the gap between platforms

The platform difference is real and it is also small next to the variation within each group. The fastest site in the dataset answers in 16 milliseconds. The slowest takes 19.58 seconds. That is a factor of roughly 1,200 between two sites doing broadly the same job.

Fastest	Server time	Slowest	Server time
fbijobs.gov	16ms	irssales.gov	19.58s
cpsc.gov	20ms	navycash.gov	18.57s
interior.gov	22ms	screwworm.gov	18.51s
doleta.gov	27ms	eaglecash.gov	18.43s
aspr.gov	28ms	fincen.gov	18.20s
cftc.gov	29ms	asc.gov	10.44s

Four of the five slowest sites are Treasury properties — FinCEN, EagleCash, NavyCash and the Alcohol and Tobacco Tax and Trade Bureau — and all four sit on Acquia behind Akamai. Eighteen seconds to first byte is not a tuning problem. It is a site that is effectively broken for anyone who tries to use it, and it has presumably been that way long enough for nobody to be watching.

If you are choosing a host on the strength of a 130-millisecond median difference while your own site sits at eight seconds, you are optimising the wrong variable by two orders of magnitude.

The CDN in front matters more than most people assume

Edge	Sites	Median server time	90th percentile
Fastly	15	0.129s	0.428s
CloudFront	115	0.206s	0.482s
Cloudflare	111	0.232s	0.762s
Akamai	34	0.265s	18.196s
No CDN detected	126	0.285s	0.656s
Azure	13	0.559s	0.673s

Look at the Akamai row twice. Its median is unremarkable — 0.265s, mid-table. Its 90th percentile is 18.196 seconds, seventy times worse than any other edge in the table. That is not a slow CDN; Akamai is not slow. It is a small number of catastrophically slow origins that happen to sit behind it, and a median would never have shown you that. This is the argument for reporting percentiles rather than averages: the Akamai group looks fine until you look at its tail, and the tail is where users actually suffer.

The Azure figure comes from 13 sites and should be treated as indicative rather than conclusive.

Drupal 11 is measurably faster than Drupal 10

Version	Sites	Median server time
Drupal 11	119	0.189s
Version not disclosed	158	0.219s
Drupal 10	129	0.306s

Drupal 11 sites answer in roughly 62 per cent of the time Drupal 10 sites take. Some of that is the release itself; more of it, we suspect, is that a site upgraded to 11 recently is a site someone is actively maintaining, on current PHP, with its caching configured. Recency of care and recency of version are hard to separate, and we are not going to pretend otherwise.

We also measured four Drupal 7 sites at a median of 66 milliseconds, which is the fastest group in the dataset. Four sites is not a finding, and the reason those sites are quick is that they are simple, old and do very little. It is worth mentioning only because it leads directly to the uncomfortable part of this dataset.

Twelve government sites are running unsupported Drupal

Version detection turned up something we were not looking for. Twelve of the 424 sites are on a Drupal release that no longer receives security patches.

Site	Version	Unsupported since
dc.gov	Drupal 7	January 2025
washingtondc.gov	Drupal 7	January 2025
open-dc.gov	Drupal 7	January 2025
sns.gov	Drupal 7	January 2025
usadf.gov	Drupal 8	November 2021
azdps.gov, azdoc.gov, azboc.gov, azdc.gov, azland.gov, azwaterbank.gov, azwifa.gov	Drupal 9	December 2023

The District of Columbia’s main portal, its open data site and its tourism domain are all on Drupal 7, which stopped receiving security coverage in January 2025. Seven Arizona state agencies — including the Department of Public Safety, the Department of Corrections and the State Land Department — are on Drupal 9, unsupported since December 2023.

dc.gov is, incidentally, one of the fastest sites we measured, at 39 milliseconds. Fast and unpatched is not a trade-off anybody chose. It is what happens when a site works well enough that nobody revisits it, which is precisely how end-of-life exposure accumulates.

We are reporting what a public HTTP header says on a public website. Some of these may have backported patches or vendor extended support, and a site announcing “Drupal 9” in its X-Generator header is not proof of an unpatched install. But a government site advertising an end-of-life version to every visitor and every scanner is, at minimum, telling attackers exactly where to start.

What we would actually tell you about choosing a host

Pick the CDN and the caching strategy first. The difference between the fastest and slowest edge configurations in this data is larger than the difference between the two biggest Drupal platforms, and unlike the platform choice it is something you can change on a Tuesday.

Then worry about the tail, not the median. Every organisation in the bottom ten of this dataset almost certainly believes its site is fine, because whoever checks it checks the homepage from an office nearby on a warm cache. The 90th percentile is where your actual users live.

Then choose the platform, and know that you are choosing operational model, compliance posture and support quality far more than you are choosing raw speed. A 130-millisecond median difference is worth roughly nothing next to a content model that fights you or a deployment process nobody trusts.

And upgrade. Drupal 11 sites in this dataset are faster than Drupal 10 sites, and both are infinitely safer than the twelve sites still serving an unsupported release to the public.

Method, and what this does not show

The frame is every Federal and State/territory domain in the CISA .gov registry, 2,742 domains, retrieved on 19 September 2026. Each was requested over HTTPS with redirects followed. 1,347 returned HTTP 200; the remainder redirected off-registry, timed out or refused. Drupal detection used X-Generator, X-Drupal-Cache, X-Drupal-Dynamic-Cache, session cookie names and markup fingerprints. Platform and edge detection used vendor response headers, which survive some CDNs and not others.

Every Drupal site was then measured three further times. The figure used for each site is the median of its passes, and 415 of the 424 returned at least two usable measurements. All measurements were taken from a single location in the Gulf region, which is why we lead with server time rather than TTFB.

Three limitations worth stating. One: a single vantage point cannot measure global performance, only server responsiveness. Two: 271 of 424 sites could not be attributed to a platform, so the platform comparison rests on 144 sites, not 424. Three: we tested cache state and found nothing — pairing each measurement with its own cache header gave medians of 0.241s with no cache header, 0.271s on a HIT and 0.272s on a MISS. An earlier version of this analysis reported a 42 per cent cache penalty; that was an artefact of comparing a cache header from one request against a timing from another, and it did not survive being done properly.

Gspikes builds and maintains Drupal platforms, and we run this kind of measurement on client sites because the 90th percentile is where the problems hide. If you want to know where your own site sits in the distribution above, send us the URL and we will measure it properly and tell you. More on how we work on our Drupal development page, and the companion data in our Drupal 11 Adoption Tracker.