前端面試之路四(web效能優化篇)

kinshan發表於2018-11-30

前端面試Web優化

概括

涉及到的分類

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

涉及到的功能點

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

資源合併與壓縮

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

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

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

動態的載入靜態的資源

dns是否可以通過快取減少dns查詢時間
網路請求的過程走最近的網路環境
相同的靜態資源是否可以快取
能否減少http請求大小
能否減少http請求數量
服務端渲染

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

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

`html`壓縮

HTML程式碼壓縮就是壓縮這些在文字檔案中有意義，但是在HTML中不顯示的字元，包括空格,製表符,換行符等，還有一些其他意義的字元，如HTML註釋也可以被壓縮

意義

大型網站意義比較大

如何進行`html`的壓縮

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

`css`及`js`壓縮

`css`的壓縮

無效程式碼刪除
- 註釋、無效字元
css語義合併

`css`壓縮的方式

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

`js`的壓縮語混亂

無效字元的刪除
- 空格、註釋、回車等
剔除註釋
程式碼語意的縮減和優化
- 變數名縮短(a,b)等
程式碼保護
- 前端程式碼是透明的，客戶端程式碼使用者是可以直接看到的，可以輕易被窺探到邏輯和漏洞

`js`壓縮的方式

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

不合並檔案可能存在的問題

檔案與檔案有插入之間的上行請求，又增加了N-1個網路延遲
受丟包問題影響更嚴重
經過代理伺服器時可能會被斷開

檔案合併缺點

首屏渲染問題
- 檔案合併之後的js變大，如果首頁的渲染依賴這個js的話，整個頁面的渲染要等js請求完才能執行
- 如果首屏只依賴a.js，只要等a.js完成後就可執行
- 沒有通過伺服器端渲染，現在框架都需要等合併完的檔案請求完才能執行，基本都需要等檔案合併後的js
快取失效問題
- 標記 js``md5戳
- 合併之後的js,任何一個改動都會導致大面積的快取失效

檔案合併對應缺點的處理

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

檔案合併對應方法

使用線上網站進行合併
構建階段，使用nodejs進行檔案合併

圖片相關優化

一張`JPG`的解析過程

jpg有失真壓縮：雖然損失一些資訊，但是肉眼可見影響並不大

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

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

檔案大小 + 色彩豐富程度

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的方式
服務端渲染

金三銀四，看見大家都在為了面試而努力特開了一個前端模擬面試題，組織了面試的群友每天來群裡分享面試題，講題急思眾議，共同進步，歡迎最近在面試或者準備面試的群友加入本群，加群格式：工作年限-面試等級(初、中、高)-工作地點 (不在面試或者不準備面試或者不活躍的勿加本群，加了也會被清理)

前端效能優化之路——圖片篇。
2018-03-07
前端優化
前端面試題（五）（安全、效能優化）
2019-02-16
前端面試題優化
web效能優化
2018-07-27
Web優化
前端面試之路五(網路HTTP篇)
2018-12-25
前端面試HTTP
前端面試之路三(javaScript高階篇)
2018-12-21
前端面試JavaScript
效能優化篇
2022-02-28
優化
前端面試之路六(Javascript設計模式篇)
2018-12-21
前端面試JavaScript設計模式
webpack打包效能優化之路
2019-01-12
Web優化
Web 效能優化方法
2018-08-18
Web優化
web前端效能優化
2019-11-05
Web前端優化
前端面試13：前端效能優化的關鍵時間點
2018-12-05
前端面試優化
Linux效能優化實戰CPU篇之總結（四）
2022-03-03
Linux優化
IOS效能優化篇
2018-08-20
iOS優化
Oracle效能優化-SQL優化(案例四)
2020-02-18
Oracle優化SQL
web效能優化（理論）
2018-10-30
Web優化
Web 效能優化筆記
2019-11-19
Web優化筆記
Android效能優化（1）—webview優化篇
2018-03-12
Android優化WebView
iOS 效能篇一一UITableView效能優化
2020-10-21
iOSUIView優化
前端效能優化JavaScript篇
2019-02-16
前端優化JavaScript
Flinkx Logminer效能探測&優化之路
2021-10-11
優化
Android效能優化篇之服務優化
2018-06-14
Android優化
web效能常見優化技巧
2022-02-17
Web優化
《金三銀四面試系列》— jvm與效能優化
2019-04-01
面試JVM優化
Linux 效能優化之 CPU 篇 ----- 套路篇
2020-06-27
Linux優化
效能優化篇 - Performance（工具 & api）
2019-03-21
優化ORMAPI
UITableView效能優化-中級篇
2018-12-16
UIView優化
Linux 效能優化之 cup 篇
2020-06-25
Linux優化
Linux 效能優化之 IO 篇
2020-07-03
Linux優化
效能優化開篇綜述
2019-05-26
優化
PHP效能優化 -理論篇
2019-02-12
PHP優化
高效能服務端優化之路
2019-04-03
服務端優化
Greenplum 效能優化之路 --（二）儲存格式
2020-09-29
優化
WEB前端效能優化常見方法
2019-02-16
Web前端優化
輕鬆實現 Web 效能優化
2018-11-24
Web優化
打個總結:Web效能優化
2020-06-20
Web優化
使用Webpack4優化Web效能
2019-05-09
Web優化
Web效能優化之瘦身祕笈
2021-03-01
Web優化
學習 Webpack5 之路（優化篇）
2021-09-02
Web優化

前端面試之路四(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`