摘要：頁面渲染初始化盒子模型相關屬性變化窗口事件觸發(fā)結構變化，比如刪除了某個節(jié)點獲取某些屬性，引發(fā)回流很多瀏覽器會對回流做優(yōu)化，他會等到足夠數(shù)量的變化發(fā)生，在做一次批處理回流。使用框架出現(xiàn)了首屏性能渲染問題。

深入理解http請求的過程是前端性能優(yōu)化的核心！

dns是否可以通過緩存減少dns查詢時間？

網絡請求的過程走最近的網絡環(huán)境？

相同的靜態(tài)資源是否可以緩存？

能否減少請求http請求大小？

減少http請求數(shù)量

服務端渲染

注意:

1、文件合并存在的問題。

首屏渲染問題（公共庫合并）

緩存失效問題（不同頁面的合并）

2、資源的合并與壓縮(html,css,js壓縮和混亂,文件合并,開啟gzip)。

目的1：減少請求http請求大小

目的2：減少http請求數(shù)量

png8/png24/png32之間的區(qū)別?

png8 --- 2^8(256)色 + 支持透明

png24 --- 2^24色 + 不支持透明

png32 --- 2^24色 + 支持透明

不同格式圖片的特點和常用的業(yè)務場景？

jpg有損壓縮，壓縮率高，不支持透明（不需要透明圖片的的業(yè)務場景）

png支持透明，瀏覽器兼容性好（需要透明圖片的業(yè)務場景）

webp壓縮程度更好，在ios webview中有兼容性問題（安卓全部）

svg矢量圖，代碼內嵌，相對較小（圖片樣式相對簡單的場景）

對圖片的優(yōu)化有哪些？

對圖片進行壓縮png24->png8（可以使用：https://tinypng.com/）

CSS雪碧圖（可以使用用這個網站生成雪碧圖相關的css代碼：http://www.spritecow.com）

Image inline（base64編碼）

使用矢量圖

HTMLParser解析器自上而下解析，生成DOM樹。
外部資源link、script，瀏覽器會發(fā)起請求。
解析CSS生成CSS規(guī)則樹，進而構建渲染樹（計算element位置，布局layout）。
接著調用操作系統(tǒng)NativeGUI的API進行繪制。

順序執(zhí)行、并發(fā)加載

外部資源并發(fā)請求，一個域名下的并發(fā)請求數(shù)是有上限的。
所以一般將網站的靜態(tài)資源托管在多個CDN下。

css阻塞

css在head中可以阻塞頁面渲染、css可以阻塞js執(zhí)行，但是css不阻塞外部腳本的加載。

js阻塞

直接引入的js阻塞頁面的渲染（asyn[異步下載、立即執(zhí)行]、differ[并行下載、順序執(zhí)行]這兩種方式加載js例外）

js不阻塞資源的加載（預資源加載器）

js順序執(zhí)行，阻塞后續(xù)js邏輯的執(zhí)行（單線程）

懶加載：圖片進入可視區(qū)域之后請求圖片資源。
懶加載的實現(xiàn)：
1.JS判斷圖片是否進入可視區(qū)域。
2.當進入時，修改img的src屬性為實際圖片地址。

預加載：圖片等靜態(tài)資源在使用之前提前請求。
預加載實現(xiàn)：
1.使用標簽（）
2.使用Image對象（new Image();）
3.使用XMLHTTPRequest對象（資源跨域問題）

UI線程和js線程互斥。
css性能能讓JavaScript變慢。
頻繁觸發(fā)重繪與回流，會導致UI頻繁渲染，最終導致js變慢。

回流： 當render tree中的一部分（或全部）因為元素的規(guī)模尺寸，布局，隱藏等改變而需要重新構建，
這就稱為回流（reflow）。

頁面渲染初始化

盒子模型相關屬性變化

窗口resize事件觸發(fā)

DOM結構變化，比如刪除了某個節(jié)點

獲取某些屬性，引發(fā)回流 很多瀏覽器會對回流做優(yōu)化，他會等到足夠數(shù)量的變化發(fā)生，在做一次批處理回流。 但是除了render樹的直接變化。

獲取以下屬性時會引發(fā)回流：
width,height
offsetTop/Left/Width/Height
scrollTop/Left/Width/Height
clientTop/Left/Width/Height
調用了getComputedStyle(), 或者 IE的 currentStyle

重繪： 當render tree中的一些元素需要更新屬性，而這些屬性只是影響元素的外觀，風格，而不會
影響布局的，比如background-color，這就稱為重繪。

Chrome中滿足以下任意情況就會創(chuàng)建圖層：

video、canvas都是一個獨立的圖層。

3D或透視變換（perspective transform）CSS屬性

使用加速視頻解碼的

擁有3D（WebGL）上下文或加速的2D上下文的節(jié)點

混合插件（如Flash）

對自己的opacity做CSS動畫或使用一個動畫webkit變換的元素

擁有加速CSS過濾器的元素

元素有一個包含復合層的后代節(jié)點（一個元素擁有一個子元素，該子元素在自己的層里）

元素有一個z-index較低且包含一個復合層的兄弟元素（換句話說就是該元素在復合層上面渲染）

常用的會獨立為一個圖層的屬性：
transform:translateZ(0);
will-change:transform;

怎么優(yōu)化呢？

將頻繁重繪回流的DOM元素多帶帶作為一個獨立圖層，那么這個DOM元素重繪和回流的影響只會在這個圖層中。（但是：瀏覽器圖層合成也會花比較多的時間，所以，是否新建圖層得看實際情況，具體問題，具體分析。）

用translate(改變不會觸發(fā)瀏覽器重新布局，但是元素仍會占據(jù)原始位置)替代top(會觸發(fā)重新布局)改變。

用opacity(不會觸發(fā)重繪)替代visibility(會觸發(fā)重繪)。

不要一條一條地修改DOM的樣式，預先定義好class,然后修改DOM的className。

把DOM離線后修改。（eg：先把DOM給display:none,然后修改100次，再把它顯示出來。）

不要把DOM節(jié)點的屬性值放在一個循環(huán)里當成循環(huán)里的變量（offsetHeight、offsetWidth）

不要使用table布局，一個小的改動會造成整個table的重新布局。

對動畫新建圖層。

啟用GPU硬件加速。（transform:translate3d(0,0,0)、transform:translateZ(0)）

Cookie 因為HTTP請求無狀態(tài)，所以需要cookie去維護客戶端狀態(tài)。

cookie的生成方式：

1.http response header中的 set-cookie（服務端生成，客戶端保存）

2.js中可以通過document.cookie可以讀寫cookie（客戶端自身數(shù)據(jù)的存儲）

cookie存儲的限制：

1.作為瀏覽器端存儲，大小4kb左右

2.需要設置過期時間`expire

對于cookie的優(yōu)化：

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存儲數(shù)據(jù)能力被localstorage替代。
httponly ：不允許js讀寫。（防止盜用cookie）

HTML5設計出來專門用于瀏覽器存儲的

大小為5M左右

僅在客戶端使用，不和服務器進行通信

接口封裝較好

瀏覽器本地緩存方案

對于LocalStorage的讀寫操作：

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

會話級別的瀏覽器存儲

大小為5M左右

僅在客戶端使用，不和服務器進行通信

接口封裝較好

對于表單信息的維護（多頁表單數(shù)據(jù)的維護）

對于 SessionStorage的讀寫操作：

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

IndexedDB是一種低級API，用于客戶端存儲大量結構化數(shù)據(jù)。

為應用創(chuàng)建離線版本

可靠：在沒有網絡的環(huán)境下也能提供基本的頁面訪問，而不會出現(xiàn)“未連接到互聯(lián)網”的頁面。

快速：針對網頁渲染及網絡數(shù)據(jù)訪問有較好優(yōu)化。

融入（Engaging）:應用可以被增加到手機桌面，并且和普通應用一樣有全屏、推送等特性。

具體內容查看筆記：

ServiceWorker探索
ServiceWorker和cacheStorage緩存及離線開發(fā)

利用ServiceWorker進行多頁面通信：

// 主頁面發(fā)送信息
navigator.serviceWorker.controller.postMessage(value);
// 主頁面監(jiān)聽消息
navigator.serviceWorker.addEventListener("message",event => {
    // console.log(event.data);
});

// ServiceWorker接收信息(對其他頁面消息分發(fā))
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);    
});

max-age 當小于緩存時間時，直接加載本地資源(from memory cache)，expires(到期時間http/1.0)和max-age相比，max-age具有更高的優(yōu)先級。

s-maxage 共享緩存，public相關的緩存設備例如CDN，優(yōu)先級高于max-age，如果客戶端訪問到的是CDN服務器緩存中的數(shù)據(jù)切未更改則返回304狀態(tài)碼。(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）服務器甚至甚至專業(yè)的中間緩存服務器，還有CDN。而有些請求返回是用戶級別、是私人的，所以你可能不希望這些中間服務器緩存返回。此時你需要將Cache-Control設置為private以避免暴露。

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

用來指定資源到期的時間，是服務器端的具體的時間點。

告訴瀏覽器在過期時間前可以直接從緩存取數(shù)據(jù)，而無需再次請求。

基于客戶端和服務端協(xié)商的緩存機制

last-modified —— response header

if-modified-since —— request header

需要與cache-control共同使用

但是last-modified是有缺點的。

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

文件修改時間改了，單文件內容卻沒有變

此緩存策略優(yōu)先級高于Last-Modified/If-Modified-Since

文件內容的hash值

etag —— response header

if-none-Match —— request header

需要與cache-controlgongt使用

vue執(zhí)行過程：
下載vue.js ==> 執(zhí)行vue.js代碼 ==> 生成HTML頁面

隨著前端瀏覽器的性能的提升，大量的運算在前端執(zhí)行。
使用vue框架出現(xiàn)了首屏性能、渲染問題。

優(yōu)化方案？

構建層模板編譯（在構建層做模板編譯工作，將模板語法編譯成在vue的runtime中可以直接執(zhí)行的js代碼）

數(shù)據(jù)無關的prerender的方式（將vue渲染完成的靜態(tài)頁面返回）

服務端渲染