FCP 第一繪畫內容

1 .第一繪畫內容，度量標準從頁面開始加載到頻幕上呈現(xiàn)頁面內容的任何部分的時間，文本摆碉，圖像芽唇，svg元素顾画，非白色canvas元素都算
2 .js測量

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntriesByName('first-contentful-paint')) {
    console.log('FCP candidate:', entry.startTime, entry);
  }
}).observe({type: 'paint', buffered: true});

3 .為了提供良好的用戶體驗，網(wǎng)站應努力使First Contentful Paint在加載頁面的1秒內發(fā)生匆笤。為確保您達到大多數(shù)用戶的這一目標研侣，衡量移動設備和臺式機設備的頁面加載量的第75個百分位是一個很好的衡量標準

最大繪畫內容

1 .測量從頁面開始加載到屏幕上最大的文本塊或圖像元素被渲染為止的時間
2 .較舊的指標（例如 load或 DOMContentLoaded） 不好，因為它們不一定與用戶在屏幕上看到的相對應炮捧。
3 .為了提供良好的用戶體驗庶诡，網(wǎng)站應努力在頁面開始加載后的前2.5秒內進行“最大內容繪畫”
4 .為“最大內容繪畫”報告的元素的大小通常是用戶在視口中可見的大小。如果元素延伸到視口之外咆课，或者任何元素被裁剪或具有不可見的 溢出末誓，則這些部分不會計入元素的大小
5 .為了使計算和分配新性能條目的性能開銷保持較低，對元素大小或位置的更改不會生成新的LCP候選對象书蚪。僅考慮元素的初始大小和在視口中的位置喇澡，這意味著可能不會報告最初在屏幕外渲染然后在屏幕上過渡的圖像。這也意味著最初在視口中渲染的元素隨后被下推殊校，但視線外仍然會報告其初始的視口大小
6 .js測量

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('LCP candidate:', entry.startTime, entry);
  }
}).observe({type: 'largest-contentful-paint', buffered: true});

7 .服務器響應時間慢
渲染阻止的JavaScript和CSS
資源加載時間
客戶端渲染

FID

1 .測量從用戶首次與您的網(wǎng)站進行交互晴玖，當他們點擊鏈接，或使用自定義的js驅動的控件到瀏覽器真正能夠訪問之間的時間
2 .首次輸入延遲（FID）是一種重要的以用戶為中心的度量为流，用于衡量 負載響應能力呕屎， 因為它可以量化用戶嘗試與無響應頁面進行交互時的體驗-低FID有助于確保頁面 可用
3 .為了提供良好的用戶體驗，站點應努力使首次輸入延遲小于100毫秒
4 .由于瀏覽器的主線程正忙于執(zhí)行其他操作敬察，所以會發(fā)生輸入延遲（又稱輸入延遲）秀睛，因此它（尚未）響應用戶。發(fā)生這種情況的一個常見原因是瀏覽器忙于解析和執(zhí)行由您的應用加載的大型JavaScript文件莲祸。在執(zhí)行此操作時蹂安，它無法運行任何事件偵聽器，因為正在加載的JavaScript可能會告訴它執(zhí)行其他操作
5 .FID測量接收輸入事件與下一次主線程空閑之間的增量锐帜。這意味著即使在未注冊事件偵聽器的情況下藤抡，也將測量FID
6 .FID是一種度量頁面加載過程中響應度的指標。因此抹估，它僅關注來自離散操作（例如單擊缠黍，輕敲和按鍵）的輸入事件.其他交互（例如滾動和縮放）是連續(xù)的動作，并且具有完全不同的性能約束（而且药蜻，瀏覽器通常能夠通過在單獨的線程上運行它們來隱藏其延遲）
7 .js檢測

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const delay = entry.processingStart - entry.startTime;
    console.log('FID candidate:', delay, entry);
  }
}).observe({type: 'first-input', buffered: true});

8 .解決

1 .感覺react框架應該有做優(yōu)化瓷式。
2 .分手長期任務.將長時間運行的代碼分解為較小的異步任務
3 .檢查第三方腳本的執(zhí)行
4 .使用webworker執(zhí)行部分代碼
5 .https://github.com/GoogleChromeLabs/comlink 第三方庫
6 .延遲未使用的JavaScript 

TTI

1 .TTI度量標準衡量從頁面開始加載到其主要子資源加載之間的時間替饿，它能夠快速可靠地響應用戶輸入
2 .為了提供良好的用戶體驗，在一般的移動硬件上進行測試時贸典，網(wǎng)站應努力使互動時間少于5秒视卢。

TBT

1 .“總阻塞時間”（TBT）度量標準度量了“第一內容油漆（FCP）”和“交互時間”（TTI）之間的總 時間， 在該時間中廊驼，主線程被阻塞足夠長的時間以防止輸入響應
2 .只要存在長任務据过，該主線程即被視為“阻塞”，該任務在主線程上運行超過50毫秒（ms）妒挎。我們說主線程“被阻止”是因為瀏覽器無法中斷正在進行的任務绳锅。因此，如果用戶確實在較長的任務中間與頁面進行交互酝掩，則瀏覽器必須等待任務完成才能響應
3 .如果主線程至少有五秒鐘沒有執(zhí)行長任務鳞芙，則TTI認為頁面“可靠地交互”
4 .為了提供良好的用戶體驗，在一般的移動硬件上進行測試時期虾，站點應努力使總阻止時間小于300毫秒
5 .好像還要學習下如何閱讀lighthouse的報告

CLS

1 .CLS會測量頁面整個生命周期中發(fā)生的每個 意外布局轉移的所有單獨布局轉移分數(shù)的總和
2 .甲布局移發(fā)生的任何時間的可見元素改變其從一個所再現(xiàn)的幀到下一個位置
3 .為了提供良好的用戶體驗原朝，網(wǎng)站應努力使CLS分數(shù)小于0.1
4 .請注意，僅當現(xiàn)有元素更改其起始位置時镶苞，才會發(fā)生布局轉換喳坠。如果將新元素添加到DOM或現(xiàn)有元素更改了大小，則只要更改不會導致其他可見元素更改其起始位置茂蚓，該元素就不會算作布局偏移
5 .并非所有的布局轉換都是不好的丙笋。實際上，許多動態(tài)Web應用程序經常更改頁面上元素的開始位置煌贴，僅當用戶不期望布局轉換時，它才是不好的锥忿。另一方面牛郑，響應于用戶交互（單擊鏈接，按下按鈕敬鬓，在搜索框中鍵入內容等）而發(fā)生的布局偏移通常很好淹朋，只要該偏移發(fā)生在與交互關系足夠近的位置即可向用戶清除
6 .js測試

let cls = 0;

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    if (!entry.hadRecentInput) {
      cls += entry.value;
      console.log('Current CLS value:', cls, entry);
    }
  }
}).observe({type: 'layout-shift', buffered: true});

7 .改善

1 .**請務必在圖片和視頻元素上包含size屬性，否則請使用[CSS寬高比框](https://css-tricks.com/aspect-ratio-boxes/)保留所需的空間钉答。**這種方法可確保在加載圖像時瀏覽器可以在文檔中分配正確的空間量础芍。請注意，您也可以使用[unsize-media功能部件策略](https://github.com/w3c/webappsec-feature-policy/blob/master/policies/unsized-media.md) 在支持功能部件策略的瀏覽器中強制執(zhí)行此行為
2 .除非響應用戶交互数尿，否則切勿在現(xiàn)有內容上方插入內容仑性。這樣可以確保可以預期發(fā)生任何版式移位
3 .首選將轉換動畫替換為觸發(fā)布局更改的屬性動畫右蹦。對過渡進行動畫處理诊杆，以提供狀態(tài)與狀態(tài)之間的上下文和連續(xù)性歼捐。
4 .無尺寸的廣告，嵌入和iframe 晨汹，盡量避免
5 .### 嵌入和iframe [＃](https://web.dev/optimize-cls/#embeds-and-iframes)

可嵌入的窗口小部件使您可以在頁面中嵌入可移植的Web內容（例如豹储，來自YouTube的視頻，來自Google地圖的地圖淘这，社交媒體帖子等）剥扣。這些嵌入可以采用多種形式
6 .### 動態(tài)內容?? [＃](https://web.dev/optimize-cls/#dynamic-content)

**摘要：**除非響應用戶交互，否則請避免在現(xiàn)有內容之上插入新內容铝穷。這樣可以確蹦魄樱可以預期發(fā)生任何版式移位
7 .### 導致FOUT / FOIT的Web字體?? [＃](https://web.dev/optimize-cls/#web-fonts-causing-foutfoit)

下載和呈現(xiàn)Web字體可以通過兩種方式引起布局變化：

*   后備字體替換為新字體（FOUT-未樣式化文本的閃爍）
*   顯示“不可見”文本，直到呈現(xiàn)新字體為止（FOIT-不可見文本閃爍）

 氧骤。### 動畫???♀? [＃](https://web.dev/optimize-cls/#animations)

**摘要：**不想`transform`動畫性質觸發(fā)布局改變的動畫呻疹。

對CSS屬性值的更改可能需要瀏覽器對這些更改做出反應。許多值觸發(fā)重新布局筹陵，繪制和合成刽锤，例如`box-shadow`和`box-sizing`‰澹可以以不太昂貴的方式更改許多CSS屬性

優(yōu)化js加載

1 .如果遇到無法響應搖樹的頑固庫并思，請查看該庫是否使用ES6語法導出其方法。如果它以CommonJS格式（例如module.exports）導出內容语稠，則該代碼不會被webpack搖晃宋彼。一些插件為CommonJS模塊提供了搖樹功能（例如 webpack-common-shake），但這只能達到某些您無法搖晃的CommonJS模式的程度仙畦。如果您想可靠地擺脫應用程序中未使用的依賴項输涕，則應繼續(xù)使用ES6模塊

離線存儲

1 .總的來說，依照兼容性和異步這倆關鍵標準慨畸，indexDB是最適合做離線存儲的方式
2 .

優(yōu)化關鍵路徑渲染

1 .通過優(yōu)化關鍵路徑渲染莱坎，可以縮短首次渲染時間。
2 .構建模型對象

1 .瀏覽器渲染頁面前需要先構造dom樹和CSSOM樹寸士，所以我們需要盡快保證將HTML和CSS都提供給瀏覽器
2 .parse HTML 這個是將一堆HTML字符轉換成DOM樹的時間
3 .Recalculate Style 這個是渲染css花費的時間

full-process.png

3 .構建渲染樹

1 .從DOM樹的根節(jié)點開始遍歷每個可見節(jié)點檐什，某些節(jié)點不可見，不會體現(xiàn)在渲染輸出中弱卡，所以會被忽略
2 .某些節(jié)點通過css隱藏乃正，所以在渲染樹種也會被忽略
3 .對于每個可見節(jié)點，為其尋找適配的CSSOM規(guī)則并應用他們
4 .發(fā)射可見節(jié)點婶博，連同內容和計算的樣式

4 .知道了有哪些節(jié)點和他們的計算樣式瓮具，這個時候就應該計算他們在設備視口的確切位置和大小了
5 .將渲染樹種的每個節(jié)點轉換成屏幕上的實際元素

阻塞渲染的css

1 .默認情況下，css被視為阻塞渲染的資源，這就意味著瀏覽器將不會渲染任何已經處理的內容搭综，除非cssOM構建完畢
2 .所以要精簡css垢箕，盡快提供css資源，并利用媒體類型和查詢來解除對渲染的阻塞
3 .如果我們有一些 CSS 樣式只在特定條件下（例如顯示網(wǎng)頁或將網(wǎng)頁投影到大型顯示器上時）使用兑巾，又該如何条获？如果這些資源不阻塞渲染，該有多好

<link href="style.css" rel="stylesheet">
<link href="print.css" rel="stylesheet" media="print">
<link href="other.css" rel="stylesheet" media="(min-width: 40em)">

4 .聲明您的樣式表資產時蒋歌，請密切注意媒體類型和查詢帅掘，因為它們將嚴重影響關鍵渲染路徑的性能

使用js添加交互

1 .js可以查詢和修改DOM和CSSOM
2 .js執(zhí)行將會阻止cssom
3 .除非將js顯示聲明為異步，不然他會阻止構建DOM
4 .我們的腳本在文檔的何處插入堂油，就在何處執(zhí)行修档。當 HTML 解析器遇到一個 script 標記時，它會暫停構建 DOM府框，將控制權移交給 JavaScript 引擎吱窝；等 JavaScript 引擎運行完畢，瀏覽器會從中斷的地方恢復 DOM 構建
5 .簡言之迫靖，JavaScript 在 DOM院峡、CSSOM 和 JavaScript 執(zhí)行之間引入了大量新的依賴關系，從而可能導致瀏覽器在處理以及在屏幕上渲染網(wǎng)頁時出現(xiàn)大幅延遲
6 .JavaScript 執(zhí)行會“阻止解析器”：當瀏覽器遇到文檔中的腳本時系宜，它必須暫停 DOM 構建照激，將控制權移交給 JavaScript 運行時，讓腳本執(zhí)行完畢盹牧，然后再繼續(xù)構建 DOM俩垃。我們在前面的示例中已經見過內聯(lián)腳本的實用情況。
7 .向script 標記添加異步關鍵字可以指示瀏覽器在等待腳本可用期間不阻止DOM 構建汰寓，這樣可以顯著提升性能口柳。

時間戳

1 .domloading:這個整個過程的起始時間戳，瀏覽器即將開始解析第一批收到的HTML文檔字節(jié)
2 .domINteractive:表示瀏覽器完成對所有HTML的解析并且DOM構建完成的時間點
3 .domContentLoaded:表示DOM準備就緒并且沒有樣式表阻止js執(zhí)行的時間點有滑，意味著現(xiàn)在可以構建渲染樹了
4 .domComplete:所有處理完成跃闹，并且網(wǎng)頁上的所有資源都以下載完畢。
5 .loadEvent:網(wǎng)頁加載的最后一步俺孙，瀏覽器會觸發(fā)onload事件
6 .

優(yōu)化關鍵渲染路徑

1 .從以下幾點因素來操作
2 .關鍵資源的數(shù)量
3 .關鍵路徑的長度：關鍵路徑長度受所有關鍵資源與其字節(jié)大小之間依賴關系圖的影響：某些資源只能在上一資源處理完畢之后才能開始下載，并且資源越大掷贾，下載所需的往返次數(shù)就越多
4 .關鍵字節(jié)的數(shù)量
5 .JavaScript 資源會阻塞解析器睛榄，除非將其標記為 async 或通過專門的 JavaScript 代碼段進行添加

http2

1 .https://hpbn.co/http2/
2 .h3-Q050 google還是猛啊，直接使用http3協(xié)議

1 .減少了 TCP 三次握手及 TLS 握手時間
2 .解決多路復用丟包時的線頭阻塞問題
3 .優(yōu)化重傳策略
4 .流量控制
5 .連接遷移
6 .弱網(wǎng)環(huán)境好像也不行
7 .chrome-extension://ikhdkkncnoglghljlkmcimlnlhkeamad/pdf-viewer/web/viewer.html?file=https%3A%2F%2Fpic.huodongjia.com%2Fganhuodocs%2F2018-04-28%2F1524906080.9.pdf 微博的分享
8 .Caddy + Quic 
9 .客戶端?一般選?用?谷歌chrome cronet庫