關鍵轉譯路徑
google 其實說得很完整又很讚...
所以今天會偏向導讀,跟說一點效能相關的東西...
流程:
工程需要注意的地方:
發 request 都蠻花時間成本的。
因為過通訊協定需要時間,訊息傳輸也有物理距離所需的來回時間。
就算檔案只有 1 B,大概也要花 100 毫秒的時間。隨著檔案的大小,所需的時間也會越來越多。
所以我們在 webpack 會去考量每支檔案的大小,看是切出去比較省時間還是包在一起。
除了 DOM 之外,CSS 也會有相同的過程,建構出 CSSOM(CSS Object Modal)
最終會把 DOM & CSSOM 合併成 Render Tree。
有了 Render Tree 才會開始真的繪製圖面到我們的螢幕上
跟效能有關的地方:瀏覽器建構的順序
結論是:
儘早開始解析 CSS、JS 最晚,讓 DOM 跟 CSSOM 可以先處理
<!DOCTYPE html>
<html lang="en">
<head>
<link href="myStyle.css" rel="stylesheet">
</head>
<body>
<div>
<p>
<span></span>
</p>
</div>
<script src="myJs.js"></script>
</body>
</html>
繪製的流程:
Scripting (爬扣)
Rendering(更新 data)
Painting(實際更新畫面 pixel)
所以 performance 那頁才會長這樣
跟繪製有關的效能考量: re-flow / layout thrashing
這兩個短時間進行大量的更新
什麼會觸發 re-flow:
什麼情況會觸發 re-flow:
read or write 那些東西的時候
var heightA = elementA.offsetHeight; // read
elementB.offsetHeight = 200; // write
什麼時候 re-flow 的代價很高:
更新 DOM 或 CSSOM 之後再讀取或寫入上述數值,可以想像首次 render 要做的事情,都要再做一遍
別人的範例:
var UpdateThrash = function(data) {
var spans = document.querySelectorAll('.item .lab');
var colWidth = 0;
for (var i = 0; i < spans.length; i++) {
var span = spans[i];
span.style.fontSize = '14.1px';
colWidth = Math.max(colWidth, span.offsetWidth);
}
};
var UpdateNoThrash = function(data) {
var spans = document.querySelectorAll('.item .lab');
for (var i = 0; i < spans.length; i++) {
var span = spans[i];
span.style.fontSize = '14.0px';
}
var colWidth = 0;
for (var i = 0; i < spans.length; i++) {
var span = spans[i];
colWidth = Math.max(colWidth, span.offsetWidth);
}
};
這區好像都蠻讚的