WEB前端機能優化

2019年8月24日 92次阅读 来源: 五月花開

要求歷程當中一些潛伏的機能優化點

深切明白http要求的歷程是前端機能優化的中心！

  • dns是不是可以經由過程緩存削減dns查詢時候？
  • 收集要求的歷程走近來的收集環境？
  • 雷同的靜態資本是不是可以緩存？
  • 可否削減要求http要求大小？
  • 削減http要求數目
  • 服務端襯着

DNS剖析歷程

《WEB前端機能優化》

服務器端要求處置懲罰

《WEB前端機能優化》

HTTP狀況碼

《WEB前端機能優化》

注重:

1、文件兼并存在的題目。

  • 首屏襯着題目（大眾庫兼并）
  • 緩存失效題目（差別頁面的兼并）

2、資本的兼并與緊縮(html,css,js緊縮和雜沓,文件兼并,開啟gzip)。

  • 目標1：削減要求http要求大小
  • 目標2：削減http要求數目

圖片相干的優化的中心觀點

png8/png24/png32之間的區分?

  • png8 — 2^8(256)色 + 支撐通明
  • png24 — 2^24色 + 不支撐通明
  • png32 — 2^24色 + 支撐通明

差別花樣圖片的特徵和經常運用的營業場景？

  • jpg有損緊縮，緊縮率高，不支撐通明（不須要通明圖片的的營業場景）
  • png支撐通明，瀏覽器兼容性好（須要通明圖片的營業場景）
  • webp緊縮水平更好，在ios webview中有兼容性題目（安卓悉數）
  • svg矢量圖，代碼內嵌，相對較小（圖片款式相對簡樸的場景）

對圖片的優化有哪些？

  • 對圖片舉行緊縮png24->png8（可以運用：https://tinypng.com/）
  • CSS雪碧圖（可以運用用這個網站天生雪碧圖相干的css代碼：http://www.spritecow.com）
  • Image inline（base64編碼）
  • 運用矢量圖

css、js加載與實行（斟酌優化點）

《WEB前端機能優化》

HTMLParser剖析器自上而下剖析，天生DOM樹。
外部資本link、script，瀏覽器會提議要求。
剖析CSS天生CSS劃定規矩樹，進而構建襯着樹（盤算element位置，規劃layout）。
接着挪用操縱系統NativeGUI的API舉行繪製。

瀏覽器襯着頁面

《WEB前端機能優化》

HTML襯着歷程的一些特徵

  • 遞次實行、併發加載

外部資本併發要求，一個域名下的併發要求數是有上限的。
所以平常將網站的靜態資本託管在多個CDN下。

  • css壅塞

css在head中可以壅塞頁面襯着、css可以壅塞js實行，然則css不壅塞外部劇本的加載。

  • js壅塞

直接引入的js壅塞頁面的襯着（asyn[異步下載、馬上實行]、differ[并行下載、遞次實行]這兩種體式格局加載js破例）

js不壅塞資本的加載（預資本加載器）

js遞次實行，壅塞後續js邏輯的實行（單線程）

懶加載、預加載

懶加載：圖片進入可視地區以後要求圖片資本。
懶加載的完成：
1.JS推斷圖片是不是進入可視地區。
2.當進入時，修正img的src屬性為現實圖片地點。

預加載：圖片等靜態資本在運用之前提早要求。
預加載完成：
1.運用標籤（<img src=”xxx” style=”display:none”>）
2.運用Image對象（new Image();）
3.運用XMLHTTPRequest對象（資本跨域題目）

迴流與重繪

UI線程和js線程互斥。
css機能能讓JavaScript變慢。
頻仍觸發重繪與迴流，會致使UI頻仍襯着，終究致使js變慢。

迴流： 當render tree中的一部分（或悉數）由於元素的範圍尺寸，規劃，隱蔽等轉變而須要從新構建，
這就稱為迴流（reflow）。

  • 頁面襯着初始化
  • 盒子模子相干屬性變化
  • 窗口resize事宜觸發
  • DOM構造變化，比方刪除了某個節點
  • 獵取某些屬性，激發迴流 許多瀏覽器會對迴流做優化，他會比及充足數目標變化發作，在做一次批處置懲罰迴流。 然則除了render樹的直接變化。

獵取以下屬性時會激發迴流：
width,height
offsetTop/Left/Width/Height
scrollTop/Left/Width/Height
clientTop/Left/Width/Height
挪用了getComputedStyle(), 或許 IE的 currentStyle

重繪： 當render tree中的一些元素須要更新屬性，而這些屬性只是影響元素的表面，作風，而不會
影響規劃的，比方background-color，這就稱為重繪。

Chrome中滿足以下恣意狀況就會建立圖層：

video、canvas都是一個自力的圖層。

  • 3D或透視變更（perspective transform）CSS屬性
  • 運用加快視頻解碼的<video>節點
  • 具有3D（WebGL）上下文或加快的2D上下文的<canvas>節點
  • 夾雜插件（如Flash）
  • 對本身的opacity做CSS動畫或運用一個動畫webkit變更的元素
  • 具有加快CSS過濾器的元素
  • 元素有一個包括複合層的子女節點（一個元素具有一個子元素，該子元素在本身的層里）
  • 元素有一個z-index較低且包括一個複合層的兄弟元素（換句話說就是該元素在複合層上面襯着）

經常運用的會自力為一個圖層的屬性：
transform:translateZ(0);
will-change:transform;

怎樣優化呢？

  • 將頻仍重繪迴流的DOM元素零丁作為一個自力圖層，那末這個DOM元素重繪和迴流的影響只會在這個圖層中。（然則：瀏覽器圖層合成也會花比較多的時候，所以，是不是新建圖層得看現實狀況，詳細題目，詳細分析。）
  • 用translate(轉變不會觸發瀏覽器從新規劃，然則元素仍會佔有原始位置)替換top(會觸發從新規劃)轉變。
  • 用opacity(不會觸發重繪)替換visibility(會觸發重繪)。
  • 不要一條一條地修正DOM的款式，預先定義好class,然後修正DOM的className。
  • 把DOM離線后修正。（eg：先把DOM給display:none,然後修正100次，再把它显示出來。）
  • 不要把DOM節點的屬性值放在一個輪迴里當做輪迴里的變量（offsetHeight、offsetWidth）
  • 不要運用table規劃，一個小的修改會形成全部table的從新規劃。
  • 對動畫新建圖層。
  • 啟用GPU硬件加快。（transform:translate3d(0,0,0)、transform:translateZ(0)）

瀏覽器存儲

Cookie相干

Cookie 由於HTTP要求無狀況，所以須要cookie去保護客戶端狀況。

cookie的天生體式格局：

  • 1.http response header中的 set-cookie（服務端天生，客戶端保留）
  • 2.js中可以經由過程document.cookie可以讀寫cookie（客戶端本身數據的存儲）

cookie存儲的限定：

  • 1.作為瀏覽器端存儲，大小4kb擺布
  • 2.須要設置逾期時候`expire

關於cookie的優化：

cookie中在相干域名下面–cdn的流量消耗
解決方法：__ cdn的域名和主站的域名要離開 __

關於cookie的讀寫操縱： 

// 寫入
document.cookie = "username=hello";
// 讀取
let cookie = document.cookie;
/**
  * param [String] cookie
  * return [Object] object
  */
function getCookie(cookie){
    if(!cookie){ return null; }
    let reg = /\s*([^;]+)\s*=\s*([^;]+)\s*/g;
    let obj = {};
    cookie.replace(reg,($0,$1,$2) => {
        if($1&&$2){
            obj[$1] = $2;
        }
    });
    return obj;
}

cookie存儲數據才能被localstorage替換。
httponly ：不允許js讀寫。（防備盜用cookie）

LocalStorage相干

  • HTML5設想出來特地用於瀏覽器存儲的
  • 大小為5M擺布
  • 僅在客戶端運用，不和服務器舉行通訊
  • 接口封裝較好
  • 瀏覽器當地緩存計劃

關於LocalStorage的讀寫操縱： 

// 寫入
localStorage.setItem('username','hello')
undefined
// 讀取
localStorage.getItem('username')
"hello"

SessionStorage相干

  • 會話級別的瀏覽器存儲
  • 大小為5M擺布
  • 僅在客戶端運用，不和服務器舉行通訊
  • 接口封裝較好
  • 關於表單信息的保護（多頁表單數據的保護）

關於 SessionStorage的讀寫操縱： 

// 寫入
 SessionStorage.setItem('username','hello')
undefined
// 讀取
 SessionStorage.getItem('username')
"hello"

IndexedDB（用的比較少）

  • IndexedDB是一種初級API，用於客戶端存儲大批構造化數據。
  • 為運用建立離線版本

PWA相干

  • 牢靠：在沒有收集的環境下也能供應基礎的頁面接見，而不會湧現“未連接到互聯網”的頁面。
  • 疾速：針對網頁襯着及收集數據接見有較好優化。
  • 融入（Engaging）:運用可以被增加到手機桌面，而且和一般運用一樣有全屏、推送等特徵。

詳細內容檢察筆記：

ServiceWorker探究
ServiceWorker和cacheStorage緩存及離線開闢

應用ServiceWorker舉行多頁面通訊： 

// 主頁面發送信息
navigator.serviceWorker.controller.postMessage(value);
// 主頁面監聽音訊
navigator.serviceWorker.addEventListener('message',event => {
    // console.log(event.data);
});

// ServiceWorker吸收信息(對其他頁面音訊分發)
self.addEventListener('message',event => {
    let promise = self.clients.matchAll().then(clientList => {
        let senderID = event.source ? event.source : 'unknown';
        clientList.forEach(client => {
            if(client.id === senderID){
                return;
            }
            client.postMessage({
                client: senderID,
                message: event.data
            });
        });
    });
    event.waitUntil(promise);    
});

瀏覽器緩存

Cache-Control

《WEB前端機能優化》

  • max-age 當小於緩存時候時，直接加載當地資本(from memory cache)，expires(到期時候http/1.0)和max-age比擬，max-age具有更高的優先級。
  • s-maxage 同享緩存，public相干的緩存裝備比方CDN，優先級高於max-age，假如客戶端接見到的是CDN服務器緩存中的數據切未變動則返回304狀況碼。(Cache-control:max-age=3600, s-maxage=31536000,就算在max-age時候內，也不直接加載當地文件，而是接見CDN緩存。緩存中的文件假如沒有變動，則直接關照客戶端304，加載當地文件。覺得和no-cache很像呀)
  • no-cache (比方：Cache-Control:private, max-age=0, no-cache),不是不緩存的意義，它現實上的機制是，依然對資本運用緩存，但每一次在運用緩存之前必需（MUST）向服務器對緩存資本舉行考證。
  • no-store 對該文件不實用任何緩存戰略。
  • public 資本將被客戶端和代理服務器緩存。
  • private 資本僅被客戶端緩存，代理服務器不緩存。
  • public VS private 要知道從服務器到瀏覽器之間並不是只要瀏覽器可以對資本舉行緩存，服務器的返回可能會經由一些中心（intermediate）服務器以至以至專業的中心緩存服務器，另有CDN。而有些要求返回是用戶級別、是私家的，所以你可能不願望這些中心服務器緩存返回。此時你須要將Cache-Control設置為private以防止暴露。

Expires

Expires是http/1.0中定義的瀏覽器緩存戰略。（expires: Wed, 24 Jan 2018 12:19:34 GMT）

  • 用來指定資本到期的時候，是服務器端的詳細的時候點。
  • 通知瀏覽器在逾期時候前可以直接從緩存取數據，而無需再次要求。

Last-Modified/If-Modified-Since

  • 基於客戶端和服務端協商的緩存機制
  • last-modified —— response header
  • if-modified-since —— request header
  • 須要與cache-control配合運用

然則last-modified是有缺點的。

  • 1.某些服務器不能獵取準確的修正時候
  • 文件修正時候改了，單文件內容卻沒有變

Etag/If-None-Match

此緩存戰略優先級高於Last-Modified/If-Modified-Since
《WEB前端機能優化》

  • 文件內容的hash值
  • etag —— response header
  • if-none-Match —— request header
  • 須要與cache-controlgongt運用

整體緩存流程圖

《WEB前端機能優化》

服務器端機能

vue襯着碰到的題目

vue實行歷程：
下載vue.js ==> 實行vue.js代碼 ==> 天生HTML頁面

跟着前端瀏覽器的機能的提拔，大批的運算在前端實行。
運用vue框架湧現了首屏機能、襯着題目。

優化計劃？

  • 構建層模板編譯（在構建層做模板編譯事情，將模板語法編譯成在vue的runtime中可以直接實行的js代碼）
  • 數據無關的prerender的體式格局（將vue襯着完成的靜態頁面返回）
  • 服務端襯着
    原文作者：五月花開
    原文地址: https://segmentfault.com/a/1190000015170460
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞