Front End vs. Back End
Following the topic in my previous post and Steve Thair ‘s comment as well as Steve Thair ‘s related post, I want to reiterate the front end vs. back end discussion.
Steve Souders in his recent interview said: For years when developers started focusing on the performance of their websites, they would start on the back end, optimizing C++ code or database queries. Then we discovered that about 10% or 20% of the overall page load time was spent on the back end. So if you cut that in half, you only improve things 5%, maybe 10%. In many cases, you can reduce the back end time to zero and most users won’t notice. So really, improvement comes from the time spent on the front end, on the network transferring resources and in the browser pulling in those resources.
Well, if we see that “about 10% or 20% of the overall page load time was spent on the back end” under the maximal load, this statement is a great example of applying performance engineering to the problem analysis. It is definitely the first thing to do investigating any performance issue – find where time is spent. And, considering popularity of WPO, it is probably the case for most modern websites with rich web interface and no need of transactional processing behind the scene. But it is usually not the case for sophisticated business applications working with transactional data (although I even doubt that it is exactly the case for the moment you click on “confirm order” button when you buy something on the Internet).
But one important thing I’d like to stress is that back end should handle multiple users while on the client side we always have single user (it perhaps may somewhat change in the future with multiple browser tabs and parallel JavaScripts doing something all the time, but we probably may ignore this for the moment). And for a single-user performance issue you, generally speaking, run a profiler, find where the time is spend, and then need to figure out why and how it should be changed.
For back end you have multi-user load and back-end performance problems observable with a single user are somewhat trivial (see above about profiler, etc.). But many performance issues may be observed only under [heavy] load. So you get one more level of sophistication on the top: you need to simulate load and you need to find a way to debug / profile under load (and most tools bring too much overhead to be used in this situation, plus issues may be related to timing and attempts to look inside may change the behavior of the system). Plus you get system resources limitations on the top of multi-user software problems (such as synchronization issues, running out software objects, etc.) introducing non-linear effects (it is where you get to capacity management, queuing theory, etc.). All these introduce a high probability that back end performance will degrade drastically with load (if not properly tested and configured), while the time spent on the client side for rendering and client side processing would remain the same in most cases (although affected by server response timing). It was the primary reason why almost all attention was used to be paid to the back end.
I think front/back end web focus is a lot like client/server from before the web basically became the client. There are a lot of different things you need to think about and plan for in both of them and the best professionals understand both sides (and everything in between).
On the front-end side you have to worry about your code running in a hostile environment on multiple different platforms (OS and browser) that all have different behaviors and with wildly varying networking characteristics. It usually comes down to measuring what you can and gathering as much information as possible from real users in the field so that you can faithfully reproduce the conditions to do your profiling (getting the ever elusive “failcase”). Very much like building desktop software, just without the hassles of providing updates.
As more and more 3rd-party widgets come into play it becomes even more difficult since they are usually served from back-ends that you don’t control but you still need to understand their performance characteristics, the impact on your product and figure out how to mitigate any potential issues caused by the 3rd-party code when they do have problems so they don’t take down you along with them.
The best engineers I have worked with understand (or designed) the full end-to-end system and can just as easily debug field issues, networking/load balancing issues and back-end scaling/performance issues. That’s one reason Velocity’s focus spans dev (front and back-end) as well as ops (though, admittedly it is very focused on the web and not all-things performance).
WPO to me is interesting, but questionable in the context of APIs being the king of the cloud these days. With over 70/80% of the content being accessed over API’s for high volume sites like Twitter (even if it’s a jQuery page that loads and starts making RESTful calls to the same origin server) page-load-speed presents an interesting, but only-half-of-the-problem dimension. We recently launched http://blitz.io to handle the back-end half of the problem. We are finding that concurrency is a *hard* problem that most people don’t even think about or don’t know about, but then struggle with after they deploy.
So I do think WPO is useful, but is only half the battle.
I think front end part is all about rendering,if you are doing processing in the front end,then there are whole lot of things to take care in general internet and this slows down the application very much even for the single user depending on how you design your JS/CSS /other stuffs and this rule applies even for mobile apps.
Back end is all is what you have mentioned and I am with you.Steve I feel is talking more on the rendering side and what it takes for the front end to display resource quickly to end user.
Whatever it is ,browsers in real sense never do parallel processing,there is always thread which gets queued up and still jobs are executed in the sequential manner.I dont really feel front end processing should take more than 5% of overall performance.
@Kiran – The “front-end” actually take 80-90% of the time for the user experience for most sites on the web. The lines get a little fuzzy with multiple API cals, etc but for the vast majority of sites the back-end generates the base page html and then the front-end is the fetching of all of the referenced content, executing javascript and 3rd-party widgets.
It’s the disconnect between the 5% expectation and 80-90% reality that largely started the front-end optimization efforts over the last 3-4 years.
To see for yourself, just go over to webpagetest.org and run you favorite sites/pages through the testing and see how it breaks down. The first request in the waterfall is usually the back-end wile the remaining requests make up the front-end.
As with all optimization efforts, it’s important to measure first and then start working on it (there are a good number of sites that have poor back-end performance as well). There are also different approaches when you are working on the steady-state performance and when you need to work on the scalability of a site.
Patrick, I am all for front end opimization and I am aware that most sites which operates in the web do take considerable amount of time to render,but again I am also aware that most of these sites are not tested for various reasons and that could be the possible reason as why we see high response time for those sites.
I am a big fan of pagetest and yslow , the problem what I have seen is that with front end optimization is that there isnt any kind of guidance or benchmarks available to compare and this makes the job really hard.The way we code the front end stuff like JS/CSS etc further complicate the things since coding rendering time depends on the code.Atleast this is what I understand from the way webkit works and renders.