資源優化

• 資源的壓縮與合并【見效最明顯的優化方法】
• • 為什么要壓縮&合并
  • HTML壓縮
  • CSS壓縮
  • JS壓縮與混淆
  • CSS JS文件合并
• 圖片格式優化【多種圖片格式，哪種最合適】
• • 圖片優化的方案
  • 圖片格式比較
• 圖片加載優化【突破大型網站圖片加載的瓶頸】
• • 圖片的懶加載（lazy loading）
  • 使用漸進式圖片
  • 漸進式圖片的優點和不足
  • 漸進式圖片的解決方案
  • 使用響應式圖片
• 字體優化
• • 什么是FOIT和FOUT
  • 使用font-display
  • 字體怎么引入進來？使用CSS Font Loading API
  • 使用Ajax + Base64

資源的壓縮與合并【見效最明顯的優化方法】

為什么要壓縮&合并

• 減少http請求數量
  請求越多，資源越多，所在網絡造成的開銷就越大
• 減少請求資源的大小
  節省流量，節省資源的大小，是我們不變的挑戰

HTML壓縮

• 使用在線工具進行壓縮
• 使用html-minifier等npm工具
  
  webpack去進行html壓縮時，也是集成了html-minifier工具
  上圖可以看到初始時候的大小，壓縮后的大小，節省高達30%，右邊也會把壓縮選項列出來，想壓縮到什么樣的情況，根據需要把不同的情況進行勾選或者反選

CSS壓縮

• 使用在線工具進行壓縮
• 使用clean-css等npm工具
  前面講的html-minifier已經包含了clean-css
  

JS壓縮與混淆

• 使用在線工具進行壓縮
• 使用Webpack對JS在構建時壓縮
  壓縮的同時做了混淆，所謂混淆，就是把它原來的變量名或者表達變成很難讓別人理解的形式，也達到了安全的一個目的

CSS JS文件合并

把若干資源合并成一個資源把它加載過來，這樣比較快，在網絡上可以達到節省的目的，比如有20個css，合成一個css一次性加載過來可能要比你20個分別加載要快，因為每個資源在請求時都要經歷不同的階段，要進行dns查找，tcp鏈接建立，這兩個可以復用，我們后面TTFB還有下載沒有辦法避免，下載20個資源分別下載和合成一個下載的下載量沒什么變化，這個不考慮，但是TTFB沒辦法避免，20個肯定要比1個稍微大一些，但是合并在一起帶來的問題是后續的解析處理和你自己的維護帶來了一些麻煩，所以折中考慮一下問題

• 若干小文件，maybe…
• 無沖突，服務相同的模塊，ok
• 優化加載，no
  現在希望漸進式加載，如果把css和js都合成一個，這兩個文件只有加載和解析完才能進行渲染，這個時間會很長，用戶會看到很長時間的白屏
  我們現在會用很多緩存技術，如果文件全合成一個，其中修改了一點點會造成整個文件的過期，就需要緩存去重新的進行更新，這也是極大的效率上的浪費

圖片格式優化【多種圖片格式，哪種最合適】

圖片優化的方案

如何正確選擇圖片格式？不同的格式有不同的優缺點，在不同場景中使用特定的圖片會有一定的優勢
圖片的大小要選擇合適，不要傳一個過大的圖片到客戶端，然后再去進行尺寸大小的調整，這樣過大的圖片在網絡上是一個浪費，需要多大就傳多大的圖片
能適配不同屏幕的尺寸，我有不同的用戶屏幕，要去設計不同尺寸的圖片在不同屏幕上進行顯示，保證在每個顯示器上都有合適尺寸的圖片來進行合適的顯示
壓縮：對于圖片壓縮，一定要謹慎，當對圖片進行壓縮時對圖片的質量也造成一定的損失，我們要根據我們網站的實際情況來看，攝影類網站圖片要追求精致感，電商網站追求圖片不高
圖片資源優先級：重要的圖片先進行加載
圖片懶加載
用一些工具：所有做的事情都不能手工去做，要有自動化的解決方案，要利用一些工具幫我們做這些事

圖片格式比較

• JPEG/JPG的優點
  很高的壓縮比，畫質還可以很好的被保存，色彩還是極為豐富
  用得最多的一種圖片格式，它是一種有損壓縮的圖片，這個圖片它進行了很好的壓縮，來減少本身的體積，本身的色彩感還很好，壓縮比很高，色彩還保存了很好，通常壓縮比達到50%時，還能保持60%的畫質，所以jpg會經常用于web開發中，通常采用24位的存儲方式，2的24次方，大約是1萬6千種顏色，所以畫質色彩感非常好，下圖是專門對jpg圖片進行壓縮的工具
  
• JPEG/JPG的使用場景
  當需要展示比較大的圖片時，還想保留畫質和色彩
• JPEG/JPG的缺陷
  如果圖片比較強調紋理或者邊緣，jpg不是特別合適，顯得有鋸齒感，或者很模糊，比如logo不會用jpg，會把邊緣表現得特別粗糙
• PNG的優點
  可以做透明背景的圖片，最大的優點是對jpg圖片的缺點進行彌補
• PNG的使用場景
  想強調線條、紋理、邊緣這些細膩程度時，jpg做不好，png做得比較好
• PNG的缺陷
  因為保留了這些比較細節的東西，所以本身體積相對會較大些，色彩上jpg和png時不相上下，png也有24位的格式，色彩豐富程度也是沒問題的，所以經常用png做一些小的圖片，比如圖標，logo之類的，如果想對png的圖片進行優化，可以用下圖中的工具，通常quality設置在65%-80%之間是比較好的，這樣可以達到對圖片80%的壓縮比率，也能保證圖片的質量
  
• WebP的優點
  google提出的新的圖片格式,已經推了幾年，普及程度不是特別高，跟png能有同樣的質量，但是壓縮比率比png要高，也就是說體積可以更小
  png壓縮到10kb，WebP可以壓縮到7，8kb，這差距不是特別明顯
• 支持WebP的瀏覽器
  WebP也要看下瀏覽器的兼容性，畢竟它不是一個標準，是google自己一家提出的，其他瀏覽器上不會特別支持
  
  svg圖片應用也非常廣泛，有非常多的優勢適合我們手機端進行應用

圖片加載優化【突破大型網站圖片加載的瓶頸】

圖片的懶加載（lazy loading）

• 原生的圖片懶加載方案
  
  
  需要瀏覽器去進行支持，自定義及可擴展性不是特別好，還是需要第三方插件幫我嗎實現這些效果

• 第三方圖片懶加載方案
  verlok/lazyload
  yall.js
  Blazy

import {LazyLoadImage} from 'react-lazy-load-image-component';<LazyLoadImageclassName={this.props.classes.media}src={this.props.image}effect="blur"rel="preconnect"/>

使用漸進式圖片

圖片不是一步到位就能加載出來的，剛開始圖片不是特別清楚，逐漸變清楚些，到最后變成非常清楚的圖片，這實現的基礎得益于jpg本身格式的特點，

基線jpg，自上而下的行掃描的形式
漸進式jpg，會從低像素到高像素的一個過程
這個圖片可以和美工要，他們在圖片制作和保存的時候實際上可以選擇這樣的格式

漸進式圖片的優點和不足

主要優點始終可以讓用戶看到圖片的全貌，只不過剛開始不太清晰，然后逐漸把它加載得更清楚，等待的時間和圖片本身的質量和大小是有關系的

漸進式圖片的解決方案

可以用這些工具生成我們需要的圖片，我們要自己幫自己

使用響應式圖片

所有設備所有的屏幕尺寸進行適配，不同的屏幕尺寸上都有一張合適的圖片給用戶達到最佳的視覺體驗，如何做？肯定不希望用一張超大的圖加載到所有設備上，然后再根據屏幕尺寸去進行縮放，這會造成浪費，而且在手機端網絡情況本來不是特別好

• Srcset屬性的使用
  圖片源集合，寬度達到100像素使用lighthouse-100.jpg圖片，寬度達到200像素使用lighthouse-200.jpg圖片，根據不同的屏幕尺寸都有一張合適的圖片，瀏覽器會根據屏幕的寬度挑選其中一張最為合適的，如何算這張呢？還和Sizes有關，會根據設備的dpi（iphone6屏幕像素比dpi為2倍圖，iphonex為3倍圖）及窗口的實際大小，根據實際情況選擇合適的圖片，可以達到真正響應式的圖片加載
• Sizes屬性的使用
• picture的使用
  兼容還不是很好
  

字體優化

網頁上的內容大部分以文字的形式展示給用戶，為了讓文字展示更漂亮，很多時候會使用自定義的字體，這些字體資源就會通過網絡加載到我們客戶端，其資源本身的大小會影響我們的加載和用戶體驗

什么是FOIT和FOUT

• 字體未下載完成時，瀏覽器隱藏或自動降級，導致字體閃爍
• Flash Of Invisible Text
  文字從看不到到看得到的閃爍變化過程，
• Flash Of Unstyled Text
  沒有經過樣式渲染，文字開始看上去一種樣式，后來經過樣式渲染又變成另外一種樣式，這中間會有個變化和閃動的過程，這就是我們字體遇到的常見的兩種問題，這兩個問題是不可避免的，因為字體經過網絡加載需要一定的時間，只要沒下載完成，瀏覽器必須做出一個選擇，要么等待下載完再給字體顯示出來，要么先有默認的已有字體先顯示，等字體下載完成后，用新字體重新進行渲染，所以字體的閃動沒辦法避免

使用font-display

• auto
• block
  開始不讓文字進行顯示，3s之后字體下載完了用你的字體，3s之后字體還沒下載完，先用默認的字體進行顯示，直到你的字體下載完成之后再換成你的字體
• swap
  剛開始就用默認的字體進行顯示，直到你的字體下載完成之后再換成你的字體，用戶從一開始就可以很快看到你的文字，不會看到白屏，用戶體驗會比較好，如果你的字體比較大，用默認文字顯示的時間就比較長，頁面很長一段時間不是很漂亮
• fallback
  是對block的優化，開始不顯示的等待時間縮短了，只有100ms
• optional
  為手機端特別優化的，瀏覽器可以判斷用戶網絡速度情況，如果速度比較好，那100ms之后就用你下載完的字體，如果判斷你的網絡情況不佳，預期很難在短時間內把你的字體下載下來，我就用默認的字體進行顯示，有一個問題，瀏覽器一旦做出了選擇就不會變化了，如果已經使用默認的字體，就不會換成你下載完的字體
  

字體怎么引入進來？使用CSS Font Loading API

通常會使用FontFace引入進來，很早的時候這個標準就被各個瀏覽器進行支持

font-family：字體名稱
src：字體從哪加載，可以工程里通過本地加載字體，也可以來自url
unicode-range：可以做個拆分，本來字符集非常大，比如中文漢字成千上萬，如果把所有的字體全放在一個字體文件里，那這個字體文件就會過大，我們網站上使用的字是有限的，通常不會使用整個漢字的字符集，所以這里就對一些高頻及常常使用的漢字進行歸類，這樣會形成幾個片段，這里引了很多font-face，每一組里字符集都是不一樣的，還有個特點就是我們這個字體文字真的要用到的時候才會去下載這個字體，所以在進行這樣有效的拆分之后，可以大大優化字體的加載效率

使用Ajax + Base64

使用Base64把我們的字體進行轉碼，然后嵌到css里或者js里，去進行加載，我把字體放在后臺去進行轉碼，轉碼之后通過異步請求的方式去獲取這個字體，通過Base64進行轉換之后，使它達到統一的格式，這樣我們有些字體不用太多去考慮瀏覽器是不是支持你這樣的字體格式，解決了兼容性問題；我們通過異步加載，可以推遲字體的加載時間；還有個主要的缺點，因為你把它作為Base64嵌到其他資源里，導致字體文件本身沒辦法有效的進行緩存，它的緩存實際就依賴于css的緩存，過期和緩存都不可控，所以這不是作為最佳的推薦方案，但是是可以考慮的一個方案

• 解決兼容性問題
• 缺點：緩存問題

總結

以上是生活随笔為你收集整理的（五）资源优化 (经典性能优化解决方案)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。