摘要:自己是做前端開(kāi)發(fā)的,在性能方面,根據(jù)的調(diào)查,后臺(tái)只占,而前端高達(dá)之多,其中有的東西是可以優(yōu)化的。相信很多人都聽(tīng)過(guò)優(yōu)化網(wǎng)站性能的條規(guī)則。淘寶和阿里巴巴中文站目前都是這樣做的。目前的瀏覽器都能良好地支持。
相信互聯(lián)網(wǎng)已經(jīng)越來(lái)越成為人們生活中不可或缺的一部分。Ajax,flex等等富客戶端的應(yīng)用使得人們?cè)郊印靶腋!钡伢w驗(yàn)著許多原先只能在C/S實(shí)現(xiàn)的功能。比如Google機(jī)會(huì)已經(jīng)把最基本的office應(yīng)用都搬到了互聯(lián)網(wǎng)上。當(dāng)然便利的同時(shí)毫無(wú)疑問(wèn)的也使頁(yè)面的速度越來(lái)越慢。自己是做前端開(kāi)發(fā)的,在性能方面,根據(jù)Yahoo的調(diào)查,后臺(tái)只占5%,而前端高達(dá)95%之多,其中有88%的東西是可以優(yōu)化的。
以上是一張web2.0頁(yè)面的生命周期圖。工程師很形象地講它分成了“懷孕,出生,畢業(yè),結(jié)婚”四個(gè)階段。如果在我們點(diǎn)擊網(wǎng)頁(yè)鏈接的時(shí)候能夠意識(shí)到 這個(gè)過(guò)程而不是簡(jiǎn)單的請(qǐng)求-響應(yīng)的話,我們便可以挖掘出很多細(xì)節(jié)上可以提升性能的東西。今天聽(tīng)了淘寶小馬哥的一個(gè)對(duì)yahoo開(kāi)發(fā)團(tuán)隊(duì)對(duì)web性能研究的 一個(gè)講座,感覺(jué)收獲很大,想在blog上做個(gè)分享。
相信很多人都聽(tīng)過(guò)優(yōu)化網(wǎng)站性能的14條規(guī)則。更多的信息可見(jiàn) developer.yahoo.com
第一條、盡可能的減少 HTTP 的請(qǐng)求數(shù) (Make Fewer HTTP Requests )
http請(qǐng)求是要開(kāi)銷的,想辦法減少請(qǐng)求數(shù)自然可以提高網(wǎng)頁(yè)速度。常用的方法,合并css,js(將一個(gè)頁(yè)面中的css和js文件分別合并)以及 Image maps和css sprites等。當(dāng)然或許將css,js文件拆分多個(gè)是因?yàn)閏ss結(jié)構(gòu),共用等方面的考慮。阿里巴巴中文站當(dāng)時(shí)的做法是開(kāi)發(fā)時(shí)依然分開(kāi)開(kāi)發(fā),然后在后臺(tái) 對(duì)js,css進(jìn)行合并,這樣對(duì)于瀏覽器來(lái)說(shuō)依然是一個(gè)請(qǐng)求,但是開(kāi)發(fā)時(shí)仍然能還原成多個(gè),方便管理和重復(fù)引用。yahoo甚至建議將首頁(yè)的css和js 直接寫在頁(yè)面文件里面,而不是外部引用。因?yàn)槭醉?yè)的訪問(wèn)量太大了,這么做也可以減少兩個(gè)請(qǐng)求數(shù)。而事實(shí)上國(guó)內(nèi)的很多門戶都是這么做的。
而css sprites是指只用將頁(yè)面上的背景圖合并成一張,然后通過(guò)css的background-position屬性定義不過(guò)的值來(lái)取他的背景。淘寶和阿里巴巴中文站目前都是這樣做的。有興趣的可以看下淘寶和阿里巴巴的背景圖。http://www.csssprites.com/ 這是個(gè)工具網(wǎng)站,它可以自動(dòng)將你上傳的圖片合并并給出對(duì)應(yīng)的background-position坐標(biāo)。并將結(jié)果以png和gif的格式輸出。
第二條、使用CDN(內(nèi)容分發(fā)網(wǎng)絡(luò)): Use a Content Delivery Network
說(shuō)實(shí)話,對(duì)于CDN這一塊自己并不是很了解,簡(jiǎn)單地講,通過(guò)在現(xiàn)有的Internet中增加一層新的網(wǎng)絡(luò)架構(gòu),將網(wǎng)站的內(nèi)容發(fā)布到最接近用戶的 cache服務(wù)器內(nèi),通過(guò)DNS負(fù)載均衡的技術(shù),判斷用戶來(lái)源就近訪問(wèn)cache服務(wù)器取得所需的內(nèi)容,杭州的用戶訪問(wèn)近杭州服務(wù)器上的內(nèi)容,北京的訪問(wèn) 近北京服務(wù)器上的內(nèi)容。這樣可以有效減少數(shù)據(jù)在網(wǎng)絡(luò)上傳輸?shù)臅r(shí)間,提高速度。更詳細(xì)地內(nèi)容大家可以參考百度百科上對(duì)于CDN的解釋。Yahoo!把靜態(tài)內(nèi)容分布到CDN減少了用戶影響時(shí)間20%或更多。
CDN技術(shù)示意圖:
CDN組網(wǎng)示意圖:
第三條、 添加Expire/Cache-Control 頭:Add an Expires Header
現(xiàn)在越來(lái)越多的圖片,腳本,css,flash被嵌入到頁(yè)面中,當(dāng)我們?cè)L問(wèn)他們的時(shí)候勢(shì)必會(huì)做許多次的http請(qǐng)求。其實(shí)我們可以通過(guò)設(shè)置Expires header 來(lái)緩存這些文件。Expire其實(shí)就是通過(guò)header報(bào)文來(lái)指定特定類型的文件在覽器中的緩存時(shí)間。大多數(shù)的圖片,flash在發(fā)布后都是不需要經(jīng)常修改的,做了緩存以后這樣瀏覽器以后就不需要再?gòu)姆?wù)器下載這些文件而是而直接從緩存中讀取,這樣再次訪問(wèn)頁(yè)面的速度會(huì)大大加快。一個(gè)典型的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
其中通過(guò)服務(wù)器端腳本設(shè)置Cache-Control和Expires可以完成。
如,在php中設(shè)置30天后過(guò)期:
pHeader("Cache-Control: must-revalidate"); $offset = 60 * 60 * 24 * 30; $ExpStr = "Expires: " . gmdate("D, d M Y H:i:s", time() + $offset) . " GMT"; Header($ExpStr);
也可以通過(guò)配置服務(wù)器本身完成,這些偶就不是很清楚了,呵呵。想了解跟多的朋友可以參考http://www.web-caching.com/
據(jù)我了解,目前阿里巴巴中文站的Expires過(guò)期時(shí)間是30天。不過(guò)期間也有過(guò)問(wèn)題,特別是對(duì)于腳本過(guò)期時(shí)間的設(shè)置還是應(yīng)該仔細(xì)考慮下,不然相應(yīng)的腳本功能更新后客戶端可能要過(guò)很長(zhǎng)一段時(shí)間才能“感知”到這樣的變化。所以,哪些應(yīng)該緩存,哪些不該緩存還是應(yīng)該仔細(xì)斟酌一番。
第四條、啟用Gzip壓縮:Gzip Components
Gzip的思想就是把文件先在服務(wù)器端進(jìn)行壓縮,然后再傳輸。這樣可以顯著減少文件傳輸?shù)拇笮 鬏斖戤吅鬄g覽器會(huì) 重新對(duì)壓縮過(guò)的內(nèi)容進(jìn)行解壓縮,并執(zhí)行。目前的瀏覽器都能“良好”地支持 gzip。不僅瀏覽器可以識(shí)別,而且各大“爬蟲(chóng)”也同樣可以識(shí)別,各位seoer可以放下心了。而且gzip的壓縮比例非常大,一般壓縮率為85%,就是 說(shuō)服務(wù)器端100K的頁(yè)面可以壓縮到25K左右再發(fā)送到客戶端。具體的Gzip壓縮原理大家可以參考csdn上的《gzip壓縮算法》 這篇文章。雅虎特別強(qiáng)調(diào), 所有的文本內(nèi)容都應(yīng)該被gzip壓縮: html (php), js, css, xml, txt… 這一點(diǎn)我們網(wǎng)站做得不錯(cuò),是一個(gè)A。以前我們的首頁(yè)也并不是A,因?yàn)槭醉?yè)上還有很多廣告代碼投放的js,這些廣告代碼擁有者的網(wǎng)站的js沒(méi)有經(jīng)過(guò)gzip壓縮,也會(huì)拖累我們網(wǎng)站。
以上三點(diǎn)大多屬于服務(wù)器端的內(nèi)容,本人也是粗淺地了解而已。說(shuō)得不對(duì)的地方有待各位指正。
第五條、將css放在頁(yè)面最上面 ( Put Stylesheets at the Top)
將css放在頁(yè)面最上面,這是為什么?因?yàn)?ie,firefox等瀏覽器在css全部傳輸完全之前不會(huì)去渲染任何的東西。理由誠(chéng)如小馬哥說(shuō)得那樣很簡(jiǎn)單。css,全稱Cascading Style Sheets (層疊樣式表單)。層疊即意味這后面的css可以覆蓋前面的css,級(jí)別高的css可以覆蓋級(jí)別低的css。在[css之!important] 這篇文章的最下面曾簡(jiǎn)單地提到過(guò)這層級(jí)關(guān)系,這里我們只需要知道css可以被覆蓋的。既然前面的可以被覆蓋,瀏覽器在他完全加載完畢之后再去渲染無(wú)疑也是合情合理的很多瀏覽器下,如IE,把樣式表放在頁(yè)面的底部的問(wèn)題在于它禁止了網(wǎng)頁(yè)內(nèi)容的順序顯示。瀏覽器阻止顯示以免重畫頁(yè)面元素,那用戶只能看到空白頁(yè)了。Firefox不會(huì)阻止顯示,但這意味著當(dāng)樣式表下載后,有些頁(yè)面元素可能需要重畫,這導(dǎo)致閃爍問(wèn)題。所以我們應(yīng)該盡快讓css加載完畢
順著這層意思,如果我們?cè)偌?xì)究的話,其實(shí)還有可以優(yōu)化的地方。比如本站上面包含的兩個(gè)css文件,
第六條、將script放在頁(yè)面最下面 (Put Scripts at the Bottom )
將腳本放在頁(yè)面最下面的目的有那么兩點(diǎn): 1、 因?yàn)榉乐箂cript腳本的執(zhí)行阻塞頁(yè)面的下載。在頁(yè)面loading的過(guò)程中,當(dāng)瀏覽器讀到j(luò)s執(zhí)行語(yǔ)句的時(shí)候一定會(huì)把它全部解釋完畢后在會(huì)接下來(lái)讀下 面的內(nèi)容。不信你可以寫一個(gè)js死循環(huán)看看頁(yè)面下面的東西還會(huì)不會(huì)出來(lái)。(setTimeout 和 setInterval的執(zhí)行有點(diǎn)類似于多線程,在相應(yīng)的響應(yīng)時(shí)間之前也會(huì)繼續(xù)下面的內(nèi)容渲染。)瀏覽器這么做的邏輯是因?yàn)閖s隨時(shí)可能執(zhí) 行 location.href或是其他可能完全中斷此頁(yè)面過(guò)程的函數(shù),即如此,當(dāng)然得等他執(zhí)行完畢之后再加載咯。所以放在頁(yè)面最后,可以有效減少頁(yè)面可 視元素的加載時(shí)間。 2、腳本引起的第二個(gè)問(wèn)題是它阻塞并行下載數(shù)量。HTTP/1.1規(guī)范建議瀏覽器每個(gè)主機(jī)的并行下載數(shù)不超過(guò)2個(gè)(IE只能為2個(gè),其他瀏覽器如ff等都是默認(rèn)設(shè)置為2個(gè),不過(guò)新出的ie8可以達(dá)6個(gè))。因此如果您把圖像文件分布到多臺(tái)機(jī)器的話,您可以達(dá)到超過(guò)2個(gè)的并行下載。但是當(dāng)腳本文件下載時(shí),瀏覽器不會(huì)啟動(dòng)其他的并行下載。
當(dāng)然對(duì)各個(gè)網(wǎng)站來(lái)說(shuō),把腳本都放到頁(yè)面底部加載的可行性還是值得商榷的。就比如阿里巴巴中文站的頁(yè)面。很多地方有內(nèi)聯(lián)的js,頁(yè)面的顯示嚴(yán)重依賴于此,我承認(rèn)這和無(wú)侵入腳本的理念相差甚遠(yuǎn),但是很多“歷史遺留問(wèn)題”卻不是那么容易解決的。
第七條、避免在CSS中使用Expressions (Avoid CSS Expressions )
不過(guò)這樣就多了兩層無(wú)意義的嵌套,肯定不好。還需要一個(gè)更好的辦法。
第八條、把javascript和css都放到外部文件中 (Make JavaScript and CSS External )
這點(diǎn)我想還是很容易理解的。不僅從性能優(yōu)化上會(huì)這么做,用代碼易于維護(hù)的角度看也應(yīng)該這么做。把css和js寫在頁(yè)面內(nèi)容可以減少2次請(qǐng)求,但也增 大了頁(yè)面的大小。如果已經(jīng)對(duì)css和js做了緩存,那也就沒(méi)有2次多余的http請(qǐng)求了。當(dāng)然,我在前面中也說(shuō)過(guò),有些特殊的頁(yè)面開(kāi)發(fā)人員還是會(huì)選擇內(nèi)聯(lián) 的css和js文件。
第九條、減少DNS查詢 (Reduce DNS Lookups)
在 Internet上域名與IP地址之間是一一對(duì)應(yīng)的,域名(kuqin.com)很好記,但計(jì)算機(jī)不認(rèn)識(shí),計(jì)算機(jī)之間的“相認(rèn)”還要轉(zhuǎn)成ip地址。在網(wǎng)絡(luò) 上每臺(tái)計(jì)算機(jī)都對(duì)應(yīng)有一個(gè)獨(dú)立的ip地址。在域名和ip地址之間的轉(zhuǎn)換工作稱為域名解析,也稱DNS查詢。一次DNS的解析過(guò)程會(huì)消耗20-120毫秒的 時(shí)間,在dns查詢結(jié)束之前,瀏覽器不會(huì)下載該域名下的任何東西。所以減少dns查詢的時(shí)間可以加快頁(yè)面的加載速度。yahoo的建議一個(gè)頁(yè)面所包含的域 名數(shù)盡量控制在2-4個(gè)。這就需要對(duì)頁(yè)面整體有一個(gè)很好的規(guī)劃。目前我們這點(diǎn)做的不好,很多打點(diǎn)的廣告投放系統(tǒng)拖累了我們。
第十條、壓縮 JavaScript 和 CSS (Minify JavaScript )
壓縮js和css的左右很顯然,減少頁(yè)面字節(jié)數(shù)。容量小頁(yè)面加載速度自然也就快。而且壓縮除了減少體積以外還可以起到一定的保護(hù)左右。這點(diǎn)我們做得不錯(cuò)。常用的壓縮工具有JsMin、YUI compressor等。另外像http://dean.edwards.name/packer/還給我們提供了一個(gè)非常方便的在線壓縮工具。你可以在jQuery的網(wǎng)頁(yè)看到壓縮過(guò)的js文件和沒(méi)有壓縮過(guò)的js文件的容量差別:
當(dāng)然,壓縮帶來(lái)的一個(gè)弊端就是代碼的可讀性沒(méi)了。相信很多做前端的朋友都遇到過(guò)這個(gè)問(wèn)題:看Google的效果很酷,可是去看他的源代碼卻是一大堆 擠在一起的字符,連函數(shù)名都是替換過(guò)的,汗死!自己的代碼也這樣豈不是對(duì)維護(hù)非常不方便。所有阿里巴巴中文站目前采用的做法是在js和css發(fā)布的時(shí)候在 服務(wù)器端進(jìn)行壓縮。這樣在我們很方便地維護(hù)自己的代碼。
第十一條、避免重定向 (Avoid Redirects )
不久前在ieblog上看到過(guò)《Internet Explorer and Connection Limits》這篇文章,比如 當(dāng)你輸入http://www.kuqin.com/ 的時(shí)候服務(wù)器會(huì)自動(dòng)產(chǎn)生一個(gè)301服務(wù)器轉(zhuǎn)向 http://www.kuqin.com/ ,你看瀏覽器的地址欄就能看出來(lái)。這種重定向自然也是需要消耗時(shí)間的。當(dāng)然這只是一個(gè)例子,發(fā)生重定向的原因還有很多,但是不變的是每增加一次重定向就會(huì)增加一次web請(qǐng)求,所以因該盡量減少。
第十二條、移除重復(fù)的腳本 (Remove Duplicate Scripts )
這點(diǎn)我想不說(shuō)也知道,不僅是從性能上考慮,代碼規(guī)范上看也是這樣。但是不得不承認(rèn),很多時(shí)候我們會(huì)因?yàn)閳D一時(shí)之快而加上一些或許是重復(fù)的代碼。或許一個(gè)統(tǒng)一的css框架和js框架可以比較好的解決我們的問(wèn)題。小豬的觀點(diǎn)很對(duì),不僅是要做到不重復(fù),更是要做到可重用。
第十三條、配置實(shí)體標(biāo)簽(ETags) (Configure ETags )
這點(diǎn)我也不懂,呵呵。在inforQ上找到一篇解釋得比較詳細(xì)的說(shuō)明《使用ETags減少Web應(yīng)用帶寬和負(fù)載》,有興趣的同學(xué)可以去看看。
第十四條、使 AJAX 緩存 (Make Ajax Cacheable )
ajax還要去緩存?做ajax請(qǐng)求的時(shí)候往往還要增加一個(gè)時(shí)間戳去避免他緩存。It’s important to remember that “asynchronous” does not imply “instantaneous”.(記住“異步”不是“瞬間”這一點(diǎn)很重要)。記住,即使AJAX是動(dòng)態(tài)產(chǎn)生的而且只對(duì)一個(gè)用戶起作用,他們依然可以被緩 存。
以上內(nèi)容轉(zhuǎn)自:http://www.itokit.com/2012/0704/74572.html
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://specialneedsforspecialkids.com/yun/85624.html
摘要:自己是做前端開(kāi)發(fā)的,在性能方面,根據(jù)的調(diào)查,后臺(tái)只占,而前端高達(dá)之多,其中有的東西是可以優(yōu)化的。相信很多人都聽(tīng)過(guò)優(yōu)化網(wǎng)站性能的條規(guī)則。淘寶和阿里巴巴中文站目前都是這樣做的。目前的瀏覽器都能良好地支持。 相信互聯(lián)網(wǎng)已經(jīng)越來(lái)越成為人們生活中不可或缺的一部分。Ajax,flex等等富客戶端的應(yīng)用使得人們?cè)郊有腋5伢w驗(yàn)著許多原先只能在C/S實(shí)現(xiàn)的功能。比如Google機(jī)會(huì)已經(jīng)把最基本的o...
摘要:規(guī)則使用內(nèi)容發(fā)布網(wǎng)絡(luò)用戶同服務(wù)器的距離會(huì)對(duì)頁(yè)面響應(yīng)時(shí)間產(chǎn)生影響。這不僅能達(dá)到響應(yīng)時(shí)間大幅減少的目的,還很容易實(shí)現(xiàn)。提供動(dòng)態(tài)頁(yè)面會(huì)引入特殊的存儲(chǔ)要求數(shù)據(jù)庫(kù)連接狀態(tài)管理驗(yàn)證硬件和優(yōu)化等,這些復(fù)雜性超過(guò)了的范圍。 鏈接參考: https://developer.yahoo.com/performance/rules.html 只有10%~20%的最終用戶響應(yīng)時(shí)間花在了下載HTML文檔上...
摘要:我從沒(méi)有聽(tīng)到有人問(wèn)如何做一名優(yōu)秀甚至卓越的前端工程師。作為一個(gè)優(yōu)秀的前端工程師還需要深入了解以及學(xué)會(huì)處理的這些缺陷。再者,優(yōu)秀的前端工程師需要具備良好的溝通能力,因?yàn)榍岸斯こ處熤辽俣家獫M足四類客戶的需求。 我所遇到的前端程序員分兩種: 第一種一直在問(wèn):如何學(xué)習(xí)前端? 第二種總說(shuō):前端很簡(jiǎn)單,就那么一點(diǎn)東西。 我從沒(méi)有聽(tīng)到有人問(wèn):如何做一名優(yōu)秀、甚至卓越的WEB前端工程師...
摘要:我從沒(méi)有聽(tīng)到有人問(wèn)如何做一名優(yōu)秀甚至卓越的前端工程師。作為一個(gè)優(yōu)秀的前端工程師還需要深入了解以及學(xué)會(huì)處理的這些缺陷。再者,優(yōu)秀的前端工程師需要具備良好的溝通能力,因?yàn)榍岸斯こ處熤辽俣家獫M足四類客戶的需求。 我所遇到的前端程序員分兩種: 第一種一直在問(wèn):如何學(xué)習(xí)前端? 第二種總說(shuō):前端很簡(jiǎn)單,就那么一點(diǎn)東西。 我從沒(méi)有聽(tīng)到有人問(wèn):如何做一名優(yōu)秀、甚至卓越的WEB前端工程師...
閱讀 3316·2021-11-16 11:45
閱讀 4385·2021-09-22 15:38
閱讀 2841·2021-09-22 15:26
閱讀 3347·2021-09-01 10:48
閱讀 827·2019-08-30 15:56
閱讀 715·2019-08-29 13:58
閱讀 1487·2019-08-28 18:00
閱讀 2160·2019-08-27 10:53