Application Performance Series- Part 1- Where to start

This is part 1 of a multiple part series on web performance improvements. The Introductory blog can be found hereIn introductory post we discussed importance of software development keeping performance performance at center. In this part we will discuss which part affect web application performance the most? Where we can start the performance improvement activity to get maximum output?
Any web application performance improvement activity is a series of calculated tasks. We need to first identify where we can achieve the greatest improvements. There are three main places to consider:

  • Frontend
  • Backend
  • Databases

Though we can group the backend and databases in same group but just for simplicity I have grouped them separately. In case of web applications the performance is always measured with respect to user response time. Whatever performance improvement tasks we do should result in improved user response time. If not then we should re-visit our performance improvement strategy again. Due to many reasons, some of them given below, it is clear that first place to focus is frontend to drastically improve the performance of the web application.

  • First and foremost, generally, the time and resources required to implement the frontend changes is less as compared to others. Improving the backend performance may require change in architecture, code, data retrieval logic etc. These tasks may take longer time than expected.
  • If we could cut the backend response time by 40-60%, this will reduce the overall end user response time by 10-20%. But if we could improve the frontend performance by 40-60% this could result in reduced end user response time upto 40-50%. Many sites likes Google, MSN, Yahoo, Ask etc has proved this point.
Points mentioned in this blog will help us reduce end user response time significantly. But sometimes we may have to take more drastic steps and may reengineer the architecture to achieve the ultimate goal.

Following figure is a snap-shot of Y-slow recordings for a page in a website.

Figure: indicating a page request response flow
As we can observe only 10-20% of user response time is spend in downloading HTML document. Rest of 80-90% is spent downloading other parts/ components of the page. Generally the same story is repeated on all pages in this website. The same is true for most of the sites on web. The point is if we want to reduce the response times of web pages, we have to focus on the 80–90% of the end user experience. Where that 80–90% is spent on? How can it be reduced? How much of this time can be reduced?

In coming blogs we will go through a series of steps that will help us understanding the performance pitfalls and how to improve them.

0 Comments

Leave a Comment