前端性能優化黃金法則

coolpail 發布于2019-08-30 13:13 / 3183人閱讀

摘要：前端優化是復雜的，針對方方面面的資源都有不同的方式。前端性能優化前端性能團隊總結的條黃金定律的團隊總結出了一系列可以提高網站速度的方法。提高性能的措施中最重要的方法就是使響應具有可緩存性。

前端是龐大的，包括 HTML、 CSS、 Javascript、Image 、Flash等等各種各樣的資源。前端優化是復雜的，針對方方面面的資源都有不同的方式。那么，前端優化的目的是什么 ?Tips:個人博客排版、UI更佳；地址：https://haonancx.github.io/

從用戶角度而言，優化能夠讓頁面加載得更快、對用戶的操作響應得更及時，能夠給用戶提供更為友好的體驗。

從服務商角度而言，優化能夠減少頁面請求數、或者減小請求所占帶寬，能夠節省可觀的資源。

總之，恰當的優化不僅能夠改善站點的用戶體驗并且能夠節省相當的資源利用。

前端性能優化 - Yahoo前端性能團隊總結的35條黃金定律

Yahoo 的Excetional Performance 團隊總結出了一系列可以提高網站速度的方法?？梢苑譃?7大類 35條（包括內容、服務器、CSS、JavaScript、Cookie、圖片、移動應用）。

內容部分

盡量減少 HTTP 請求

減少 DNS 查找

避免跳轉

緩存 Ajax

推遲加載

提前加載

減少 DOM 元素數量

用域名劃分頁面內容

使 frame 數量最少

避免404錯誤

合并文件是通過把所有的腳本放到一個文件中來減少 HTTP請求的方法。

CSS Sprites是減少圖像請求的有效方法。

緩存 DNS查找可以改善頁面性能。

跳轉是使用 301和 302代碼實現的（但是要記住跳轉會降低用戶體驗）。

為了提高性能，優化 Ajax響應是很重要的。提高 Ajxa性能的措施中最重要的方法就是使響應具有可緩存性。

你可以仔細看一下你的網頁，問問自己“哪些內容是頁面呈現時所必需首先加載的？哪些內容和結構可以稍后再加載？預加載和后加載看起來似乎恰恰相反，但實際上預加載是為了實現另外一種目標。預加載是在瀏覽器空閑時請求將來可能會用到的頁面內容（如圖像、樣式表和腳本）。使用這種方法，當用戶要訪問下一個頁面時，頁面中的內容大部分已經加載到緩存中了，因此可以大大改善訪問速度。

一個復雜的頁面意味著需要下載更多數據，同時也意味著JavaScript遍歷DOM的效率越慢。比如當你增加一個事件句柄時在500和5000個 DOM元素中循環效果肯定是不一樣的。

把頁面內容劃分成若干部分可以使你最大限度地實現平行下載。

使iframe的數量最小，ifrmae元素可以在父文檔中插入一個新的HTML文檔。了解iframe的工作理然后才能更加有效地使用它，這一點很重要。

HTTP請求時間消耗是很大的，因此使用HTTP請求來獲得一個沒有用處的響應（例如404沒有找到頁面）是完全沒有必要的，它只會降低用戶體驗而不會有一點好處。

服務器部分

使用內容分發網絡

為文件頭指定 Expires 或 Cache-Control

Gzip壓縮文件內容

配置ETag

盡早刷新輸出緩沖

使用 GET 來完成 AJAX 請求

避免空的圖像來源

用戶與你網站服務器的接近程度會影響響應時間的長短。把你的網站內容分散到多個、處于不同地域位置的服務器上可以加快下載速度。

為文件頭指定Expires或Cache-Control，這條守則包括兩方面的內容：對于靜態內容：設置文件頭過期時間Expires的值為“Never expire”（永不過期）；對于動態內容：使用恰當的Cache-Control文件頭來幫助瀏覽器進行有條件的請求。

網絡傳輸中的HTTP請求和應答時間可以通過前端機制得到顯著改善。的確，終端用戶的帶寬、互聯網提供者、與對等交換點的靠近程度等都不是網站開發者所能決定的。但是還有其他因素影響著響應時間。通過減小HTTP響應的大小可以節省HTTP響應時間。

Entity tags（ETags）（實體標簽）是web服務器和瀏覽器用于判斷瀏覽器緩存中的內容和服務器中的原始內容是否匹配的一種機制（“實體”就是所說的“內容”，包括圖片、腳本、樣式表等）。增加ETag為實體的驗證提供了一個比使用“last-modified date（上次編輯時間）”更加靈活的機制。

當用戶請求一個頁面時，無論如何都會花費200到500毫秒用于后臺組織HTML文件。（盡早刷新輸出緩沖）。

Yahoo!Mail團隊發現，當使用XMLHttpRequest時，瀏覽器中的POST方法是一個“兩步走”的過程：首先發送文件頭，然后才發送數據。因此使用GET最為恰當，因為它只需發送一個TCP包（除非你有很多cookie）。IE中URL的最大長度為2K，因此如果你要發送一個超過2K的數據時就不能使用GET了。

CSS部分

把樣式表置于頂部

避免使用 CSS 表達式（）

用代替 @import

避免使用濾鏡

在研究Yahoo!的性能表現時，我們發現把樣式表放到文檔的內會使頁面有步驟的加載顯示。

避免使用CSS表達式（Expression），CSS表達式是動態設置CSS屬性的強大（但危險）方法。Internet Explorer從第5個版本開始支持CSS表達式。

對于擁有較大瀏覽量的首頁來說，有一種技術可以平衡內置代碼帶來的HTTP請求減少與通過使用外部文件進行緩存帶來的好處。

（削減JavaScript和CSS）精簡是指從去除代碼不必要的字符減少文件大小從而節省下載時間。消減代碼時，所有的注釋、不需要的空白字符（空格、換行、tab縮進）等都要去掉。

前面的最佳實現中提到CSS應該放置在頂端以利于有序加載呈現。在IE中，頁面底部@import和使用作用是一樣的，因此最好不要使用它。

IE獨有屬性AlphaImageLoader用于修正7.0以下版本中顯示PNG圖片的半透明效果。這個濾鏡的問題在于瀏覽器加載圖片時它會終止內容的呈現并且凍結瀏覽器。在每一個元素（不僅僅是圖片）它都會運算一次，增加了內存開支，因此它的問題是多方面的。

JavaScript部分

把腳本置于頁面底部

使用外部 JavaScript 和 CSS

削減 JavaScript 和 CSS

剔除重復腳本

減少DOM訪問

開發智能事件處理程序

腳本帶來的問題就是它阻止了頁面的平行下載。HTTP/1.1 規范建議，瀏覽器每個主機名的并行下載內容不超過兩個。一個經常用到的替代方法就是使用延遲腳本。

在同一個頁面中重復引用JavaScript文件會影響頁面的性能。你可能會認為這種情況并不多見。對于美國前10大網站的調查顯示其中有兩家存在重復引用腳本的情況。有兩種主要因素導致一個腳本被重復引用的奇怪現象發生：團隊規模和腳本數量。

使用JavaScript訪問DOM元素比較慢，因此為了獲得更多的應該頁面，應該做到：緩存已經訪問過的有關元素，線下更新完節點之后再將它們添加到文檔樹中，避免使用JavaScript來修改頁面布局，有關此方面的更多信息請查看Julien Lecomte在YUI專題中的文章“高性能Ajax應該程序”。

有時候我們會感覺到頁面反應遲鈍，這是因為DOM樹元素中附加了過多的事件句柄并且些事件句病被頻繁地觸發。這就是為什么說使用event delegation（事件代理）是一種好方法了。

Coockie部分

減小Cookie體積

對于頁面內容使用無coockie域名

coockie 是通過HTTP文件頭來在web服務器和瀏覽器之間進行交流的。去除不必要的coockie，使coockie體積盡量小以減少對用戶響應的影響，注意在適應級別的域名上設置coockie以便使子域名不受影響；設置合理的過期時間。較早地Expire時間和不要過早去清除coockie，都會改善用戶的響應時間。

對于頁面內容使用無coockie域名，當瀏覽器在請求中同時請求一張靜態的圖片和發送coockie時，服務器對于這些coockie不會做任何地使用。因此他們只是因為某些負面因素而創建的網絡傳輸。所有你應該確定對于靜態內容的請求是無coockie的請求。創建一個子域名并用他來存放所有靜態內容。

Image 部分

優化圖像

優化 CSS Spirite

不要在 HTML 中縮放圖像

favicon.ico 要小而且可緩存

優化圖像和CSS Spirite，在Spirite中水平排列你的圖片，垂直排列會稍稍增加文件大小；Spirite 中把顏色較近的組合在一起可以降低顏色數，理想狀況是低于256色以便適用PNG8格式；

favicon.ico是位于服務器根目錄下的一個圖片文件。它是必定存在的，因為即使你不關心它是否有用，瀏覽器也會對它發出請求，因此最好不要返回一個404 Not Found的響應。

七、 Mobile部分

保持單個內容小于25K

打包組件成復合文本

保持單個內容小于25K，這條限制主要是因為iPhone不能緩存大于25K的文件。注意這里指的是解壓縮后的大小。由于單純gizp壓縮可能達不要求，因此精簡文件就顯得十分重要。

打包組件成復合文本，把頁面內容打包成復合文本就如同帶有多附件的Email，它能夠使你在一個HTTP請求中取得多個組件（切記：HTTP請求是很奢侈的）。當你使用這條規則時，首先要確定用戶代理是否支持（iPhone就不支持）。

是不是感覺挺多的，這還只是優化方案的概括，細分起來還有很多細節。

好了，今天就到這兒，下篇文章見。 該文章部分知識網絡整理

GPU云服務器云服務器前端性能優化前端開發性能優化性能優化前端優化

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.hztianpu.com/yun/115389.html

前端性能優化黃金法則

摘要：前端優化是復雜的，針對方方面面的資源都有不同的方式。前端性能優化前端性能團隊總結的條黃金定律的團隊總結出了一系列可以提高網站速度的方法。提高性能的措施中最重要的方法就是使響應具有可緩存性。前端是龐大的，包括 HTML、 CSS、 Javascript、Image 、Flash等等各種各樣的資源。前端優化是復雜的，針對方方面面的資源都有不同的方式。那么，前端優化的目的是什么 ?Tips...

zhangke3016 2019-08-02 15:56 評論0 收藏0
前端性能優化黃金法則

摘要：前端優化是復雜的，針對方方面面的資源都有不同的方式。前端性能優化前端性能團隊總結的條黃金定律的團隊總結出了一系列可以提高網站速度的方法。提高性能的措施中最重要的方法就是使響應具有可緩存性。前端是龐大的，包括 HTML、 CSS、 Javascript、Image 、Flash等等各種各樣的資源。前端優化是復雜的，針對方方面面的資源都有不同的方式。那么，前端優化的目的是什么 ?Tips...

Hegel_Gu 2019-08-22 10:45 評論0 收藏0
提高前端性能的黃金法則

摘要：雖然如此，但是網站前端性能優化的思路基本沒變。為什么前端性能如此重要數據顯示只有的最終用戶響應時間花在了下載文檔上。前端性能優化一味奉行最佳實踐有時候反而過而不及，所以針對項目的實際情況來優化才是明智的選擇。前端近幾年變化很大，各種工具，庫，框架并發。雖然如此，但是網站前端性能優化的思路基本沒變。為什么前端性能如此重要？數據顯示: 只有 10%~20% 的最終用戶響應時間花在了下載...

keithyau 2019-08-19 17:54 評論0 收藏0
關于網站性能優化準則

打算現在開始在博客里寫點東西，也能為自己看過的書學過的知識做一個歸納總結。這幾日拜讀了Steve Souders的《高性能網站建設指南這本書》，雖然這本書可能已經有些老了，但薄薄的一個小冊子里提出的網站性能優化的準則還是非常有價值的。這些規則都有個共同點，就是用很小的工作就能獲得很明顯的性能提升，性價比極高。廢話不多說了，總結一下書里的幾點性能優化規則。首先有一點需要說明的是書中所寫的性能黃金法...

Travis 2019-08-22 10:58 評論0 收藏0
開放封閉原則之模式的黃金法則

摘要：開放封閉原則應該算是這幾個原則里面最容易理解的一個。另外，語句就是開放封閉原則的死敵這個是狀態模式中的一個例子。處理開放封閉模式的特例我們都是人，不可能一開始都寫出完美的代碼。開放-封閉原則應該算是這幾個原則里面最容易理解的一個。它的宗旨就是:如果你想擴展或者改變一個程序的功能，可以增加代碼，但是不能改變程序的源碼。如果，是對于那些碼農來說，最快捷的辦法就是改變源碼，但是我們面向的是...

MasonEast 2019-08-19 17:29 評論0 收藏0