我們的應用程序使用用於UI的ExtJS（Sencha）框架。我在框架中遇到的問題是框架輸出的HTML數量。減少網頁上CSS計算次數的方法
我已經注意到，用戶報告爲緩慢的系統區域有大量的CSS計算調用。我在Google的Speedtracer中測量了這一點，一些頁面需要8秒才能加載。 80％的時間純粹用於CSS計算。在嘗試改變框架的工作方式之前，有沒有辦法延遲頁面的CSS計算，還是在渲染對象時完成這些計算？
我一直在尋找方法來做到這一點，也許我的「谷歌福」是可怕的，但我還沒有找到具體如何實現這樣的事情。
編輯：在說完一個同事之後，他指出我在加載任何數據和.resumeEvents（）之後調用網格上的.suspendEvents（）方向，然後單獨保存了300ms的加載時間：O這會減少由Firebug檢測到的數字.getStyle調用。我還沒有用谷歌SpeedTracer測試這種差異
這很難說是什麼導致你的性能問題，不知道到底是什麼你的應用程序在做什麼。 CSS會產生一定的影響but not much，在頁面渲染時，應用中的某些JavaScript更有可能是causing excessive reflows。 stubornella的文章
摘要（第二個鏈接）
迴流是通過在網頁中的元素根據樣式規則得到中規定的過程。迴流在計算上很昂貴，但通常可以在單個迴流中繪製靜態HTML頁面，只要後面的元素的渲染不影響已經繪製的元素。事情是可能導致多個迴流和一些變通：
position: fixed或作爲t的position: absolute元素因爲你避免出現兩個迴流table-layout: fixedSmartoptimizer真的很棒，你有沒有試過這些類型的gzip代碼壓縮類型工具？
我們也一直用的ExtJS的開銷掙扎 - 雖然框架是非常全面的，性能受到影響（尤其是IE6）是一個很大的侷限性。下面是一些我們採取了優化框架的步驟：
所得轉 「精簡版」 應產生顯著的性能提升，特別是在IE6關鍵。儘管Secha團隊在每次發佈時都在不斷改進性能，但加載整個框架的開銷太昂貴而無法忽略。
希望這有助於...
不知道我理解你的問題。但通常CSS不支持頁面渲染。你提到的問題是ExtJS輸出HTML和CSS的計算量。我猜這個問題仍然是由JS渲染造成的。也許你可以試試Firebug或者Fiddler跟蹤請求以找到瓶頸 – tshao 2010-11-26 13:33:22
同意。世界上沒有多少CSS需要8秒才能計算，除非它運行在電報或其他東西上。我很想知道更多關於你如何測試的內容。 – 2010-11-26 17:15:06
如果我可以上傳SpeedTracer結果，我可能會嘗試截取它的截圖。 SpeedTracer與螢火蟲的不同之處在於，它實際上顯示UI何時可用，何時不可用。 Firebug和Fiddler顯示從服務器下載響應的時間。 – StevenMcD 2010-11-26 18:41:19