在整個優化過程中，始終使用簡單的html和css結構完成ui功能，讓整個html結構看起來有層次，有語義，結構簡單。比如實現滑動效果，就要避免使用div結構，而使用a結構，因為a的hover是ie瀏覽器一貫支援，並且不需要js指令碼的支援。
不得不承認extjs的強大，但是extjs為了瀏覽器的相容性和功能的健壯性，使用了很多繁雜的html結構，比如在構建tab時使用div+table結構和dom動態定位，這種結構雖然適用各種瀏覽器，但是以渲染效能損耗為代價的。u8 bs門戶目前只支援ie瀏覽器，也就是說extjs中因為瀏覽器相容而做出的效能損失，對我們是不適用的。另外extjs的元件功能複雜很多功能不是我們需要的，有些功能會成為我們開發新功能的的牽絆。 結合以上幾點，我們的優化過程就是去extjs元件化的過程。使用extjs的基礎功能構建我們所需要的自定義的元件，這樣的元件足夠簡單，又足夠我們使用，簡化html和css結構，從而節約效能開支。
做效能優化，日誌是必不可少的。我們的日誌很細，整個指令碼的關鍵執行過程都有日誌輸出，包括異常和錯誤。針對性能優化的推進，效能公關點的日誌可以細到每個執行語句的日誌輸出。另外我們的日誌採用begin-end結構，結合效能日誌分析系統，可以很方便的評估系統的效能瓶頸和優化效果。
因為使用自定義的前端元件，ie版本之間的相容性測試要在每個元件開發完之後必須做的工作。避免出現在在開發後期因為相容性問題導致前端元件的html大規模變更而帶來的的時間風險。
重構、優化工作意味著對老舊**的改造，這就要求團隊成員之間目標一致，高效溝通，以免引入新的bug或是遺漏功能。我們的最佳實踐是採用結對程式設計+極限程式設計的理念，每個人知道都知道其他人的工作內容和優化方式，不定期的**走查，以提高**質量。
這個點不是我們的最佳實踐。效能指標是效能優化的目標。隨時的做測試，可以讓我們實時了解我們和目標的距離，以激發工作激情。同時也可以作為一種總結和優化方式改進的契機。