Best practices for making web pages fast. The list includes 22 best practices.
Minimize HTTP Requests
Combined files are a way to reduce the number of HTTP requests by combining all scripts into a single script, and similarly combining all CSS into a single stylesheet. Combining files is more challenging when the scripts and stylesheets vary from page to page, but making this part of your release process improves response times.
The time it takes to transfer an HTTP request and response across the network can be significantly reduced by decisions made by front-end engineers. It's true that the end-user's bandwidth speed, Internet service provider, proximity to peering exchange points, etc. are beyond the control of the development team. But there are other variables that affect response times. Compression reduces response times by reducing the size of the HTTP response. Starting with HTTP/1.1, web clients indicate support for compression with the Accept-Encoding header in the HTTP request.
Gzipping generally reduces the response size by about 70%. Approximately 90% of today's Internet traffic travels through browsers that claim to support gzip. If you use Apache, the module configuring gzip depends on your version: Apache 1.3 uses mod_gzip while Apache 2.x uses mod_deflate.
Gzipping as many file types as possible is an easy way to reduce page weight and accelerate the user experience.
Front-end engineers that care about performance want a page to load progressively; that is, we want the browser to display whatever content it has as soon as possible. This is especially important for pages with a lot of content and for users on slower Internet connections. The importance of giving users visual feedback, such as progress indicators, has been well researched and documented. In our case the HTML page is the progress indicator! When the browser loads the page progressively the header, the navigation bar, the logo at the top, etc. all serve as visual feedback for the user who is waiting for the page. This improves the overall user experience.
In some situations it's not easy to move scripts to the bottom. If, for example, the script uses document.write to insert part of the page's content, it can't be moved lower in the page. There might also be scoping issues. In many cases, there are ways to workaround these situations.
The key factor, then, is the frequency with which external JavaScript and CSS components are cached relative to the number of HTML documents requested. This factor, although difficult to quantify, can be gauged using various metrics. If users on your site have multiple page views per session and many of your pages re-use the same scripts and stylesheets, there is a greater potential benefit from cached external files.
Entity tags (ETags) are a mechanism that web servers and browsers use to determine whether the component in the browser's cache matches the one on the origin server. (An "entity" is another word a "component": images, scripts, stylesheets, etc.) ETags were added to provide a mechanism for validating entities that is more flexible than the last-modified date. An ETag is a string that uniquely identifies a specific version of a component. The only format constraints are that the string be quoted. The origin server specifies the component's ETag using the ETag response header.
When
users request a page, it can take anywhere from 200 to 500ms for the
backend server to stitch together the HTML page. During this time, the
browser is idle as it waits for the data to arrive. In PHP you have the
function flush(). It allows you to
send your partially ready HTML response to the browser so that the
browser can start fetching components while your backend is busy with
the rest of the HTML page. The benefit is mainly seen on busy backends
or light frontends.
A good place to consider flushing is right after the HEAD because the HTML for the head is usually easier to produce and it allows you to include any CSS and JavaScript files for the browser to start fetching in parallel while the backend is still processing.
Example:
-
Minimize HTTP Requests
-
Gzip Components
-
Put Stylesheets at the Top
-
Put Scripts at the Bottom
-
Avoid CSS Expressions
-
Make JavaScript and CSS External
-
Reduce DNS Lookups
-
Minify JavaScript and CSS
-
Avoid Redirects
-
Remove Duplicate Scripts
-
Configure ETags
-
Make Ajax Cacheable
-
Flush the Buffer Early
-
Use GET for AJAX Requests
-
Minimize the Number of iframes
-
No 404s
-
Reduce Cookie Size
-
Avoid Filters
-
Optimize Images
-
Optimize CSS Sprites
-
Don't Scale Images in HTML
-
Avoid Empty Image src
Minimize HTTP Requests
80%
of the end-user response time is spent on the front-end. Most of this
time is tied up in downloading all the components in the page: images,
stylesheets, scripts, Flash, etc. Reducing the number of components in
turn reduces the number of HTTP requests required to render the page.
This is the key to faster pages.
One
way to reduce the number of components in the page is to simplify the
page's design. But is there a way to build pages with richer content
while also achieving fast response times? Here are some techniques for
reducing the number of HTTP requests, while still supporting rich page
designs.
Combined files are a way to reduce the number of HTTP requests by combining all scripts into a single script, and similarly combining all CSS into a single stylesheet. Combining files is more challenging when the scripts and stylesheets vary from page to page, but making this part of your release process improves response times.
CSS Sprites
are the preferred method for reducing the number of image requests.
Combine your background images into a single image and use the CSS
background-image and background-position properties to display the
desired image segment.
Image maps combine
multiple images into a single image. The overall size is about the
same, but reducing the number of HTTP requests speeds up the page. Image
maps only work if the images are contiguous in the page, such as a
navigation bar. Defining the coordinates of image maps can be tedious
and error prone. Using image maps for navigation is not accessible too,
so it's not recommended.
Inline images use the data:
URL scheme to embed the image data in the actual page. This can
increase the size of your HTML document. Combining inline images into
your (cached) stylesheets is a way to reduce HTTP requests and avoid
increasing the size of your pages. Inline images are not yet supported
across all major browsers.
Reducing
the number of HTTP requests in your page is the place to start. This is
the most important guideline for improving performance for first time
visitors. As described in Tenni Theurer's blog post Browser Cache Usage -
Exposed!, 40-60% of daily visitors to your site come in with an empty
cache. Making your page fast for these first time visitors is key to a
better user experience.
The time it takes to transfer an HTTP request and response across the network can be significantly reduced by decisions made by front-end engineers. It's true that the end-user's bandwidth speed, Internet service provider, proximity to peering exchange points, etc. are beyond the control of the development team. But there are other variables that affect response times. Compression reduces response times by reducing the size of the HTTP response. Starting with HTTP/1.1, web clients indicate support for compression with the Accept-Encoding header in the HTTP request.
Accept-Encoding: gzip, deflate
If
the web server sees this header in the request, it may compress the
response using one of the methods listed by the client. The web server
notifies the web client of this via the Content-Encoding header in the
response. Content-Encoding: gzip
Gzip is the most popular and effective compression method at this time. It was developed by the GNU project and standardized by RFC 1952. The only other compression format you're likely to see is deflate, but it's less effective and less popular. Gzipping generally reduces the response size by about 70%. Approximately 90% of today's Internet traffic travels through browsers that claim to support gzip. If you use Apache, the module configuring gzip depends on your version: Apache 1.3 uses mod_gzip while Apache 2.x uses mod_deflate.
Gzipping as many file types as possible is an easy way to reduce page weight and accelerate the user experience.
Moving
stylesheets to the document HEAD makes pages appear to be loading
faster. This is because putting stylesheets in the HEAD allows the page
to render progressively.
Front-end engineers that care about performance want a page to load progressively; that is, we want the browser to display whatever content it has as soon as possible. This is especially important for pages with a lot of content and for users on slower Internet connections. The importance of giving users visual feedback, such as progress indicators, has been well researched and documented. In our case the HTML page is the progress indicator! When the browser loads the page progressively the header, the navigation bar, the logo at the top, etc. all serve as visual feedback for the user who is waiting for the page. This improves the overall user experience.
The
problem with putting stylesheets near the bottom of the document is
that it prohibits progressive rendering in many browsers, including
Internet Explorer. These browsers block rendering to avoid having to
redraw elements of the page if their styles change. The user is stuck
viewing a blank white page.
The
HTML specification clearly states that stylesheets are to be included
in the HEAD of the page: "Unlike A, [LINK] may only appear in the HEAD
section of a document, although it may appear any number of times."
Neither of the alternatives, the blank white screen or flash of unstyled
content, are worth the risk. The optimal solution is to follow the HTML
specification and load your stylesheets in the document HEAD.
The
problem caused by scripts is that they block parallel downloads. The
HTTP/1.1 specification suggests that browsers download no more than two
components in parallel per hostname. If you serve your images from
multiple hostnames, you can get more than two downloads to occur in
parallel. While a script is downloading, however, the browser won't
start any other downloads, even on different hostnames.
In some situations it's not easy to move scripts to the bottom. If, for example, the script uses document.write to insert part of the page's content, it can't be moved lower in the page. There might also be scoping issues. In many cases, there are ways to workaround these situations.
An
alternative suggestion that often comes up is to use deferred scripts.
The DEFER attribute indicates that the script does not contain
document.write, and is a clue to browsers that they can continue
rendering. Unfortunately, Firefox doesn't support the DEFER attribute.
In Internet Explorer, the script may be deferred, but not as much as
desired. If a script can be deferred, it can also be moved to the bottom
of the page. That will make your web pages load faster.
CSS
expressions are a powerful (and dangerous) way to set CSS properties
dynamically. They were supported in Internet Explorer starting with
version 5, but were deprecated starting with IE8. As an example, the
background color could be set to alternate every hour using CSS
expressions:
background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" );
As
shown here, the expression method accepts a JavaScript expression. The
CSS property is set to the result of evaluating the JavaScript
expression. The expression method is ignored by other browsers, so it is
useful for setting properties in Internet Explorer needed to create a
consistent experience across browsers.
Many
of these performance rules deal with how external components are
managed. However, before these considerations arise you should ask a
more basic question: Should JavaScript and CSS be contained in external
files, or inlined in the page itself?
Using
external files in the real world generally produces faster pages
because the JavaScript and CSS files are cached by the browser.
JavaScript and CSS that are inlined in HTML documents get downloaded
every time the HTML document is requested. This reduces the number of
HTTP requests that are needed, but increases the size of the HTML
document. On the other hand, if the JavaScript and CSS are in external
files cached by the browser, the size of the HTML document is reduced
without increasing the number of HTTP requests. The key factor, then, is the frequency with which external JavaScript and CSS components are cached relative to the number of HTML documents requested. This factor, although difficult to quantify, can be gauged using various metrics. If users on your site have multiple page views per session and many of your pages re-use the same scripts and stylesheets, there is a greater potential benefit from cached external files.
The
Domain Name System (DNS) maps hostnames to IP addresses, just as
phonebooks map people's names to their phone numbers. When you type
www.yahoo.com into your browser, a DNS resolver contacted by the browser
returns that server's IP address. DNS has a cost. It typically takes
20-120 milliseconds for DNS to lookup the IP address for a given
hostname. The browser can't download anything from this hostname until
the DNS lookup is completed.
Minification
is the practice of removing unnecessary characters from code to reduce
its size thereby improving load times. When code is minified all
comments are removed, as well as unneeded white space characters (space,
newline, and tab). In the case of JavaScript, this improves response
time performance because the size of the downloaded file is reduced. Two
popular tools for minifying JavaScript code are JSMin and YUI
Compressor. The YUI compressor can also minify CSS.
Obfuscation
is an alternative optimization that can be applied to source code. It's
more complex than minification and thus more likely to generate bugs as
a result of the obfuscation step itself. In a survey of ten top U.S.
web sites, minification achieved a 21% size reduction versus 25% for
obfuscation. Although obfuscation has a higher size reduction, minifying
JavaScript is less risky.
In
addition to minifying external scripts and styles, inlined
An alternative in PHP would be to create a function called insertScript.
In
addition to preventing the same script from being inserted multiple
times, this function could handle other issues with scripts, such as
dependency checking and adding version numbers to script filenames to
support far future Expires headers.
Entity tags (ETags) are a mechanism that web servers and browsers use to determine whether the component in the browser's cache matches the one on the origin server. (An "entity" is another word a "component": images, scripts, stylesheets, etc.) ETags were added to provide a mechanism for validating entities that is more flexible than the last-modified date. An ETag is a string that uniquely identifies a specific version of a component. The only format constraints are that the string be quoted. The origin server specifies the component's ETag using the ETag response header.
HTTP/1.1 200 OK
Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT
ETag: "10c24bc-4ab-457e1c1f"
Content-Length: 12195
A good place to consider flushing is right after the HEAD because the HTML for the head is usually easier to produce and it allows you to include any CSS and JavaScript files for the browser to start fetching in parallel while the backend is still processing.
Example:
...
...
when
using XMLHttpRequest, POST is implemented in the browsers as a two-step
process: sending the headers first, then sending data. So it's best to
use GET, which only takes one TCP packet to send (unless you have a lot
of cookies). The maximum URL length in IE is 2K, so if you send more
than 2K data you might not be able to use GET.
An
interesting side affect is that POST without actually posting any data
behaves like GET. Based on the HTTP specs, GET is meant for retrieving
information, so it makes sense (semantically) to use GET when you're
only requesting data, as opposed to sending data to be stored
server-side.
Iframes
allow an HTML document to be inserted in the parent document. It's
important to understand how iframes work so they can be used
effectively.
www.codeintellects.com
No comments:
Post a Comment