不管是做前端開發還是測試，我覺得都應對網頁內容加載和執行有所瞭解，特別是JavaScript，否則遲早都會得到教訓，在我寫此文之前就得到過教訓，所以印象特別深刻，當時也爲了搞明白其中緣由，查了些資料，現在終於有時間整理出來，也是承前面的《瀏覽器渲染原理及可能出現的bug》繼續前端知識普及。
先說說當時我們遇到的一個問題：
網頁第三方廣告較多，出現嚴重客戶端性能瓶頸；
第三方跟蹤代碼出現異常無響應，導致頁面不顯示圖片。
爲了解決以上兩個問題，就需要了解以下知識。
JS執行時有兩個特性：1. 加載後馬上執行；2. 執行時會阻礙頁面後續的內容，包括渲染和其他資源的下載。
再來看兩個事件：
Window.onload：該事件要求網頁內所有的元素全部加載完畢之後纔會觸發，如果網頁裏有很大的圖片，flash等，加載時間非常長，那麼我們的初始化函數會延時很久後才執行！在網速較慢的情況下，這樣的延時往往是不可接受的。
DomReady：爲了解決這個Window.onload的問題，很多JS框架提供了此事件，DOMReady 只判斷頁面內所有的DOM節點是否已經全部生成，至於節點的內容是否加載完成，它並不關心，所以速度更快。但是它並不是原生JavaScript支持的事件，不能直接使用，需要結合JS框架使用它。
因爲JS的兩個特性，所以很多網站都會把Javascript放在最後面執行，配合使用Window.onload或DomReady事件。而頁面很多內容可能並不是非常重要的，那就又會引入異步加載。
關於異步加載，你可能聽過這些內容：
AJAX
維基百科這麼介紹：
AJAX即“Asynchronous JavaScript and XML”（異步的JavaScript與XML技術），指的是一套綜合了多項技術的瀏覽器端網頁開發技術。傳統的Web應用允許用戶端填寫表單（form），當提交表單時就向Web服務器發送一個請求。服務器接收並處理傳來的表單，然後送回一個新的網頁，注意是新的頁面，但這個做法浪費了許多帶寬，因爲在前後兩個頁面中的大部分HTML碼往往是相同的。由於每次應用的溝通都需要向服務器發送請求，應用的迴應時間依賴於服務器的迴應時間。這導致了用戶界面的迴應比本機應用慢得多。
與此不同，AJAX應用可以僅向服務器發送並取回必須的數據，它使用SOAP或其它一些基於XML的頁面服務接口，並在客戶端採用JavaScript處理來自服務器的迴應。因爲在服務器和瀏覽器之間交換的數據大量減少（大約只有原來的5%）。結果，我們感覺服務器迴應更快了。同時，很多的處理工作可以在發出請求的客戶端機器上完成，因此Web服務器的負荷也減少了。這也是目前使用最爲廣泛的一項技術。
那具體實現Javascript載入方式有哪些呢？
Document.write
對於在同一個script標籤裏的JavaScript的代碼來說，它不會阻塞後面的內容執行，但是對於整個頁面來說，這個還是會阻塞，所以要儘量避免使用。
動態創建DOM
這種方式使用最爲廣泛，它能解決異步載入JS的問題，但是無法保證載入時機。爲了解決時機問題，就需要綁定到具體的事件上。比如點擊某個查詢按鈕或鼠標hover效果等來動態創建DOM。
延遲加載（lazy loading）
有些JS並不是頁面初始化時就需要的，而是在稍後過程中才會用到，延遲加載就是一開始並不加載這些暫不用到的JS，而是在需要的時候通過JS控制來實現異步加載。例如大量圖片的站點，可能只需要出現在可視範圍內時顯示即可。
瞭解了上面的內容，現在再來看出現過的那兩個bug：
第一個問題就是因爲過多的廣告內容，加載內容很多，而沒有使用異步加載，只是綁定了DomReady事件來加載資源，導致頁面從請求到響應完畢需要大概9s多的時間，非常慢。爲了解決這個問題就預先使用一張跟廣告圖片類似的打底圖佔位顯示，再在頁面其他內容加載完之後異步加載該廣告，這樣既可以解決性能問題同時還不會給用戶帶來較差的體驗。
第二個問題是圖片使用了延遲加載，並且綁定在domready事件上的，如果Dom能完全加載出來那就不會影響其圖片的加載。而因爲第三方服務器宕掉，發出的請求一直未響應，導致了其中dom節點未加載出來，導致延遲加載的腳本未執行，後來從DomReady改成了立即執行，即解決了這個問題。
通過這兩次事件之後，目前所有要加載的第三方跟蹤代碼都需要通過前端開發人員的review和測試人員的細緻測試才允許業務部門添加，把風險最小化。
