Flickr使用YUI3重構時遇到的問題

上週做yuiconf2010介紹分享時沒有作為重點的《porting flickr to yui3》卻被大家關注。所以回來仔細看了一遍video又得到了新概念——感知效能。

《porting flickr to yui3》的分享者ross harmes是flickr的前端開發工程師，在這次會議上他主要分享了他的團隊在運用yui3時的效能，元件，技巧，經驗。幾個月前，flickr推出了新的**網頁，他們決定使用yui3徹底推倒重建舊的頁面，使用yui3是件快樂的事情，但也總結了一些問題：

第乙個問題：延遲的js

為了不讓js堵塞頁面載入，一般都是將頁面的js**移動到頁面底部，但是問題產生了，這樣一些完全依賴js的ui元素將無法可用，必須要讓使用者等待到js載入完成後才能操作。flickr的**頁面這個等待過程一般情況下是2s，再ie下更加嚴重。比如一些連線、按鈕在等待js載入完之前人們為了友好性會給使用者乙個連線響應，讓使用者另跳到頁面繼續操作，但是這不是乙個很好的解決方法。

flickr採取的解決方案是動態排隊，提高使用者的感知效能。其實就是為使用者增加乙個響應的效果，flickr舉的例子是他們頁面上的乙個導航提示層，如圖：

flickr將原生的js(動態排隊)的功能內嵌到頁面頂部，而yui3所有內容包括seed全部移動到頁面底部。頂部**如：

(function(f) 
button.blur();
if (!document.getelementbyid('interim-menu-action')) 
if (document.getelementbyid('interim-menu-share')) }},
cleanup: function(id) 
f.actionqueue['photo-button-bar'].display_action();}},
'photo-button-bar');
} (f));

這樣做的目的是在yui3沒有載入完成前，使用者點選操作顯示的彈出層是js原生onclick執行(建立正在載入中的外框)。而具體需要顯示的內容給使用者乙個等待載入的過程，在暗示使用者心理的過程中，頁面已經載入完js(包括頁面底部的yui3各種模組載入)，並顯示出使用者需要的內容。這就叫感知效能的提公升。

這個過程沒有真正提高頁面js載入速度，反而會相應的增加些，但是產生的結果對使用者而言確實是提公升了體驗，這一點很有意思，所以有時效能與感知要有乙個權衡。

第二個問題：y.delegate()和y.on()的_poll方法導致輪詢

然而提高了使用者可感知性，便遇到另乙個問題，如果使用者不去點選那個彈出層，也就是具體操作的dom物件不存在，當yui3載入後的y.on()將無法找到對應的dom物件，導致y.on()一直在輪詢。

y.delegate()與y.on()的事件監聽檢測機智雖然非常之像樣，但是同樣導致一些效能損耗，因為檢測的過程是不停的去判斷dom的存在情況，直到dom已經載入完。

為了避免這種情況,flickr將所有點選後顯示的dom都採用display：none的形式保證在y.on()之前存在dom物件。至於動態排隊的顯示框與載入後的顯示框是完全沒有關係的，當具體操作的js執行時，將移出之前動態建立的元素，顯示出隱藏的內容。

第三個問題：過長的url

flickr的combo-handler url 有2,792characters，而少數使用者的防火牆是限制url的長度，因此這一點需要大家注意，flickr使用一定的演算法減少40%字元。但是有人提出乙個更好的解決方法就是在載入完模組後進行檢測如果存在沒有載入的模組之後再次載入剩餘模組。

flickr最後總結要去深入的挖掘js文件庫，才能真正的運用yui3 提高效能。

flickr目前只是改版了**頁面，位址為

Flickr使用YUI3重構時遇到的問題

YUI 3 學習筆記 queue base

YUI3學習（一）入門

使用YUI3建立Popup彈出層

Flickr使用YUI3重構時遇到的問題

YUI 3 學習筆記 queue base

YUI3學習（一） 入門

使用YUI3建立Popup彈出層

相關推薦

YUI3學習（一）入門