頁面性能優化辦法有哪些?

互聯網有一項著名的8秒原則。用戶在訪問Web網頁時,如果時間超過8秒就會感到不耐煩,如果加載需要太長時間,他們就會放棄訪問。大部分用戶希望網頁能在2秒之內就完成加載。事實上,加載時間每多1秒,你就會流失7%的用戶。8秒并不是準確的8秒鐘,只是向網站開發者表明了加載時間的重要性。那我們如何優化頁面性能,提高頁面加載速度呢?這是本文主要要探討的問題,然而性能優化是個綜合性問題,沒有標準答案,想要面面俱到羅列出來,并非易事。本文只關注一些核心要點,以下是我總結性能優化常見的辦法:

一、資源壓縮與合并

主要包括這些方面:html壓縮、css 壓縮、js的壓縮和混亂和文件合并。 資源壓縮可以從文件中去掉多余的字符,比如回車、空格。你在編輯器中寫代碼的時候,會使用縮進和注釋,這些方法無疑會讓你的代碼簡潔而且易讀,但它們也會在文檔中添加多余的字節。

1.html壓縮

html代碼壓縮就是壓縮這些在文本文件中有意義,但是在HTML中不顯示的字符,包括空格,制表符,換行符等,還有一些其他意義的字符,如HTML注釋也可以被壓縮。

如何進行html壓縮:

  1. 使用在線網站進行壓縮(開發過程中一般不用)

  2. nodejs 提供了html-minifier工具

  3. 后端模板引擎渲染壓縮

2.css代碼壓縮:

css代碼壓縮簡單來說就是無效代碼刪除和css語義合并

如何進行css壓縮:

  1. 使用在線網站進行壓縮(開發過程中一般不用)

  2. 使用html-minifier工具

  3. 使用clean-css對css壓縮

image

3.js的壓縮和混亂

js的壓縮和混亂主要包括以下這幾部分:

  1. 無效字符的刪除

  2. 剔除注釋

  3. 代碼語義的縮減和優化

  4. 代碼保護(代碼邏輯變得混亂,降低代碼的可讀性,這點很重要)

如何進行js的壓縮和混亂

  1. 使用在線網站進行壓縮(開發過程中一般不用)

  2. 使用html-minifier工具

  3. 使用uglifyjs2對js進行壓縮

其實css壓縮與js的壓縮和混亂比html壓縮收益要大得多,同時css代碼和js代碼比html代碼多得多,通過css壓縮和js壓縮帶來流量的減少,會非常明顯。所以對大公司來說,html壓縮可有可無,但css壓縮與js的壓縮和混亂必須要有!

4.文件合并

image

從上圖可以看出不合并請求有以下缺點:

  • 文件與文件之間有插入的上行請求,增加了N-1個網絡延遲

  • 受丟包問題影響更嚴重

  • keep-alive方式可能會出現狀況,經過代理服務器時可能會被斷開,也就是說不能一直保持keep-alive的狀態

壓縮合并css和js可以減少網站http請求的次數,但合并文件可能會帶來問題:首屏渲染和緩存失效問題。那該如何處理這問題呢?----公共庫合并和不同頁面的合并。

如何進行文件合并

  1. 使用在線網站進行文件合并

  2. 使用nodejs實現文件合并(gulp、fis3)

二、非核心代碼異步加載異步加載的方式

1、異步加載的方式

異步加載的三種方式——async和defer、動態腳本創建

① async方式

  • async屬性是HTML5新增屬性,需要Chrome、FireFox、IE9+瀏覽器支持

  • async屬性規定一旦腳本可用,則會異步執行

  • async屬性僅適用于外部腳本

  • 如果是多個腳本,該方法不能保證腳本按順序執行

<pre class="" style="margin: 0px; padding: 8px 0px 6px; max-width: 100%; box-sizing: border-box; word-wrap: break-word !important; font-style: normal; font-variant: normal; font-weight: normal; orphans: auto; text-indent: 0px; text-transform: none; widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px; letter-spacing: 0.544px; border-radius: 0px; overflow-y: auto; color: rgb(80, 97, 109); text-align: start; font-size: 10px; line-height: 12px; overflow-wrap: break-word !important; font-family: consolas, menlo, courier, monospace, 'Microsoft Yahei' !important; border: 1px solid rgb(226, 226, 226) !important; background: rgb(241, 239, 238);">

  1. <script type="text/javascript" src="xxx.js" async="async"></script>

</pre>

② defer方式

  • 兼容所有瀏覽器

  • defer屬性規定是否對腳本執行進行延遲,直到頁面加載為止

  • 如果是多個腳本,該方法可以確保所有設置了defer屬性的腳本按順序執行

  • 如果腳本不會改變文檔的內容,可將defer屬性加入到script標簽中,以便加快處理文檔的速度

③動態創建script標簽在還沒定義defer和async前,異步加載的方式是動態創建script,通過window.onload方法確保頁面加載完畢再將script標簽插入到DOM中,具體代碼如下:

<pre class="" style="margin: 0px; padding: 8px 0px 6px; max-width: 100%; box-sizing: border-box; word-wrap: break-word !important; font-style: normal; font-variant: normal; font-weight: normal; orphans: auto; text-indent: 0px; text-transform: none; widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px; letter-spacing: 0.544px; border-radius: 0px; overflow-y: auto; color: rgb(80, 97, 109); text-align: start; font-size: 10px; line-height: 12px; overflow-wrap: break-word !important; font-family: consolas, menlo, courier, monospace, 'Microsoft Yahei' !important; border: 1px solid rgb(226, 226, 226) !important; background: rgb(241, 239, 238);">

  1. function addScriptTag(src){

  2. var script = document.createElement('script');

  3. script.setAttribute("type","text/javascript");

  4. script.src = src;

  5. document.body.appendChild(script);

  6. }

  7. window.onload = function(){

  8. addScriptTag("js/index.js");

  9. }

</pre>

2、異步加載的區別

1)defer是在HTML解析完之后才會執行,如果是多個,按照加載的順序依次執行

2)async是在加載完之后立即執行,如果是多個,執行順序和加載順序無關

image

其中藍色線代表網絡讀取,紅色線代表執行時間,這倆都是針對腳本的;綠色線代表 HTML 解析。

三、利用瀏覽器緩存

對于web應用來說,緩存是提升頁面性能同時減少服務器壓力的利器。

瀏覽器緩存類型

1.強緩存:不會向服務器發送請求,直接從緩存中讀取資源,在chrome控制臺的network選項中可以看到該請求返回200的狀態碼,并且size顯示from disk cache或from memory cache;

相關的header:

Expires :response header里的過期時間,瀏覽器再次加載資源時,如果在這個過期時間內,則命中強緩存。它的值為一個絕對時間的GMT格式的時間字符串, 比如Expires:Thu,21 Jan 2018 23:39:02 GMT

Cache-Control :這是一個相對時間,在配置緩存的時候,以秒為單位,用數值表示。當值設為max-age=300時,則代表在這個請求正確返回時間(瀏覽器也會記錄下來)的5分鐘內再次加載資源,就會命中強緩存。比如Cache-Control:max-age=300,

簡單概括:其實這兩者差別不大,區別就在于 Expires 是http1.0的產物,Cache-Control是http1.1的產物,兩者同時存在的話,Cache-Control優先級高于Expires;在某些不支持HTTP1.1的環境下,Expires就會發揮用處。所以Expires其實是過時的產物,現階段它的存在只是一種兼容性的寫法。強緩存判斷是否緩存的依據來自于是否超出某個時間或者某個時間段,而不關心服務器端文件是否已經更新,這可能會導致加載文件不是服務器端最新的內容,那我們如何獲知服務器端內容較客戶端是否已經發生了更新呢?此時我們需要協商緩存策略。

2.協商緩存:向服務器發送請求,服務器會根據這個請求的request header的一些參數來判斷是否命中協商緩存,如果命中,則返回304狀態碼并帶上新的response header通知瀏覽器從緩存中讀取資源;另外協商緩存需要與cache-control共同使用。

相關的header:

①Last-Modified和If-Modified-Since:當第一次請求資源時,服務器將資源傳遞給客戶端時,會將資源最后更改的時間以“Last-Modified: GMT”的形式加在實體首部上一起返回給客戶端。

<pre class="" style="margin: 0px; padding: 8px 0px 6px; max-width: 100%; box-sizing: border-box; word-wrap: break-word !important; font-style: normal; font-variant: normal; font-weight: normal; orphans: auto; text-indent: 0px; text-transform: none; widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px; letter-spacing: 0.544px; border-radius: 0px; overflow-y: auto; color: rgb(80, 97, 109); text-align: start; font-size: 10px; line-height: 12px; overflow-wrap: break-word !important; font-family: consolas, menlo, courier, monospace, 'Microsoft Yahei' !important; border: 1px solid rgb(226, 226, 226) !important; background: rgb(241, 239, 238);">

  1. Last-Modified: Fri, 22 Jul 2016 01:47:00 GMT

</pre>

客戶端會為資源標記上該信息,下次再次請求時,會把該信息附帶在請求報文中一并帶給服務器去做檢查,若傳遞的時間值與服務器上該資源最終修改時間是一致的,則說明該資源沒有被修改過,直接返回304狀態碼,內容為空,這樣就節省了傳輸數據量 。如果兩個時間不一致,則服務器會發回該資源并返回200狀態碼,和第一次請求時類似。這樣保證不向客戶端重復發出資源,也保證當服務器有變化時,客戶端能夠得到最新的資源。一個304響應比一個靜態資源通常小得多,這樣就節省了網絡帶寬。

image

但last-modified 存在一些缺點:

Ⅰ.某些服務端不能獲取精確的修改時間

Ⅱ.文件修改時間改了,但文件內容卻沒有變

既然根據文件修改時間來決定是否緩存尚有不足,能否可以直接根據文件內容是否修改來決定緩存策略?----ETag和If-None-Match

②ETag和If-None-Match:Etag是上一次加載資源時,服務器返回的response header,是對該資源的一種唯一標識,只要資源有變化,Etag就會重新生成。瀏覽器在下一次加載資源向服務器發送請求時,會將上一次返回的Etag值放到request header里的If-None-Match里,服務器只需要比較客戶端傳來的If-None-Match跟自己服務器上該資源的ETag是否一致,就能很好地判斷資源相對客戶端而言是否被修改過了。如果服務器發現ETag匹配不上,那么直接以常規GET 200回包形式將新的資源(當然也包括了新的ETag)發給客戶端;如果ETag是一致的,則直接返回304知會客戶端直接使用本地緩存即可。

image

兩者之間對比首先在精確度上,Etag要優于Last-Modified。Last-Modified的時間單位是秒,如果某個文件在1秒內改變了多次,那么他們的Last-Modified其實并沒有體現出來修改,但是Etag每次都會改變確保了精度;如果是負載均衡的服務器,各個服務器生成的Last-Modified也有可能不一致。第二在性能上,Etag要遜于Last-Modified,畢竟Last-Modified只需要記錄時間,而Etag需要服務器通過算法來計算出一個hash值。第三在優先級上,服務器校驗優先考慮Etag

緩存的機制

強制緩存優先于協商緩存進行,若強制緩存(Expires和Cache-Control)生效則直接使用緩存,若不生效則進行協商緩存(Last-Modified / If-Modified-Since和Etag / If-None-Match),協商緩存由服務器決定是否使用緩存,若協商緩存失效,那么代表該請求的緩存失效,重新獲取請求結果,再存入瀏覽器緩存中;生效則返回304,繼續使用緩存。主要過程如下:

image

用戶行為對瀏覽器緩存的影響

1.地址欄訪問,鏈接跳轉是正常用戶行為,將會觸發瀏覽器緩存機制;

2.F5刷新,瀏覽器會設置max-age=0,跳過強緩存判斷,會進行協商緩存判斷;

3.ctrl+F5刷新,跳過強緩存和協商緩存,直接從服務器拉取資源。

如果想了解更多緩存機制,請猛戳 深入理解瀏覽器的緩存機制

四、使用CDN

大型Web應用對速度的追求并沒有止步于僅僅利用瀏覽器緩存,因為瀏覽器緩存始終只是為了提升二次訪問的速度,對于首次訪問的加速,我們需要從網絡層面進行優化,最常見的手段就是CDN(Content Delivery Network,內容分發網絡)加速。通過將靜態資源(例如javascript,css,圖片等等)緩存到離用戶很近的相同網絡運營商的CDN節點上,不但能提升用戶的訪問速度,還能節省服務器的帶寬消耗,降低負載。

image

CDN是怎么做到加速的呢?

其實這是CDN服務商在全國各個省份部署計算節點,CDN加速將網站的內容緩存在網絡邊緣,不同地區的用戶就會訪問到離自己最近的相同網絡線路上的CDN節點,當請求達到CDN節點后,節點會判斷自己的內容緩存是否有效,如果有效,則立即響應緩存內容給用戶,從而加快響應速度。如果CDN節點的緩存失效,它會根據服務配置去我們的內容源服務器獲取最新的資源響應給用戶,并將內容緩存下來以便響應給后續訪問的用戶。因此,一個地區內只要有一個用戶先加載資源,在CDN中建立了緩存,該地區的其他后續用戶都能因此而受益。

五、預解析DNS

資源預加載是另一個性能優化技術,我們可以使用該技術來預先告知瀏覽器某些資源可能在將來會被使用到。通過 DNS 預解析來告訴瀏覽器未來我們可能從某個特定的 URL 獲取資源,當瀏覽器真正使用到該域中的某個資源時就可以盡快地完成 DNS 解析。例如,我們將來可從 example.com 獲取圖片或音頻資源,那么可以在文檔頂部的 標簽中加入以下內容:

<pre class="" style="margin: 0px; padding: 8px 0px 6px; max-width: 100%; box-sizing: border-box; word-wrap: break-word !important; font-style: normal; font-variant: normal; font-weight: normal; orphans: auto; text-indent: 0px; text-transform: none; widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px; letter-spacing: 0.544px; border-radius: 0px; overflow-y: auto; color: rgb(80, 97, 109); text-align: start; font-size: 10px; line-height: 12px; overflow-wrap: break-word !important; font-family: consolas, menlo, courier, monospace, 'Microsoft Yahei' !important; border: 1px solid rgb(226, 226, 226) !important; background: rgb(241, 239, 238);">

  1. <link rel="dns-prefetch" >

</pre>

當我們從該 URL 請求一個資源時,就不再需要等待 DNS 的解析過程。該技術對使用第三方資源特別有用。通過簡單的一行代碼就可以告知那些兼容的瀏覽器進行 DNS 預解析,這意味著當瀏覽器真正請求該域中的某個資源時,DNS 的解析就已經完成了,從而節省了寶貴的時間。 另外需要注意的是,瀏覽器會對a標簽的href自動啟用DNS Prefetching,所以a標簽里包含的域名不需要在head中手動設置link。但是在HTTPS下不起作用,需要meta來強制開啟功能。這個限制的原因是防止竊聽者根據DNS Prefetching推斷顯示在HTTPS頁面中超鏈接的主機名。下面這句話作用是強制打開a標簽域名解析

<pre class="" style="margin: 0px; padding: 8px 0px 6px; max-width: 100%; box-sizing: border-box; word-wrap: break-word !important; font-style: normal; font-variant: normal; font-weight: normal; orphans: auto; text-indent: 0px; text-transform: none; widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px; letter-spacing: 0.544px; border-radius: 0px; overflow-y: auto; color: rgb(80, 97, 109); text-align: start; font-size: 10px; line-height: 12px; overflow-wrap: break-word !important; font-family: consolas, menlo, courier, monospace, 'Microsoft Yahei' !important; border: 1px solid rgb(226, 226, 226) !important; background: rgb(241, 239, 238);">

  1. <meta http-equiv="x-dns-prefetch-control" content="on">

</pre>

?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,546評論 6 533
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,570評論 3 418
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事?!?“怎么了?”我有些...
    開封第一講書人閱讀 176,505評論 0 376
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,017評論 1 313
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,786評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,219評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,287評論 3 441
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,438評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,971評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,796評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,995評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,540評論 5 359
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,230評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,662評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,918評論 1 286
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,697評論 3 392
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,991評論 2 374

推薦閱讀更多精彩內容

  • 又是新的一天
    JianShuRR閱讀 300評論 0 0
  • 大數據時代這本書不能說他廢話多,也不能說她扯張虎皮做大旗,那本書所做的是對大數據發展的闡述、現今大數據使用的舉...
    文瀾仙域閱讀 196評論 0 1
  • 孩子的爸在杭州打工,常年不在家,女兒在本省上大學,常態是一個女人帶著兩個兒子,孩子小學在讀,額!為什么竟然有倆兒子...
    甜甜芽閱讀 263評論 1 3