JavaScript 往往是視覺變更的觸發器。 有時是直接透過樣式操作，有時是計算造成視覺變更，例如搜尋或排序一些資料。 時機不對或長時間執行的 JavaScript 可能是常見的效能問題導因，您應該儘量減少它的影響。
TL;DR
- 針對視覺更新避免 setTimeout 或 setInterval；一律改為使用 requestAnimationFrame。
- 將長時間執行的 JavaScript 從主執行緒移動至 Web Worker。
- 使用微任務，以讓 DOM 在多個畫面內變更。
- 使用 Chrome DevTools 的 Timeline 和 JavaScript Profiler，以評估 JavaScript 的影響。
JavaScript 效能分析可能稱得上是一門藝術，因為您撰寫的 JavaScript 程式碼一點也不像實際執行的程式碼。 最新的瀏覽器使用 JIT 編譯器和各式各樣的最佳化和技巧，以試圖給您儘可能最快的執行速度，這大幅變更了程式碼的動力。
不過話雖如此，您還是可以做一些努力，以協助您的應用程式成功執行 JavaScript。
針對視覺變更，請使用 RequestAnimationFrame
當視覺變更在螢幕上發生時，您會想在正確時機為瀏覽器執行自己的工作，這也正是畫面開始之際。 要保證 JavaScript 會在畫面開始之時執行的唯一方法是使用 requestAnimationFrame。
/**
* If run as a requestAnimationFrame callback, this
* will be run at the start of the frame.
*/
function updateScreen(time) {
// Make visual updates here.
}
requestAnimationFrame(updateScreen);
架構或範例可以像動畫一樣，使用 setTimeout 或 setInterval 做視覺變更，但這種方式的問題在於，回呼會在畫面的 某一點 執行，可能就在結束之時，如此往往造成我們遺漏一個畫面的效果，從而導致閃避現象。
事實上，時下 jQuery 的預設 animate 行為是使用 setTimeout！您可以 修補它以使用 requestAnimationFrame，強烈建議使用者採用。
降低複雜性或使用 Web Worker
JavaScript 是在瀏覽器的主執行緒上運作，就連同樣式計算、版面配置，以及在許多情況下與繪製一起運作。 如果您的 JavaScript 長時間執行，它將封鎖這些其他任務，有可能導致畫面遺漏。
關於 JavaScript 的執行時機和持續時間，您應該按戰略計劃安排。 例如，如果您處於如捲動的動畫中，您應該最好要設法將您的 JavaScript 維持在 3-4ms 之間。 比這個數字長的時間，您就可能會佔用太多時間。 如果您處於閒置期，對於所佔用的時間，您可以更寬鬆一些。
在許多情況下，只要 Web Worker 不需要 DOM 存取時，您就可以將純運算工作移轉給 Web Worker。 像排序或搜尋等資料操作或穿越動作，常常正好適合這種模式，也適合載入和模型產生。
var dataSortWorker = new Worker("sort-worker.js");
dataSortWorker.postMesssage(dataToSort);
// The main thread is now free to continue working on other things...
dataSortWorker.addEventListener('message', function(evt) {
var sortedData = e.data;
// Update data on screen...
});
並非所有的工作都可以適用這種模式：Web Worker 並無 DOM 存取能力。 當您的工作必須在主執行緒上運作時，請考慮批次方案：將較大的任務分割成微任務，每個微任務僅需幾 ms 的時間，同時是跨每個畫面在 requestAnimationFrame 處理常式內執行。
var taskList = breakBigTaskIntoMicroTasks(monsterTaskList);
requestAnimationFrame(processTaskList);
function processTaskList(taskStartTime) {
var taskFinishTime;
do {
// Assume the next task is pushed onto a stack.
var nextTask = taskList.pop();
// Process nextTask.
processTask(nextTask);
// Go again if there’s enough time to do the next task.
taskFinishTime = window.performance.now();
} while (taskFinishTime - taskStartTime < 3);
if (taskList.length > 0)
requestAnimationFrame(processTaskList);
}
這種方法會伴隨 UX 和 UI 後果，您將需要確定使用者知道一項任務正在處理中，此時可使用進度或活動指示器。 任一情況下，這種方法將讓您的應用程式的主執行緒保持空閒，協助它對使用者互動保持高回應性。
知曉您 JavaScript 的「畫面負擔」
當評估架構、程式庫或您自己的程式碼時，以個別畫面為基礎，評估執行 JavaScript 程式碼的成本。 在做轉換或捲動等效能關鍵的動畫工作時，這一點尤其重要。
測量您 JavaScript 成本和效能設定檔的最佳方法，是使用 Chrome DevTools。 基本上，您將取得看起來像以下的低詳細資料記錄：
如果您發現您有長時間執行的 JavaScript，您可以啟用 DevTools 使用者介面頂部的 JavaScript 分析工具：
啟用 DevTools 中的 JS 分析工具。"><img src="images/optimize-javascript-execution/js-profiler-toggle.jpg" alt="
以這種方式分析 JavaScript 會帶有額外負荷，所以當您想要更深入瞭解 JavaScript 執行期特性時，要確定只啟用此功能。 啟用核取方塊之後，您現在可以執行相同的行為，對於您 JavaScript 呼叫了哪些功能，您會得到多出許多的相關資訊：
持有這項資訊，您可以評估 JavaScript 對您的應用程式的效能影響，並開始尋找並修復功能執行所需時間太長的任何熱點。 正如之前所述，您應設法刪除長時間執行的 JavaScript，若不可能的話，就將之移動到 Web Worker ，騰出主執行緒去執行其它任務。
避免微最佳化您的 JavaScript
瀏覽器可以執行一個項目的一種版本會比其他事快 100 倍，例如要求與元素的 offsetTop 比計算 getBoundingClientRect() 快，這當然很好。但事實是每個畫面中，您只會呼叫這類功能幾次，所以著重在 JavaScript 效能的這一方面，通常是浪費精力。 一般情況下，您只會節省 ms 的九牛一毛。
如果您在製作遊戲或高運算成本的的應用程式，那麼就是上述的例外情況，因為在這種情況下，您通常會在單一畫面中納入許多運算，此時所有考量都有幫助。
簡而言之，因為微最佳化通常不會對應至您正在打造的應用程式種類，因此對於微最佳化要非常謹慎。