Performance Bottlenecks
The speed at which your page loads depends on many factors. The browser performs this sequence, after requesting the file(s) from the server:
- Wait for the file(s) to get back from the server
- Render the HTML
- Render the images
- Run the scripts
- Obtain XHR data after the page is loaded
First, the browser requests all necessary files from the server. This includes the web page HTML file itself, and may include additional files such as images, scripts, and style sheets.
At any point, bottlenecks may occur.
Getting the files
The time it takes for files to get from the server to the browser consist of two components:
- Latency: The time it takes for data to start transferring from the server to the browser.
- Transfer time: The time between the start of data transfer and the completion of data transfer.
In general, for smaller files, latency accounts for more delay than transfer time. For larger files, the opposite is true. Obviously, the best situation is to transfer just one small file, and the worst situation is to transfer many large files. But given a choice between transferring a few large files or many small files, which is better? This also depends on many things.
- If the network connection is slow, transfer time will be longer.
- If the server is overloaded, both latency and transfer time will be longer.
- For larger files, transfer time will be longer.
- For many files, latency adds up quickly.
I did some informal tests and found that some popular web sites require the transfer of well over 100 files. Typical numbers were around 5 JavaScript files, 10 CSS files, and 80 image files. In general, transfer time was correlated with file size, and latency was longer in these situations:
- For image files in particular.
- When transferring a lot of small files.
- For almost all files after the first 10 or so.
This could mean several things. First, it could mean that images are stored on a secondary server that may not be as fast as the main server. The sites I tested are known for hosting images on a separate site. Whether the separate site is less capable, I cannot say, but it looked like the images had a much longer latency.
This could also mean that not all 100 files found on one of these typical pages can be transferred at once. Many operating systems and many servers limit the number of simultaneous file transfers. If there is a limitation (on either end) of 10 simultaneous file transfers, then when transferring 100 files, the first 10 files will come pretty quickly, and subsequent files will have to wait until more network connections become available.
In general, latency accounted for about 90 percent of the delay, and transfer time only about 10 percent. A typical number was a three-second latency followed by a 300-millisecond transfer time.
One strategy for decreasing latency is to reduce the number of files that have to be transmitted. This can be done by combining CSS files and making images into sprites that are combined in one or a few files. Of course, combining many files into a few huge files could increase the file transfer time, but this seems to be less a factor than latency.
(This site uses image sprites for the four small icons: Facebook, Twitter, Pinterest, and Menu. This did speed up the site. The Icons page and the Books page still have a little slowdown due to the many images.
Rendering and Running Scripts
Rendering the HTML and images and running scripts are activities that occur in the browser, and their speed depends on the capabilities of the client computer, operating system, and browser. It is hard for a web site developer to have control over any of those factors. But a web site can be friendly to less-capable browsers by being as simple as possible, by using as few files as possible, by using the smallest files possible, and by using the fewest scripts possible.
XHR After the Page Loads
XHR stands for xmlHttpRequest, which is more commonly known as AJAX (asynchronous JavaScript and XML). These are scripts that execute after a page loads, initiating more data transfers between the browser and the server. XHR was initially intended to improve web page performance by deferring non-essential data transfers until after the page loads, then performing those additional data transfers in the background as the user peruses the page. But XHR has turned into a mechanism for delivering ads, enabling consumer tracking, and enabling social media. A recent study showed that the typical social media “snippet” placed on a web page can cause a four-second delay on that page. On a page that has four social media references (e.g. Facebook, Twitter, Tumblr, and Pinterest) this could cause a 16-second delay. And I’m sure you have seen web pages that are all but useless until all the ads have loaded (for whatever reason, because this is all supposed to happen in the background).
The best ways to improve the performance of XHR are to use XHR only for its intended purpose, and to limit or eliminate its use for these other purposes:
- Social media snippets
- Ad delivery
- User tracking
- Site analytics