Although 80% of web performance problems are typically due to front-end issues (Souders 2009), back-end bottlenecks can slow your site down to a crawl. One thing to watch out for is when static pages load relatively quickly, while dynamic pages load slowly. This article shows what to look for when a server slows down a web site.
Web site response time is made up of a myriad of factors, including network responsiveness, server response time and load, content size and composition, and client side delays (AJAX, etc.). For optimum web site performance all of these factors should be optimized. For most sites, optimizing the content delivered (and perhaps the hosting) is enough to satisfy users (i.e., combining files, optimizing multimedia, properly caching and compressing files, minifying and trimming, converting to CSS behavior, etc.). However, some sites need more than content optimization, they need server optimization. One possible indicator of a slow server is to look for a slow Time to First Byte (see Figure 1).
The Time to First Byte is the amount of time it takes after the client sends an HTTP GET request to receive the first byte of the requested resource from the server. Time to First Byte as WebPageTest.org defines is it the time it takes for the browser to wait for the first byte of a requested resource to be received after the DNS lookup and connection time. Some definitions lump DNS, connection and waiting into the TTFB metric. So TTFB represents the amount of time it takes for the server to respond and build the web page.
Figure 1 shows a 3 second time to first byte time over a DSL connection (a search query result page). This is an unusually long delay, normally TTFB is in the range of 0.1 to 0.5 seconds. Users perceive that your web page is slow if you have a slow Time to First Byte, because the start render time will be delayed. This is a form of feedback that users key off of that is routinely measured in website performance studies. A more typical time to first byte is shown for CNN.com in Figure 2. Note that CNN.com uses one minified CSS file followed by one minified JavaScript file.
Web page delay can come from any number of sources. The four metrics at issue here are DNS lookup time (the time to look up the IP address of the domain in question), connection time (the time it takes to set up the TCP connection), wait time (the time it takes to receive the first byte after the connection has been setup (i.e., time to first byte)), and the content download time (the time it takes to download the object). Figures 3 and 4 show the distribution of these four components for 290 top sites tested from a remote connection (Habib & Abrams 2000).
Surprisingly, the Time to First Byte is the largest web page load time component taking 40 to 60% of total web page latency. Overall, Habib and Abrams found that DNS lookup time takes from 10-20%, connection setup time from 20-30%, time to get the first byte takes from 40 to 60%, and content downloading time takes from 10 to 20% of the total page load time. DNS time was signifant in international web sites, and decreased significantly (90+%) on cached resources.
Once you know you've got a server performance issue, how do you know what to fix? Here are some server performance issues that may be slowing down your server.
You can use the time to first byte metric to help diagnose a slow web server. Studies have shown that time to first byte can dominate web page latency. This article showed an example of slow time to first byte, and some possible causes of slow web server response times.
By website optimization on 10 Dec 2011 PM
Increased speeds by 30-90% with our analysis and optimization services.
Increase conversions with adaptive multivariate testing to squeeze more leads out of your exiating traffic. Quickly boost your ROI.
Improve your site's look, usability and accessibility for a more credible and successful website.
