前端優(yōu)化之雅虎(Yahoo)軍規(guī)14條規(guī)則

相信很多人都聽過優(yōu)化網站性能的雅虎軍規(guī)14條規(guī)則勋篓,下面就詳細介紹一下這14條規(guī)則的優(yōu)化吧

第一條、盡可能的減少 HTTP 的請求數(shù) (Make Fewer HTTP Requests )

http請求是要開銷的者填,想辦法減少請求數(shù)自然可以提高網頁速度刻伊。常用的方法载佳,合并css炒事,js(將一個頁面中的css和js文件分別合并)以及 Image maps和css sprites等。當然或許將css蔫慧,js文件拆分多個是因為css結構挠乳,共用等方面的考慮。阿里巴巴中文站當時的做法是開發(fā)時依然分開開發(fā)姑躲,然后在后臺 對js睡扬,css進行合并,這樣對于瀏覽器來說依然是一個請求黍析,但是開發(fā)時仍然能還原成多個卖怜,方便管理和重復引用。yahoo甚至建議將首頁的css和js 直接寫在頁面文件里面阐枣,而不是外部引用马靠。因為首頁的訪問量太大了奄抽,這么做也可以減少兩個請求數(shù)。而事實上國內的很多門戶都是這么做的甩鳄。

而css sprites是指只用將頁面上的背景圖合并成一張逞度,然后通過css的background-position屬性定義不過的值來取他的背景。淘寶和阿里巴巴中文站目前都是這樣做的妙啃。有興趣的可以看下淘寶和阿里巴巴的背景圖档泽。

http://www.csssprites.com/ 這是個工具網站,它可以自動將你上傳的圖片合并并給出對應的background-position坐標揖赴。并將結果以png和gif的格式輸出馆匿。

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

說實話燥滑,對于CDN這一塊自己并不是很了解渐北,簡單地講,通過在現(xiàn)有的Internet中增加一層新的網絡架構铭拧,將網站的內容發(fā)布到最接近用戶的 cache服務器內腔稀,通過DNS負載均衡的技術,判斷用戶來源就近訪問cache服務器取得所需的內容羽历,杭州的用戶訪問近杭州服務器上的內容,北京的訪問 近北京服務器上的內容淡喜。這樣可以有效減少數(shù)據在網絡上傳輸?shù)臅r間秕磷,提高速度。更詳細地內容大家可以參考百度百科上對于CDN的解釋炼团。Yahoo!把靜態(tài)內容分布到CDN減少了用戶影響時間20%或更多澎嚣。

CDN技術示意圖:

image.png

CDN組網示意圖:

image.png

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

現(xiàn)在越來越多的圖片瘟芝,腳本易桃,css,flash被嵌入到頁面中锌俱,當我們訪問他們的時候勢必會做許多次的http請求晤郑。其實我們可以通過設置Expires header 來緩存這些文件。Expire其實就是通過header報文來指定特定類型的文件在覽器中的緩存時間贸宏。大多數(shù)的圖片造寝,flash在發(fā)布后都是不需要經常修改的,做了緩存以后這樣瀏覽器以后就不需要再從服務器下載這些文件而是而直接從緩存中讀取吭练,這樣再次訪問頁面的速度會大大加快诫龙。一個典型的HTTP 1.1協(xié)議返回的頭信息:

| 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可以完成。
想了解跟多的朋友可以參考http://www.web-caching.com/

據我了解鲫咽,目前阿里巴巴中文站的Expires過期時間是30天签赃。不過期間也有過問題谷异,特別是對于腳本過期時間的設置還是應該仔細考慮下,不然相應的腳本功能更新后客戶端可能要過很長一段時間才能“感知”到這樣的變化锦聊。所以歹嘹,哪些應該緩存,哪些不該緩存還是應該仔細斟酌一番括丁。

第四條荞下、啟用Gzip壓縮:Gzip Components

Gzip的思想就是把文件先在服務器端進行壓縮,然后再傳輸史飞。這樣可以顯著減少文件傳輸?shù)拇笮〖饣琛鬏斖戤吅鬄g覽器會 重新對壓縮過的內容進行解壓縮,并執(zhí)行构资。目前的瀏覽器都能“良好”地支持 gzip抽诉。不僅瀏覽器可以識別,而且各大“爬蟲”也同樣可以識別吐绵,各位seoer可以放下心了迹淌。而且gzip的壓縮比例非常大,一般壓縮率為85%己单,就是 說服務器端100K的頁面可以壓縮到25K左右再發(fā)送到客戶端唉窃。具體的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加載完畢

順著這層意思,如果我們再細究的話饲趋,其實還有可以優(yōu)化的地方拐揭。比如本站上面包含的兩個css文件,

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

將腳本放在頁面最下面的目的有那么兩點:

1堂污、 因為防止script腳本的執(zhí)行阻塞頁面的下載。在頁面loading的過程中龄砰,當瀏覽器讀到js執(zhí)行語句的時候一定會把它全部解釋完畢后在會接下來讀下 面的內容敷鸦。不信你可以寫一個js死循環(huán)看看頁面下面的東西還會不會出來。(setTimeout 和 setInterval的執(zhí)行有點類似于多線程寝贡,在相應的響應時間之前也會繼續(xù)下面的內容渲染。)瀏覽器這么做的邏輯是因為js隨時可能執(zhí) 行 location.href或是其他可能完全中斷此頁面過程的函數(shù)值依,即如此圃泡,當然得等他執(zhí)行完畢之后再加載咯。所以放在頁面最后愿险,可以有效減少頁面可 視元素的加載時間颇蜡。

2、腳本引起的第二個問題是它阻塞并行下載數(shù)量辆亏。HTTP/1.1規(guī)范建議瀏覽器每個主機的并行下載數(shù)不超過2個(IE只能為2個风秤,其他瀏覽器如ff等都是默認設置為2個,不過新出的ie8可以達6個)扮叨。因此如果您把圖像文件分布到多臺機器的話缤弦,您可以達到超過2個的并行下載。但是當腳本文件下載時彻磁,瀏覽器不會啟動其他的并行下載碍沐。

當然對各個網站來說狸捅,把腳本都放到頁面底部加載的可行性還是值得商榷的。就比如阿里巴巴中文站的頁面累提。很多地方有內聯(lián)的js尘喝,頁面的顯示嚴重依賴于此,我承認這和無侵入腳本的理念相差甚遠斋陪,但是很多“歷史遺留問題”卻不是那么容易解決的朽褪。

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

不過這樣就多了兩層無意義的嵌套无虚,肯定不好缔赠。還需要一個更好的辦法。

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

這點我想還是很容易理解的橡淑。不僅從性能優(yōu)化上會這么做,用代碼易于維護的角度看也應該這么做咆爽。把css和js寫在頁面內容可以減少2次請求梁棠,但也增 大了頁面的大小。如果已經對css和js做了緩存斗埂,那也就沒有2次多余的http請求了符糊。當然,我在前面中也說過呛凶,有些特殊的頁面開發(fā)人員還是會選擇內聯(lián) 的css和js文件男娄。

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

在 Internet上域名與IP地址之間是一一對應的漾稀,域名(kuqin.com)很好記模闲,但計算機不認識,計算機之間的“相認”還要轉成ip地址崭捍。在網絡 上每臺計算機都對應有一個獨立的ip地址尸折。在域名和ip地址之間的轉換工作稱為域名解析,也稱DNS查詢殷蛇。一次DNS的解析過程會消耗20-120毫秒的 時間,在dns查詢結束之前实夹,瀏覽器不會下載該域名下的任何東西。所以減少dns查詢的時間可以加快頁面的加載速度粒梦。yahoo的建議一個頁面所包含的域 名數(shù)盡量控制在2-4個亮航。這就需要對頁面整體有一個很好的規(guī)劃。目前我們這點做的不好匀们,很多打點的廣告投放系統(tǒng)拖累了我們缴淋。

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

壓縮js和css的左右很顯然,減少頁面字節(jié)數(shù)宴猾。容量小頁面加載速度自然也就快圆存。而且壓縮除了減少體積以外還可以起到一定的保護左右。這點我們做得不錯仇哆。常用的壓縮工具有JsMin沦辙、YUI compressor等。另外像http://dean.edwards.name/packer/還給我們提供了一個非常方便的在線壓縮工具讹剔。你可以在jQuery的網頁看到壓縮過的js文件和沒有壓縮過的js文件的容量差別:

image.png

當然油讯,壓縮帶來的一個弊端就是代碼的可讀性沒了。相信很多做前端的朋友都遇到過這個問題:看Google的效果很酷延欠,可是去看他的源代碼卻是一大堆 擠在一起的字符陌兑,連函數(shù)名都是替換過的,汗死由捎!自己的代碼也這樣豈不是對維護非常不方便兔综。所有阿里巴巴中文站目前采用的做法是在js和css發(fā)布的時候在 服務器端進行壓縮。這樣在我們很方便地維護自己的代碼狞玛。

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

不久前在ieblog上看到過《Internet Explorer and Connection Limits》這篇文章,比如 當你輸入http://www.kuqin.com/ 的時候服務器會自動產生一個301服務器轉向 http://www.kuqin.com/ 心肪,你看瀏覽器的地址欄就能看出來锭亏。這種重定向自然也是需要消耗時間的。當然這只是一個例子硬鞍,發(fā)生重定向的原因還有很多慧瘤,但是不變的是每增加一次重定向就會增加一次web請求,所以因該盡量減少固该。

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

這點我想不說也知道,不僅是從性能上考慮伐坏,代碼規(guī)范上看也是這樣怔匣。但是不得不承認,很多時候我們會因為圖一時之快而加上一些或許是重復的代碼著淆。或許一個統(tǒng)一的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是動態(tài)產生的而且只對一個用戶起作用屠升,他們依然可以被緩存。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
  • 序言:七十年代末狭郑,一起剝皮案震驚了整個濱河市腹暖,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌翰萨,老刑警劉巖脏答,帶你破解...
    沈念sama閱讀 207,113評論 6 481
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異亩鬼,居然都是意外死亡殖告,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,644評論 2 381
  • 文/潘曉璐 我一進店門辛孵,熙熙樓的掌柜王于貴愁眉苦臉地迎上來丛肮,“玉大人,你說我怎么就攤上這事魄缚”τ耄” “怎么了?”我有些...
    開封第一講書人閱讀 153,340評論 0 344
  • 文/不壞的土叔 我叫張陵冶匹,是天一觀的道長习劫。 經常有香客問我,道長嚼隘,這世上最難降的妖魔是什么诽里? 我笑而不...
    開封第一講書人閱讀 55,449評論 1 279
  • 正文 為了忘掉前任,我火速辦了婚禮飞蛹,結果婚禮上谤狡,老公的妹妹穿的比我還像新娘。我一直安慰自己卧檐,他們只是感情好墓懂,可當我...
    茶點故事閱讀 64,445評論 5 374
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著霉囚,像睡著了一般捕仔。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 49,166評論 1 284
  • 那天榜跌,我揣著相機與錄音闪唆,去河邊找鬼。 笑死钓葫,一個胖子當著我的面吹牛悄蕾,可吹牛的內容都是我干的。 我是一名探鬼主播瓤逼,決...
    沈念sama閱讀 38,442評論 3 401
  • 文/蒼蘭香墨 我猛地睜開眼笼吟,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了霸旗?” 一聲冷哼從身側響起贷帮,我...
    開封第一講書人閱讀 37,105評論 0 261
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎诱告,沒想到半個月后撵枢,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經...
    沈念sama閱讀 43,601評論 1 300
  • 正文 獨居荒郊野嶺守林人離奇死亡精居,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 36,066評論 2 325
  • 正文 我和宋清朗相戀三年锄禽,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片靴姿。...
    茶點故事閱讀 38,161評論 1 334
  • 序言:一個原本活蹦亂跳的男人離奇死亡沃但,死狀恐怖,靈堂內的尸體忽然破棺而出佛吓,到底是詐尸還是另有隱情宵晚,我是刑警寧澤,帶...
    沈念sama閱讀 33,792評論 4 323
  • 正文 年R本政府宣布维雇,位于F島的核電站淤刃,受9級特大地震影響,放射性物質發(fā)生泄漏吱型。R本人自食惡果不足惜逸贾,卻給世界環(huán)境...
    茶點故事閱讀 39,351評論 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望津滞。 院中可真熱鬧铝侵,春花似錦、人聲如沸触徐。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,352評論 0 19
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽锌介。三九已至嗜诀,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間孔祸,已是汗流浹背隆敢。 一陣腳步聲響...
    開封第一講書人閱讀 31,584評論 1 261
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留崔慧,地道東北人拂蝎。 一個月前我還...
    沈念sama閱讀 45,618評論 2 355
  • 正文 我出身青樓,卻偏偏與公主長得像惶室,于是被迫代替她去往敵國和親温自。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 42,916評論 2 344

推薦閱讀更多精彩內容

  • Yahoo!的Exceptional Performance團隊為改善Web性能帶來最佳實踐皇钞。他們?yōu)榇诉M行了一系列...
    拉風的老衲閱讀 1,834評論 0 1
  • 網站優(yōu)化離不開前后端的互相協(xié)作悼泌,但是對于前端工程師來說,在保證后端技術方案不變時夹界,能不能只利用前端技術來優(yōu)化網站呢...
    留七七閱讀 6,307評論 0 31
  • 問答題47 /72 常見瀏覽器兼容性問題與解決方案馆里? 參考答案 (1)瀏覽器兼容問題一:不同瀏覽器的標簽默認的外補...
    _Yfling閱讀 13,728評論 1 92
  • 日歷馬上就要翻到新的一年,以往每年的這個時候都會在本子上寫一句:新年新氣象可柿!然后心懷憧憬繼續(xù)混天度日鸠踪,從沒覺得有何...
    千語千竹閱讀 226評論 0 0
  • 媽媽說,今天請馮姨來家里吃飯复斥。于是那一天有了內容 有了希冀有了快樂和意義营密,仿佛其他日期都不曾真的活過一樣。 馮姨給...
    煜煙閱讀 424評論 3 4