Install

go get -u github.com/valyala/fasthttp

Switching from net/http to fasthttp

Unfortunately, fasthttp doesn't provide API identical to net/http.
See the FAQ for details.
There is net/http -> fasthttp handler converter,
but it is better to write fasthttp request handlers by hand in order to use
all of the fasthttp advantages (especially high performance :) ).

The RequestHandler
accepts only one argument - RequestCtx.
It contains all the functionality required for http request processing
and response writing. Below is an example of a simple request handler conversion
from net/http to fasthttp.

Fasthttp allows setting response headers and writing response body
in an arbitrary order. There is no 'headers first, then body' restriction
like in net/http. The following code is valid for fasthttp:

requestHandler := func(ctx *fasthttp.RequestCtx) {
// set some headers and status code first
ctx.SetContentType("foo/bar")
ctx.SetStatusCode(fasthttp.StatusOK)
// then write the first part of body
fmt.Fprintf(ctx, "this is the first part of body\n")
// then set more headers
ctx.Response.Header.Set("Foo-Bar", "baz")
// then write more body
fmt.Fprintf(ctx, "this is the second part of body\n")
// then override already written body
ctx.SetBody([]byte("this is completely new body contents"))
// then update status code
ctx.SetStatusCode(fasthttp.StatusNotFound)
// basically, anything may be updated many times before
// returning from RequestHandler.
//
// Unlike net/http fasthttp doesn't put response to the wire until
// returning from RequestHandler.
}

Fasthttp doesn't provide ServeMux,
but there are more powerful third-party routers and web frameworks
with fasthttp support:

VERY IMPORTANT! Fasthttp disallows holding references
to RequestCtx or to its'
members after returning from RequestHandler.
Otherwise data races are inevitable.
Carefully inspect all the net/http request handlers converted to fasthttp whether
they retain references to RequestCtx or to its' members after returning.
RequestCtx provides the following band aids for this case:

Call TimeoutError
before returning from RequestHandler if there are references to RequestCtx or to its' members.
See the example
for more details.

Use this brilliant tool - race detector -
for detecting and eliminating data races in your program. If you detected
data race related to fasthttp in your program, then there is high probability
you forgot calling TimeoutError
before returning from RequestHandler.

Blind switching from net/http to fasthttp won't give you performance boost.
While fasthttp is optimized for speed, its' performance may be easily saturated
by slow RequestHandler.
So profile and optimize your
code after switching to fasthttp. For instance, use quicktemplate
instead of html/template.

Avoid conversion between []byte and string, since this may result in memory
allocation+copy. Fasthttp API provides functions for both []byte and string -
use these functions instead of converting manually between []byte and string.
There are some exceptions - see this wiki page
for more details.

Verify your tests and production code under
race detector on a regular basis.

atreugo - Micro-framework to make simple the use of routing and middlewares.

FAQ

Why creating yet another http package instead of optimizing net/http?

Because net/http API limits many optimization opportunities.
For example:

net/http Request object lifetime isn't limited by request handler execution
time. So the server must create a new request object per each request instead
of reusing existing objects like fasthttp does.

net/http headers are stored in a map[string][]string. So the server
must parse all the headers, convert them from []byte to string and put
them into the map before calling user-provided request handler.
This all requires unnecessary memory allocations avoided by fasthttp.

net/http client API requires creating a new response object per each request.

Why fasthttp API is incompatible with net/http?

Because net/http API limits many optimization opportunities. See the answer
above for more details. Also certain net/http API parts are suboptimal
for use:

net/http should contain less bugs, since it is used and tested by much
wider audience.

net/http works on Go older than 1.5.

Why fasthttp API prefers returning []byte instead of string?

Because []byte to string conversion isn't free - it requires memory
allocation and copy. Feel free wrapping returned []byte result into
string() if you prefer working with strings instead of byte slices.
But be aware that this has non-zero overhead.