async 和 defer 的區別

• <script src="a.js" async></script>
• <script src="a.js" defer></script>

js 優化：

• 1、縮小JS代碼。
• 2、使用async和defer 編寫腳本。
• 3、拆分代碼以盡可能少地加載 - 並從依賴項中刪除未使用的代碼。

css 優化：

• 1、縮小CSS代碼。
• 2、提取關鍵CSS 並首先獲取它

• // 第一步提取出關鍵 css（critical.css）和非關鍵 css（other.css）
• critical.css + other.css
• // 第二步將關鍵 css（critical.css）用內聯方式嵌入頁面
• <style>...</style>
• // 第三步利用預處理在後臺加載非關鍵 css（other.css）
• <link rel="preload" href="other.css" as="style">
• // 第四步當 other.css 被緩存完後將 rel 屬性的 preload 改成 stylesheet。這使瀏覽器獲取緩存的 CSS 文件並將其應用於文檔
• <link rel="preload" href="other.css" as="style" onload="this.rel = ‘stylesheet‘">

html 優化：

• 通過網絡傳輸較少數據的第一種方法是縮小。縮小您發送給客戶端的HTML文檔（以及CSS和JS，如前所述）。
• 使用 Gzip壓縮文本(css,js)，圖片，字體，視頻。和其他二進制文件通常已經被壓縮，因此gzipping它們只會使響應時間更長。SVG圖像是唯一的例外，因為它們是文本。
• Gzip有另一種選擇 - 一種名為Brotli的壓縮算法。
• Brotli的優勢：在相同的CPU負載下，它比Gzip壓縮20-30％。這是免費下載的字節數減少30％！
• Brotli的劣勢：它相對較新，並且支持比Gzip更糟糕。因此，您不能輕易地將Gzip替換為Brotli - 您必須同時使用兩者來進行壓縮才能在不同的瀏覽器中工作。

註意：使用這些說明啟用Gzip將導致服務器動態壓縮資源。這會使響應時間略大。在大多數情況下，您不需要關心這一點，但如果您希望獲得一流的響應時間，請在構建期間預先壓縮資源。

註意：不要將Brotli的壓縮級別設置為最大值，因為它會比Gzip慢得多。Brotli的壓縮級別4 比Gzip的默認級別更快並且壓縮得更好。

什麽是CDN？

• 想象一下，您構建了一個應用程序並將其托管在位於美國的服務器上。如果應用程序的用戶在華沙，他們的請求必須一直前往美國並返回波蘭。這將花費大量時間，因為： - 請求必須行進很長的距離（其速度受光速限制）; - 它還必須通過許多路由器和類似設備（並且每個設備都會增加處理延遲）。
• 如果請求是檢索應用程序數據，並且只有美國的一個服務器知道如何正確地形成它，則可以證明這是合理的。但是，如果用戶試圖下載圖像或視頻，這絕對沒有必要 - 因為這只是一個可以由任何服務器提供服務的常規靜態內容。

預加載資源

• 指示瀏覽器提前對服務器的IP地址發出DNS請求。這對於CDN，Google字體以及所有其他情況非常有用，當您知道在短時間內需要資源時，知道它所托管的域，但不知道其確切路徑。在這種情況下，提前解析服務器的IP地址可以節省50到300毫秒。

• <link rel="dns-prefetch" href="//example.com">

• 指示瀏覽器提前執行與服務器的連接。在有用的情況下，它在相同的情況下dns-prefetch很有用，但可以建立完整的連接並節省更多時間。這裏的缺點是打開新連接是非常耗費資源的，因此您不希望過度使用此優化。

• <link rel="preconnect" href="https://example.com">

• 以低優先級預加載和緩存後臺資源。這對於為應用程序的下一頁預加載JS包非常有用。

• <link rel="prefetch" href="/style.css" as="style">

• 在後臺預加載具有高優先級的資源。這對於在幾秒鐘內預加載您需要的資源非常有用 - 例如，非關鍵的CSS文件。

• <link rel="preload" href="/style.css" as="style">

• 在後臺預加載指定的頁面並將其呈現在不可見的選項卡中。稍後，當訪問者點擊指向預渲染頁面的鏈接時，頁面會立即顯示。這是Google用來預加載其第一個搜索結果的內容。

• <link rel="prerender" href="https://example.com/about">

註意：不要過度使用預取方法。在後臺下載內容仍然會消耗訪問者的流量 - 這在移動設備上非常糟糕。因此，添加10個額外的預加載可能會使您的應用程序更快一些，但您的訪問者將為此付出真正的金錢。每頁2-4個預加載可能沒問題。

圖片介紹及應用--圖片在線壓縮

• svg 最適合矢量圖像，如圖標或徽標。
• jpg 最適用於照片，因為它可以壓縮圖像，但人眼無法看到輕微的質量損失。
• png 最適合您想要顯示而沒有任何質量損失的光柵圖形 - 例如光柵圖標或像素藝術。
• 不幸的是，webp在Chrome瀏覽器只支持。但是，您仍然可以使用標記加載或回退webp圖像
• webp適用於照片和光柵圖形，因為它支持有損和無損壓縮。它也比jpg壓縮至少20-30％。
• <picture>
• <source srset="img.webp" type="image/webp">
• <img src="img.jpg" type="image/jpeg">
• </picture>
• gif（並不推薦使用，推薦用視頻替代 gif ）- 使用視頻替換動畫GIF

svg壓縮

• 縮小。由於SVG圖像是文本，因此可以通過刪除註釋和空格來縮小它們。
• 簡化路徑。如果從圖形編輯器自動生成或導出SVG文件，則其中的路徑可能過於復雜。如果出現這種情況，請刪除不會直觀影響任何內容的路徑點
• 簡化文件結構。如果通常從圖形編輯器導出SVG文件，它還包括額外的元元素。刪除那些以使SVG更小。

jpg壓縮

• 壓縮級別為70-80的JPG圖像與壓縮級別為100的JPG圖像，質量損失並不明顯
• 要壓縮JPG圖像，請使用Photoshop或Gimp等圖形編輯器，webpack加載器（例如）或其他工具。 image-webpack-loader

imageoptim 圖片壓縮

如何在 webpack 中優化圖像

註意：不要過度使用預取方法。在後臺下載內容仍然會消耗訪問者的流量 - 這在移動設備上非常糟糕。因此，添加10個額外的預加載可能會使您的應用程序更快一些，但您的訪問者將為此付出真正的金錢。每頁2-4個預加載可能沒問題。

字體優化

• 字體要在 font-family 後面設置指定備用字體，後備字體可能是一種流行的內置字體（如Georgia）; 它可能是一個通用的字體系列（如 serif 或者 sans-serif）
• 使用 font-display CSS 屬性作為自定義字體

• - font-display: fallback ，瀏覽器將立即使用可用字體呈現文本：自定義字體（如果已緩存）或後備字體。如果未緩存自定義字體，瀏覽器將下載它。如果自定義字體下載得足夠快（通常在3秒內），瀏覽器會將後備字體與自定義字體交換。

  - font-display: optional。這與後備行為一樣，只有瀏覽器可以根據用戶的連接速度決定不使用自定義字體（如果你的3G或更慢的3G，下載自定義字體然後交換將需要永遠太晚了，太煩人了）

字體兼容查詢

windows 和 mac 常用字體

使用工具優化網站性能

• 第一個工具是Google PageSpeed Insights。

• - PageSpeed Insights 會對您提供的網址進行大量審核。他們分析頁面資源，查找優化建議並計算您的績效分數。如果您只是從網絡性能開始，這個工具將最適合您。旨在使 PageSpeed 得分為80或更高。

  - 如果您只是從網絡性能開始，這個工具將最適合您。旨在使 PageSpeed 得分為80或更高。

• 第二個工具是Lighthouse

• - Lighthouse 是 PageSpeed 對類固醇的見解。它有幾個審計（包括性能，搜索引擎優化和可訪問性）。它計算多個指標並輸出更多性能建議。

  - 與 PageSpeed Insights（作為獨立站點運行）不同，Lighthouse 內置於 Chrome DevTools 中。這意味著即使是非公開訪問的應用程序，您也可以使用它！

• 第三個工具是WebPageTest

• - WebPageTest 是一種高級審計工具。它分析網站性能並輸出大量數據，如指標，加載瀑布，內容細分等。它在進行復雜優化時很有用。

• 第四個工具是webpack-bundle-analyzer

• - webpack-bundle-analyzer 是一個 webpack 實用程序，可以顯示您的包內容。了解捆綁包中的大小以及可以優化的內容非常有用。

文章內容來自https://3perf.com/talks/web-perf-101/

web網站性能優化整理