Oh my god, really? Doing server side processing means that nothing is being sent until said processing is over? What have I been doing with my life?!

Seriously, stop posting and upvoting these stupid as hell blog posts, install Varnish or load your content with AJAX. And most importantly, don't put your real name on posts like these.

Thank you for being the hero that this thread needs. You're absolutely right, and your tone and bluntness is completely appropriate for the quality of this post.

Putting a cache in front is not a solution to all performance problems!

I disagree with the general tone here. The fact is that relatively unsophisticated frameworks often perform better from a UX point of view because of this very reason.

I know I'm over-generalizing here, but most PHP apps can print a the website's headers and navigation and send those to the browser before it starts doing the heavy lifting. The reason? Basically because they are just a smart template, and the logic is in the view.

Java JSP's are actually the same. Very often you can see a jsp powered site print the website headers and CSS so that the browser can be rendering while the server is still working.

The problem with most MVC frameworks is that their interface looks like HTTPResponse process(HTTPRequest), which doesn't imply but pretty strongly suggests that the server isn't going to send any data back until the request is finished processing. Generators provide an API that theoretically gets around this limitation, but in reality would require massive amounts of coding in order to make all the iterators involved lazy.

So using some dumb, non mvc frameworks, it's easy to get a shorter time-to-first-byte. With a fancy MVC framework, it's pretty difficult and involves lots of lazy loading (to delay the processing associated with database requests).

So yes, MVC as implemented by most of the web, might be slowing down your site, and despite the relative sophistication of the HN crowd, it's not a problem that most front-end devs have on their radar.

Well said. Pages that start with the view like PHP and JSP fare better than most dumb MVC frameworks.

This doesn't seem to have much to do with MVC. Assuming that the beginning of the requested page can be returned while more processing is ongoing, it seems like a controller method would be a good place to do this.

It might be interesting to try something like this with a generator, so that "for response in process_request(request): send_response_to_client(response)" would work.

As others have already pointed out, that has nothing to do with MVC, but is more a result of how template engines usually work.

E.g. in Rails, by default, due to the fact that you can have views provide content for your layout (using content_for), it has not been possible to start sending your rendered HTML before the rendering was completely finished.

There is an experimental Fiber based solution in Rails Core, that shipped with 3.2, that kind of fixes that issue, but only to a certain degree (see http://api.rubyonrails.org/classes/ActionController/Streamin...).

"The problem here is not with MVC per se, but how it is commonly implemented."

So why give it a linkbait-style title?

> "The problem here is not with MVC per se..."

Even the article admits this isn't necessarily an MVC problem.

This has nothing to do with MVC.

This has nothing to do with MVC, ABC, <put your architecture here>. You should eliminate the initial browser blank state, optimise the TTFB and your start render time, number of resources <23+4 Steve Sauders optimisation techniques>. Twitter found Time To First Tweet as an important KPI, and it caused them to build a mixed deliver architecture (server-side and client-side, http://engineering.twitter.com/2012/05/improving-performance...)

Hm, what if there is an error in processing and you've already sent the "HTTP/1.1 200 OK" and started streaming output? You're better off utilizing caching and other optimization based on profiling.

By definition a browser can't see what's happening on the server side. There's a lot of things that can block loading (io, database, network ...). Pointing the finger at an architectural pattern using data collected via a browser extension is pure speculation.

What you can infer from such testing is that the server is not writing any response for a while, and then quickly writing all the response. There could be two reasons - the server may be busy doing some blocking activity, or the server or some intermediary is buffering all the response in memory and emitting it when the complete response is available. Experience tells me that it is usually the former. I'm the author of this post.

most developers don't understand the concept of I/O. The I/O speed is really important in terms of TTFB. Most websites are hosted on SATA drives which have poor IO speed. Even if they are on RAID-10. The speed of CPU doesn't really matter here, unless your app does heavy CPU processing. To speed up TTFB, only thing you can do is to cache/cache/cache, and possibly having a varnish in front of your web apps. Also you'll see substantial boost in TTFB times if you switch over to something like RAID-10 SAS, and even more so if you switch to the newer drives like the SSD. I've seen Magento stores go from several seconds per load to almost varnish-cache level when placed on PCI-Express SSDs.

This has nothi...

Oh, everyone else already covered it.