制作优质页面必读 --- (二)

永动机

（续）Gzip Components

tag: server

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.

There are known issues with browsers and proxies that may cause a  mismatch in what the browser expects and what it receives with regard to compressed content. Fortunately, these edge cases are dwindling as the  use of older browsers drops off. The Apache modules help out by adding  appropriate Vary response headers automatically.

Servers choose what to gzip based on file type, but are typically too limited in what they decide to compress. Most web sites gzip their HTML documents. It's also worthwhile to gzip your scripts and stylesheets,  but many web sites miss this opportunity. In fact, it's worthwhile to  compress any text response including XML and JSON. Image and PDF files  should not be gzipped because they are already compressed. Trying to  gzip them not only wastes CPU but can potentially increase file sizes.

Gzipping as many file types as possible is an easy way to reduce page weight and accelerate the user experience.

t

Put Stylesheets at the Top

tag: css

While researching performance at Yahoo!, we discovered that 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.

top | discuss this rule

Put Scripts at the Bottom

tag: javascript

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.


[url=http://developer.yahoo.net/blog/archives/2007/07/high_performanc_11.html][/url]