前端優化

時間 2019-11-07

標籤前端優化简体版

原文原文鏈接

前端優化理解
影響用戶訪問的最大部分是前端的頁面。
網站的劃分通常爲二：前端和後臺。咱們能夠理解成後臺是用來實現網站的功能的，好比：實現用戶註冊，用戶可以爲文章發表評論等等。而前端呢？其實應該是屬於功能的表現。

前端的頁面主要包括xhtml,css,js。其實xhtml就是現實中所談到的內容，頁面的內容：文字，圖片，flash,視頻等。
而前端開發工做者能夠控制的是什麼呢？那就是xhtml，css，js的代碼及相應的修飾（背景）圖片。
1、提倡前端開發工程師在書寫xhtml的時候作到結構語義化。
標籤語義化的好處：1.有利於搜索引擎；2.結構清晰的HTML在團隊合做中的做用3.有利於盲人屏幕閱讀器。
2、css，js文件數量及大小的優化
那麼關於css、js的優化的話，通常狀況下建議css和js採用外聯式。你必定要把你的css規劃好，儘可能的採用縮寫，減小重複性代碼，代碼重複利用，這樣能夠減小css文件的大小，那麼對css作相應的規劃也能夠減小css的個數，減小http請求數，js同理。
3、背景圖片數量及大小的優化
背景合併起來，這樣便可減小http請求數，同時，咱們在背景整合的時候，也須要考慮圖片質量，同時也須要考慮圖片的大小，這裏建議使用PNG8格式的圖片結合css sprite，一樣
4、內容圖片的大小的優化
把樣式表置於頂部
把腳本置於頁面底部
避免使用 CSS 表達式（Expression）
使用外部 JavaScript 和 CSS
削減 JavaScript 和 CSS
用 <link> 代替 @import
避免使用濾鏡
剔除重複腳本
減小DOM訪問
開發智能事件處理程序
最好的方案就是按照 HTML 規範在文檔 <head /> 內加載你的樣式表。
對於擁有較大瀏覽量的首頁來講，有一種技術能夠平衡內置代碼帶來的 HTTP 請求減小與經過使用外部文件進行緩存帶來的好處。其中一個就是在首頁中內置 JavaScript 和 CSS ，可是在頁面下載完成後動態下載外部文件，在子頁面中使用到這些文件時，它們已經緩存到瀏覽器了。
Coockie:
減少Cookie體積
對於頁面內容使用無coockie域名
圖片：
優化圖像
優化CSS Spirite
不要在HTML中縮放圖像
favicon.ico要小並且可緩存
移動應用：
保持單個內容小於25K
打包組件成複合文本

2.前端性能優化14個黃金法則
只有10%-20%的最終用戶響應時間花在接受請求的HTML文檔上，剩下的80%-90%時間花在爲HTML文檔所引用的全部組件（圖片、腳本、樣式表等）進行的HTTP請求上。

規則01：儘可能減小HTTP請求
經過使用圖片地圖，CSS Sprites（有利有弊），內聯圖片（data：URL模式，IE不支持，不能被緩存），合併腳本和樣式表。
因此，咱們要減小HTTP請求是要平衡性能和設計的。
①  圖片地圖

初看「圖片地圖」四個字，對非專業的前端人員來講一頭霧水，個人第一印象就是這樣的，我們以京東的移動站點爲例，右側用戶和購物車的圖標，正常實現我會選擇以下方式：
<a href=」用戶跳轉頁面URL」>
  <div class=」定義用戶icon顯示的樣式表」></div>
</a>
<a href=」購物車跳轉頁面URL」>
  <div class=」定義用戶icon顯示的樣式表」></div>
</a>
這種方式無可厚非的，可是兩張圖片就有兩個HTTP請求，這明顯是增長了頁面中的HTTP請求。那麼咱們能夠把這兩個HTTP請求變成一個嗎？
答案固然是能夠的，這就是圖片地圖：容許在一張圖片上關聯多個URL，而目標URL的選擇取決於用戶單擊了圖片上的哪一個位置。
這樣上面京東兩個圖標合併成一張圖片，這樣圖片的HTTP請求就減小了一個。
示例代碼以下：
<img src=合併後的圖片>
<map name=」map1」>
  <areashape=」rect」 coords=」0,0,40,40」 href=」用戶跳轉頁面URL」>
  <areashape=」rect」 coords=」50,0,90,40」 href=」購物車跳轉頁面URL」>
</map>
不過圖片地圖只支持矩形形狀，其餘形狀不支持。
②  請CSS喝「雪碧」（CSS Sprites）CSS Sprites一句話：將多個圖片合併到一張單獨的圖片，這樣就大大減小了頁面中圖片的HTTP請求。

③  內聯圖片和腳本使用data:URL（Base64編碼）模式直接將圖片包含在Web頁面中而無需進行HTTP請求。可是此種方法存在明顯缺陷：- 不受IE的歡迎；- 圖片太大不宜採用這種方式，由於Base64編碼以後會增長圖片大小，這樣頁面總體的下載量會變大；- 內聯圖片在頁面跳轉的時候不會被緩存。（大圖片可使用瀏覽器的本地緩存，在首次訪問的時候保存到瀏覽器緩存中，典型的是HTML5的manifest緩存機制以及LocalStorage等）。

④  樣式表的合併將頁面樣式定義、腳本、頁面自己代碼嚴格區分開，可是樣式表、腳本也不是分割越細越好，由於每多引用一個樣式表就增長一次HTPP請求，能合併的樣式表儘可能合併。一個網站有一個公用樣式表定義，每一個頁面只要有一個樣式表就OK啦。

因此減小頁面HTTP請求數量，是一個很重要的原則。

規則02：使用內容發佈網絡（CDN的使用）
什麼叫內容發佈網絡（CDN）？它是一組分佈在多個不一樣地理位置的Web服務器，用於更加有效地向用戶發佈內容。主要用於發佈頁面靜態資源：圖片、css文件、js文件等。如此，能輕易地提升響應速度。
若是應用程序web服務器離用戶更近，則一個HTTP請求的響應時間將縮短；
若是組件web服務器離用戶更近，則多個HTTP請求的響應時間將縮短。
內容發佈網絡（CDN）是一組分佈在多個不一樣地理位置的web服務器，用於更加有效地向用戶發佈內容

規則03：添加Expires頭
瀏覽器使用緩存來減小HTTP請求的數據，並減少HTTP響應的大小，使頁面加載更快。Web服務器使用Expires頭來告訴瀏覽器它可使用一個組件的當前副本，直到指定的deadline爲止。HTTP規範中稱此頭爲：在這一時間以後響應被認爲失效。
web服務器使用Expires頭告訴web客戶端他可使用一個組件的當前副本，直到指定的時間爲止。要求服務器與客戶端的時鐘嚴格同步，而且要在時間過時後在服務器配置中提供一個新的日期。
Max-Age和mod_expires能夠彌補Expires的不足。

我的對這塊表示不想使用，其實就是一句話，把一些css、js、圖片在首次訪問的時候所有緩存到瀏覽器本地，從我作移動網站的過程當中發現，其實沒有這麼複雜，徹底可使用HTML5提供的本地緩存機制就OK了。

規則04：壓縮組件（使用Gzip方式）
書中關於壓縮從gzip壓縮方式到如何壓縮講了不少，我想直接跳過，對於作PC網站或者移動網站來講，急須要壓縮的是css文件和js文件，至於如何壓縮，網上有不少在線工具，去挑選一個本身用的順手看的順眼的就好，固然也有人選擇對HTML進行壓縮，這樣也能夠。

規則05：將CSS樣式表放在頂部
若是將css樣式定義放在頁面中或者頁面底部，會出現短暫白屏或者某一區域短暫白板的狀況，這和瀏覽器的運營機制有關的，無論頁面如何加載，頁面都是逐步呈現的。因此在每作一個頁面的時候，用Link標籤把每個樣式表定義放在head中。
逐步呈現，避免白屏

規則06：將javascript腳本放在底部
瀏覽器在加載css文件時，頁面逐步呈現會被阻止，直到全部css文件加載完畢，因此要把css文件的引用放到head中去，這樣在加載css文件時不會組織頁面的呈現。可是對於js文件，在使用的時候，它下面全部也頁面內容的呈現都會被阻塞，將腳本放在頁面越靠下的地方，就意味着越多的內容可以逐步呈現。
HTTP1.1規範建議瀏覽器從每一個主機名並行下載兩個組件，在下載腳本時，並行下載其實是被禁用的。
緣由之一是腳本有可能使用document.write來修改頁面內容，所以瀏覽器會等待，以確保頁面可以恰當地佈局；
緣由之二是爲了保證腳本可以按照正確的順序執行，若是並行下載多個腳本，就沒法保證響應是按照特定順序到達瀏覽器。
將腳本放在頂部將會阻塞對其後面內容的呈現，而且會阻塞對其後面組件的下載。

規則07：避免使用CSS表達式
CSS表達式是動態玩CSS的一種很強大的方式，可是強大的同時也存在很高的危險性。由於css表達式的頻繁求值會致使css表達式性能低下。若是真想玩css表達式，能夠選用只求值一次的表達式或者使用事件處理來改變css的值。
表達式expression方法被其餘瀏覽器忽略，可是對於IE來講是一個有用的工具。可以在IE中設置屬性，建立跨瀏覽器的一致體驗。例如，IE[IE6，IE7（Quirk），IE8（Quirk]不支持min-width屬性，用表達式的方法能夠解決這一問題：
代碼以下:

width: expression(document.body.clientwidth<600?"600px": "auto");
min-width: 600px;
表達式的問題在於對其進行的求值的頻率比人們指望的要高。他們不只在頁面呈現和大小改變時求值，當頁面滾動甚至用戶鼠標在頁面上移過期都要求值。咱們能夠向CSS表達式中添加一個計數器來進行跟蹤。
表達式計數器的實例：
http://stevesouders.com/hpws/expression-counter.php
代碼以下:

P {
width: expression(setCntr(),document.body.clientwidth<600?"600px": "auto");
min-width: 600px;
}
取表明達式的方法：事件處理器（Event Handlers）
經過在onresize事件中設置樣式的width屬性來修正min-width問題。
事件處理器的實例：
http://stevesouders.com/hpws/event-handler.php
當瀏覽器的大小改變時，這個例子使用setMinWidth()函數來修改全部段落元素的大小——
代碼以下:

function setMinWidth(){
setCntr(); //用於顯示求值次數
var aElements = document.getElementsByTagName("p");
for(var i=0;i<aElements.length;i++){
aElements.runtimeStyle.width=(document.body.clientwidth<600?"600px": "auto");
}
}
if(1!=navigator.userAgent.indexOf("MSIE")){
window.onresize=setMinWidth;
}
這會在瀏覽器改變大小時中動態設置寬度，可是第一次呈現時這並不能恰當地設置段落大小，所以，頁面還須要使用「一次性表達式」，經過表達式設置初始寬度。

規則08：使用外部javascript和CSS
內聯js和css其實比外部文件有更快的響應速度，那爲何還要用外部呢？由於使用外部的js和css可讓瀏覽器緩存他們，這樣不只HTML文檔大小減小，並且不會增長HTTP請求數量。另外，使用外部js和css能夠提升組件的可複用性。

規則09：減小DNS查詢
DNS查詢有時間開銷，一般一個瀏覽器查找一個給定主機名的IP地址須要20-120ms。緩存DNS：緩存DNS查詢能夠很好地提升網頁性能，一旦緩存了DNS查詢，以後對於相同主機名的請求就無需進行再次的DNS查找，至少短期內不須要。因此在使用頁面中URL、圖片、js文件、css文件等時，不要使用過多不一樣的主機名。

規則10：精簡javascript

如何精簡？
最初始的精簡方式：就是移除沒必要要的字符減少js文件大小，改善加載時間。包括全部的註釋、沒必要要的空白字符。

高級一點的精簡方式就是：混淆。
它不但會移除沒必要要的字符，還會改寫代碼，好比函數和變量的名字會被改爲很短的字符串，這樣使js代碼更簡練更難閱讀。

規則11：避免重定向
重定向的英文是Redirect，用於將用戶從一個URL從新跳轉到另外一個URL。
最多見的Redirect就是301和302兩種。
範圍在3xx的狀態碼，這表示用戶代理必須執行進一步操做才能完成請求。
重定向影響的是HTML文檔的下載
在咱們實際開發中避免重定向最簡單也最容易被忽視的一個問題就是，設置URL的時候，最後的「/」，有些人有時候會忽略，其實你少了「/」，這時候的URL就被重定向了，因此在給頁面連接加URL的時候切記最後的「/」不可丟。

規則12：刪除重複腳本
重複的js代碼除了有沒必要要的HTTP請求以外，還會浪費執行js的時間。
將你使用的js代碼模塊化，能夠很好地避免這個問題，至於js模塊化如何實現，如今有不少可使用的開源框架，我用的比較多的是咱們公司玉伯的Sea.js。

規則13：配置ETag
Etag（Entity Tag），實體標籤，是Web服務器和瀏覽器用戶確認緩存組件的有效性的一種機制。寫的很複雜，對我這種非專業的前端開發人員來講，有點過了，關於這個原則有興趣的本身看吧。

規則14：使Ajax可緩存
針對頁面中主動的Ajax請求返回的數據要緩存到本地，固然這個是針對短時間內不會變化的數據。若是不肯定數據變化週期的話，能夠增長一個修改標識的判斷，我正常處理過程當中會給一些Ajax請求返回的數據增長一個MD5值的判斷，每次請求會判斷當前MD5是否變化，若是變化了取最新的數據，若是不變化，則不變。

時間總結下來，就是：儘可能減小頁面大小，儘可能下降頁面響應時間。在頁面性能和交互設計之中找平衡點。

3.移動端優化
1)爲何要最移動頁面進行優化？
移動網絡的現狀：

移動頁面佈局愈來愈複雜，效果愈來愈炫，直接致使了文件愈來愈大，下載和運行速度愈來愈低，而速度低會形成不良影響，據統計：

71%的用戶指望移動頁面跟pc頁面同樣快，74%的用戶能容忍的響應時間爲5秒，因此咱們必須保證移動端頁面有足夠的速度。
移動頁面的速度跟三個因素有關，
移動網絡帶寬速度，設備性能（CPU，GPU，瀏覽器），頁面自己。

網絡制式供應商，手機制造商，瀏覽器產商如此給力，咱們呢？
咱們能作得是對移動端頁面自己優化

2)該怎麼作移動端頁面優化呢？
pc經常使用的優化手段：
代碼優化（css、html、js優化）
減小HTTP請求（雪碧圖，文件合併…）
減小DOM節點
無阻塞（內聯CSS，JS置後…）
緩存

首先咱們得關注一下一個頁面從開始到呈現完畢須要經歷什麼階段，主要有四個階段：

每一個階段的主要工做如上圖所示，而咱們的優化目標是：

下面咱們來針對上面的幾個階段細說一下都有哪些優化手段。
首先，來看看加載中有哪些優化手段：
1. 預加載
預加載方式有兩種：
A.顯性加載

相似這種用戶能明顯感知的，我把它稱爲「顯性加載」，互動頁面都建議加上這種加載方式，它一方面能增長頁面的趣味性，另外一方面能讓後續頁面體驗更流暢。
B.隱性加載

這種在加載第一張圖片的時候已經預先加載了第二張圖片，從而使得頁面體驗更流暢的方式，我把它稱爲隱性加載，這種方式的好處是節省流量之餘又能使得體驗加強。
2. 按需加載
按需加載是不可或缺的優化手段，主要有如下兩種方式：

對於這種方式，在首屏加載的時候把首屏的內容加載儘可能，而位於首屏以外的元素都只在出如今首屏時才加載，很大程度地節省了流量，提高了首次加載時間。

這種叫響應式加載方式，意思是利用js或者css判斷分辨率，從而選擇不一樣尺寸的圖片進行引入，這種的好處顯而易見，一樣能夠加快加載速度和節省流量。
3.壓縮圖片
對於壓縮圖片，首先要提的是jpg文件：

對於移動端的Jpg文件，有這樣的結論：
a.使用大尺寸大有損壓縮比的jpg
b.使用jpegtran進行無損壓縮

而對於png有如下結論：
a.多彩圖片使用png24
b.低彩圖片使用png8
c.推薦使用pngquant

4.儘可能避免重定向
爲何要儘可能避免重定向呢？由於如圖：

這是一個同一網速下的測試結果，重定向之因此會比較慢，是由於它重複了域名查找，tcp連接，發送請求。
5. 使用其餘方式代替圖片
有兩種方式，第一種是：依靠css3繪製圖片

第二種：使用iconfont代替圖片

但iconfont不必定比圖片好
對於大圖片，iconfont並不比雪碧圖好，建議單側小尺寸圖標才使用iconfont.

而後，針對腳本執行中有哪些優化手段，這裏只提兩點：
1.儘可能避免DataURI
DataURI在移動端並不如它在pc端吃香
經測試，DataURI要比簡單的外鏈資源慢6倍，生成的代碼文件相對圖片文件體積沒有減小反而增大，並且瀏覽器在對這種base64解碼過程當中須要消耗內存和cpu，這個在移動端壞處特別明顯。
2.點擊事件優化
在移動端請適當使用touchstart，touchend，touch等事件代替延遲比較大的click事件。Click之因此慢是由於mousedown致使的：

而後，針對渲染階段中有哪些優化手段，這裏也只提兩點：
1. 動畫優化
a) 儘可能使用css3動畫
優勢：
不佔用js主線程
可利用硬件加速
瀏覽器可對動畫作優化

缺點：
不支持中間狀態監

b) 適當使用canvas動畫
優勢：
可規避渲染樹的計算渲染更快
缺點：
開發成本高
維護較麻煩
經過對css3動畫和canvas動畫對比
獲得結論：5個元素之內使用css3動畫，5個以上使用canvas動畫。

c) 合理使用RAF(requestAnimationFrame)
優勢：
能解決腳本問題引發的丟幀，卡頓問題
支持中間狀態監聽
缺點：
兼容問題

經過RAF動畫與settimeout動畫對比：
獲得結論：不須要兼容android 4.3瀏覽器的狀況下，請使用RAF製做腳本動畫

2. 高頻事件優化
相似touchmove，scroll這類的事件可致使屢次渲染，對於這種事件能夠經過如下手段進行優化：
a.使用requestAnimationFrame監聽幀變化，使得在正確的時間進行渲染
b.增長響應變化的時間間隔，減小重繪次數。

最後，針對合成/繪製只提一個優化手段：
GPU加速
觸發GPU加速的方式有：
CSS3 transitions
CSS3 3D transforms
WebGL 3D 繪製
Video
...

GPU加速其實是大幅減小了合成/繪製時間，從而大大地提升了頁面速度，但GPU加速有本身的缺點：
過多的GPU層會帶來性能開銷，主要緣由是使用GPU加速實際上是利用了GPU層的緩存，讓渲染資源能夠重複使用，因此一旦層多了，緩存增大，就會引發別的性能問題。
總結

按需加載提高速度，但可能致使大量重繪；
Touch響應快，但不少場景不適合；
GPU加速效率高，但內存開銷大等等
Loading會讓總體體驗流暢，但容易形成用戶流失
圖片壓縮讓帶寬成本下降，但可能會致使視覺效果變差
相似這樣的矛盾點還有不少，請結合業務按照實際狀況進行優化。javascript

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。