Your MVC may be Slowing Down Your Site

One of most common design patterns used on the Web is the model-view-controller. Though some variations of this pattern exist, the basic idea is simple – a controller parses and processes the incoming HTTP request, thinks for a while, and then writes a view as HTTP response.

The point of this post is not to blame MVC, but to point out that implementations in web frameworks may be leading to higher time to first byte times.

But did you know that, this style, as commonly implemented, may be slowing down your site? See the waterfall charts below for some of the Alexa's top 500 sites in US, captured using webpagetest over the DSL network profile with Firefox.

When you look from the network perspective, all these charts share a common pattern – deafening silence, followed by a log jam.

The network is silent when the server is thinking (the green area). As soon as response starts to trickle down (the blue area), the browser starts new network activity and immediately gets into a log jam mode. In this mode, the browser is busy making DNS look ups, TCP handshakes, followed by several HTTP requests over a limited number of connections.

From a user experience point of view, this is bad as it leads to a rapid backlog of HTTP requests. As the number of connections is limited, it takes a while for this log jam to clear up which increases the overall page latency. A protocol like SPDY can deal with the log jam better, but reducing the jam is better for the user.

The problem here is not with MVC per se, but how it is commonly implemented. Most often, the thinking part consists of talking to back-end systems and/or some computation completely blocking response generation. Even in implementations that do some of this thinking asynchronously, view rendering ofter starts after the thinking part is done. This contributes to higher "time to first byte" times and the subsequent log jam.

Below is a waterfall chart of a site that minimizes this log jam.

In this case, the server is starting HTML delivery as soon possible so that the browser can start to download some of those resources sooner. The HTML delivery continues even after some of the subsequent resources complete. This is possible by interleaving HTML delivery with backend work and stream chunks of response as they become ready.

Though such sooner delivery does not completely avoid the log jam, it does help ease it.

If you do MVC, don’t forget to think from the network point of view.

Update: See the Hacker News thread for more comments: http://news.ycombinator.com/item?id=4194500