For thirteen years, if you wanted to know which web framework was fastest, you looked in one place. That place is gone.
In March 2026 the TechEmpower Framework Benchmarks were sunset and the repository archived, read-only. It began in 2013 with 25 frameworks and ended with more than 330 implementations in Round 23. The maintainers gave the honest reasons: the cost of keeping two hundred frameworks building, and volunteers running out of appetite as the thing grew.
The historic data is still online. It is just frozen, and every month that passes makes it a worse answer to the question in the title.
So the question is open again. Something has moved in to answer it, and it is stricter than what it replaces.
HttpArena
HttpArena. One machine. An AMD Ryzen Threadripper PRO 3995WX, 64 cores, 128 threads, 251 GB of RAM, Ubuntu 24.04, performance governor. Every entry runs on that same box, under the same conditions, run by the project rather than self-reported by the framework authors.
Thirty test profiles, grouped into six boards: HTTP/1.1, HTTP/2, HTTP/3, gRPC, Gateway, WebSocket.
The HTTP/1.1 board alone counts twelve scored profiles:
| Profile | What it does |
|---|---|
| baseline | mixed GET/POST with query parsing, 512 and 4096 connections |
| limited-conn | connections closed after 10 requests, so the handshake counts |
| json | dataset processing and serialization |
| json-comp | the same, compressed, with Accept-Encoding: gzip, br
|
| json-tls | the JSON workload over HTTP/1.1 + TLS |
| upload | 20 MB body ingestion |
| static | 20 static files off disk |
| static-tls | the same over TLS |
| async-db | async Postgres query with pooling |
| crud | a REST API with cache-aside reads, updates, list and upsert |
| api-4 / api-16 | mixed workloads pinned to 4 and 16 CPUs |
How the score is built
Each profile is normalised against the best result in the field: your average RPS divided by the leader's, times 100. Those per-profile scores are then summed across the profiles an entry runs.
One profile does not use raw throughput. json-comp multiplies by the square of the compression ratio, rps × (minBpr / myBpr)², where bpr is bytes per response. Ship a body twice as large and you quarter your score. It is the only place in the benchmark where being smaller beats being faster, and it changes what you optimise for.
Two profiles, pipelined and fortunes, are displayed but deliberately excluded from the ranking, because they measure a library rather than the server: HTTP/1.1 pipelining is dead in browsers, and Fortunes mostly measures a template engine.
The rules are the interesting part
This is where HttpArena earns its numbers:
- No pre-computed responses. No pre-serialized caches, no pre-compressed bodies, no response lookup tables. The JSON has to be serialized per request and the compression has to run per request.
-
Use the framework's own machinery. The template test requires a real template engine with a separate template file and HTML auto-escaping, not string concatenation in the handler. One seeded row contains a raw
<script>tag, and the rendered output has to escape it. - Stock proxies only. The Gateway tests require a production-grade third-party proxy, nginx or Caddy or Envoy or HAProxy. No custom ones. Exactly two services, no extra caches or sidecars.
- Anti-cheat per protocol. The cleartext HTTP/2 profiles reject an entry that also serves HTTP/1.1 on the same port.
- Correctness first. A validation script checks response shapes, headers, escaping and sizes before any result is accepted.
And two separations that matter more than any single rule:
Frameworks and engines are ranked apart. A raw event-loop engine with no application layer does not compete against something you would actually build an app in. Standard and tuned entries are marked, so a default configuration is not silently compared against one that has been swept for a week.
Where things landed
HTTP/1.1 board, framework entries:
| # | Entry | Score | Language |
|---|---|---|---|
| 1 | genhttp-11-ioxide | 968 | C# |
| 2 | genhttp-11 | 868 | C# |
| 3 | fulmine | 823 | JS |
| 4 | true-async-server | 780 | PHP |
| 5 | swoole | 707 | PHP |
| 6 | actix | 702 | Rust |
| 7 | aspnet-minimal-ioxide | 697 | C# |
The engine league, ranked separately: ioxide 966 (C#), vanilla-io_uring 864 (V), sark 846 (Rust).
Two things are worth noticing. The top of the framework board is C#, not Rust, and the languages people assume are slow are not where you would expect them to be. PHP holds fourth and fifth.
How to read a board like this
The composite is a sum, not an average, so it rewards breadth as much as speed. An entry running twelve profiles at 60 beats one running eight at 90. That is deliberate, so a one-trick entry cannot top the board, but it means the headline number answers two questions at once and you cannot tell them apart from the outside.
So: open the per-profile columns before concluding anything. And remember the top entries sit within a few percent of each other, on a machine that is not yours, on workloads that are not your application.
A benchmark tells you what is possible. It does not tell you what your bottleneck is.
Top comments (0)