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
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
the page to load more slowly.
and css external
or as an external script:
<script src=”foo.js” type=”text/
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
are less dynamic, often not changing for
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
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.
As described in Rule 4, compression is
the best way to reduce the size of text
files transferred over the Internet. The
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
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
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.
Rule 13: configure etags
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
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-