Web pages are almost always a combination of files, including the initial HTML, Cascading Style Sheet (CSS) files, JavaScript files and images. As of March 2014, the average number of requests per page is 93 summing 1700 KB, according to the HTTP Archive. When your browser requests to see a web page, if it doesn’t have any of the page objects in cache, it must make 93 separate requests and download 1700 KB of data, on average, to display.
In the How to Compare Hosting Companies’ Speed & Reliability article, on the SYS-CON Media site, the best web hosting review method is explained. It’s speed and uptime, over time. In a nutshell:
The GoDaddy Web Hosting Performance team is the group within GoDaddy that is responsible for tuning our web hosting environment for peak performance. In order to do so, we measure the response time of a control page loaded on every one of our web servers, every 5 minutes. An Application Index (APDEX) score is calculated for every server, which rolls up to product location, to product to product group. The Hosting Operations Center team has a prioritized list of servers to investigate if a performance issue arises. The company has great situational awareness of the performance levels of its products and services.
Every server has a “control site” that we use for performance monitoring. The control site is a WordPress page on Linux and a DotNetNuke page on Windows. A headless browser simulates a full page load of the control site on a regular basis. Time to first byte and full page load times, and many other interesting metrics, are pushed into graphite.
From the graphite API, an APDEX score is calculated on every server. Listed in table format, sorted by APDEX, the Web Hosting Operations Center team has a prioritized list of servers, updated frequently.
Continue reading
Once in awhile, your site visitors wait for a cold cache DNS lookup time. The more popular your site, the less likely this is, and visa versa.
It’s hard to notice, because it only happens on first load per visitor per shared DNS resolver. When you experience it on your own site, the common reaction is to hit refresh and see if it happens again. And it doesn’t, so you scratch it up to ‘whatever.’ But is an extra [up to 1] second of page load time really what you want for your first impression? This article is about squeezing in one more performance enhancement by reducing the likelihood of visitors needing to wait for a full cold start DNS lookup.
If you’re running a Windows .NET web app, like DotNetNuke, it must be compiled by IIS before serving it up. When a page request comes in, IIS checks to see if the compiled bytecode is loaded in the iis application pool. If so, it uses it and if not, it loads all files and compiles them, puts them into the iis application pool, then serves the page.
We refer to this “wait while I compile the site before serving up the page” page load as the “cold start” page load. This can add 1-10 seconds of page response time, depending on how complex the .NET app is, the amount of disk i/o required, and how busy the web server is (i.e. available CPU) at the time of compile.
This article is meant to provide a tip to website performance enthusiasts for keeping their sites warm and reducing the likelihood of site visitors waiting for the “cold start” page load.
