FineUI 的下個版本（v8.0.0），我們會為表格新增延遲加載功能（EnableDelayRender），從而使得典型表格頁面加載性能提升 3 倍以上！
大數據表格
FineUI很早之前就已經支持大數據表格了，對於需要一次性展示超過 1000 條數據的純展示場景非常有用。
官網示例：FineUIPro 在線示例 - 基於 jQuery 的專業 ASP.NET 控件庫
但是大數據表格屬於企業版功能，必須使用網址數據源，而且不支持樹表格、列鎖定、單元格合並等等很多特性，局限性比較大。
大數據表格的實現原理其實是虛擬滾動條，只展示當前用戶可視區域內的表格數據。
如下圖所示，長長的滾動條是由一個 .f-grid-table-bigdata-shadow 元素的高度撐起來的，而這個高度是根據每行的高度和總行數計算來的（所以大數據表格要求行的高度必須固定）。
v8.0新增的延遲加載
由於大數據表格存在一定的局限性，我們一直在思考有沒有更簡單的辦法提高普通表格的加載性能，特別是每頁 200 - 1000 條數據的表格性能，這個才是我們最經常遇到的應用場景。
說到底，表格行數對渲染性能的影響歸根結底是因為大量DOM節點的產生，而在 200 條以上的數據情況下， 用戶在頁面第一次加載時最多看到不超過 30 條數據。
也就是說，我們要額外加載 170 條用戶看不到的數據，而這些額外加載的數據會影響頁面的打開速度。
如果能夠延遲加載那些用戶看不到的數據，豈不是一舉兩得：
- 不會影響頁面第一次加載時的用戶看到的數據
- 加快頁面第一次打開的速度
FineUI v8.0新增的延遲加載特性就是為了實現這個目的，來看下頁面第一次加載時的DOM節點渲染情況：
和大數據表格的情況類似，但是實現方式完全不同。
整個表格在頁面第一次加載時就完全渲染了，只不過DOM節點只渲染了前面的 30 多行數據，剩余的 400 多行數據以占位符的形式渲染到DOM，這就節省了大量的DOM渲染時間（加載了頁面第一次渲染速度，提升用戶體驗）。
為了比較准確的描述表格的渲染速度，我們寫了如下的測試代碼，用於衡量當前表格渲染用時：
<f:Grid ID="Grid1" ...> <Columns> ... </Columns> <Listeners> <f:Listener Event="render" Handler="onGridRender" /> </Listeners> </f:Grid> <script> // 等所有JS資源下載完畢后開始 var __STARTTIME = new Date(); // 表格渲染完畢后結束 function onGridRender() { F.ui.Grid1.setTitle(F.ui.Grid1.getTitle() + ' - 渲染時間：' + ((new Date() - __STARTTIME) / 1000).toFixed(2)); } </script>
首先來看下，目前表格在加載 500 條數據和 1000 條數據的性能表現：
添加了 v8.0.0 新增的延遲加載特性（EnableDelayRender=true）之后，我們再來看下相同頁面的加載速度：
小結
經過多次測試，我們測算出平均渲染速度，如下表所示。
可以看出，FineUI v8.0新增的延遲加載屬性（EnableDelayRender=true）可以極大的提升表格頁面的加載速度，在典型的每頁 500 條數據的情況下，頁面第一次加載的速度提升 3 倍以上。
| 第一次 | 第二次 | 第三次 | 第四次 | 第五次 | 第六次 | 平均加載時間（秒） | 渲染速度提升 | |
| 500條數據 | 0.91 | 0.87 | 0.84 | 1.01 | 0.92 | 0.88 | 0.91 | - |
| 1000條數據 | 1.72 | 1.68 | 1.65 | 1.64 | 1.70 | 1.62 | 1.67 | - |
| 500條數據（延遲渲染） | 0.25 | 0.22 | 0.24 | 0.24 | 0.22 | 0.20 | 0.23 | 396% |
| 1000條數據（延遲渲染） | 0.40 | 0.38 | 0.35 | 0.34 | 0.41 | 0.39 | 0.38 | 439% |
為了更直觀的感受兩者的差異，我們通過兩個動圖來呈現 FineUI v8.0 帶來的表格渲染速度的提升。
未啟用延遲加載
啟用延遲加載
三石出品，必屬精品