Andy's Blog » » 13步优化网站

13步优化网站

13步优化网站

13 Simple Steps Optimization your Website

来自sitepoint的文章,本文非常值得仔细看看
关于压缩部份,有4种方法,要仔细看看,分别是mod_gzip,mod_deflate,php.ini,和php程序,前3者是全局的设置

Earlier this year, Steve Souders from the Yahoo! Performance team published a series of front-end performance optimization "rules" for optimizing a page.

This tutorial takes a practical, example-based approach to implementing those rules. It's targeted towards web developers with a small budget, who are most likely using shared hosting, and working under the various restrictions that come with such a setup. Shared hosts make it harder to play with Apache configuration -- sometimes it's even impossible -- so we'll take a look at what you can do, given certain common restrictions, and assuming your host runs PHP and Apache.

The tutorial is divided into four parts:

1. basic optimization rules

2. optimizing assets (images, scripts, and styles)

3. optimizations specific to scripts

4. optimizations specific to styles

Credits and Suggested Reading

The article is not going to explain Yahoo!'s performance rules in detail, so you'd do well to read through them on your own for a better understanding of their importance, the reasoning behind the rules, and how they came to be. Here's the list of rules in question:

1. Make fewer HTTP requests

2. Use a Content Delivery Network

3. Add an Expires header

4. Gzip components

5. Put CSS at the top

6. Move scripts to the bottom

7. Avoid CSS expressions

8. Make JavaScript and CSS external

9. Reduce DNS lookups

10. Minify JavaScript

11. Avoid redirects

12. Remove duplicate scripts

13. Configure ETags

You can read about these rules on the Yahoo! Developer Network site. You can also check out the book "High Performance Web Sites" by Steve Souders, and the performance research articles on the YUI blog by Tenni Theurer.
Basic Optimization Rules

Decrease Download Sizes

Decreasing download sizes isn't even in Yahoo!'s list of rules -- probably because it's so obvious. However I don't think it hurts to reiterate the point -- let's call it Rule #0.

When we look at a simple web page we see:

* some HTML code
* different page components (assets) referenced by the HTML

The assets are images, scripts, styles, and perhaps some external media such as Flash movies or Java applets (remember those?). So, when it comes to download sizes, you should aim to have all the assets as lightweight as possible -- advice which also extends to the page's HTML content. Creating lean HTML code often means using better (semantic) markup, which also overlaps with the SEO (search engine optimization) efforts that are a necessary part of the site creation process. As most professional web developers know, a key characteristic of good markup is that it only describes the content, not the presentation of the page (no layout tables!). Any layout or presentational elements should be moved to CSS.

Here's an example of a good approach to HTML markup for a navigation menu:

<ul id="menu">
 <li><a href="home.html">Home</a></li>
 <li><a href="about.html">About</a></li>
 <li><a href="contact.html">Contact</a></li>
</ul>

This sort of markup should provide "hooks" to allow for the effective use of CSS and make the menu look however you want it to -- whether that means adding fancy bullets, borders, or rollovers, or placing the menu items into a horizontal menu. The markup is minimal, which means there are fewer bytes to download; it's semantic, meaning it describes the content (a navigation menu is a list of links); and finally, being minimal, it also gives you an SEO advantage: it's generally agreed that search engines prefer a higher content-to-markup ratio in the pages that they index.

Once you're sure your markup is lightweight and semantic, you should go through your assets and make sure they are also of minimal size. For example, check whether it's possible to compress images more without losing too much quality, or to choose a different file format that gives you better compression. Tools such as PNGOUT and pngcrush are a good place to start.

Make Fewer HTTP Requests

Making fewer HTTP requests turns out to be the most important optimization technique, with the biggest impact. If your time is limited, and you can only complete one optimization task, pick this one. HTTP requests are generally the most "expensive" activity that the browser performs while displaying your page. Therefore, you should ensure that your page makes as few requests as possible.

How you can go about that, while maintaining the richness of your pages?

* Combine scripts and style sheets: Do you have a few < script > tags in your head? Well, merge the .js files into one and save your visitors some round trips; then do the same with the CSS files.
* Use image sprites: This technique allows you to combine several images into one and use CSS to show only the part of the image that's needed. When you combine five or ten images into a single file, already you're making a huge saving in the request/response overhead.
* Avoid redirects: a redirect adds another client-server round trip, so instead of processing your page immediately after receiving the initial response, the browser will have to make another request and wait for the second response.
* Avoid frames: if you use frames, the browser has to request at least three HTML pages, instead of just one -- those of the frameset as well as each of the frames.

You've got the basics now. In summary, make your page and its assets smaller in size, and use fewer assets by combining them wherever you can. If you concentrate on this aspect of optimization only, you and your visitors will notice a significant improvement.

Now let's explore some of the Yahoo! recommendations in more detail, and see what other optimizations can be made to improve performance.
Optimizing Assets

Use a Content Delivery Network

A Content Delivery Network (CDN) is a network of servers in different geographical locations. Each server has a copy of a site's files. When a visitor to your site requests a file, the file is delivered from the nearest server (or the one that's experiencing the lightest load at the time).

This setup can have a significant impact on your page's overall performance, but unfortunately, using a CDN can be pricey. As such, it's probably not something you'd do for a personal blog, but it may be useful when a client asks you to build a site that's likely to experience high volumes of traffic. Some of the most widely known CDN providers are Akamai and Amazon, through its S3 service.

There are some non-profit CDNs in the market; check the CDN Wikipedia article to see if your project might qualify to use one of them. For example, one free non-profit peer-to-peer CDN is Coral CDN, which is extremely easy to integrate with your site. For this CDN, you take a URL and append "nyud.net" to the hostname. Here's an example:

http://example.org/logo.png

becomes:

http://example.org.nyud.net/logo.png

Host Assets on Different Domains but Reduce DNS Lookups

After your visitor's browser has downloaded the HTML for a page and figured out that a number of components are also needed, it begins downloading those components. Browsers restrict the number of simultaneous downloads that can take place; as per the HTTP/1.1 specification, the limit is two assets per domain.

Because this restriction exists on a per-domain basis, you can use several domains (or simply use subdomains) to host your assets, thus increasing the number of parallel downloads. Most shared hosts will allow you to create subdomains. Even if your host places a limit on the number of subdomains you can create (some restrict you to a maximum of five), it's not that important, as you won't need to utilize too many subdomains to see some noticeable performance improvements.

However, as Rule #9 states, you should also reduce the number of DNS lookups, because these can also be expensive. For every domain or subdomain that hosts a page asset, the browser will need to make a DNS lookup. So the more domains you have, the more your site will be slowed down by DNS lookups. Yahoo!'s research suggests that two to four domains is an optimal number, but you can decide for yourself what's best for your site.

As a general guideline, I'd suggest you use one domain to host HTML pages and two other domains for your assets. Here's an example:

* www.sitepoint.com - hosts only HTML (and maybe content images)
* i1.sitepoint.com - hosts JS, CSS, and some images
* i2.sitepoint.com - hosts most of the site's images

Different hosting providers will probably offer different interfaces for creating subdomains, and ideally they should provide you with an option to specify the directory that holds the files for the subdomain. For example, if your canonical domain is www.sitepoint.com, and it points to /home/sitepoint/htdocs, ideally you should be able to create the subdomain i1.sitepoint.com (either via an administration control panel or by creating a symbolic link in the file system) and point it to the same folder, /home/sitepoint/htdocs. This way, you can keep all files in the same location, just as they are in your development environment, but reference them using a subdomain.

However, some hosts may prevent you from creating subdomains, or may restrict your ability to point to particular locations on the file system. In such cases, your only real options is to physically copy the assets to the new location. Don't be tempted to create some kind of redirect in this case -- it will only make things worse, as it creates two requests for each image.

If your hosting provider doesn't allow subdomains at all, you always have the option of buying more domains and using them purely to host assets -- after all, that's what a lot of big sites do. Yahoo! uses the domain yimg.com, Amazon has images-amazon.com, and SitePoint has sitepointstatic.com. If you own several sites, or manage the hosting of your client's sites, you might consider buying two domains, such as yourdomain-i1.com and yourdomain-i2.com, and using them to host the components for all the sites you maintain.

Tags: SEO

本文地址: http://www.21andy.com/new/20071118/667.html