內部實質意義再浩博的網站，假如慢到沒有辦法過訪也是一無意義的; SEO做的再好的網站，假如搜索蛛蛛抓不到也是沒有用處; UE預設的再人性化的網站，假如用戶連看都看不到也是空談。
所以網頁的速率完全是最值當關心注視的方面。怎麼樣能力增長一個網頁的速率呢?Steve Souders(Steve Souders的資料提出的增長網頁速率的14條准則，而這些個准則也將是我們下篇媒介紹到的YSlow工具的理論基礎：
第1條：Make Fewer HTTP Requests 盡有可能的減損HTTP的Request煩請數。
80百分之百的用戶響應時間都是耗費在前端。而這些個時間主要又是由於下載圖片、式樣表、JavaScript腳本代碼、flash等文件導致的。減損這些個資源文件的Request煩請數將是增長網頁顯露速率的重點。
這處好似有個矛盾，就是假如我減損了眾多的圖片，式樣，腳本代碼還是flash，那末網頁豈不是光禿禿的，那多不好看呢?實際上這是一個曲解。我們只是說盡力的減損，並沒有說絕對不可以運用。減損這些個文件的Request煩請數，當然也有一點技法和提議的：
1：用一個大圖片接替多個小圖片。
這確實有些顛覆傳統的思惟了。曾經我們一直以為多個小圖片的下載速度之和會小於一個大圖片的下載速度。不過如今利用httpwatch工具的對多個頁面施行剖析後的最後結果表明事情的真實情況並不是這麼。
第1張圖是一個體積為40528bytes的337*191px的大圖片的剖析最後結果。
第二張圖是一個體積為13883bytes的280*90px的小圖片的剖析最後結果。
一個體積為40528bytes的337*191px的大圖片的剖析最後結果(點擊圖片可以檢查完整大圖片)
一個體積為13883bytes的280*90px的小圖片的剖析最後結果(點擊圖片可以檢查完整大圖片)
第1誇大圖片消耗的錢時間為：
Blocked：13.034s
Send：0.001s
Wait：0.163s
Receive：4.596s
TTFB：0.164s
NetWork：4.760s
功耗時：17.795s
真正用於傳道輸送大文件消耗的錢的時間為Reveive時間，即4.596s，大多數的時間是用來檢索緩存和確認鏈接是否管用的Blocked時間，供消耗的錢13.034s，佔總時間的73.2百分之百。
第二張小圖片消耗的錢時間為：
Blocked：16.274s
Send：小於0.001s
Wait：0.117s
Receive：0.397s
TTFB：0.118s
NetWork：0.516s
功耗時：16.790s
真正用於傳道輸送文件的消耗的錢時間是Reveive時間，即0.397s，這確實要比剛剛大文件的4.596s小眾多。不過他的Blocked時間為16.274s，佔總時間的97百分之百。
假如這些個數值還不夠使心服你的話，讓我們看看下邊這張圖。這處列出了某個網頁中全部圖片中的消耗的錢時間概況圖。當然，裡邊的圖片有大有小，規格不相同。
大約80百分之百以上的時間是用來檢索緩存和確認鏈接是否管用的Blocked時間。那裡面藏青色的為傳道輸送文件消耗的錢的Reveive時間，而面前白的顏色的為檢索緩存和明確承認鏈接是否管用的Blocked時間。鐵同樣的事情的真實情況奉告我們：
大文件和小文件下載所需時間確實是不一樣的，差別的完全值半大。並且下載所需時間佔總耗消耗時間間比例細小。
大約80百分之百以上的時間是用來檢索緩存和確認鏈接是否管用的Blocked時間。不管文件體積，這個時間的消耗的錢大概是相同的。並且所佔總耗消耗時間間的比例是莫大的。
一個100k的大圖片總耗消耗時間間完全大於4個25k的小圖片的總耗消耗時間間。並且主要區別就是4個小圖片的Blocked時間完全大於1個大圖片的Blocked時間。
所以假如有可能仍然運用大圖片來代替過多的瑣細的小圖片吧。這也是為何翻滾轉動門的速率要高於圖片調換成功實現的滑動門的端由。
不過，請注意：也不可以用太大的單張圖片，由於那樣子會影響到用戶體驗認識。例如個幾兆的環境圖片的運用完全不是一個好意思。
2：合並你的css文件。
圖:合並與合成一體我曾經犯了一個不正確，你在看我《式樣表的團體與計劃》的系列文章中會曉得。當初，我為了便捷團體和計劃式樣表，將用於不一樣用場的式樣表文件離合去來，形成不一樣的css文件。而後在頁面中依據需求援用多個css文件。
依據盡有可能的減損HTTP的Request煩請數准則我們曉得，那樣子確實是不符合理的，由於那樣子會萌生更多的HTTP的Request煩請數。因此減低網頁的速率。所以，從增長網頁速率的角度上而言，我們仍然應當將全部的css寫在同一個css文件中。不過問題又來了。那末怎麼來美好的團體和計劃式樣表呢?這確實是個矛盾。我如今的作法是認為合適而使用兩套色版本。編輯版和宣布版。編輯版還是運用多個css文件以易於計劃和團體。而等到宣布的時刻，再將多個css文件合並到一個文件中去，因此達到減損HTTPRequest煩請數的目標。
3：合並你的javascript文件。
端由和處置辦法同上，不再贅言。
第二條：Use a Content Delivery Network 運用CDN
這個看中去好似頎長深的模樣，不過只要接合中國的網絡獨特的風格，這個便不難了解了。北方服務器、長江以南地區服務器、電相信和佩服務器、網通服務器這些個詞聽起來是那末知道得清楚和壓抑。假如，一個北京的電信譽戶打算從廣東的網通服務器上敞開一個大致相似《壁紙合集》帖子的網頁時，你就能很深刻的了解。
鑒於這個不是我們研發擔任職務的人力挽狂瀾的准則，所以這處也就無幾言了。
第三條：Add an Expires Header 添加周期頭
這個也並非研發擔任職務的人來扼制，而是網站服務器管理員的職務和責任。所以，假如作為研發擔任職務的人的你不成解和清楚也沒相關系。仍然把這個准則奉告企業的網站服務器管理員。
第四條：Gzip Components 開始使用Gzip壓縮
這個大家應當比較知道得清楚。Gzip的思想就是把文件先在服務器端施行壓縮，而後再傳道輸送。這對於大小較大的純書契型的文件有特效。鑒於這也並非研發擔任職務的人，而是網站服務器管理員的辦公范疇，這處就不詳解釋了。假如你對此有興致，可以此訊貴企業的網站服務器管理擔任職務的人。
第五條：Put CSS at the Top 把CSS式樣放在頁面的上方。
不管是HTML仍然XHTML仍然CSS都是詮釋型的語言，而非編譯型的。所以CSS到上方的話，那末瀏覽器解析結構的時刻，就已經可以對頁面施行渲染。這麼就不會顯露出來，頁面結構光禿禿的先出來，而後CSS渲染，頁面又忽然華美起來，這麼太具備詩劇性的頁面瀏覽體驗認識了。
第六條：Move Scripts to the Bottom 將腳本代碼放在底部
端由同第五條同樣。只是腳本代碼普通是用來於用戶交互的。所以假如頁面還沒有出來，用戶連頁面都不曉得啥子模樣，那談交互簡直就是扯談。所以，腳本代碼和CSS正巧相反，腳本代碼應當放在頁面的底部。
第七條：Avoid CSS Expressions 防止運用CSS中的Expressions
圖:CSS中的Expressions實際上也是一種if判斷首先有不可缺少先解釋明白一下子CSS Expressions是啥子一個物品。實際上它就像其他語言中的ifelse語句。這麼在CSS中就可以施行簡單的思維規律判斷了。舉個簡單的例子——
這麼css就可以根結一點事情狀況作別運用不一樣的式樣了。假如你對這個有興致可以到我的博客上閱覽有關的文章—— 《CSS中的expression系列文章》。不過CSS中Expressions 的代價卻是極高的。當你的頁面需求依據判斷來渲染效果的元素眾多的時刻，那末你的瀏覽器將長時期處於假死狀況，因此給用戶帶來極差的用戶體驗認識。
第八條：Make JavaScript and CSS External 將javascript和css獨立成外部文件
這一條好似和第1條有些矛盾。確實，假如從HTTP的request煩請數來講的話，這麼做確實是減低了速率。不過之所以這樣做，是由於額外一個關緊的思索問題因素——緩存。由於外部的援用文件會被瀏覽器緩存，所以假如javascript和css大小較大的時刻，我們將他們獨立成外部文件。這麼當用戶只要瀏覽一次往後，這些個大小較大的js和css文件就能被緩存起來，因此極高地增長用戶再次過訪時的速率。
第九條：Reduce DNS Lookups 減損DNS查問
DNS域名解析系統。大家都曉得我們之所以能記取那末多的網址，是由於我們記取的都是單詞，而非頁面，這句話看起來確實很知道得清楚。不過，我就奇怪了，為何不直接鏈接到那一個頁面呢?
2：一點鏈接地址請更明確的開具來。例如:將http://justinyoung.cnblogs.com/ 寫成http://justinyoung.cnblogs.com (注意最終面一個/符號)。確實，這兩個網址都能過訪到我的博客，不過，事情的真實情況上，他們是有差別的。http://justinyoung.cnblogs.com 的最後結果是個301響應，它會被從新指向http://justinyoung.cnblogs.com/ 。不過顯然，半中腰多耗費了一點時間。
第十二條 Remove Duplicate Scripts 移除重復的腳本代碼
圖:對重復說不!這個准則的道理很簡明易懂，不過真正在辦公中，眾多人卻由於項目時間緊、太累了、開始的一段時間沒有計劃好這麼的理由NULL就這樣過去了。你，確實可以找眾多的理由不去處置這些個駢枝重復的腳本，假如你的網站不必更高的速率和後期保護的話。
也正是這點，我提示大家一點，一點javascript框架、javascript包必須要慎用。至少要問一下子：用了這個js kit 到盡頭給我們若乾便捷，增長了若乾辦公速率。而後，再與它由於駢枝的、重復的代碼帶來的負面效果比較一下子。
第十三條：Configure ETags 配備布置你的實體標簽
首先來講講啥子是Etag吧。Etag(Entity tags )實體標簽。這個tag和你在網上常常看見的標簽雲那種tag有些差別。這個Etag不是給用戶用的，而是給瀏覽器緩存用的。Etag是服務器奉告瀏覽器緩存，緩存中的內部實質意義是否已經變樣的一種機制。經過Etag，瀏覽器就可以曉得如今的緩存中的內部實質意義是不是最新的，需不必從新從服務器上從新下載。這和Last-Modified的概念有些大致相似。很抱憾作為網頁研發擔任職務的人對此力不從心。他依舊是網站服務器擔任職務的人的辦公范疇。假如，你對此有興致，可以諮詢貴企業的網站服務器管理員。
第十四條：Make Ajax Cacheable 上頭的准則也適合使用Ajax
圖:Ajax的運用要妥當如今的Ajax好似有些被神話了，好似網頁只要Ajax了，那末就不存在速率問題了。實際上這是一種曲解。笨拙低劣的運用Ajax不會讓你的網頁速率更高，反倒會減低你的網頁速率。Ajax確實是個好物品，不過請不要麼為己甚的神話它。運用Ajax的時刻也要思索問題上頭的那一些准則。
後記：
當然，上頭的這些個也只是供你參照的理論上的准seo則。具體的事情狀況仍然要具體的去看待。理論和准則只是用來引導事實辦公的，卻是萬萬不可以死記硬套。