DEV Community

Cover image for I Benchmarked fasthttp vs net/http — The Results Surprised Me
Mustafa Veysi Soyvural
Mustafa Veysi Soyvural

Posted on • Originally published at github.com

I Benchmarked fasthttp vs net/http — The Results Surprised Me

I kept hearing that fasthttp was faster than Go's standard net/http. So I decided to stop guessing and just measure it.

The result? 5.6x faster. Zero heap allocations. And the benchmark is only two files.

Keeping It Fair

The trick to an honest benchmark: remove everything except what you're testing.

Both servers use the same in-memory listener — no TCP, no network noise. Same endpoints, same response bodies. The only difference is the HTTP stack.

// net/http
func SimpleHandler(w http.ResponseWriter, r *http.Request) {
    w.Write([]byte("Hello, World!"))
}

// fasthttp
func SimpleFastHandler(ctx *fasthttp.RequestCtx) {
    ctx.Write([]byte("Hello, World!"))
}
Enter fullscreen mode Exit fullscreen mode

Same job. Very different performance.

The Numbers

Apple M2 Pro, Go 1.23.4

Benchmark net/http fasthttp Speedup
Simple 14,449 ns/op, 63 allocs 2,563 ns/op, 0 allocs 5.6x
JSON 15,561 ns/op, 72 allocs 3,136 ns/op, 6 allocs 5.0x
Parallel 3,541 ns/op, 63 allocs 1,437 ns/op, 0 allocs 2.5x

Zero allocations on simple requests. That's not a typo.

The parallel gap is smaller (2.5x) because net/http already handles concurrency well. But even there — 63 allocations vs. 0.

What Makes fasthttp So Fast?

It comes down to one idea: don't allocate, reuse.

net/http creates fresh Request and ResponseWriter objects for every single request. fasthttp pools them with sync.Pool and resets them between requests. That's why you see 63 allocs drop to 0.

It also skips things most apps don't need — header map cloning, chunked encoding by default, HTTP/2. Less work per request = less time per request.

So Should You Switch?

Use fasthttp when:

  • You're building a proxy, gateway, or high-throughput service
  • Allocation pressure and GC pauses are a real problem
  • You need every microsecond on hot paths

Stick with net/http when:

  • You need HTTP/2
  • You rely on the Go middleware ecosystem
  • context.Context propagation matters to you

For most apps, net/http is the right choice. But when performance is the priority, fasthttp earns its name.

Run It Yourself

git clone https://github.com/soyvural/fasthttp-vs-nethttp.git
cd fasthttp-vs-nethttp
go test -bench=. -benchmem -count=3
Enter fullscreen mode Exit fullscreen mode

Two files. No dependencies beyond fasthttp. Clone it, run it, see your own numbers.


Full source: soyvural/fasthttp-vs-nethttp

Got different results on your machine? I'd love to see them in the comments.

Top comments (0)