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.
Minimizing the payload size of both dynamic and static resources can reduce network latency significantly. In addition, for scripts that are cached, cutting down their byte size speeds up the time the browser takes to parse and execute code needed to render the page.
Compressing resources with gzip can reduce the number of bytes sent over the network.
Most modern browsers support data compression for HTML, CSS, and JavaScript files. This allows content to be sent over the network in more compact form and can result in a dramatic reduction in download time.
Many web servers can compress files in gzip format before
sending them for download, either by calling a third-party module or
using built-in routines. To enable compression, configure your web
server to set the Content-Encoding header to gzip
format for all compressible resources. (You can also use deflate,
which uses the same compression algorithms, but it is not widely used,
so we recommend gzip.) If streaming compression imposes
too much load on your server, you can usually configure it to
pre-compress files and cache them for future downloading.
Note that gzipping is only beneficial for larger resources. Due to the overhead and latency of compression and decompression, you should only gzip files above a certain size threshold; we recommend a minimum range between 150 and 1000 bytes. Gzipping files below 150 bytes can actually make them larger.
|
href first for links
(since it is most common), then alphabetize the rest. For example, on
Google's search results page, when HTML attributes were alphabetized, a
1.5% reduction in the size of the gzipped output resulted.
Removing or deferring style rules that are not used by a document avoid downloads unnecessary bytes and allow the browser to start rendering sooner.
Before a browser can begin to render a web page, it must download and parse any stylesheets that are required to lay out the page. Even if a stylesheet is in an external file that is cached, rendering is blocked until the browser loads the stylesheet from disk. In addition, once the stylesheet is loaded, the browser's CSS engine has to evaluate every rule contained in the file to see if the rule applies to the current page. Often, many web sites reuse the same external CSS file for all of their pages, even if many of the rules defined in it don't apply to the current page.
The best way to minimize the latency caused by stylesheet loading and rendering time is to cut down on the CSS footprint; an obvious way to do this is to remove or defer CSS rules that aren't actually used by the current page.
Tip: When you run Page Speed against a page referencing CSS files, it identifies all CSS rules that don't apply to that page.
onload
event is fired.Compacting JavaScript code can save many bytes of data and speed up downloading, parsing, and execution time.
"Minifying" code refers to eliminating unnecessary bytes, such as extra spaces, line breaks, and indentation. Keeping JavaScript code compact has a number of benefits. First, for inline JavaScript and external files that you don't want cached, the smaller file size reduces the network latency incurred each time the page is downloaded. Secondly, minification can further enhance compression of external JS files and of HTML files in which the JS code is inlined. Thirdly, smaller files can be loaded and run more quickly by web browsers.
Several tools are freely available to minify JavaScript, including the Closure Compiler, JSMin or the YUI Compressor. You can create a build process that uses these tools to minify and rename the development files and save them to a production directory. We recommend minifying any JS files that are 4096 bytes or larger in size. You should see a benefit for any file that can be reduced by 25 bytes or more (less than this will not result in any appreciable performance gain).
Tip: When you run Page Speed against a page referencing JS files, it automatically runs the Closure Compiler (if available) and JSMin (for inline blocks and if the compiler is not available) on the files and saves the minified output to a configurable directory.
Compacting CSS code can save many bytes of data and speed up downloading, parsing, and execution time.
Minifying CSS has the same benefits as those for minifying JS: reducing network latency, enhancing compression, and faster browser loading and execution.
Several tools are freely available to minify JavaScript,
including the YUI
Compressor and cssmin.js.
Tip: When you run Page Speed against a page referencing CSS files, it automatically runs cssmin.js on the files and saves the minified output to a configurable directory.
Deferring loading of JavaScript functions that are not called at startup reduces the initial download size, allowing other resources to be downloaded in parallel, and speeding up execution and rendering time.
Like stylesheets, scripts must be downloaded, parsed, and executed before the browser can begin to render a web page. Again, even if a script is contained in an external file that is cached, processing of all elements below the script is blocked until the browser loads the code from disk and executes it. However, for some browsers, the situation is worse than for stylesheets: while JavaScript is being processed, the browser blocks all other resources from being downloaded. For AJAX-type applications that use many bytes of JavaScript code, this can add considerable latency.
For many script-intensive applications,
the bulk of the JavaScript code handles user-initiated events,
such as mouse-clicking and dragging, form entry and submission, hidden
elements expansion, and so on. All of these user-triggered events occur
after the page is loaded and the onload
event is triggered. Therefore, much of the delay in the "critical path"
(the time to load the main page at startup) could be avoided by
deferring the loading of the JavaScript until it's actually needed.
While this "lazy" method of loading doesn't reduce the total JS
payload, it can significantly reduce the number of bytes needed to load
the initial state of the page, and allows the remaining bytes to be
loaded asynchronously
in the background.
To use this technique, you should first identify all of the
JavaScript functions that are not actually used by the document before
the onload event. For any file containing
more than 25 uncalled functions, move all of those functions to a
separate, external JS file. This may require some refactoring of your
code to work around dependencies between files. (For files containing
fewer
than 25 uncalled functions, it's not worth the effort of refactoring.)
Tip: Use the Page Speed Profile Deferrable Javascript option to automatically identify candidates for refactoring.
Then, you insert a JavaScript event listener in the head of
the containing document that forces the external file to be loaded
after the onload event. You can do this by
any of the usual scripting means, but we recommend a very simple
scripted DOM element (to avoid cross-browser and same-domain policy
issues). Here's an example (where "deferredfunctions.js" contains the
functions to be lazily loaded):
<script type="text/javascript">
// Add a script element as a child of the body
function downloadJSAtOnload() {
var element = document.createElement("script");
element.src = "deferredfunctions.js";
document.body.appendChild(element);
}
// Check for browser support of event handling capability
if (window.addEventListener)
window.addEventListener("load", downloadJSAtOnload, false);
else if (window.attachEvent)
window.attachEvent("onload", downloadJSAtOnload);
else window.onload = downloadJSAtOnload;
</script>
Properly formatting, sizing, and losslessly compressing images can save many bytes of data.
Images saved from programs like Fireworks can contain kilobytes of extra comments, and use too many colors, even though a reduction in the color palette may not perceptibly reduce image quality. Improperly optimized images can take up more space than they need to; for users on slow connections, it is especially important to keep image sizes to a minimum.
You should perform both basic and advanced optimization on all images. Basic optimization includes cropping unnecessary space, reducing color depth to the lowest acceptable level, removing image comments, and saving the image to an appropriate format. You can perform basic optimization with any image editing program, such as GIMP. Advanced optimization involves further (lossless) compression of JPEG and PNG files. You should see a benefit for any image file that can be reduced by 25 bytes or more (less than this will not result in any appreciable performance gain).
--strip-all
option). For PNG, we recommend OptiPNG
or PNGOUT.
Tip: When you run Page Speed against a page referencing JPEG and PNG files, it automatically compresses the files and saves the output to a configurable directory.
It's important to serve a resource from a unique URL, to eliminate duplicate download bytes and additional RTTs.
Sometimes it's necessary to reference the same resource from multiple places in a page — images are a typical example. Even more likely is that you share the same resources across multiple pages in a site such as .css and .js files. If your pages do need to include the same resource, the resource should always be served from a consistent URL. Ensuring that one resource is always assigned a single URL has a number of benefits. It reduces the overall payload size, as the browser does not need to download additional copies of the same bytes. Also, most browsers will not issue more than one HTTP request for a single URL in one session, whether or not the resource is cacheable, so you also save additional round-trip times. It's especially important to ensure that the same resource is not served from a different hostname, to avoid the performance penalty of additional DNS lookups.
Note that a relative URL and an absolute URL are consistent if the hostname of the absolute URL matches that of the containing document. For example, if the main page at www.example.com references resource /images/example.gif and www.example.com/images/example.gif, the URLs are consistent. However, if that page references /images/example.gif and mysite.example.com/images/example.gif, these URLs are not consistent.
Back to top