web前端性能優化總結

時間 2019-11-06

標籤 web 前端性能優化總結欄目 HTML 简体版

原文原文鏈接

歸納

涉及到的分類

網絡層面
構建層面
瀏覽器渲染層面
服務端層面

涉及到的功能點

資源的合併與壓縮
圖片編解碼原理和類型選擇
瀏覽器渲染機制
懶加載預加載
瀏覽器存儲
緩存機制
PWA
Vue-SSR

資源合併與壓縮

`http`請求的過程及潛在的性能優化點

理解減小http請求數量和減小請求資源大小兩個優化要點
掌握壓縮與合併的原理
掌握經過在線網站和fis3兩種實現壓縮與合併的方法

瀏覽器的一個請求從發送到返回都經歷了什麼

動態的加載靜態的資源javascript

dns是否能夠經過緩存減小dns查詢時間
網絡請求的過程走最近的網絡環境
相同的靜態資源是否能夠緩存
可否減小http請求大小
可否減小http請求數量
服務端渲染

資源的合併與壓縮設計到的性能點

減小http請求的數量
減小請求的大小

`html`壓縮

HTML代碼壓縮就是壓縮這些在文本文件中有意義，可是在 HTML中不顯示的字符，包括 空格, 製表符, 換行符等，還有一些其餘意義的字符，如 HTML註釋也能夠被壓縮

意義

大型網站意義比較大

如何進行`html`的壓縮

使用在線網站進行壓縮(走構建工具多，公司級在線網站手動壓縮小)
node.js提供了html-minifier工具
後端模板引擎渲染壓縮

`css`及`js`壓縮

`css`的壓縮

無效代碼刪除php
- 註釋、無效字符
css語義合併

`css`壓縮的方式

使用在線網站進行壓縮
使用html-minifier對html中的css進行壓縮
使用clean-css對css進行壓縮

`js`的壓縮語混亂

無效字符的刪除css
- 空格、註釋、回車等
剔除註釋
代碼語意的縮減和優化html
- 變量名縮短(a,b)等
代碼保護前端
- 前端代碼是透明的，客戶端代碼用戶是能夠直接看到的，能夠輕易被窺探到邏輯和漏洞

`js`壓縮的方式

使用在線網站進行壓縮
使用html-minifier對html中的js進行壓縮
使用uglifyjs2對js進行壓縮

不合並文件可能存在的問題

文件與文件有插入之間的上行請求，又增長了N-1個網絡延遲
受丟包問題影響更嚴重
通過代理服務器時可能會被斷開

文件合併缺點

首屏渲染問題vue
- 文件合併以後的js變大，若是首頁的渲染依賴這個js的話，整個頁面的渲染要等js請求完才能執行
- 若是首屏只依賴a.js，只要等a.js完成後就可執行
- 沒有經過服務器端渲染，如今框架都須要等合併完的文件請求完才能執行，基本都須要等文件合併後的js
緩存失效問題java
- 標記 js`md5`戳
- 合併以後的js,任何一個改動都會致使大面積的緩存失效

文件合併對應缺點的處理

公共庫合併
不一樣頁面的合併node
- 不一樣頁面js單獨打包
見機行事，隨機應變

文件合併對應方法

使用在線網站進行合併
構建階段，使用nodejs進行文件合併

圖片相關優化

一張`JPG`的解析過程

jpg有損壓縮：雖然損失一些信息，可是肉眼可見影響並不大android

`png8`/`png24`/`png32`之間的區別

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

文件大小 + 色彩豐富程度webpack

png32是在png24上支持了透明，針對不一樣的業務場景選擇不一樣的圖片格式很重要

不一樣的格式圖片經常使用的業務場景

不一樣格式圖片的特色

jpg有損壓縮，壓縮率高，不支持透明
png支持透明，瀏覽器兼容性好
webp壓縮程度更好，在ios webview中有兼容性問題
svg矢量圖，代碼內嵌，相對較小，圖片樣式相對簡單的場景(儘可能使用，繪製能力有限，圖片簡單用的比較多)

不一樣格式圖片的使用場景

jpg：大部分不須要透明圖片的業務場景
png：大部分須要透明圖片的業務場景
webp：android所有(解碼速度和壓縮率高於jpg和png，可是ios safari還沒支持)
svg：圖片樣式相對簡單的業務場景

圖片壓縮的幾種狀況

針對真實圖片狀況，捨棄一些相對可有可無的色彩信息
CSS雪碧圖：把你的網站用到的一些圖片整合到一張單獨的圖片中
- 優勢：減小HTTP請求的數量(經過backgroundPosition定位所需圖片)
- 缺點：整合圖片比較大時，加載比較慢(若是這張圖片沒有加載成功，整個頁面會失去圖片信息)facebook官網任然在用，主要pc用的比較多，相對性能比較強
Image-inline：將圖片的內容嵌到html中(減小網站的HTTP請求)
- base64信息，減小網站的HTTP請求,若是圖片比較小比較多，時間損耗主要在請求的骨幹網絡
使用矢量圖
- 使用SVG進行矢量圖的繪製
- 使用icon-font解決icon問題
在android下使用webp
- webp的優點主要體如今它具備更優的圖像數據壓縮算法，能帶來更小的圖片體積，並且擁有肉眼識別無差別的圖像質量；
- 同時具有了無損和有損的壓縮模式、Alpha透明以及動畫的特性，在JPEG和PNG上的轉化效果都很是優秀、穩定和統一

`css`和`js`的裝載與執行

HTML頁面加載渲染的過程

一個網站在瀏覽器端是如何進行渲染的

HTML渲染過程當中的一些特色

順序執行，併發加載
- 詞法分析：從上到下依次解析
  - 經過HTML生成Token對象（當前節點的全部子節點生成後，纔會經過next token獲取到當前節點的兄弟節點），最終生成Dom Tree
- 併發加載：資源請求是併發請求的
- 併發上限
  - 瀏覽器中能夠支持併發請求，不一樣瀏覽器所支持的併發數量不一樣（以域名劃分），以Chrome爲例，併發上限爲6個
  - 優化點：把CDN資源分佈在多個域名下
是否阻塞
- css阻塞
  - css 在head中經過link引入會阻塞頁面的渲染
    - 若是咱們把css代碼放在head中去引入的話，那麼咱們整個頁面的渲染實際上就會等待head中css加載並生成css樹，最終和DOM整合生成RanderTree以後纔會進行渲染
    - 爲了瀏覽器的渲染，能讓頁面顯示的時候視覺上更好。

避免某些狀況，如：假設你放在頁面最底部，用戶打開頁面時，有可能出現，頁面先是顯示一大堆文字或圖片，自上而下，絲毫沒有排版和樣式可言。最後，頁面又恢復所要的效果

- `css`不阻塞`js`的加載，但阻塞`js`的執行
    - `css`不阻塞外部腳步的加載(`webkit preloader 預資源加載器`)
- `js`阻塞
    -  直接經過`<script src>`引入會阻塞後面節點的渲染
        -  `html parse`認爲`js`會動態修改文檔結構(`document.write`等方式)，沒有進行後面文檔的變化
        -  `async`、`defer`(`async`放棄了依賴關係)
            - `defer`屬性（`<script src="" defer></script>`）

(這是延遲執行引入的js腳本（即腳本加載是不會致使解析中止，等到document所有解析完畢後，defer-script也加載完畢後，在執行全部的defer-script加載的js代碼，再觸發Domcontentloaded）

- `async`屬性（`<script src="" async></script>`） 
                - 這是異步執行引入的`js`腳本文件 
                - 與`defer`的區別是`async`會在加載完成後就執行，可是不會影響阻塞到解析和渲染。可是仍是會阻塞`load`事件，因此`async-script`會可能在`DOMcontentloaded`觸發前或後執行，可是必定會在`load`事件前觸發。

懶加載與預加載

懶加載

圖片進入可視區域以後請求圖片資源
對於電商等圖片不少，頁面很長的業務場景適用
減小無效資源的加載
併發加載的資源過多會會阻塞js的加載，影響網站的正常使用

img src被設置以後，webkit解析到以後纔去請求這個資源。因此咱們但願圖片到達可視區域以後，img src纔會被設置進來，沒有到達可視區域前並不現實真正的src，而是相似一個1px的佔位符。

場景：電商圖片

預加載

圖片等靜態資源在使用以前的提早請求
資源使用到時能從緩存中加載，提高用戶體驗
頁面展現的依賴關係維護

場景：抽獎

懶加載原生`js`和`zepto.lazyload`

原理

先將img標籤中的src連接設爲同一張圖片（空白圖片），將其真正的圖片地址存儲再img標籤的自定義屬性中（好比data-src）。當js監聽到該圖片元素進入可視窗口時，即將自定義屬性中的地址存儲到src屬性中，達到懶加載的效果。

注意問題：

關注首屏處理,由於還沒滑動
佔位，圖片大小首先須要預設高度，若是沒有設置的話，會所有顯示出來

var viewheight = document.documentElement.clientHeight   //可視區域高度

function lazyload(){
    var eles = document.querySelectorAll('img[data-original][lazyload]')

    Array.prototype.forEach.call(eles,function(item,index){
        var rect;
        if(item.dataset.original === '') return;
        rect = item.getBoundingClientRect(); //返回元素的大小及其相對於視口的

        if(rect.bottom >= 0 && rect.top < viewheight){
            !function(){
                var img = new Image();
                img.src = item.dataset.url;
                img.onload = function(){
                    item.src = img.src
                }
                item.removeAttribute('data-original');
                item.removeAttribute('lazyload');
            }()
        }
    })
}

lazyload()
document.addEventListener('scroll',lazyload)

預加載原生`js`和`preloadJS`實現

預加載實現的幾種方式

第一種方式：直接請求下來

<img src="https://user-gold-cdn.xitu.io/2019/2/21/1690d1b216cbfa18" style="display: none"/>
<img src="https://user-gold-cdn.xitu.io/2019/2/21/1690d1b21b70c8d2" style="display: none"/>
<img src="https://user-gold-cdn.xitu.io/2019/2/21/1690d1b216e17e26" style="display: none"/>
<img src="https://user-gold-cdn.xitu.io/2019/2/21/1690d1b217b3ae59" style="display: none"/>

第二種方式：image對象

var image = new Image();
image.src = "www.pic26.com/dafdafd/safdas.jpg"；

第三種方式：xmlhttprequest
- 缺點：存在跨域問題
- 優勢：好控制

var xmlhttprequest = new XMLHttpRequest();

xmlhttprequest.onreadystatechange = callback;

xmlhttprequest.onprogress = progressCallback;

xmlhttprequest.open("GET","http:www.xxx.com",true);

xmlhttprequest.send();

function callback(){
    if(xmlhttprequest.readyState == 4 && xmlhttprequest.status == 200){
        var responseText = xmlhttprequest.responseText;
    }else{
        console.log("Request was unsuccessful:" + xmlhttprequest.status);
    }
}

function progressCallback(){
    e = e || event;
    if(e.lengthComputable){
        console.log("Received"+e.loaded+"of"+e.total+"bytes")
    }
}

PreloadJS模塊

本質：權衡瀏覽器加載能力，讓它儘量飽和利用起來

重繪與迴流

`css`性能讓`javascript`變慢

要把css相關的外部文件引入放進head中，加載css時，整個頁面的渲染是阻塞的，一樣的執行javascript代碼的時候也是阻塞的，例如javascript死循環。

一個線程   =>  javascript解析
一個線程   =>  UI渲染

這兩個線程是互斥的，當UI渲染的時候，javascript的代碼被終止。當javascript代碼執行，UI線程被凍結。因此css的性能讓javascript變慢。

頻繁觸發重繪與迴流，會致使UI頻繁渲染，最終致使js變慢

什麼是重繪和迴流

迴流

當render tree中的一部分(或所有)由於元素的規模尺寸，佈局，隱藏等改變而須要從新構建。這就成爲迴流(reflow)
當頁面布局和幾何屬性改變時，就須要迴流

重繪

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

關係

用到chrome 分析 performance

迴流必將引發重繪，可是重繪不必定會引發迴流

避免重繪、迴流的兩種方法

觸發頁面重佈局的一些css屬性

盒子模型相關屬性會觸發重佈局
- width
- height
- padding
- margin
- display
- border-width
- border
- min-height
定位屬性及浮動也會觸發重佈局
- top
- bottom
- left
- right
- position
- float
- clear
改變節點內部文字結構也會觸發重佈局
text-align
overflow-y
font-weight
overflow
font-family
line-height
vertical-align
white-space
font-size

優化點：使用不觸發迴流的方案替代觸發迴流的方案

只觸發重繪不觸發迴流

color
border-style、border-radius
visibility
text-decoration
background、background-image、background-position、background-repeat、background-size
outline、outline-color、outline-style、outline-width
box-shadow

新建DOM的過程

獲取DOM後分割爲多個圖層
對每一個圖層的節點計算樣式結果(Recalculate style 樣式重計算)
爲每一個節點生成圖形和位置(Layout 迴流和重佈局)
將每一個節點繪製填充到圖層位圖中(Paint Setup和Paint 重繪)
圖層做爲紋理上傳至gpu
符合多個圖層到頁面上生成最終屏幕圖像(Composite Layers 圖層重組)

瀏覽器繪製`DOM`的過程是這樣子的：

獲取 DOM 並將其分割爲多個層（layer），將每一個層獨立地繪製進位圖（bitmap）中
將層做爲紋理（texture）上傳至 GPU，複合（composite）多個層來生成最終的屏幕圖像
left/top/margin之類的屬性會影響到元素在文檔中的佈局，當對佈局（layout）進行動畫時，該元素的佈局改變可能會影響到其餘元素在文檔中的位置，就致使了全部被影響到的元素都要進行從新佈局，瀏覽器須要爲整個層進行重繪並從新上傳到 GPU，形成了極大的性能開銷。
transform 屬於合成屬性（composite property），對合成屬性進行 transition/animation 動畫將會建立一個合成層（composite layer），這使得被動畫元素在一個獨立的層中進行動畫。
一般狀況下，瀏覽器會將一個層的內容先繪製進一個位圖中，而後再做爲紋理（texture）上傳到 GPU，只要該層的內容不發生改變，就不必進行重繪（repaint），瀏覽器會經過從新複合（recomposite）來造成一個新的幀。

`chrome`建立圖層的條件

將頻繁重繪迴流的DOM元素單獨做爲一個獨立圖層，那麼這個DOM元素的重繪和迴流的影響只會在這個圖層中

3D或透視變換
CSS 屬性使用加速視頻解碼的 <video> 元素
擁有 3D (WebGL) 上下文或加速的
2D 上下文的 <canvas> 元素
複合插件(如 Flash)
進行 opacity/transform 動畫的元素擁有加速
CSS filters 的元素元素有一個包含複合層的後代節點(換句話說，就是一個元素擁有一個子元素，該子元素在本身的層裏)
元素有一個 z-index 較低且包含一個複合層的兄弟元素(換句話說就是該元素在複合層上面渲染)

總結：對佈局屬性進行動畫，瀏覽器須要爲每一幀進行重繪並上傳到 GPU 中對合成屬性進行動畫，瀏覽器會爲元素建立一個獨立的複合層，當元素內容沒有發生改變，該層就不會被重繪，瀏覽器會經過從新複合來建立動畫幀

gif圖

總結

儘可能避免使用觸發迴流、重繪的CSS屬性
將重繪、迴流的影響範圍限制在單獨的圖層(layers)以內
圖層合成過程當中消耗很大頁面性能，這時候須要平衡考慮重繪迴流的性能消耗

實戰優化點總結

用translate替代top屬性
- top會觸發layout，但translate不會
用opacity代替visibility
- opacity不會觸發重繪也不會觸發迴流，只是改變圖層alpha值，可是必需要將這個圖片獨立出一個圖層
- visibility會觸發重繪
不要一條一條的修改DOM的樣式，預先定義好class，而後修改DOM的className
把DOM離線後修改，好比：先把DOM給display:none（有一次reflow），而後你修改100次，而後再把它顯示出來
不要把DOM節點的屬性值放在一個循環裏當成循環的變量
- offsetHeight、offsetWidth每次都要刷新緩衝區，緩衝機制被破壞
- 先用變量存儲下來
不要使用table佈局，可能很小的一個小改動會形成整個table的從新佈局
- div只會影響後續樣式的佈局
動畫實現的速度的選擇
- 選擇合適的動畫速度
- 根據performance量化性能優化
對於動畫新建圖層
- 啓用gpu硬件加速(並行運算)，gpu加速意味着數據須要從cpu走總線到gpu傳輸，須要考慮傳輸損耗.
  - transform:translateZ(0)
  - transform:translate3D(0)

瀏覽器存儲

`cookies`

多種瀏覽器存儲方式並存，如何選擇？

由於http請求無狀態，因此須要cookie去維持客戶端狀態
cookie的生成方式：
- http-->response header-->set-cookie
- js中能夠經過document.cookie能夠讀寫cookie
- cookie的使用用處：
  - 用於瀏覽器端和服務器端的交互(用戶狀態)
  - 客戶端自身數據的存儲
expire：過時時間
cookie的限制：
- 做爲瀏覽器存儲，大小4kb左右
- 須要設置過時時間 expire
重要屬性：httponly 不支持js讀寫(防止收到模擬請求攻擊)
不太做爲存儲方案而是用於維護客戶關係
優化點：cookie中在相關域名下面
- cdn的流量損耗
- 解決方案：cdn的域名和主站域名要分開

`localStorage`

`localstorage`

HTML5設計出來專門用於瀏覽器存儲的
大小爲5M左右
僅在客戶端使用，不和服務端進行通訊
接口封裝較好
瀏覽器本地緩存方案

`sessionstorage`

會話級別的瀏覽器存儲
大小爲5M左右
僅在客戶端使用，不和服務器端進行通訊
接口封裝較好
對於表單信息的維護

`indexedDB`

IndexedDB是一種低級API，用於客戶端存儲大量結構化數據。該API使用索引來實現對該數據的高性能搜索。雖然Web
Storage對於存儲叫少許的數據很管用，但對於存儲更大量的結構化數據來講，這種方法不太有用。IndexedDB提供了一個解決方案。

爲應用建立離線版本

cdn域名不要帶cookie
localstorage存庫、圖片

cookie種在主站下，二級域名也會攜帶這個域名，形成流量的浪費

`Service Worker`產生的意義

`PWA`與`Service Worker`

PWA(Progressive Web Apps)是一種Web App新模型，並非具體指某一種前言的技術或者某一個單一的知識點，咱們從英文縮寫來看就能看出來，這是一個漸進式的Web App，是經過一系列新的Web特性，配合優秀的UI交互設計，逐步加強Web App的用戶體驗

`PWA`與`Service worker`

`chrome` 插件 `lighthouse`

檢測是否是一個漸進式 web app

當前手機在弱網環境下能不能加載出來
離線環境下能不能加載出來

特色

可靠：沒有網絡的環境中也能提供基本的頁面訪問，而不會出現「未鏈接到互聯網」的頁面
快速：針對網頁渲染及網絡數據訪問有較好的優化
融入(Engaging)：應用能夠被增長到手機桌面，而且和普通應用同樣有全屏、推送等特性

`service worker`

service worker是一個腳本，瀏覽器獨立於當前頁面，將其在後臺運行，爲實現一些不依賴頁面的或者用戶交互的特性打開了一扇大門。在將來這些特性將包括消息推送，背景後臺同步， geofencing(地理圍欄定位)，但他將推出的第一個首要的特性，就是攔截和處理網絡請求的能力，包括以編程方式來管理被緩存的響應。

案例分析

Service Worker學習與實踐

瞭解servie worker

chrome://serviceworker-internals/

chrome://inspect/#service-worker/

service worker網絡攔截能力，存儲Cache Storage，實現離線應用

`indexedDB`

callback && callback()寫法
至關於 
if(callback){
   callback();
}

`cookie`、`session`、`localStorage`、`sessionStorage`基本操做

`indexedDB`基本操做

object store:對象存儲
自己就是結構化存儲

function openDB(name, callback) {
            //創建打開indexdb  indexedDB.open
            var request = window.indexedDB.open(name)
            request.onerror = function(e) {
                console.log('on indexedDB error')
            }
            request.onsuccess = function(e) {
                    myDB.db = e.target.result
                    callback && callback()
                }
                //from no database to first version,first version to second version...
            request.onupgradeneeded = function() {
                console.log('created')
                var store = request.result.createObjectStore('books', {
                    keyPath: 'isbn'
                })
                console.log(store)
                var titleIndex = store.createIndex('by_title', 'title', {
                    unique: true
                })
                var authorIndex = store.createIndex('by_author', 'author')

                store.put({
                    title: 'quarry memories',
                    author: 'fred',
                    isbn: 123456
                })
                store.put({
                    title: 'dafd memories',
                    author: 'frdfaded',
                    isbn: 12345
                })
                store.put({
                    title: 'dafd medafdadmories',
                    author: 'frdfdsafdafded',
                    isbn: 12345434
                })
            }
        }
        var myDB = {
            name: 'tesDB',
            version: '2.0.1',
            db: null
        }

        function addData(db, storeName) {

        }

        openDB(myDB.name, function() {
            // myDB.db = e.target.result
            // window.indexedDB.deleteDatabase(myDB.name)
        });

        //刪除indexedDB

`indexDB`事務

transcation 與 object store創建關聯關係來操做object store
創建之初能夠配置

var transcation = db.transcation('books', 'readwrite')
 var store = transcation.objectStore('books')

 var data =store.get(34314)
 store.delete(2334)
 store.add({
     title: 'dafd medafdadmories',
     author: 'frdfdsafdafded',
     isbn: 12345434
 })

`Service Worker`離線應用

serviceworker須要https協議

如何實現`ServiceWorker`與主頁面之間的通訊

lavas

緩存

指望大規模數據能自動化緩存，而不是手動進行緩存，須要瀏覽器端和服務器端協商一種緩存機制

Cache-Control所控制的緩存策略

last-modified 和 etage以及整個服務端瀏覽器端的緩存流程

基於node實踐以上緩存方式

`httpheader`

`可緩存性`

public:代表響應能夠被任何對象（包括：發送請求的客戶端，代理服務器，等等）緩存。
private:代表響應只能被單個用戶緩存，不能做爲共享緩存（即代理服務器不能緩存它）。
no-cache:強制全部緩存了該響應的緩存用戶，在使用已存儲的緩存數據前，發送帶驗證器的請求到原始服務器
only-if-cached:代表若是緩存存在，只使用緩存，不管原始服務器數據是否有更新

`到期`

max-age=<seconds>:設置緩存存儲的最大週期，超過這個時間緩存被認爲過時(單位秒)。與 Expires相反，時間是相對於請求的時間。
s-maxage=<seconds>:覆蓋max-age 或者 Expires 頭，可是僅適用於共享緩存(好比各個代理)，而且私有緩存中它被忽略。cdn緩存
max-stale[=<seconds>]

代表客戶端願意接收一個已通過期的資源。可選的設置一個時間(單位秒)，表示響應不能超過的過期時間。

min-fresh=<seconds>

表示客戶端但願在指定的時間內獲取最新的響應。

`從新驗證`和`從新加載`

從新驗證

must-revalidate：緩存必須在使用以前驗證舊資源的狀態，而且不可以使用過時資源。
proxy-revalidate：與must-revalidate做用相同，但它僅適用於共享緩存（例如代理），並被私有緩存忽略。
immutable ：表示響應正文不會隨時間而改變。資源（若是未過時）在服務器上不發生改變，所以客戶端不該發送從新驗證請求頭（例如If-None-Match或If-Modified-Since）來檢查更新，即便用戶顯式地刷新頁面。在Firefox中，immutable只能被用在 https:// transactions.

從新加載

no-store:緩存不該存儲有關客戶端請求或服務器響應的任何內容。
no-transform:不得對資源進行轉換或轉變。Content-Encoding, Content-Range, Content-Type等HTTP頭不能由代理修改。例如，非透明代理能夠對圖像格式進行轉換，以便節省緩存空間或者減小緩慢鏈路上的流量。 no-transform指令不容許這樣作。

`Expires`

緩存過時時間，用來指定資源到期的時間，是服務器端的時間點
告訴瀏覽器在過時時間前瀏覽器能夠直接從瀏覽器緩存中存取數據，而無需再次請求
expires是http1.0的時候的
http1.1時候，咱們希望cache的管理統一進行，max-age優先級高於expires，當有max-age在的時候expires可能就會被忽略。
若是沒有設置cache-control時候會使用expires

`Last-modified`和`If-Modified-since`

基於客戶端和服務器端協商的緩存機制
last-modified --> response header

if-modified-since --> request header
須要與cache-control共同使用

last-modified有什麼缺點？

某些服務端不能獲取精確的修改時間
文件修改時間改了，但文件的內容卻沒有變

`Etag` 和 `If-none-match`

文件內容的hash值
etag -->reponse header

if-none-match -->request header
須要與cache-control共同使用

好處：

比if-modified-since更加準確
優先級比etage更高

流程圖

服務端性能優化

服務端用的node.js由於和前端用的同一種語言，能夠利用服務端運算能力來進行相關的運算而減小前端的運算

vue渲染遇到的問題
vue-ssr和原理和引用

vue渲染面臨的問題

先加載vue.js
=>  執行vue.js代碼
=>  生成html

之前沒有前端框架時，

用jsp/php在服務端進行數據的填充，發送給客戶端就是已經填充好數據`的html
使用jQuery異步加載數據
使用React和Vue前端框架
- 代價：須要框架所有加載完，才能把頁面渲染出來，頁面的首屏性能很差

多層次的優化方案

構建層的模板編譯。runtime,compile拆開,構建層作模板編譯工做。webpack構建時候，統一，直接編譯成runtime能夠執行的代碼
數據無關的prerender的方式
服務端渲染

相關標籤/搜索

每日一句

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

web前端性能優化總結

歸納

涉及到的分類

涉及到的功能點

資源合併與壓縮

http請求的過程及潛在的性能優化點

瀏覽器的一個請求從發送到返回都經歷了什麼

資源的合併與壓縮設計到的性能點

html壓縮

如何進行html的壓縮

css及js壓縮

css的壓縮

css壓縮的方式

js的壓縮語混亂

js壓縮的方式

不合並文件可能存在的問題

文件合併缺點

文件合併對應缺點的處理

文件合併對應方法

圖片相關優化

一張JPG的解析過程

png8/png24/png32之間的區別

不一樣的格式圖片經常使用的業務場景

不一樣格式圖片的特色

不一樣格式圖片的使用場景

圖片壓縮的幾種狀況

css和js的裝載與執行

HTML頁面加載渲染的過程

一個網站在瀏覽器端是如何進行渲染的

HTML渲染過程當中的一些特色

懶加載與預加載

懶加載

預加載

懶加載原生js和zepto.lazyload

預加載原生js和preloadJS實現

預加載實現的幾種方式

重繪與迴流

css性能讓javascript變慢

什麼是重繪和迴流

迴流

重繪

關係

避免重繪、迴流的兩種方法

觸發頁面重佈局的一些css屬性

只觸發重繪不觸發迴流

新建DOM的過程

瀏覽器繪製DOM的過程是這樣子的：

chrome建立圖層的條件

總結

實戰優化點總結

瀏覽器存儲

cookies

多種瀏覽器存儲方式並存，如何選擇？

localStorage

localstorage

sessionstorage

indexedDB

Service Worker產生的意義

PWA與Service Worker

PWA與Service worker

chrome 插件 lighthouse

service worker

案例分析

indexedDB

cookie、session、localStorage、sessionStorage基本操做

indexedDB基本操做

indexDB事務

Service Worker離線應用

如何實現ServiceWorker與主頁面之間的通訊

緩存

httpheader

可緩存性

到期

從新驗證和從新加載

Expires

Last-modified和If-Modified-since

Etag 和 If-none-match

流程圖

服務端性能優化

vue渲染面臨的問題

`http`請求的過程及潛在的性能優化點

`html`壓縮

如何進行`html`的壓縮

`css`及`js`壓縮

`css`的壓縮

`css`壓縮的方式

`js`的壓縮語混亂

`js`壓縮的方式

一張`JPG`的解析過程

`png8`/`png24`/`png32`之間的區別

`css`和`js`的裝載與執行

懶加載原生`js`和`zepto.lazyload`

預加載原生`js`和`preloadJS`實現

`css`性能讓`javascript`變慢

瀏覽器繪製`DOM`的過程是這樣子的：

`chrome`建立圖層的條件

`cookies`

`localStorage`

`localstorage`

`sessionstorage`

`indexedDB`

`Service Worker`產生的意義

`PWA`與`Service Worker`

`PWA`與`Service worker`

`chrome` 插件 `lighthouse`

`service worker`

`indexedDB`

`cookie`、`session`、`localStorage`、`sessionStorage`基本操做

`indexedDB`基本操做

`indexDB`事務

`Service Worker`離線應用

如何實現`ServiceWorker`與主頁面之間的通訊

`httpheader`

`可緩存性`

`到期`

`從新驗證`和`從新加載`

`Expires`

`Last-modified`和`If-Modified-since`

`Etag` 和 `If-none-match`