1,前言

我們開發(fā)了一個專題系統(tǒng),生成了JSON的數(shù)據(jù)格式,采用JQuery動態(tài)插入HTML中,在前期的使用中,沒有太大的問題,效率還可以接受,但是最近可能由于網(wǎng)絡(luò)加之頁面設(shè)計問題,我們的JS效率比較差,長達(dá)10多秒中,實(shí)在難以忍受,到底是什么原因呢?


2,分析

我觀察了一下JS腳本,應(yīng)該說沒有太費(fèi)時間的操作,采用ID的元素選擇法,應(yīng)該是最快的,雖然有個類選擇器,但是元素很少,一般在2個左右,不至于影響效率,我注釋一下,發(fā)現(xiàn)確實(shí)不是這個問題。


后來分析,可能是HTML外面套的INDEX.JSP的問題,加上頭尾后,效率很慢,所以我們分析思路:

        2.1 把JSP分出top,bottom.jsp,采用jquery load()事件加入至頁面,確實(shí)效率有所提升,但是在FF,和CHROME下不太正常,而調(diào)整后,都正常顯示,但是效率又下降了。

        2.2 采用IFrame方式:把頁面的頭和尾部采用Iframe嵌入,去掉邊框,固定大小,這個確實(shí)效率提高了,但是ifram里的跳轉(zhuǎn)是個大問題,效果不是很好;

3,根本原因

我們吧注意力放在了JS上面,突然想到,是不是$(document).ready()方法的原因??

我們?nèi)サ舸朔椒ǎ優(yōu)楹瘮?shù),同時在頁面中用setTimeout()延時10毫秒觸發(fā),發(fā)現(xiàn),正常了;

我網(wǎng)上查了一下read方法的說明:

當(dāng) DOM(文檔對象模型) 已經(jīng)加載,并且頁面(包括圖像)已經(jīng)完全呈現(xiàn)時,會發(fā)生 ready 事件。  
由于該事件在文檔就緒后發(fā)生,因此把所有其他的 jQuery 事件和函數(shù)置于該事件中是非常好的做法。正如上面的例子中那樣。  
ready() 函數(shù)規(guī)定當(dāng) ready 事件發(fā)生時執(zhí)行的代碼。  
ready() 函數(shù)僅能用于當(dāng)前文檔,因此無需選擇器。