Most of you are aware that one of the biggest problems while
developing mobile apps / websites, is the reduced bandwidth / connectivity
that the user has on his phone compared to traditional devices
connected to a solid WiFi or via cable.

How can you actually improve connectivity to the app? There are tricks to
improve performances, like transparent redirects.

An heavy stack

The stack on which your web apps will run will be heavy, by definition:
HTTP wasn’t built with performances in mind1, and you might
want to add SSL, to provide your users with an additional security layer,
on top of that.

Now imagine your users requesting GET /my-page and you serving a redirect:

In this way the client already has all the information it needs in
order to show the user the data he requested.

Even better: if you are serving contents from an API you can have your main
application handle the transparent redirect with the history.pushState(...)
API of HTML5.

Current implemetation

At the moment you will have to be cautious with it, as current browsers (or, at least,
a few of them) treat non 2XX status codes as errors, thing that becomes tricky when you
handle things with JS callbacks / promises:

1234

http.get(..., onSuccess, onError)
// the browser will call onError if the response status code is
// different than 2XX

I remember banging our heads over our desks here at the Namshi
office, so we decided to use a very simple approach, using custom headers with a 200 Ok:
if the response ends up in a redirect, we use 2 custom headers (N-Status-Code and N-Location),
intercept the response in our frontends and do our trick with #pushState(...).

Future considerations

It would be nice if, one day, the HTTP spec would be able to incorporate this
behavior natively, with a status code like 308 Transparent redirect, so that browser will be able to
automatically update the state of the apps and the user wouldn’t need to wait for another roundtrip
connection to see the data they have been requesting, no matter the location.

Notes

We’re talking about raw performances, scalability is another matter, which is implemented almost flawlessy in the protocol ↩