Optimizing a Page-Load Performance Profile
Applies To: Windows Server 2003, Windows Server 2003 with SP1
By optimizing page-load performance profiles, you can provide more efficient Web sites for your users. Begin by making sure that HTTP Keep-Alives are enabled, enabling HTTP compression if appropriate for your Web sites, and setting expiration dates on the files associated with your Web pages. Then identify your slow-loading files, reviewing them for unneeded file content. Next measure your file quantity and size. Finally, determine port usage and minimize unneeded screen refreshes. After reviewing all these factors and optimizing your Web sites, obtain a new page-load profile to determine whether the changes significantly improve the efficiency of your Web site.
For additional tips for optimizing your Web sites, see Best Practices for Creating Efficient Sites. For instructions telling how to obtain a page-load profile, see Obtaining a Page-Load Performance Profile.
Verify That HTTP Keep-Alives Are Enabled
Another item to verify is the connection = keep-alive state for each TCP connection. If keep-alive connections are turned off, every file requires a new TCP connection. For small files, enabling HTTP Keep-Alives in IIS effectively doubles the number of roundtrips. For more information about HTTP Keep-Alives, see Enabling HTTP Keep-Alives to Keep Connections Open.
Set HTTP Compression
If you have Web sites that use large amounts of bandwidth, consider enabling HTTP compression to obtain faster transmission times between your server and compression-enabled browsers. The performance cost of compressing a static file is small and is typically incurred only once because the compressed file is stored in a compression cache.
The cost of expanding the file at the browser is minimal. Compressed files download faster, which makes them especially beneficial to the performance of any browser that uses a network connection with restricted bandwidth, such as a modem connection.
For more information about enabling HTTP compression, see Using HTTP Compression for Faster Downloads.
Set Expiration Dates on Files
A common performance mistake is forgetting to set the expiration dates on the files associated with Web pages. When a user returns to a Web page, Internet Explorer already has most of the files for the page in its cache, but it does not use these files if the expiration dates are in the past. Instead, Internet Explorer sends a GET request to the server for the file, indicating the date of the file in the cache. If the file has not changed, the server sends a Not Modified message. This GET/Not-Modified sequence costs the client a roundtrip. For small files of 3 KB or less, this roundtrip is as expensive as getting the original file.
For more information about setting expiration dates, see Using Content Expiration.
Identify Slow-Loading Files
Identifying which files are taking the longest to load often provides the best clues about what you need to improve. Causes of very long load times can include server capacity issues, network congestion, and large file content. Use the data that you collect from Network Monitor captures to identify how long each file takes to load. Visit a Web page several times and observe which files are regularly loaded most slowly. Multiple visits to a page help improve statistical veracity.
Remove Unneeded File Content
Files often contain clutter, such as tabs, spaces, new lines, and comments, which consumes up to 15 percent or more of a page. For production Web sites that are visited by millions of users, remove every bit of file content that is not absolutely necessary for the rendering of the page.
View the packet contents of your files with Network Monitor. Look for repetitive text such as <Option Value = data> statements that are used to insert text into drop-down lists. It takes much less space to add a few lines of code that sends an array (that reads the drop-down lists) to the client.
Measure File Quantity and Size
The number and size of files that you load on your Web site have a large impact on page-load times. Fewer large files load faster than many small files, as follows:
Number of files. For each file, HTTP must perform a GET-File. Each GET-File is at least a single roundtrip. If the files are on a new server that the user has not previously connected to, HTTP must also make another roundtrip to create a new connection. Roundtrips across a modem cost 250 milliseconds or more.
The optimal minimum number of files for a Web site is about four. Consider consolidating like files; for example, have only one .js or .css file instead of two or three.
Size of files. The TCP slow-start algorithm favors larger files. When a new connection is first opened, TCP sends a small number of packets in response to a GET-File. Thereafter, for each acknowledgement received by the server, TCP increases the number of response packets sent to the client.
Small files of 3 KB or less are complete in one roundtrip. Files larger than 20 KB receive only about 16 KB of data per roundtrip. The size of a file can make the difference between a very small bit rate of 1 to 10 kilobits per second (Kbps) and a high bit rate of 40 to hundreds of Kbps.
Determine Your Port Usage
Using HTTP 1.1, Internet Explorer can open a maximum of two ports to any one server and a maximum of four ports total. The best performance occurs when four ports are opened and are kept open to be reused by all the files. Reusing a port is a good thing; when TCP slow-start increases the window size for a file, the next file that uses the same port can also use the increased window size.
View your Network Monitor capture summary to determine how many ports were used during your page-load tests, and by which files. Keep in mind that measuring Web pages through a proxy server hides the true number of ports being used. The best tests from your office are conducted by using a direct connection to the Internet without a proxy.
Control Screen Refreshes
In a refresh request, Internet Explorer (the client) tells the server the date stamp of the version of a file that it has in its cache by using the If-Modified-Since header. IIS 6.0 then determines whether the file has been modified since that time. If the file is unmodified, IIS 6.0 replies with a brief Not Modified response.
In routine file updates for your Web site, do not copy files that have not been modified. A static HTML page is not retrieved during a screen refresh if it has not been updated. Some publication processes copy files that have not been modified, which gives the files new time stamps and thus updates them as far as the system is concerned. These files are downloaded even though they are actually unchanged. When you set up your publication process, make every effort to avoid this waste of resources.