只有10-20%的最終用戶響應時間花在了下載HTML文檔上。其余的80-90%時間花在了下載頁面中的所有組件上。
HTTP概述
-
壓縮
-
條件GET請求
-
Expire
-
Keep-Alive
規則1、減少HTTP請求
-
圖片地圖:將多個圖片合并成一個,而后通過css定位顯示不同的位置
-
CSS Sprites:同上
-
內聯圖片
-
合并腳本和樣式表
規則2、使用內容發布網絡(CDN,Content Delivery Network)
規則3、添加Expires頭
-
Expires頭:在這一日期/時間之后,響應將被認為是無效的
-
Max-Age: 設置相對有效時間Cache-Control:max-age=100
-
空緩存VS完整緩存:盡可能將頁面內容放入大緩存中
-
不僅僅是圖片:圖片應該使用緩存,但這一優質實踐不應該僅限于圖片
-
修訂文件名:為能夠獲取最新的文件,最有效的解決方案是修改其所有鏈接,這樣,全新的請求將從原始服務器下載最新的內容。
規則4、壓縮組件
-
gzip:Accept-Encoding:gzip,deflate。gzip是目前最流行和最有效的壓縮方法,是最理想的壓縮方法
-
壓縮內容:壓縮腳本和樣式表是非常值得的,同時還有XML和JSON在內的文本。圖片和PDF不應該壓縮,因為它們本來就已經被壓縮了。
-
節省率:壓縮通常能將響應的數據量減少將近70%
-
gzip配置:不同的web服務器有不同的gzip配置方式,但大多支持gzip
-
代理緩存:Web服務器基于Accept-Encoding來檢測是否對響應進行壓縮。不管是否壓縮過,瀏覽器都會基于響應中的其他HTTP頭如Expires和Cache-Control來緩存響應。由于壓縮的決定是基于Accept-Encoding請求頭的,因此需要在服務器的Vary響應頭中包含Accept-Encoding。
-
邊緣情形:服務器和客戶端的壓縮對等性看似簡單,但必須正確才行。無論是客戶端還是服務器發生錯誤(發送壓縮內容到不支持它的客戶端、忘記將壓縮內容聲明為已經進行了gzip編碼等),頁面都會被破壞。錯誤并不會經常發生,但它們是必須考慮的邊緣情形(Edge Case)。這種情況雖然可以通過瀏覽器白名單方式解決,但設置瀏覽器白名單的指令過于復雜,無法使用HTTP頭進行編碼。優質做法是將User-Agent作為代理的另外一種判斷標準添加到Vary頭中Vary:Accept-Encoding,User-Agent
規則5、將樣式表放在頂部
規則5對于加載頁面所需的實際時間沒有太多影響,它影響更多的是瀏覽器對這些組件順序的反應。為避免當樣式變化時重繪頁面中的元素,瀏覽器會等待位于底部的樣式表加載完成后才會呈現,這時瀏覽器會延遲任何可視化組件。實際上,用戶感覺緩慢的頁面反而是可視化組建加載得更快的頁面。使用LINK標簽將樣式表放在文檔的HEAD中可以解決該問題。
在使用樣式表時,頁面逐步呈現會被阻止,直到所有的樣式表下載完成。將樣式表移到文檔head中,這樣就能首先下載它們而不會阻止頁面呈現。
規則6、將腳本放在底部
-
并行下載 對響應時間影響的是頁面中組件的數量,如果一個Web頁面平均地將其組件分別放在兩個主機名下,整體響應時間將可以減少大約一半。但并行下載數量并不是越多越快,因為增加并行下載數量是有開銷的,其優劣取決于帶寬和cpu速度。
-
腳本阻塞下載 并行下載組件的優點是很明顯的,然而,在下載腳本時并行下載實際上被禁用的。即使使用了不同的主機名,瀏覽器也不會啟動其他的下載。其中一個原因是,腳本可能使用document.write來修改頁面內容,因此瀏覽器會等待,已確保頁面能夠恰當地布局。另一個原因是為了保證腳本能夠按照正確的順序執行。
在使用腳本時,對于所有位于腳本以下的內容,逐步呈現都被阻塞了。將腳本放在頁面越靠下的地方,意味著越多的內容能逐步地呈現。
規則7、避免css表達式
規則8、使用外部JavaScript和Css
-
純碎而言,內聯快一些
-
頁面查看 每個用戶產生的頁面查看越少,內聯JavaScript和Css的論據越強勢。另一方面,如果普通用戶能夠產生很多的頁面查看,瀏覽器很可能將(具有長久的Expires頭的)外部文件放在其緩存中。
-
組件重用 如果你的網站中的每一個頁面都使用了相同的JavaScript和Css,使用外部文件可以提高這些組件的重用率。在這種情況下使用外部文件更加具有優勢,因為當用戶在頁面間瀏覽時,JavaScript和Css組件已經位于瀏覽器的緩存中了。
-
動態內聯 如果主頁服務器知道一個組件是否在瀏覽器的緩存中,它可以在內聯和使用外部文件之間做出優質選擇。盡管服務器不能查看瀏覽器緩存中有些什么,但可以用cookies做指示器。如果cookie不存在,就內聯了JavaScript和Css。如果cookie出現了,則有可能外部組件位于瀏覽器的緩存中,并使用了外部文件。
規則9、減少DNS查找
Internet是通過IP地址來查找服務器的。由于IP地址很難記憶,通常使用包含主機名的URL來取代它,但當瀏覽器發送其請求時,IP地址仍然是必需的。這就是Domain Name System(DNS) 所處的角色。DNS也有開銷,通常瀏覽器查找一個給定的主機名的IP地址要花費20-120毫秒。響應時間依賴于DNS解析器(通常由你的ISP提供)、它所承擔的請求壓力、你與它之間的距離和你的帶寬速度。
-
DNS緩存 DNS查找可以被緩存起來提高性能。這種緩存可以發生在由你的ISP或局域網中的一臺特殊的緩存服務器上,但這里探討的是發生在獨立用戶的計算機上的DNS緩存。在用戶請求了一個主機名之后,DNS信息會留在操作系統的DNS緩存中,之后對于該主機名的請求將無需進行過多的DNS查找,至少短時間內不需要?!?
-
影響DNS緩存的因素 首先,服務器可以表明記錄可以被緩存多久。查找返回的DNS記錄包含了一個存活時間(Time-to-live,TTL)值。該值告訴客戶端可以對該記錄緩存多久,盡管操作系統緩存會考慮TTL值,但瀏覽器通常忽略該值,并設置它自己的時間限制。另外瀏覽器對緩存的DNS記錄的數量也有限制,TTL設置值通常是1天。
-
減少DNS查找 當客戶端的DNS緩存為空(瀏覽器和操作系統都是)時,DNS查找的數量與Web頁面中唯一主機名的數量相等。這包括頁面URL、圖片、腳本文件、樣式表、Flash對象等的主機名。減少唯一主機名的數量就可以就可以減少DNS查找的數量。
-
通過使用Keep-Alive和較少的域名來減少DNS查找
規則10、精簡JavaScript
JavaScript作為一門解釋型語言,是構建Web頁面的選。當以快速原型為基準開發用戶界面時,解釋語言要優于其他語言。
-
精簡 是從代碼中移除不必要的字符以減少其大小,進而改善加載時間的實踐。在代碼被精簡后,所有的注釋以及不必要的空白字符(空格、換行和制表符)都將被移除。對于JavaScript而言,這可以改善響應時間效率,因為需要下載的文件大小減少了。精簡JavaScript最流行的工具是JSMin。
-
混淆 是可以應用在源代碼上的另外一種優化方式。和精簡一樣,它也會移除注釋和空白,同時它還會改寫代碼。作為改寫的一部分,函數和變量的名字將被轉換為更短的字符串,這時的代碼更加精煉。但是會帶來三個弊端:可能引入錯誤、增加調試難度、需要對JavaScript關鍵字標記
-
內聯腳本 內聯的JavaScript塊也應該精簡
規則11、避免重定向
重定向用于將用戶從一個URL重新路由到另一個URL,種類有很多,常用的是301和302。它是損傷性能的,可以采用Alias、mod_rewirte、DirectorySlash和直接連接代碼來避免重定向。
規則12、移除重復腳本
-
重復腳本--確有其事 開發一個網站需要極大數量的資源,除了核心團隊要構建網站外,其他團隊也會向頁面貢獻HTML代碼。由于來自不同團隊的很多人都要向頁面中添加HTML,很容易想到相同的腳本可能會被添加多次
-
重復腳本傷害性能 引起不必要的HTTP請求和執行JavaScript所消耗的時間
規則13、配置ETag
實體標簽(Entity Tag,ETag)是Web服務器和瀏覽器用于確認緩存組件的有效性的一種機制。減少呈現頁面時所必需的HTTP請求的數量是加速用戶體驗的優質方式??梢酝ㄟ^化瀏覽器緩存組件的能力來實現這一目標,但當網站被宿主在多于一臺服務器上時,ETag頭可能會阻礙緩存。
ETag帶來的問題 ETag的問題在于,通常使用組件的某些屬性來構造它,這些屬性對于特定的、寄宿了網站的服務器來說是唯一的。當瀏覽器從一臺服務器上獲取了原始組件,之后又向另外一臺不同的服務器發起條件GET請求時,ETag是不會匹配的----而對于使用服務器集群來處理請求的網站來說,這是很常見的一種情況。默認情況下,對于擁有多臺服務器的網站,Apache和IIS向ETag中嵌入的數據都會大大地降低有效性驗證的成功率。
解決該問題的兩種方式:選擇ETag的配置方式或者直接移除ETag
規則14、使Ajax可緩存
Ajax表示異步JavaScript和XML(Asynchronous JavaScript and XML),盡管今天除了XML有很多其他選擇,最著名的是JSON。Ajax的目的是為了突破Web本質的開始--停止交互方式。向用戶顯示一個白屏然后重繪整個頁面不是一種后的用戶體驗。而Ajax在UI和Web服務器之間插入了一層。這個Ajax層位于客戶端,與Web服務器進行交互以獲取請求的信息,并與表現層交互,僅更新哪些必要的組件。它將Web體驗從“瀏覽頁面”轉變為“與應用程序進行交互”。
Ajax的一個明顯優點是向用戶提供了及時反饋,因為它異步地從后端Web服務器請求信息。但Ajax并不保證用戶就不會一邊玩弄自己的手指一邊等著“異步JavaScript和XML”返回響應,記住“異步”并沒有暗示“即時”,這一點很重要。用戶是否需要等待的關鍵因素在于Ajax請求是被動的還是主動的。被動請求是為了將來使用而預先發起的。主動請求是基于用戶當前的操作而發起的。
改善Ajax請求的最重要的方式就是使響應可緩存,前面第4、9、10、11、13原則也適用于此。
確保Ajax請求遵守性能指導,尤其應具有長久的Expires頭。
網站標題:高性能網站建設指南---前端工程師技能精髓
文章分享:http://vcdvsql.cn/news10/284210.html
成都網站建設公司_創新互聯,為您提供網站設計公司、軟件開發、定制網站、品牌網站制作、網站建設、云服務器
廣告
聲明:本網站發布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經允許不得轉載,或轉載時需注明來源:
創新互聯