HTTP caching allows these resources to be saved, or cached, by a browser or proxy. Once a resource is cached, a browser or proxy can refer to the locally cached copy instead of having to download it again on subsequent visits to the web page. Thus caching is a double win: you reduce round-trip time by eliminating numerous HTTP requests for the required resources, and you substantially reduce the total payload size of the responses. Besides leading to a dramatic reduction in page load time for subsequent user visits, enabling caching can also significantly reduce the bandwidth and hosting costs for your site.
Leverage browser caching - Setting an expiry date or a maximum age in the HTTP headers for static resources allows the browser to load previously downloaded resources from local disk rather than over the network.
Leverage proxy caching - Enabling public caching in the HTTP headers for static resources allows the browser to download resources from a nearby proxy server rather than from a remoter origin server.
Round-trip time (RTT) is the time it takes for a client to send a request and the server to send a response over the network, not including the time required for data transfer. That is, it includes the back-and-forth time on the wire, but excludes the time to fully download the transferred bytes (and is therefore unrelated to bandwidth). For example, for a browser to initiate a first-time connection with a web server, it must incur a minimum of 3 RTTs: 1 RTT for DNS name resolution; 1 RTT for TCP connection setup; and 1 RTT for the HTTP request and first byte of the HTTP response. Many web pages require dozens of RTTs.
Every time a client sends an HTTP request, it has to send all associated cookies that have been set for that domain and path along with it. Most users have asymmetric Internet connections: upload-to-download bandwidth ratios are commonly in the range of 1:4 to 1:20. This means that a 500-byte HTTP header request could take the equivalent time to upload as 10 KB of HTTP response data takes to download. The factor is actually even higher because HTTP request headers are sent uncompressed. In other words, for requests for small objects (say, less than 10 KB, the typical size of a compressed image), the data sent in a request header can account for the majority of the response time.
The amount of data sent in each server response can add significant latency to your application, especially in areas where bandwidth is constrained. In addition to the network cost of the actual bytes transmitted, there is also a penalty incurred for crossing an IP packet boundary. (The maximum packet size, or Maximum Transmission Unit (MTU), is 1500 bytes on an Ethernet network, but varies on other types of networks.) Unfortunately, since it's difficult to know which bytes will cross a packet boundary, the best practice is to simply reduce the number of packets your server transmits, and strive to keep them under 1500 bytes wherever possible.
Optimize images - Properly formatting, sizing, and losslessly compressing images can save many bytes of data.
Serve resources from a consistent URL - It's important to serve a resource from a unique URL, to eliminate duplicate download bytes and additional RTTs.
Use efficient CSS selectors - Avoiding inefficient key selectors that match large numbers of elements can speed up page rendering.
Avoid CSS expressions - CSS expressions degrade rendering performance; replacing them with alternatives will improve browser rendering for IE users. This best practices in this section apply only to Internet Explorer 5 through 7, which support CSS expressions.
Put CSS in the document head - Moving inline style blocks and <link> elements from the document body to the document head improves rendering performance.
Specify image dimensions - Specifying a width and height for all images allows for faster rendering by eliminating the need for unnecessary reflows and repaints.