ruptive to the user. The best answer is to avoid including stylesheets lower in the page, and instead load them in the HEAD of the document.
Rule 6: Put scripts at the Bottom External scripts (typically, “.js” files) have a bigger impact on performance than other resources for two reasons. First, once a browser starts do wnloading a script it won’t start any other parallel downloads. Second, the browser won’t render any elements below a script until the script has finished downloading. Both of these impacts are felt when scripts are placed near the top of the page, such as in the HEAD section. Other resources in the page (such as images) are delayed from being downloaded and elements in the page that already exist (such as the HTML text in the document itself) aren’t displayed until the earlier scripts are done. Moving scripts lower in the page avoids these problems.
Rule 7: avoid css expressions CSS expressions are a way to set CSS properties dynamically in Internet Explorer. They enable setting a style’s property based on the result of executing JavaScript code embedded within the style declaration. The issue with CSS expressions is that they are evaluated more frequently than one might expect—potentially thousands of times during a single page load. If the JavaScript code is inefficient it can cause the page to load more slowly.
JavaScript can be added to a page as an inline script:
<script type=”text/javascript”> var foo=”bar”;
</script> or as an external script:
<script src=”foo.js” type=”text/ javascript”></script>
Similarly, CSS is included as either an inline style block or an external stylesheet. Which is better from a performance perspective?
HTML documents typically are not cached because their content is constantly changing. JavaScript and CSS are less dynamic, often not changing for weeks or months. Inlining JavaScript and CSS results in the same bytes (that haven’t changed) being downloaded
on every page view. This has a negative impact on response times and increases the bandwidth used from your data center. For most Web sites, it’s better to serve JavaScript and CSS via external files, while making them cacheable with a far future Expires header as explained in Rule 3.
Rule 9: Reduce Dns Lookups The Domain Name System (DNS) is like a phone book: it maps a hostname to an IP address. Hostnames are easier for humans to understand, but the IP address is what browsers need to establish a connection to the Web server. Every hostname that’s used in a Web page must be resolved using DNS. These DNS lookups carry a cost; they can take 20–100 milliseconds each. Therefore, it’s best to reduce the number of unique hostnames used in a Web page.
Rule 10: minify Javascript As described in Rule 4, compression is the best way to reduce the size of text files transferred over the Internet. The size of JavaScript can be further reduced by minifying the code. Minification is the process of stripping unneeded characters (comments, tabs, new lines, extra white space, and so on) from the code. Minification typically reduces the size of JavaScript by 20%. External scripts should be minified, but inline scripts also benefit from this size reduction.
Rule 11: avoid Redirects Redirects are used to map users from one URL to another. They’re easy to implement and useful when the true URL is too long or complicated for users to remember, or if a URL has changed. The downside is that redirects insert an extra HTTP roundtrip between the user and her content. In many cases, redirects can be avoided with some additional work. If a redirect is truly necessary, make sure to issue it with a far future Expires header (see Rule 3), so that on future visits the user can avoid this delay. b
Rule 12: Remove Duplicate scripts If an external script is included multiple times in a page, the browser has to parse and execute the same code mul-
b Caching redirects is not supported in some browsers.
tiple times. In some cases the browser will request the file multiple times. This is inefficient and causes the page to load more slowly. This obvious mistake would seem uncommon, but in a review of U. S. Web sites it could be found in two of the top 10 sites. Web sites that have a large number of scripts and a large number of developers are most likely to suffer from this problem.
Entity tags (ETags) are a mechanism used by Web clients and servers to verify that a cached resource is valid. In other words, does the resource (image, script, stylesheet, among others) in the browser’s cache match the one on the server? If so, rather than transmitting the entire file (again), the server simply returns a 304 Not Modified status telling the browser to use its locally cached copy. In HTTP/1.0, validity checks were based on a resource’s Last-Modified date: if the date of the cached file matched the file on the server, then the validation succeeded. ETags were introduced in HTTP/1.1 to allow for validation schemes based on other information, such as version number and checksum.
ETags don’t come without a cost. They add extra headers to HTTP requests and responses. The default ETag syntax used in Apache and IIS makes it likely that the validation will erroneously fail if the Web site is hosted on multiple servers. These costs impact performance, making pages slower and increasing the load on Web servers. This is an unnecessary loss of performance, because most Web sites don’t take advantage of the advanced features of ETags, relying instead on the Last-Modified date as the means of validation. By default, ETags are enabled in popular Web servers (including Apache and IIS). If your Web site doesn’t utilize ETags, it’s best to turn them off in your Web server. In Apache, this is done by simply adding “FileETag none” to your configuration file.
Rule 14: make ajax cacheable Many popular Web sites are moving to Web 2.0 and have begun incorporating Ajax. Ajax requests involve fetching data that is often dynamic, personalized, or both. In the Web 1.0 world, this data is served by the user going to a specified URL and getting back an HTML docu-
References:
Archives