Web 網(wǎng)頁性能及性能優(yōu)化

一、Web 性能

Web 性能是 Web 開發(fā)的一個(gè)重要方面，側(cè)重于網(wǎng)頁加載速度以及對(duì)用戶輸入的響應(yīng)速度

通過優(yōu)化網(wǎng)站來改善性能，可以在為用戶提供更好的體驗(yàn)

網(wǎng)頁性能既廣泛又非常深入

1. 為什么性能這么重要？

1. 性能關(guān)乎留住用戶

性能對(duì)于任何在線業(yè)務(wù)都至關(guān)重要

與加載速度緩慢、讓人感覺運(yùn)行緩慢的網(wǎng)站相比，加載速度快并能及時(shí)響應(yīng)用戶輸入的網(wǎng)站能更好地吸引并留住用戶

2. 性能能提高轉(zhuǎn)化次數(shù)

性能會(huì)對(duì)網(wǎng)站用戶是否會(huì)瀏覽應(yīng)用產(chǎn)生重大影響

3. 性能關(guān)乎用戶體驗(yàn)

隨著網(wǎng)頁開始加載，用戶會(huì)等待一段時(shí)間，等待內(nèi)容顯示。在此之前，就談不上用戶體驗(yàn)

快速連接會(huì)讓這種體驗(yàn)一閃而過。而如果連接速度較慢，用戶就不得不等待

性能是打造良好用戶體驗(yàn)的基本要素

當(dāng)網(wǎng)站發(fā)送大量代碼時(shí)，瀏覽器必須使用用戶流量套餐中的兆字節(jié)流量下載應(yīng)用

尤其是移動(dòng)設(shè)備的 CPU 性能和內(nèi)存有限。這可能會(huì)導(dǎo)致糟糕的性能條件，而且考慮到人們了解人類的行為，用戶只能容忍網(wǎng)站上的不利條件長達(dá)很長的時(shí)間，然后才會(huì)放棄網(wǎng)站

2. 網(wǎng)頁核心指標(biāo)

2.1. 指標(biāo)類型：

• 感知加載速度：網(wǎng)頁可以多快地加載網(wǎng)頁中的所有視覺元素并將其渲染到屏幕上

• 加載響應(yīng)速度：頁面加載和執(zhí)行組件快速響應(yīng)用戶互動(dòng)所需的任何 JavaScript 代碼的速度

• 運(yùn)行時(shí)響應(yīng)速度：網(wǎng)頁在加載后對(duì)用戶互動(dòng)的響應(yīng)速度

• 視覺穩(wěn)定性：頁面上的元素是否會(huì)以用戶意想不到的方式發(fā)生偏移，是否可能會(huì)干擾用戶的互動(dòng)？

• 流暢性：過渡和動(dòng)畫是否以一致的幀速率渲染，并在一種狀態(tài)之間流暢地流動(dòng)？

2.2. 要衡量的指標(biāo)：

• FCP（First Contentful Paint） ：從網(wǎng)頁開始加載到網(wǎng)頁內(nèi)容的任何部分呈現(xiàn)在屏幕上所用的時(shí)間

• LCP（Largest Contentful Paint） ：從網(wǎng)頁開始加載到屏幕上呈現(xiàn)最大的文本塊或圖片元素所用的時(shí)間

• INP（Interaction to Next Paint） ：與網(wǎng)頁進(jìn)行的每次 tap 、 click 或鍵盤互動(dòng)的延遲時(shí)間，并根據(jù)交互的數(shù)量選擇頁面中最差的交互延遲作為單個(gè)代表性值來描述頁面的總體響應(yīng)性

• TBT（Total Blocking Time） ：從 FCP 到可交互時(shí)間 ( TTI ) 之間的總時(shí)長

• CLS（Cumulative Layout Shift） ：從頁面開始加載到其生命周期狀態(tài)更改為隱藏期間發(fā)生的所有意外布局偏移的累計(jì)分?jǐn)?shù)

• TTFB（Time to First Byte） ：網(wǎng)絡(luò)使用資源的第一個(gè)字節(jié)響應(yīng)用戶請(qǐng)求所花費(fèi)的時(shí)間

• FID（First Input Delay） ：用戶首次與網(wǎng)頁互動(dòng)（即，點(diǎn)擊鏈接、點(diǎn)按按鈕或使用由 JavaScript 提供支持的自定義控件）到瀏覽器實(shí)際能夠開始處理事件處理腳本以響應(yīng)相應(yīng)互動(dòng)的時(shí)間

2.3. Web 頁面性能衡量指標(biāo)-以用戶為中心的性能指標(biāo)

Web 頁面性能衡量指標(biāo)-以用戶為中心的性能指標(biāo)

二、性能優(yōu)化

1. HTML 頁面性能優(yōu)化

每個(gè)網(wǎng)站都是從請(qǐng)求 HTML 文檔開始的，該請(qǐng)求對(duì)網(wǎng)站的加載速度有著重大影響

要想構(gòu)建可快速加載的網(wǎng)站，第一步就是要及時(shí)從服務(wù)器接收網(wǎng)頁 HTML 的響應(yīng)

當(dāng)在瀏覽器的地址欄中輸入網(wǎng)址時(shí)，瀏覽器會(huì)向服務(wù)器發(fā)送 GET 請(qǐng)求進(jìn)行檢索

網(wǎng)頁的第一個(gè)請(qǐng)求針對(duì)的是 HTML 資源，因此，確保 HTML 以最短延遲快速到達(dá)是關(guān)鍵性能目標(biāo)

1.1. 盡量減少重定向

在請(qǐng)求資源時(shí)，服務(wù)器可能會(huì)做出一個(gè)重定向響應(yīng)，該重定向可以是永久重定向（301 Moved Permanently 響應(yīng)）或臨時(shí)重定向（302 Found 響應(yīng)）

重定向會(huì)降低網(wǎng)頁加載速度，因?yàn)樗�需要瀏覽器在新位置發(fā)出額外的 HTTP 請(qǐng)求來檢索資源。重定向有兩種類型：

1. 完全發(fā)生在源站內(nèi)的同源重定向。這些類型的重定向完全由項(xiàng)目控制，因?yàn)楣芾硭鼈兊倪壿嬐耆�位于�? Web 服務(wù)器上
2. 由其他源啟動(dòng)的跨域重定向。這些類型的重定向通常無法控制

1.2. 緩存 HTML 響應(yīng)

緩存 HTML 響應(yīng)很困難，因?yàn)轫憫?yīng)可能包含指向其他關(guān)鍵資源（例如 CSS 、 JavaScript 、圖片和其他資源類型）的鏈接。這些資源的文件名中可能包含唯一指紋，該指紋會(huì)根據(jù)文件的內(nèi)容而變化

但是較短的緩存生命周期（而不是不緩存）具有諸多優(yōu)勢(shì)：

• 允許在 CDN 中緩存資源，減少從源服務(wù)器傳送的請(qǐng)求數(shù)量

• 在瀏覽器中傳送資源，從而重新驗(yàn)證資源而不是再次下載此

• 可以將緩存資源的適當(dāng)時(shí)間設(shè)置為合適的分鐘數(shù)

緩存 HTML 的一種方法是使用 ETag 或 Last-Modified 響應(yīng)標(biāo)頭

ETag （也稱為實(shí)體標(biāo)記）標(biāo)頭是一個(gè)標(biāo)識(shí)符，用于唯一標(biāo)識(shí)所請(qǐng)求資源，通常使用資源內(nèi)容的哈希值：

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

每當(dāng)資源發(fā)生變化時(shí)，都必須生成新的 ETag 值。在后續(xù)請(qǐng)求中，瀏覽器會(huì)通過 If-None-Match 請(qǐng)求標(biāo)頭發(fā)送 ETag 值。如果服務(wù)器上的 ETag 與瀏覽器發(fā)送的 ETag 匹配，服務(wù)器會(huì)返回 304 Not Modified 響應(yīng)，瀏覽器則會(huì)使用緩存中的資源。雖然這仍然會(huì)導(dǎo)致網(wǎng)絡(luò)延遲，但 304 Not Modified 響應(yīng)比整個(gè) HTML 資源小得多

但是，重新驗(yàn)證資源的新鮮度涉及的網(wǎng)絡(luò)延遲也本身也是一個(gè)缺點(diǎn)，需自行決定以這種方式緩存 HTML 的額外工作是否值得，或者最好是謹(jǐn)慎操作，不必費(fèi)心緩存 HTML 內(nèi)容。

1.3. 測(cè)量服務(wù)器響應(yīng)時(shí)間

如果響應(yīng)未緩存，則服務(wù)器的響應(yīng)時(shí)間在很大程度上取決于的托管服務(wù)提供商和后端應(yīng)用堆棧

與動(dòng)態(tài)網(wǎng)頁相比，提供動(dòng)態(tài)生成的響應(yīng)（例如從數(shù)據(jù)庫獲取數(shù)據(jù)）的網(wǎng)頁的 TTFB 可能更高，無需在后端投入大量計(jì)算時(shí)間即可立即提供

1.4. 壓縮

基于文本的響應(yīng)（例如 HTML 、 JavaScript 、 CSS 和 SVG 圖片）應(yīng)進(jìn)行壓縮，以減小通過網(wǎng)絡(luò)傳輸時(shí)的大小，從而加快其下載速度。最常用的壓縮算法是 gzip 和 Brotli 。 Brotli 比 gzip 提高了約 15% 到 20%。

• 盡可能使用 Brotli ，所有主流瀏覽器都支持 Brotli ，但如果網(wǎng)站有大量用戶在舊版瀏覽器中使用，請(qǐng)確保將 gzip 用作后備選項(xiàng)，因?yàn)槿魏螇嚎s都比不進(jìn)行壓縮要好。
• 文件大小至關(guān)重要。非常小的資源（小于 1 KiB ）壓縮得不太好，有時(shí)甚至根本壓縮不到。任何類型的數(shù)據(jù)壓縮的效果都取決于能夠使用壓縮算法找到更多可壓縮數(shù)據(jù)位的大量數(shù)據(jù)。文件越大，壓縮效果就越好
• 了解動(dòng)態(tài)壓縮和靜態(tài)壓縮。動(dòng)態(tài)壓縮和靜態(tài)壓縮是確定何時(shí)應(yīng)壓縮資源的不同方法
  • 動(dòng)態(tài)壓縮會(huì)在請(qǐng)求資源時(shí)壓縮資源，有時(shí)甚至在每次請(qǐng)求資源時(shí)壓縮資源。
  • 靜態(tài)壓縮消除了壓縮本身涉及的延遲時(shí)間，在使用動(dòng)態(tài)壓縮的情況下，這可能會(huì)增加服務(wù)器響應(yīng)時(shí)間。 JavaScript 、 CSS 和 SVG 圖片等靜態(tài)資源應(yīng)靜態(tài)壓縮，而 HTML 資源應(yīng)動(dòng)態(tài)壓縮。

1.5. CDN

CDN 是分布式服務(wù)器網(wǎng)絡(luò)，服務(wù)器從源服務(wù)器緩存資源，反過來再從物理上更靠近用戶的邊緣服務(wù)器傳送資源。在距離用戶較近時(shí)，可以縮短往返時(shí)間 ( RTT )，而 HTTP/2 或 HTTP/3 、緩存和壓縮等優(yōu)化技術(shù)則可以讓 CDN 更快地提供內(nèi)容，而不是從源服務(wù)器提取內(nèi)容。在某些情況下，使用 CDN 可以顯著改善網(wǎng)站的 TTFB 。

2. 關(guān)鍵渲染路徑

關(guān)鍵渲染路徑是網(wǎng)頁性能中的一個(gè)概念。

關(guān)鍵渲染路徑是指網(wǎng)頁開始在瀏覽器中呈現(xiàn)之前所涉及的步驟。為了呈現(xiàn)網(wǎng)頁，瀏覽器需要 HTML 文檔本身以及呈現(xiàn)該文檔所需的所有關(guān)鍵資源。

2.1. 漸進(jìn)式渲染

網(wǎng)絡(luò)是自然分布的。與客戶端和 APP 不同，瀏覽器不能依賴于擁有呈現(xiàn)頁面所需的所有資源的網(wǎng)站。因此，瀏覽器非常擅長漸進(jìn)式呈現(xiàn)頁面。原生應(yīng)用通常有一個(gè)安裝階段，然后是運(yùn)行階段。然而，對(duì)于網(wǎng)頁和網(wǎng)絡(luò)應(yīng)用來說，這兩個(gè)階段之間的界限就不那么明顯了。

2.2. 關(guān)鍵渲染路徑

瀏覽器需要知道它應(yīng)該等待的最小資源數(shù)量，以避免呈現(xiàn)明顯不正常的體驗(yàn)。

另一方面，瀏覽器也不應(yīng)該等待超過必要的時(shí)間才向用戶顯示一些內(nèi)容。瀏覽器在執(zhí)行初始呈現(xiàn)之前所采取的步驟序列稱為關(guān)鍵渲染路徑。

呈現(xiàn)路徑涉及以下步驟：

• 通過 HTML 構(gòu)建文檔對(duì)象模型 ( DOM )

• 通過 CSS 構(gòu)建 CSS 對(duì)象模型 ( CSSOM )

• 應(yīng)用任何會(huì)更改 DOM 或 CSSOM 的 JavaScript

• 通過 DOM 和 CSSOM 構(gòu)建渲染樹

• 在頁面上執(zhí)行樣式和布局操作，看看哪些元素適合顯示

• 在內(nèi)存中繪制元素的像素

• 如果有任何像素重疊，則合成像素

• 以物理方式將所有生成的像素繪制到屏幕上

只有在完成所有這些步驟后，用戶才會(huì)在屏幕上看到內(nèi)容

這一呈現(xiàn)過程會(huì)發(fā)生多次。初始渲染會(huì)調(diào)用此流程，但隨著更多會(huì)影響網(wǎng)頁渲染的資源可用，瀏覽器將會(huì)重新運(yùn)行此流程（或許只是其中的一部分），以更新用戶看到的內(nèi)容。關(guān)鍵渲染路徑側(cè)重于之前為初始渲染概述的流程，并依賴于執(zhí)行初始渲染所需的關(guān)鍵資源

2.3. 關(guān)鍵渲染路徑上有哪些資源？

瀏覽器需要等待一些關(guān)鍵資源下載完畢，然后才能完成初始渲染。這些資源包括：

• HTML 的一部分
• 元素中阻塞渲染的 CSS
• 元素中的阻塞渲染的 JavaScript

關(guān)鍵在于瀏覽器以流式方式處理 HTML 。瀏覽器一旦獲取網(wǎng)頁 HTML 的任何部分，就會(huì)開始對(duì)其進(jìn)行處理。然后，瀏覽器就可以（并且通常確實(shí)）決定先呈現(xiàn)網(wǎng)頁，然后再接收網(wǎng)頁的其余部分 HTML

3. 優(yōu)化資源加載

網(wǎng)頁加載時(shí)，其 HTML 中會(huì)引用許多資源，通過 CSS 提供網(wǎng)頁的外觀和布局，并通過 JavaScript 提供互動(dòng)性。

3.1. 渲染阻塞

CSS 是一種阻塞渲染的資源，因?yàn)樗鼤?huì)阻止瀏覽器渲染任何內(nèi)容，直至構(gòu)建了 CSS 對(duì)象模型 ( CSSOM )。瀏覽器會(huì)阻止呈現(xiàn)，以防止出現(xiàn)非樣式內(nèi)容閃爍 ( FOUC )

渲染阻塞未必是不可取的，但需要通過對(duì) CSS 進(jìn)行優(yōu)化來最大限度地縮短其持續(xù)時(shí)間

3.2. 預(yù)加載掃描器

3.2.1. 什么是預(yù)加載掃描程序？

預(yù)加載掃描程序的角色是推測(cè)性，也就是說，它會(huì)檢查原始標(biāo)記，以便查找資源，以便在主要 HTML 解析器發(fā)現(xiàn)之前抓取相應(yīng)資源

預(yù)加載掃描程序是一種瀏覽器優(yōu)化，采用輔助 HTML 解析器的形式，可掃描原始 HTML 響應(yīng)，以找出并推測(cè)性地提取資源，然后主 HTML 解析器才會(huì)發(fā)現(xiàn)這些資源

為了充分利用預(yù)加載掃描器，服務(wù)器發(fā)送的 HTML 標(biāo)記中應(yīng)包含關(guān)鍵資源。預(yù)加載掃描器無法發(fā)現(xiàn)以下資源加載模式：

• 由 CSS 使用 background-image 屬性加載的圖片。這些圖片引用位于 CSS 中，預(yù)加載掃描器無法發(fā)現(xiàn)這些引用
• 動(dòng)態(tài)加載的腳本，采用

  • root ：用作窗口的元素，用于檢查目標(biāo)的可見性，如果未指定或?yàn)?null，則默認(rèn)為瀏覽器窗口。

  • rootMargin ：根周圍的邊距

  • threshold ：一個(gè)數(shù)字或一個(gè)數(shù)字?jǐn)?shù)組，表示目標(biāo)可見度達(dá)到多少百分比時(shí)，觀察器的回調(diào)就應(yīng)該執(zhí)行。如果只想在能見度超過 50% 時(shí)檢測(cè)，可以使用 0.5 的值。如果希望每次能見度超過 25% 時(shí)都執(zhí)行回調(diào)，則需要指定數(shù)組 [0, 0.25, 0.5, 0.75, 1]。默認(rèn)值為 0（這意味著只要有一個(gè)像素可見，回調(diào)就會(huì)運(yùn)行）。值為 1.0 意味著在每個(gè)像素都可見之前，閾值不會(huì)被認(rèn)為已通過。

  10. 預(yù)提取、預(yù)渲染和 Service Worker 預(yù)緩存

  雖然許多性能涉及到可以采取哪些措施來優(yōu)化和消除不必要的資源，但建議先加載一些資源才是需要用到的，這似乎有點(diǎn)自相矛盾。不過，在某些情況下，可以提前加載某些資源

  10.1. prefetch

  可以使用 資源提示提前提取資源（包括圖片、樣式表或 JavaScript 資源）。 prefetch 提示用于告知瀏覽器在不久的將來可能需要某個(gè)資源

  指定 prefetch 提示后，瀏覽器可能會(huì)以最低優(yōu)先級(jí)發(fā)起對(duì)該資源的請(qǐng)求，以避免與當(dāng)前頁面所需的資源發(fā)生爭(zhēng)用

  預(yù)提取資源可以改善用戶體驗(yàn)，因?yàn)橛脩魺o需等待近期所需的資源下載完畢，因?yàn)榭梢栽谛枰獣r(shí)立即從磁盤緩存中檢索這些資源

  還可以通過在指向某個(gè) HTML 文檔時(shí)指定 as="document" 屬性來預(yù)提取網(wǎng)頁及其所有子資源

  在基于 Chromium 的瀏覽器中，可以使用 Speculation Rules API 預(yù)提取文檔。推測(cè)規(guī)則定義為包含在網(wǎng)頁的 HTML 中的 JSON 對(duì)象，或通過 JavaScript 動(dòng)態(tài)添加：

  10.2. prerender

  除了預(yù)提取資源之外，還可以提示瀏覽器在用戶導(dǎo)航到某個(gè)網(wǎng)頁之前預(yù)呈現(xiàn)該網(wǎng)頁

  這種做法幾乎可以即時(shí)加載網(wǎng)頁，因?yàn)橄到y(tǒng)會(huì)在后臺(tái)提取和處理網(wǎng)頁及其資源。當(dāng)用戶導(dǎo)航到相應(yīng)頁面后，系統(tǒng)會(huì)將該頁面置于前臺(tái)

  Speculation Rules API 支持預(yù)渲染：

  10.3. Service Worker 預(yù)緩存

  還可以使用 Service Worker 推測(cè)性地預(yù)提取資源

  Service Worker 預(yù)緩存可以使用 CacheAPI 提取和保存資源，這樣瀏覽器無需訪問網(wǎng)絡(luò)即可使用 Cache API 處理請(qǐng)求

  Service Worker 預(yù)緩存使用一種非常有效的 Service Worker 緩存策略，稱為“僅緩存”策略。這種模式非常有效，因?yàn)閷①Y源放入 Service Worker 緩存后，可在收到請(qǐng)求時(shí)幾乎即時(shí)提取這些資源

  

  如需使用 Service Worker 預(yù)緩存資源，可以使用 Workbox

  Workbox 使用預(yù)緩存清單來確定應(yīng)預(yù)緩存的資源，預(yù)緩存清單是一個(gè)文件和版本控制信息列表，可作為要預(yù)緩存的資源的可信來源

  [{
      url: 'script.ffaa4455.js',
      revision: null
  }, {
      url: '/index.html',
      revision: '518747aa'
  }]
  

  上述代碼是一個(gè)示例清單，其中包含 script.ffaa4455.js 和 /index.html 這兩個(gè)文件。如果資源在文件本身中包含版本信息（稱為文件哈希），則 revision 屬性可以保留為 null ，因?yàn)槲募�已進(jìn)行版本控制（例如，上述代碼中 script.ffaa4455.js 資源的 ffaa4455 屬性）。
  設(shè)置后， Service Worker 可用于預(yù)緩存靜態(tài)頁面或其子資源，以加快后續(xù)頁面導(dǎo)航的速度

  workbox.precaching.precacheAndRoute([
    '/styles/product-page.ac29.css',
    '/styles/product-page.39a1.js',
  ]);
  

  Service Worker 使用的 Cache 接口和 HTTP 緩存并不相同

  Cache 接口是由 JavaScript 控制的高層級(jí)緩存，而 HTTP 緩存是由 Cache-Control 標(biāo)頭控制的低層級(jí)緩存

  與使用資源提示或推測(cè)規(guī)則預(yù)提取或預(yù)呈現(xiàn)資源類似， Service Worker 預(yù)緩存會(huì)消耗網(wǎng)絡(luò)帶寬、存儲(chǔ)空間和 CPU

  建議僅預(yù)緩存可能會(huì)使用的資源，并在預(yù)緩存清單中指定過多的資源

  11. Web Worker

  用戶在瀏覽器中看到的大部分內(nèi)容都在稱為主線程的單個(gè)線程上完成。不過，在某些情況下，可以啟動(dòng)新線程來執(zhí)行計(jì)算開銷很大的工作，以便主線程可以處理面向用戶的重要任務(wù)。執(zhí)行此操作的 API 稱為 Web Worker API

  JavaScript 通常被描述為一種單線程語言。這是指主線程，這是瀏覽器執(zhí)行在瀏覽器中看到的大部分工作的單個(gè)線程。其中包括編寫腳本、某些類型的渲染工作、 HTML 和 CSS 解析以及其他類型的面向用戶的工作來改善用戶體驗(yàn)等

  就 JavaScript 而言，通常只能在主線程上執(zhí)行工作，但可以在 JavaScript 中注冊(cè)和使用其他線程。允許在 JavaScript 中實(shí)現(xiàn)多線程的功能稱為 Web Workers API

  11.1. Web Worker 啟動(dòng)方式

  實(shí)例化 Worker 類

  const myWebWorker = new Worker('/my-web-worker.js');
  

  11.2. Web Worker 的限制

  與在主線程上運(yùn)行的 JavaScript 不同， Web Worker 無法直接訪問 window上下文 ，并且對(duì)其提供的 API 的訪問受到限制。 Web Worker 受到以下限制條件的約束：

  • Web Worker 無法直接訪問 DOM
  • Web Worker 可以通過消息傳遞流水線與 window 上下文進(jìn)行通信，這意味著 Web Worker 可以通過某種方式間接訪問 DOM
  • Web Worker 的作用域是 self ，而不是 window
  • Web Worker 范圍_確實(shí)_可以訪問 JavaScript 基元和構(gòu)造，以及 fetch 等 API 和相當(dāng)多的其他 API

  11.3. Web Worker 如何與 window 通信

  Web Worker 可以通過消息傳遞流水線與主線程的 window 上下文進(jìn)行通信。利用此流水線，可以將數(shù)據(jù)傳送到主線程和 Web 工作器以及從主線程和 Web 工作器傳輸數(shù)據(jù)。如需將數(shù)據(jù)從 Web Worker 發(fā)送到主線程，需要在 Web Worker 的上下文 ( self ) 中設(shè)置 message 事件

  // my-web-worker.js
  self.addEventListener("message", () => {
    // Sends a message of "Hellow, window!" from the web worker:
    self.postMessage("Hello, window!");
  });
  

  然后，在主線程上 window 上下文的腳本中，可以使用另一個(gè) message 事件接收來自網(wǎng)頁工作器線程的消息：

  // scripts.js
  // Creates the web worker:
  const myWebWorker = new Worker('/js/my-web-worker.js');
  // Adds an event listener on the web worker instance that listens for messages:
  myWebWorker.addEventListener("message", ({ data }) => {
    // Echoes "Hello, window!" to the console from the worker.
    console.log(data);
  });
  

  三、總結(jié)

  • 本文概述了性能以及性能的重要性
  • 羅列了性能優(yōu)化的點(diǎn)
  • 希望對(duì)大家有幫助

  引用

  • performance
  • web performance