【性能優化】Yahoo網站優化的14條規則

1.減小HTTP請求
　　減小HTTP請求的方式不少，常見的包括CSS Sprites、合併JS和CSS、圖片地圖等。遵照這條規則能夠改善首次訪問網站的響應時間。

2.使用CDN（內容發佈網絡）
　　只有10%-20%的最終用戶響應時間花在了下載HTML文檔上，其他的80%-90%時間花在了下載頁面中的全部組件上。若是web服務器離服務器更近，則一個HTTP請求的響應時間將縮短。CDN是一組分佈在多個不一樣地理位置的web服務器，每一個服務器都擁有全部網站的文件副本，用戶訪問網站時，就能夠從離用戶最近的服務器發送所需的文件給客戶端。Yahoo！Shopping網站使用CDN後響應時間減小了20%。

3.添加Expires頭
　　經過使用Expires頭，瀏覽器能夠在用戶首次訪問網站後，將頁面的資源緩存下來。能夠爲Expires指定過時時間，在指定時間後，緩存將失效。

4.啓用Gzip
　　客戶端能夠經過HTTP請求中的Accept-Encoding頭來標識對壓縮的支持（Accept-Encoding：gzip,deflate），服務器看到請求中有這個頭，就會使用客戶端列出的一種方法來壓縮響應。大多數網站使用gzip壓縮了HTML。

5.將CSS放在頂部
　　將CSS放在底部會發生無樣式閃爍，瀏覽器會先加載HTML，而後加載CSS，會出現一段沒有任何樣式的「白屏時間」。而將CSS放在頂部則能規避這個問題。

6.將腳本放在底部
　　將腳本放在頂部或頁面中，瀏覽器會對script標籤內的內容進行解析，從而阻塞樣式的渲染。除此以外，HTTP1.1規範建議瀏覽器從每一個主機並行的下載兩個組件，在高版本的IE和chrome、Firefox等瀏覽器則支持並行下載六個組件。但script會阻塞並行下載。所以咱們應該將腳本放在底部。

7.避免CSS表達式
　　CSS表達式具有求值計算能力，然而每次頁面發生重繪時，CSS表達式會影響頁面的加載時間。

8.使用外部JavaScript和CSS
　　使用大量內聯的JS和CSS就不能實現樣式、結構、行爲的分離，這樣會在維護上形成不少麻煩，同時也會增大網頁的體積。

9.減小DNS查詢
　　經過使用Keep-Alive和較少的域名能夠減小DNS查詢

10.精簡JavaScript和CSS
　　進行代碼混淆能夠壓縮JS文件的大小，這個經過gulp等構建工具能夠自動化的進行。

11.避免重定向
　　重定向用於將用戶從一個URL從新路由到另外一個URL。重定向有不少種，包括301永久重定向、302臨時重定向，304 Not Modified並非真正的重定向，它是用來響應Get請求，避免下載已經存在於瀏覽器緩存中的數據。在URL的結尾加上斜線（/）能夠避免一部分重定向。

12.移除重複腳本
13.配置ETag
　　實體標籤（Entity Tag）是web服務器和瀏覽器用於確認緩存資源的有效性的一種機制，它能夠檢測瀏覽器中緩存的資源與原始服務器上的資源是否匹配。ETag是惟一標識資源的一個特定版本的字符串，瀏覽器要驗證一個資源，它會使用If-None-Match頭將ETag傳回原始服務器。若是ETag是匹配的，就會返回304狀態碼，從而使用瀏覽器緩存。

14.緩存Ajax
　　確保Ajax請求具備長久的Expires頭

做者：蘇星河
連接：https://www.jianshu.com/p/603d9ac62ba6
來源：簡書
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

 

 

//https://blog.csdn.net/qq_17431235/article/details/54949167

第一條、儘量的減小 HTTP 的請求數 (Make Fewer HTTP Requests )

http請求是要開銷的，想辦法減小請求數天然能夠提升網頁速度。經常使用的方法，合併css，js(將一個頁面中的css和js文件分別合併)以及 Image maps和css sprites等。固然或許將css，js文件拆分多個是由於css結構，共用等方面的考慮。阿里巴巴中文站當時的作法是開發時依然分開開發，而後在後臺 對js，css進行合併，這樣對於瀏覽器來講依然是一個請求，可是開發時仍然能還原成多個，方便管理和重複引用。yahoo甚至建議將首頁的css和js 直接寫在頁面文件裏面，而不是外部引用。由於首頁的訪問量太大了，這麼作也能夠減小兩個請求數。而事實上國內的不少門戶都是這麼作的。 
而css sprites是指只用將頁面上的背景圖合併成一張，而後經過css的background-position屬性定義不過的值來取他的背景。淘寶和阿里巴巴中文站目前都是這樣作的。有興趣的能夠看下淘寶和阿里巴巴的背景圖。 
http://www.csssprites.com/ 這是個工具網站，它能夠自動將你上傳的圖片合併並給出對應的background-position座標。並將結果以png和gif的格式輸出。

第二條、使用CDN(內容分發網絡): Use a Content Delivery Network

說實話，對於CDN這一塊本身並非很瞭解，簡單地講，經過在現有的Internet中增長一層新的網絡架構，將網站的內容發佈到最接近用戶的 cache服務器內，經過DNS負載均衡的技術，判斷用戶來源就近訪問cache服務器取得所需的內容，杭州的用戶訪問近杭州服務器上的內容，北京的訪問 近北京服務器上的內容。這樣能夠有效減小數據在網絡上傳輸的時間，提升速度。更詳細地內容你們能夠參考百度百科上對於CDN的解釋。Yahoo!把靜態內 容分佈到CDN減小了用戶影響時間20%或更多。

第三條、 添加Expire/Cache-Control 頭：Add an Expires Header

如今愈來愈多的圖片，腳本，css，flash被嵌入到頁面中，當咱們訪問他們的時候勢必會作許屢次的http請求。其實咱們能夠經過設置 Expires header 來緩存這些文件。Expire其實就是經過header報文來指定特定類型的文件在覽器中的緩存時間。大多數的圖片，flash在發佈後都是不須要常常修 改的，作了緩存之後這樣瀏覽器之後就不須要再從服務器下載這些文件而是而直接從緩存中讀取，這樣再次訪問頁面的速度會大大加快。一個典型的HTTP 1.1協議返回的頭信息：

HTTP/1.1 200 OK
Date: Fri, 30 Oct 1998 13:19:41 GMT
Server: Apache/1.3.3 (Unix)
Cache-Control: max-age=3600, must-revalidate
Expires: Fri, 30 Oct 1998 14:19:41 GMT
Last-Modified: Mon, 29 Jun 1998 02:28:12 GMT
ETag: 「3e86-410-3596fbbc」
Content-Length: 1040
Content-Type: text/html

其中經過服務器端腳本設置Cache-Control和Expires能夠完成。

第四條、啓用Gzip壓縮：Gzip Components

Gzip的思想就是把文件先在服務器端進行壓縮，而後再傳輸。這樣能夠顯著減小文件傳輸的大小。傳輸完畢後瀏覽器會 從新對壓縮過的內容進行解壓縮，並執行。目前的瀏覽器都能「良好」地支持 gzip。不只瀏覽器能夠識別，並且各大「爬蟲」也一樣能夠識別，各位seoer能夠放下心了。並且gzip的壓縮比例很是大，通常壓縮率爲85%，就是 說服務器端100K的頁面能夠壓縮到25K左右再發送到客戶端。具體的Gzip壓縮原理你們能夠參考csdn上的《gzip壓縮算法》 這篇文章。雅虎特別強調， 全部的文本內容都應該被gzip壓縮: html (php), js, css, xml, txt… 這一點咱們網站作得不錯，是一個A。之前咱們的首頁也並非A，由於首頁上還有不少廣告代碼投放的js，這些廣告代碼擁有者的網站的js沒有通過gzip 壓縮，也會拖累咱們網站。

以上三點大多屬於服務器端的內容，本人也是粗淺地瞭解而已。說得不對的地方有待各位指正。

第五條、將css放在頁面最上面 ( Put Stylesheets at the Top)

將css放在頁面最上面，這是爲何?由於 ie，firefox等瀏覽器在css所有傳輸徹底以前不會去渲染任何的東西。理由誠如小馬哥說得那樣很簡單。css，全稱Cascading Style Sheets (層疊樣式表單)。層疊即意味這後面的css能夠覆蓋前面的css，級別高的css能夠覆蓋級別低的css。在[css之!important] 這篇文章的最下面曾簡單地提到過這層級關係，這裏咱們只須要知道css能夠被覆蓋的。既然前面的能夠被覆蓋，瀏覽器在他徹底加載完畢以後再去渲染無疑也是 合情合理的不少瀏覽器下，如IE，把樣式表放在頁面的底部的問題在於它禁止了網頁內容的順序顯示。瀏覽器阻止顯示以避免重畫頁面元素，那用戶只能看到空白頁 了。Firefox不會阻止顯示，但這意味着當樣式表下載後，有些頁面元素可能須要重畫，這致使閃爍問題。因此咱們應該儘快讓css加載完畢

順着這層意思，若是咱們再細究的話，其實還有能夠優化的地方。好比本站上面包含的兩個css文件， 
<linkrel=「stylesheet」 rev=「stylesheet」href=「http://www.space007.com/themes/google/style/google.css」 type=「text/css」 media=「screen」/> 和<link rel=「stylesheet」 rev=「stylesheet」 href=「http://www.space007.com/css/print.css」type=「text/css」 media=「print」 />
從media就能夠看出第一個css是針對瀏覽器的，第二個css文件是針對打印樣式的。從用戶的行爲習慣上來將，要打印頁面的動做必定是發生在頁面頁面 顯示出來以後的。因此比較好的方法應該是在頁面加載完畢以後再動態地爲這張頁面加上針對打印設備的css，這樣又能夠提升一點速度。(哈哈)

第六條、將script放在頁面最下面 (Put Scripts at the Bottom )

將腳本放在頁面最下面的目的有那麼兩點： 一、 由於防止script腳本的執行阻塞頁面的下載。在頁面loading的過程當中，當瀏覽器讀到js執行語句的時候必定會把它所有解釋完畢後在會接下來讀下 面的內容。不信你能夠寫一個js死循環看看頁面下面的東西還會不會出來。(setTimeout 和 setInterval的執行有點相似於多線程，在相應的響應時間以前也會繼續下面的內容渲染。)瀏覽器這麼作的邏輯是由於js隨時可能執 行 location.href或是其餘可能徹底中斷此頁面過程的函數，即如此，固然得等他執行完畢以後再加載咯。因此放在頁面最後，能夠有效減小頁面可 視元素的加載時間。 二、腳本引發的第二個問題是它阻塞並行下載數量。HTTP/1.1規範建議瀏覽器每一個主機的並行下載數不超過2個(IE只能爲2個，其餘瀏覽器如ff等都 是默認設置爲2個，不過新出的ie8能夠達6個)。所以若是您把圖像文件分佈到多臺機器的話，您能夠達到超過2個的並行下載。可是當腳本文件下載時，瀏覽 器不會啓動其餘的並行下載。

固然對各個網站來講，把腳本都放到頁面底部加載的可行性仍是值得商榷的。就好比阿里巴巴中文站的頁面。不少地方有內聯的js，頁面的顯示嚴重依賴於此，我認可這和無侵入腳本的理念相差甚遠，可是不少「歷史遺留問題」卻不是那麼容易解決的。

第七條、避免在CSS中使用Expressions (Avoid CSS Expressions )

不過這樣就多了兩層無心義的嵌套，確定很差。還須要一個更好的辦法。

第八條、把javascript和css都放到外部文件中 (Make JavaScript and CSS External )

這點我想仍是很容易理解的。不只從性能優化上會這麼作，用代碼易於維護的角度看也應該這麼作。把css和js寫在頁面內容能夠減小2次請求，但也增 大了頁面的大小。若是已經對css和js作了緩存，那也就沒有2次多餘的http請求了。固然，我在前面中也說過，有些特殊的頁面開發人員仍是會選擇內聯 的css和js文件。

第九條、減小DNS查詢 (Reduce DNS Lookups)

在 Internet上域名與IP地址之間是一一對應的，域名(kuqin.com)很好記，但計算機不認識，計算機之間的「相認」還要轉成ip地址。在網絡 上每臺計算機都對應有一個獨立的ip地址。在域名和ip地址之間的轉換工做稱爲域名解析，也稱DNS查詢。一次DNS的解析過程會消耗20-120毫秒的 時間,在dns查詢結束以前，瀏覽器不會下載該域名下的任何東西。因此減小dns查詢的時間能夠加快頁面的加載速度。yahoo的建議一個頁面所包含的域 名數儘可能控制在2-4個。這就須要對頁面總體有一個很好的規劃。目前咱們這點作的很差，不少打點的廣告投放系統拖累了咱們。

第十條、壓縮 JavaScript 和 CSS (Minify JavaScript )

壓縮js和css的左右很顯然，減小頁面字節數。容量小頁面加載速度天然也就快。並且壓縮除了減小體積之外還能夠起到必定的保護左右。這點咱們作得 不錯。經常使用的壓縮工具備JsMin、YUI compressor等。另外像http://dean.edwards.name/packer/還給咱們提供了一個很是方便的在線壓縮工具。你能夠在 jQuery的網頁看到壓縮過的js文件和沒有壓縮過的js文件的容量差異：

固然，壓縮帶來的一個弊端就是代碼的可讀性沒了。相信不少作前端的朋友都遇到過這個問題：看Google的效果很酷，但是去看他的源代碼倒是一大堆 擠在一塊兒的字符，連函數名都是替換過的，汗死!本身的代碼也這樣豈不是對維護很是不方便。全部阿里巴巴中文站目前採用的作法是在js和css發佈的時候在 服務器端進行壓縮。這樣在咱們很方便地維護本身的代碼。

第十一條、避免重定向 (Avoid Redirects )

不久前在ieblog上看到過《Internet Explorer and Connection Limits》 這篇文章，好比 當你輸入http://www.kuqin.com/ 的時候服務器會自動產生一個301服務器轉向 http://www.kuqin.com/ ，你看瀏覽器的地址欄就能看出來。這種重定向天然也是須要消耗時間的。固然這只是一個例子，發生重定向的緣由還有不少，可是不變的是每增長一次重定向就會 增長一次web請求，因此因該儘可能減小。

第十二條、移除重複的腳本 (Remove Duplicate Scripts )

這點我想不說也知道，不只是從性能上考慮，代碼規範上看也是這樣。可是不得不認可，不少時候咱們會由於圖一時之快而加上一些或許是重複的代碼。或許一個統一的css框架和js框架能夠比較好的解決咱們的問題。小豬的觀點很對，不只是要作到不重複，更是要作到可重用。

第十三條、配置實體標籤(ETags) (Configure ETags ) 
這點我也不懂，呵呵。在inforQ上找到一篇解釋得比較詳細的說明《使用ETags減小Web應用帶寬和負載》，有興趣的同窗能夠去看看。

第十四條、使 AJAX 緩存 (Make Ajax Cacheable )

ajax還要去緩存?作ajax請求的時候每每還要增長一個時間戳去避免他緩存。It’s important to remember that 「asynchronous」 does not imply 「instantaneous」.(記住「異步」不是「瞬間」這一點很重要)。記住，即便AJAX是動態產生的並且只對一個用戶起做用，他們依然能夠被緩 存。