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

永动机

Avoid Redirects

tag: content

Redirects are accomplished using the 301 and 302 status codes. Here's an example of the HTTP headers in a 301 response:

      HTTP/1.1 301 Moved Permanently      Location: http://example.com/newuri      Content-Type: text/html
The browser automatically takes the user to the URL specified in the Location field. All the information necessary for a redirect is in the headers.  The body of the response is typically empty. Despite their names,  neither a 301 nor a 302 response is cached in practice unless additional headers, such as Expires or Cache-Control,  indicate it should be. The meta refresh tag and JavaScript are other  ways to direct users to a different URL, but if you must do a redirect,  the preferred technique is to use the standard 3xx HTTP status codes,  primarily to ensure the back button works correctly.

The main thing to remember is that redirects slow down the user  experience. Inserting a redirect between the user and the HTML document  delays everything in the page since nothing in the page can be rendered  and no components can start being downloaded until the HTML document has arrived.

One of the most wasteful redirects happens frequently and web  developers are generally not aware of it. It occurs when a trailing  slash (/) is missing from a URL that should otherwise have one. For  example, going to http://astrology.yahoo.com/astrology results in a 301 response containing a redirect to http://astrology.yahoo.com/astrology/ (notice the added trailing slash). This is fixed in Apache by using Alias or mod_rewrite, or the DirectorySlash directive if you're using Apache handlers.

Connecting an old web site to a new one is another common use for  redirects. Others include connecting different parts of a website and  directing the user based on certain conditions (type of browser, type of user account, etc.). Using a redirect to connect two web sites is  simple and requires little additional coding. Although using redirects  in these situations reduces the complexity for developers, it degrades  the user experience. Alternatives for this use of redirects include  using Alias and mod_rewrite if the two code  paths are hosted on the same server. If a domain name change is the  cause of using redirects, an alternative is to create a CNAME (a DNS  record that creates an alias pointing from one domain name to another)  in combination with Alias or mod_rewrite.



Remove Duplicate Scripts

tag: javascript

It hurts performance to include the same JavaScript file twice in one page. This isn't as unusual as you might think. A review of the ten top U.S. web sites shows that two of them contain a duplicated script. Two  main factors increase the odds of a script being duplicated in a single  web page: team size and number of scripts. When it does happen,  duplicate scripts hurt performance by creating unnecessary HTTP requests and wasted JavaScript execution.

Unnecessary HTTP requests happen in Internet Explorer, but not in  Firefox. In Internet Explorer, if an external script is included twice  and is not cacheable, it generates two HTTP requests during page  loading. Even if the script is cacheable, extra HTTP requests occur when the user reloads the page.

In addition to generating wasteful HTTP requests, time is wasted  evaluating the script multiple times. This redundant JavaScript  execution happens in both Firefox and Internet Explorer, regardless of  whether the script is cacheable.

One way to avoid accidentally including the same script twice is to  implement a script management module in your templating system. The  typical way to include a script is to use the SCRIPT tag in your HTML  page.

      <script type="text/javascript" src="menu_1.0.17.js"></script>
An alternative in PHP would be to create a function called insertScript.

      <?php insertScript("menu.js") ?>
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.



Configure ETags

tag: server

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
Later, if the browser has to validate a component, it uses the If-None-Match header to pass the ETag back to the origin server. If the ETags match, a 304 status code is returned reducing the response by 12195 bytes for  this example.
      GET /i/yahoo.gif HTTP/1.1      Host: us.yimg.com      If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT      If-None-Match: "10c24bc-4ab-457e1c1f"      HTTP/1.1 304 Not Modified
The problem with ETags is that they typically are constructed using  attributes that make them unique to a specific server hosting a site.  ETags won't match when a browser gets the original component from one  server and later tries to validate that component on a different server, a situation that is all too common on Web sites that use a cluster of  servers to handle requests. By default, both Apache and IIS embed data  in the ETag that dramatically reduces the odds of the validity test  succeeding on web sites with multiple servers.
The ETag format for Apache 1.3 and 2.x is inode-size-timestamp. Although a given file may reside in the same directory across multiple  servers, and have the same file size, permissions, timestamp, etc., its  inode is different from one server to the next.
IIS 5.0 and 6.0 have a similar issue with ETags. The format for ETags on IIS is Filetimestamp:ChangeNumber. A ChangeNumber is a counter used to track configuration changes to IIS. It's unlikely that the ChangeNumber is the same across all IIS servers behind a web site.
The end result is ETags generated by Apache and IIS for the exact same component won't match from one server to another. If the ETags  don't match, the user doesn't receive the small, fast 304 response that  ETags were designed for; instead, they'll get a normal 200 response  along with all the data for the component. If you host your web site on  just one server, this isn't a problem. But if you have multiple servers  hosting your web site, and you're using Apache or IIS with the default  ETag configuration, your users are getting slower pages, your servers  have a higher load, you're consuming greater bandwidth, and proxies  aren't caching your content efficiently. Even if your components have a  far future Expires header, a conditional GET request is still made whenever the user hits Reload or Refresh.
If you're not taking advantage of the flexible validation model  that ETags provide, it's better to just remove the ETag altogether. The Last-Modified header validates based on the component's timestamp. And removing the  ETag reduces the size of the HTTP headers in both the response and  subsequent requests. This Microsoft Support article describes how to remove ETags. In Apache, this is done by simply adding the following line to your Apache configuration file:
      FileETag none