I like my HTTP package to actually speak as good an approximation of HTTP as it can, so fasthttp wouldn't be my first option.

Furthermore, the HTTP stack doesn't show up on most web servers' profiles. net/http is better understood by the community, interoperates with libraries better (e.g. golang.org/x/oauth2), and is better supported.

Use net/http.

The main issue with net/http is that it generates a lot of garbage which is definitely going to show up in your profile if you're handling a lot of requests per second.

Allocation pressure imposed by net/http has never been a top K source of profile CPU burn in any service I’ve ever written, and I’ve written plenty of high-performance, high-QPS services. fasthttp is rarely if ever a good idea.

This is terrible advice for something serving broadly to consumers.

Fasthttp is great if you can limit your interactions to a minor testable subset of calls but otherwise its not suitable.

First off, the author of fasthttp has made some great packages that I do use in production.

However, last time I looked fasthttp was great if you don't care about http2 support or streaming bodies. Unfortunately I do.

IIRC, fasthttp only supports a subset of HTTP. This may or may not be a deal-breaker for some people.

It serves everything that is required for an ad-server.