我正在嘗試使用Google Speed Tracer來分析我的YUI3應用程序。瞭解Google Speed Tracer的報告
這是第一個快照：
到目前爲止好，ST表示地點拍攝195ms。所以，我放大它：
更妙的是，對不對？這裏ST帶我到那一行：
但下一步是什麼？我的意思是，這裏是行：
return ('scrollTop' in node) ? node.scrollTop : Y.DOM.docScrollY(node);
而且由於堆棧跟蹤在這裏結束我認爲node.scrollTop返回，這僅僅是一個JS屬性訪問。
那麼聲稱背後的邏輯是什麼，風格重新計算髮生在這一點，產生36ms的執行時間？
任何人都可以解釋給我看？
這裏最有可能發生的情況是，您已經累積了對需要重新計算樣式的DOM和/或樣式表的更改。但大多數渲染引擎（絕對是WebKit）儘可能延遲風格重新計算（以及佈局和渲染）。在最好的情況下，一旦當前事件處理程序將控制權返回給本機代碼，樣式重新計算，佈局和呈現都按順序運行。
但有很多事情可以強制早期重新計算或佈局。最常見的情況是您要訪問必須計算的DOM元素上的屬性（例如scrollTop）。其他屬性如offset[Left Top Width Height]也通常強制重新計算和佈局樣式。瀏覽器無法在後臺執行此操作，因爲渲染引擎（大部分）是使用Javascript虛擬機進行單線程的，所以它通常需要等待您調用本機代碼。
從截圖中分辨出來有點難，但從我所看到的情況看，在這個事件發生之前（18ms內）有一大塊HTML被解析出來，這可能相當於大量的風格重新計算和佈局（後者需要26ms）。我也在你的堆棧跟蹤中看到TableView._defRenderBodyFr()，這導致我懷疑在這個getter被調用之前，你已經添加/變異了一大堆錶行。 TableView代碼最有可能構建了一個大的HTML字符串，但只有在設置爲innerHTML時才支付HTML解析（和DOM構建），但只要代碼嘗試訪問屬性（在此例中爲scrollTop），您支付款式重新計算和佈局。
通過減少每個突變影響的行數，您應該能夠將這些成本分解爲更小的塊（從而使UI線程有機會呼吸，並且通常感覺響應更快）。我不是YUI專家，所以我不能告訴你如何在他們的TableView中做到這一點。