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.
- Enable compression
- Remove unused CSS
- Minify CSS
- Minify HTML
- Optimize images
- Serve scaled images
- Serve resources from a consistent URL
Compressing resources with
deflate can reduce the number of bytes sent over the network.
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.
- Write your web page content to make compression most effective.
- To ensure that your content compresses well, do the following:
- Ensure consistency in HTML and CSS code. To achieve consistency:
- Specify CSS key-value pairs in the same order where possible, i.e. alphabetize them.
- Specify HTML attributes in the same order , i.e. alphabetize them. Put
hreffirst 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.
- Use consistent casing, i.e. use lowercase wherever possible.
- Use consistent quoting for HTML tag attributes, i.e. always single quote, always double quote, or no quoting at all where possible.
- Ensure consistency in HTML and CSS code. To achieve consistency:
- Don’t use gzip for image or other binary files.
- Image file formats supported by the web, as well as videos, PDFs and other binary formats, are already compressed; using gzip on them won’t provide any additional benefit, and can actually make them larger. To compress images, see Optimize images.
- For more tips on ensuring that your content is downloaded in compressed format, see Use compression to make the web faster.
Remove unused CSS
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.
- Remove any inline style blocks containing CSS that is not used by the current page.
- Minify CSS.
- If your site uses external CSS files shared among multiple pages, consider splitting them into smaller files containing rules for specific pages.
- If a page references style rules that are not needed right at startup, put them in a separate .css file and defer loading of the file until the
onloadevent is fired.
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.
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.
Minifying HTML has the same benefits as those for minifying CSS and JS: reducing network latency, enhancing compression, and faster browser loading and execution. Moreover, HTML frequently contains inline JS code (in
<script> tags) and inline CSS (in
<style> tags), so it is useful to minify these as well.
Note: This rule is experimental and is currently focused on size reduction rather than strict HTML well-formedness. Future versions of the rule will also take into account correctness. For details on the current behavior, see the Page Speed wiki.
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.)
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):
Properly formatting and 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).
- Choose an appropriate image file format.
- The type of an image can have a drastic impact on the file size. Use these guidelines:
- PNGs are almost always superior to GIFs and are usually the best choice. IE 4.0b1+, Mac IE 5.0+, Opera 3.51+ and Netscape 4.04+ as well as all versions of Safari and Firefox fully support PNG, including transparency. IE versions 4 to 6 don’t support alpha channel transparency (partial transparency) but they support 256-color-or-less PNGs with 1-bit transparency (the same that is supported for GIFs). IE 7 and 8 support alpha transparent PNGs except when an alpha opacity filter is applied to the element. You can generate or convert suitable PNGs with GIMP by using “Indexed” rather than “RGB” mode. If you must maintain compatibility with 3.x-level browsers, serve an alternate GIF to those browsers.
- Use GIFs for very small or simple graphics (e.g. less than 10×10 pixels, or a color palette of less than 3 colors) and for images which contain animation. If you think an image might compress better as a GIF, try it as a PNG and a GIF and pick the smaller.
- Use JPGs for all photographic-style images.
- Do not use BMPs or TIFFs.
- Use an image compressor.
- Several tools are available that perform further, lossless compression on JPEG and PNG files, with no effect on image quality. For JPEG, we recommend jpegtran or jpegoptim (available on Linux only; run with the
--strip-alloption). 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.
Serve scaled images
Properly sizing images can save many bytes of data.
Sometimes you may want to display the same image in various sizes, so you will serve a single image resource and use HTML or CSS in the containing page to scale it. For example, you may have a 10 x 10 thumbnail version of a larger 250 x 250 image, and rather than forcing the user to download two separate files, you use markup to resize the thumbnail version. This makes sense if the actual image size matches at least one — the largest — of the instances in the page, in this case 250 x 250 pixels. However, if you serve an image that is larger than the dimensions used in all of the markup instances, you are sending unnecessary bytes over the wire. You should use an image editor to scale images to match the largest size needed in your page, and make sure that you specify those dimensions in the page as well.
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.
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 http://www.example.com references resource /images/example.gif and http://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.
- Serve shared resources from a consistent URL across all pages in a site.
- For resources that are shared across multiple pages, make sure that each reference to the same resource uses an identical URL. If a resource is shared by multiple pages/sites that link to each other, but are hosted on different domains or hostnames, it’s better to serve the file from a single hostname than to re-serve it from the hostname of each parent document. In this case, the caching benefits may outweigh the DNS lookup overhead. For example, if both mysite.example.com and yoursite.example.com use the same JS file, and mysite.example.com links to yoursite.example.com (which will require a DNS lookup anyway), it makes sense to just serve the JS file from mysite.example.com. In this way, the file is likely to already be in the browser cache when the user goes to yoursite.example.com.