[ASP.NET]DOLOTO: Code Splitting for Network-Bound Web 2.0 Applications

2009-09-11

8159
0
ASP.NET

DOLOTO，第一次看到這個名字，會讓人情不自禁的把他跟LOLOTA、TOTORO等等名詞聯想在一起...XD，不過這東西可是微軟針對AJAX網頁的效率最佳化所提供的一個小工具喔，DOLOTO是"Download Time Optimizer"的簡寫，而同時也代表俄文中"鑿子"的意思，根據這個描述我們就可以比較輕易了解它的用意了，DOLOTO主要針對網頁的資料下載，提供最佳化的管理，但如何管理呢？請待我們下方進行說明。

目前網頁為了講求高度的互動性，因此將許多操作交給了Javascript來協助，甚至連前後端的溝通，都因為AJAX framework的出現，讓前端的Javascript內容愈長愈肥，或許您不知道，當您使用了ASP.NET AJAX時，您的系統用戶，基本的Javascript消費就已經是100多KB了，若您對100多KB的感覺不大，您可以參考這篇文章：[ASP.NET]非程式面的效能問題(1)-頻寬

如果您知道Internet的頻寬價格，我想您應該會更加的在意頻寬這回事，目前的瀏覽器雖然都有靜態檔案的cache功能，這對頻寬的的問題來說，自然是非常的好，但每次頁面載入時都需要將一大堆的js檔案(不管有沒有用到)一次下載到client端來，這樣的結果若能有所改善，對我們網頁的執行效率還是很不錯，我想陸陸續續都有許多人對於降低網路流量都有提出不少解決方法，其中的網頁壓縮就是一種很不錯的方法，雖然會稍微提高Server端的CPU負擔，但卻可以大大的改善流量，畢竟CPU的價格比起頻寬，還是便宜太多了...

下方我們看一下一些公開的網站，在進行網頁壓縮後的流量狀況：

挺嚇人的，即使經過gzip壓縮，pageflakes、gmail這些網站竟然還要接近1MB的流量，而在gmail中，Javascript就佔了37%，而圖檔在壓縮過程中效果並不好，因此我們通常不會壓縮圖檔，因此就算使用gzip，圖檔的大小通常根本來沒有太大的差別。

以gmail為例，它預先載入的這些Javascript多達300KB左右，而當中可能它只需要先用到其中的10KB，但它卻不能自己選擇它用到哪些script內容再自動篩選並下載，如果有一個工具，可以幫我們判斷哪些scipt是在第一次載入就要用到，後續若有需要再透過動態呼叫來載入其他未載到前端的function，那豈不是很好？如何，聽起來很不錯吧，不過因為javascript並沒有特定的格式，要分析它的內容實在太困難了，所以我該說它瘋了嗎？DOLOTO竟然就搞了一個動態載入script的架構出來....

一般我們在使用script時我們會在html中這樣寫，當html render到這幾行時，就會向server端送出request，並下載這些js檔到client端來，這時候你是沒有選擇的要整個檔案下載的：

而後來有人提出使用XMLHTTP來動態向server端取得某段script內容，並透過eval的方式將這段script的內容賦與另一個新的變數，我們可以稱之為function rewrite，但當responseText的內容太肥，造成流量太大時，我們可能會看到畫面hang住不動：

DOLOTO實際上正透過以上的作法來達成script分批送到前端的工作，將script在需要的時候才送到client端，不過要做到這一點似乎並不容易，因此Doloto提了兩個步驟：Access Profiles跟Server-side code rewrite，Access Profiles主要是透過script被呼叫的時間來區分哪些script可以被歸為同一個cluster，這邊他有一個特殊的演算法則，細節是什麼個人並不是特別清楚；而Server-side code rewrite則較好理解，我們看看以下的程式範例：

在Server端的js檔上，其實有f1跟f2這兩個function，而這兩個function可能是放在一個很大的js檔中，經過Access Profiles的分析後，這兩個function可能被放到同一個cluster中，因此下面透過識別guard_cluster_c1()這個function來分別取得Server上js檔對f1跟f2 function的內容，並將功能重新賦予給的f1'跟f2' fucntion，透過這種方式將f1賦與給f1'的過程，來達到function rewrite，因此在前端可以直接呼叫f1'跟f2'，而其執行的結果跟實際的f1跟f2是相同的。