摘要：發現內存泄漏打開的任務管理器，確保列有顯示。如果線圖不停的上升，就說明出現了內存泄漏。定位內存泄漏在開發者工具的面板中，我們可以選擇，記錄一個當前頁面具體內存使用情況的快照。如果該對象的增長了，說明確實出現了內存泄漏。

隨著網頁的加載，每個HTTP請求都會是瀑布流中的一條。第一條都是文件document的加載，當文件被解析，隨后通常是CSS文件的加載。和寫在HTML文件中的標簽中的順序是一樣的。但瀏覽器會做一些優化，比如會降低圖片的優先度，提升CSS文件的優先度等。

在瀑布流下方的表格中，我們可以看到請求的Name，Status，Type等信息。Initiator列的意思是，什么文件需求加載了這一行的文件。按住Shift點擊表格的一行，調用該行文件的相應文件會變綠(who called it?)，該行文件調用的相應行會變紅(who does it called?)。

白色 隊列中。不常見。HTTP1中，瀏覽器一次性只能進行6個TCP連接，比如我們有7個CSS文件，那么其中的一個就會在隊列中。

灰色 一個請求能發送前的各種停滯反應時間。

淺灰色 在Proxy代理服務器消耗的時間

深綠色 DNS查找的時間

橙色 建立連接時間。包括TCP握手時間和建立SSL連接時間。

棕色 SSL連接時間

綠色 等待回復的時間。也就是等待獲得第一個字節的時間。如果綠色很長說明應用服務器很慢。

藍色 下載回復內容的時間。和文件大小有關系。

如果我們點擊Capture Screenshot按鈕，重新加載頁面， 就可以看到網頁的每次repaint，也就是網頁是如何加載的。

使用這個功能，我們可以知道在慢速網絡下，網頁是如何呈現出來的。

Network面板中，我們可以點擊文件類型來查看特定類型的文件。左側有個輸入框也可以輸入特定條件。比如larger-than:200px，就可以觀察大于200px的圖片請求。

Disable Cache，Offline，Preserve Log三個按鈕的功能是顯而易見的。

開發者性能測試是在開發環境中做性能測試，但是用戶端是在真實用戶使用的情況下記錄測試數據。以前是這么做的：

const start = new Date().getTime();

const end = new Date().getTime();

const time = end - start;

這樣我們就可以記錄下用戶作出一個操作的時間，然后將數據post回來。

后來有了Performance API:

performance.mark("start")

performance.mark("end);

performance.measure("Our Measurement,"start","end");

performance.getEntriesByType("measure")

一般圖片過大的解決方法：

resize圖片

刪除圖片的meta data

在服務器端使用gzip，brotli, zopfli等工具。

還有一個HTML API要知道，srcset
可以在不同窗口大小的時候加載指定的圖片。

但是為了瀏覽器兼容性，我們總是應該給默認的src attribute留一個URL。

現代大多數屏幕刷新率都是60幀每秒。1秒/60 = 16.66毫秒。所以我們的一個畫面更新的處理時間如果超過了16毫秒，就感覺卡。

有一種卡的原因是因為，解析Javascript的時間過長。V8引擎渲染頁面的時候，需要編譯Javascript，生成AST(Abstract Syntax Tree)。當客戶端的處理性能很差的時候，就要等很久。

還有一種卡的原因是因為，Layout thrashing，反復布局，又稱布局抖動。

//Read
const h1 = element.clientHeight;
//Write
element1.style.height = (h1 * 2) + "px";
//Read
const h2 = element2.clientHeight;
//Write
element2.sytle.height = (h2 * 2) + "px";

當我們反復進行這種DOM讀寫操作的時候，就會造成布局抖動。

如果我們可以將讀和寫完全分開，一次性操作所有讀，一次性操作所有寫，就不會有這種情況，但是這是不現實的。這就是使用window.requestAnimationFrame()的原因。

簡單說requestAnimationFrame將讀寫操作和屏幕刷新率匹配起來，當瀏覽器準備好更新下一幀時，做想做的操作，減少性能浪費，避免跳幀。關于這個話題有很多寫Event Loop的文章里也有寫，這里不多寫。

在開發者工具中，我們在更多工具中可以找到Rendering的選項。

打開這個選項，頁面每次repaint的地方都會變成綠色，幫助開發者觀察是否一些沒必要重繪的地方在不停的被重繪，浪費性能。

我們點擊錄制按鈕，在頁面上做一些操作，比如Scroll。Performance面板中就會有一些數據。

最下方有一個餅狀圖是一個概括總結。

展開Main行，X軸代表處理時間，Y軸是Call Stack。Y軸高沒關系，只是函數之間不斷的調用，但是如果有色塊很寬的話就說明處理時間很長。

我們可以使用WASD來操作。按W Zoom In可以看到具體信息。

找到一個很寬的色塊，看之前是哪個色塊調用了這個色塊，然后我們就可以在下方Summary面板中找到具體文件名，點擊去Sources面板看代碼。

當一些內存沒有按開發者的意愿被釋放的時候，就出現了內存泄漏。

意外添加的全局變量

function foo() {
  bar = "Hi"
}

當foo被調用的時候，因為bar沒有變量聲明關鍵詞const， var， let。JS就會一直向上找這個變量到全局作用域，然后會為你創建一個全局變量bar。當這個函數結束的時候，你以為這個bar會被回收，但其實它一直留在全局。設想如果這個bar不是“Hi”而是一個擁有很多元素的array，它留在了全局作用域，這并不是我們想要的情況。

沒有取消的計時器

顧名思義，計時器沒有被取消或移除。

多余的DOM元素變量

const button = document.getElementById("button);

document.body.removeChild(
  document.getElementById("button)
);
}

這里我們在DOM中移除了這個button，但是之前指向這個元素的reference還在，就是變量button。所以這個reference就留在了內存中。

打開Chrome的任務管理器，確保Javascript Memory列有顯示。我們可以看到每個標簽頁的內存使用情況。如果有一個標簽頁的內存使用不穩定，一直在上升，說明出現了內存泄漏。

在Performance面板記錄下的數據中，如果我們打勾Memory選項，我們就可以看到Memory行。如果線圖不停的上升，就說明出現了內存泄漏。

在開發者工具的Memory面板中，我們可以選擇Heap Snapshot，記錄一個當前頁面具體內存使用情況的快照。注意Shallow Size列和Retained Size列。

Shallow Size是對象自身占用內存的大小，而Retained Size是指我們移除Object后能獲得多少空間，也就是將對象本身和連同的相關對象一起刪除后釋放的內存大小。比如一個變量指向一個很大的Object，這個變量本身是個reference很小（Shallow Size很小），但是移除這個變量以后，我們就可以獲得很大的空間（Retained Size很大)。

我們可以根據Shallow Size給Heap Snapshot排序，找到占用內存最多的對象，如果不確認是否是內存泄漏，可以再記錄一個Heap Snapshot做對比。如果該對象的Shallow Size增長了，說明確實出現了內存泄漏。我們可以根據工具給的提示信息，找到開發代碼片段做修改。

現在的Audit面板整合了谷歌的Lighthouse服務。網上還有一些其他不錯的第三方服務如webpagetest， sonarwhal。

官方文檔
Chrome Developer Tool