摘要：二模塊化誤區(qū)加快加載和執(zhí)行的速度，一直是前端優(yōu)化的一個(gè)熱點(diǎn)。結(jié)果文件減少，也達(dá)到了預(yù)期的效果。避免不必要的延遲。最后再根據(jù)文件的功能類型，來(lái)決定是放在頁(yè)面的頭部還是尾部。

注：本文是純技術(shù)探討文，無(wú)圖無(wú)笑點(diǎn)，希望您喜歡

一.前言

軟件行業(yè)極其缺乏前端人才這是圈內(nèi)的共識(shí)了，某種程度上講，同等水平前端的工資都要比后端高上不少，而圈內(nèi)的另一項(xiàng)共識(shí)則是——網(wǎng)頁(yè)是公司的臉面！

幾年前，谷歌的一項(xiàng)統(tǒng)計(jì)表明，如果亞馬遜頁(yè)面加載每慢 100ms，將影響他們 1% 的收入；如果谷歌頁(yè)面加載慢 500ms，流量將銳減 20%，這個(gè)數(shù)據(jù)現(xiàn)在必將更加恐怖！

在前端高性能優(yōu)化（一）、（二）中，筆者介紹了一些關(guān)于前端優(yōu)化的技術(shù)，這些技術(shù)都依賴于前人的辛苦努力，但我們?nèi)砸靼椎氖?，前端的情況十分復(fù)雜，優(yōu)化前端性能是必須因地制宜、因時(shí)制宜。

在本篇文章中，主要介紹的就是在一些條件下，傳統(tǒng)優(yōu)化 JavaScript 的技術(shù)并不像我們認(rèn)為的那樣適用。

二.JavaScript 模塊化誤區(qū)

加快 JavaScript 加載和執(zhí)行的速度，一直是前端優(yōu)化的一個(gè)熱點(diǎn)。因此我們先來(lái)說(shuō)下 JavaScript 模塊化技術(shù)的相關(guān)知識(shí)，希望通過(guò)實(shí)踐來(lái)體現(xiàn)模塊化技術(shù)在使用時(shí)的注意事項(xiàng)，避免濫用。

為什么會(huì)有模塊化技術(shù)？

長(zhǎng)久以來(lái)，編寫 JavaScript 一直以文件為單位，一般一個(gè)類型的 JavaScript 功能代碼會(huì)被放在同一個(gè)文件里。在一個(gè)頁(yè)面里，引用的文件一般是寫死的，也就是不管頁(yè)面用不用，只要你引入了這個(gè)文件，這個(gè)文件就會(huì)被加載。

舉個(gè)例子，我們開發(fā)了一個(gè)內(nèi)容復(fù)雜、功能強(qiáng)大的頁(yè)面，JavaScript 文件大到 500K，當(dāng)頁(yè)面費(fèi)勁的把這 500K 加載下來(lái)，然而用戶真正只使用了這 500K 里極少的一部分功能，但我們又不得不把這 500K 加載下來(lái)，因?yàn)椴煌挠脩羰褂玫墓δ茳c(diǎn)可能不一樣，我們必須滿足所有需求。

而模塊化技術(shù)提出 按需加載，也就是當(dāng)用戶觸發(fā)該功能的時(shí)候，那個(gè)功能才真正的被加載。好比 500K 被拆成了 50 個(gè)模塊，每個(gè)模塊 10K，當(dāng)用戶觸發(fā)一個(gè)功能時(shí)，加載 10K，再觸發(fā)再加載，以這樣懶加載的方式來(lái)加載模塊，可以很大的提高響應(yīng)速度。這樣，管理模塊懶加載的技術(shù)也隨之誕生。

模塊化技術(shù)并非到處靠譜!!

之前筆者在網(wǎng)上搜索到了一個(gè)模塊化技術(shù)：SeaJS。它是一個(gè)遵循 CommonJS 規(guī)范的 JavaScript 模塊加載框架，可以實(shí)現(xiàn) JavaScript 的模塊化開發(fā)及加載機(jī)制。與 JQuery 等 JavaScript 框架不同，SeaJS 不會(huì)擴(kuò)展封裝語(yǔ)言特性，而只是實(shí)現(xiàn) JavaScript 的模塊化及按模塊加載。

SeaJS 的主要目的是令 JavaScript 開發(fā)模塊化并可以輕松愉悅進(jìn)行加載，將前端工程師從繁重的 JavaScript 文件及對(duì)象依賴處理中解放出來(lái)，可以專注于代碼本身的邏輯。說(shuō)白了就是有 Lazy Load 的特性，用到某模塊時(shí)，SeaJS 才會(huì)去加載模塊的 JS 文件。我們可以按功能劃分多個(gè)模塊，觸發(fā)模塊功能時(shí)，SeaJS 先加載功能模塊的文件，然后執(zhí)行相應(yīng)的功能。

這個(gè) SeaJS 擁有的特性，初看非常吸引人，它可以說(shuō)是新定義了一種開發(fā)和管理 JavaScript 文件的模式。遵循這個(gè)模式，你會(huì)享受起 JavaScript 的開發(fā)。

實(shí)踐證明，它也的確可以使 JavaScript 模塊化，根據(jù)功能劃分模塊，每個(gè)模塊對(duì)應(yīng)一個(gè) JavaScript 文件，當(dāng)執(zhí)行到模塊的功能，或者你需要加載模塊時(shí)，模塊才會(huì)被下載，同時(shí)不會(huì)造成重復(fù)下載。這一切看起來(lái)如此的合理，如此的順暢。。。。。

但是在使用后發(fā)現(xiàn)了一些 問(wèn)題：由于當(dāng)時(shí)開發(fā)的網(wǎng)站功能相對(duì)簡(jiǎn)單，JavaScript 文件并不是非常大，過(guò)多的模塊，反而會(huì)導(dǎo)致總加載的時(shí)間變多了。

由于是 Lazy Load 特性，不適合的模塊劃分導(dǎo)致網(wǎng)站出現(xiàn)反應(yīng)慢的現(xiàn)象，原因是得先加載模塊的文件，才能執(zhí)行模塊的功能。當(dāng)網(wǎng)絡(luò)情況不好時(shí)，該現(xiàn)象表現(xiàn)的更為嚴(yán)重?。?！

可以說(shuō)，問(wèn)題出在了對(duì)新技術(shù)的不了解上，從而出現(xiàn)了問(wèn)題，預(yù)期是 SeaJS 可以處理 JavaScript 優(yōu)化的問(wèn)題，因?yàn)樗哂斜苊饧虞d不必要模塊的功能，結(jié)果反而南轅北轍。

總結(jié)

雖然嘗試出現(xiàn)了問(wèn)題，但是，收獲也是巨大的，簡(jiǎn)單來(lái)說(shuō)就是以下兩點(diǎn)：

1）因地制宜，根據(jù)實(shí)際需要使用模塊化技術(shù)，切勿跟風(fēng)技術(shù)，在自己沒(méi)有完全掌握時(shí)，謹(jǐn)慎用于產(chǎn)品中。

2）模塊如果是懶加載的，粒度不能太小，也就是模塊不能太小。

根據(jù) 大功能來(lái)劃分模塊 也是一個(gè)不錯(cuò)的嘗試。

筆者嘗試將所有模塊劃分為 基礎(chǔ)模塊 和 功能模塊 ，基礎(chǔ)模塊包括頁(yè)面頭部，尾部相關(guān)的公共部分，功能模塊則根據(jù)前后臺(tái)劃分，前臺(tái)部分，又根據(jù)具體的頁(yè)面來(lái)劃分，能合并到一起的，就合并成一個(gè)模塊，增加粒度。結(jié)果 JavaScript 文件減少，也達(dá)到了預(yù)期的效果。

從實(shí)際體驗(yàn)來(lái)看，對(duì)于流量不大的網(wǎng)站來(lái)說(shuō)，沒(méi)有必要使用懶加載 JavaScript 的相關(guān)技術(shù)，因?yàn)楸旧?JavaScript 文件就不是非常大。因此在網(wǎng)頁(yè)加載時(shí)，就可以先加載所需要的模塊。避免不必要的延遲。

三.JavaScript 的位置問(wèn)題

這一部分，我們來(lái)說(shuō)說(shuō) JavaScript 的位置問(wèn)題對(duì)網(wǎng)頁(yè)網(wǎng)站性能的影響。

為什么要考慮位置問(wèn)題？

其實(shí)不管是 CSS 還是 JavaScript，都需要考慮位置的問(wèn)題，因?yàn)?HTML 的渲染和加載順序是從上往下，也就是如果前面插入了 JavaScript 的引用，那么必須等到這個(gè) JavaScript 下載完畢才會(huì)渲染后續(xù)的部分。

因此 JavaScript 的插入位置就成為一個(gè)值得考慮的問(wèn)題，因?yàn)椴贿m合的位置可能引起渲染的延遲等，造成不好的用戶體驗(yàn)。

傳統(tǒng)方案帶來(lái)的問(wèn)題和思考

CSS 放在頭部，JavaScript 放在尾部，這是傳統(tǒng)的經(jīng)驗(yàn)，它的好處是可以讓頁(yè)面優(yōu)先渲染, 從而頁(yè)面可以快速顯示。

但有事實(shí)往往沒(méi)有我們預(yù)想的那么美好。

有的時(shí)候會(huì)出現(xiàn)這么一種情況：當(dāng)頁(yè)面已經(jīng)渲染完畢時(shí)，我們立刻去使用網(wǎng)站的功能，但很多時(shí)候 功能按鈕會(huì)沒(méi)有反應(yīng)。原因也很簡(jiǎn)單，就是 JavaScript 放在頁(yè)面的尾部，還沒(méi)來(lái)得及加載。。。。

這就糾結(jié)了。。。。

兩種 JavaScript 放置方式，一種放在頭部，一種放在尾部（暫時(shí)忽略部分放在頭部，部分放在尾部的方式），一個(gè)犧牲了渲染速度，一個(gè)犧牲了用戶體驗(yàn)。所以很多時(shí)候 js 的問(wèn)題我們需要做權(quán)衡。

對(duì)一般的小型網(wǎng)站來(lái)說(shuō)，用戶體驗(yàn)問(wèn)題要遠(yuǎn)遠(yuǎn)大于頁(yè)面渲染的問(wèn)題，就比如上文提到的那種功能按鈕不可用的情況。而且，如果 JavaScript 不是很大的話，放在頭部就很好，既不會(huì)有太久的頁(yè)面空白，也能讓其優(yōu)先加載，二者得到了很好的平衡。

因此，很多經(jīng)驗(yàn)上的東西并不是絕對(duì)的，一定要根據(jù)實(shí)際的情況，包括功能特點(diǎn)、服務(wù)器網(wǎng)絡(luò)情況等來(lái)綜合考慮。

為此，筆者寫下一個(gè)自認(rèn)為較為合理的位置選擇方案，僅供參考。

圖 1. 判斷 JavaScript 放置位置決策表

從上面的分類介紹，我們也可以看出，將功能代碼按類型歸類到不同的 JavaScript 文件是多么的重要，比如應(yīng)該放頭部和應(yīng)該放尾部的代碼，最好不要合并在一起,不要等到出問(wèn)題要優(yōu)化的時(shí)候再去整理和重構(gòu)，這樣會(huì)增加很多不必要的工作量。

這不僅僅是為自己工作負(fù)責(zé)，也是為后面要讀你代碼的新人負(fù)責(zé)。養(yǎng)成好的設(shè)計(jì)編碼習(xí)慣，也是技術(shù)積累的一部分。最后再根據(jù) JavaScript 文件的功能類型，來(lái)決定是放在頁(yè)面的頭部還是尾部。

四.怎樣確定是不是 JavaScript 的問(wèn)題？

這個(gè)問(wèn)題在之前的前端高性能優(yōu)化（一）、（二）中也都簡(jiǎn)單的說(shuō)過(guò)，之所以在這再次提及是因?yàn)榇_實(shí)覺(jué)得這個(gè)工具用著很舒服。

沒(méi)錯(cuò)，就是舒服。

隨著信息爆炸時(shí)代的到來(lái)，網(wǎng)站本身性能也深刻影響著公司的形象、利益等問(wèn)題。但是大多數(shù)前端測(cè)試工具都太碎片化，沒(méi)有辦法針對(duì)多個(gè)使用場(chǎng)景，而且很多都是像 yslow 這樣簡(jiǎn)單打個(gè)分，也不是真實(shí)的用戶體驗(yàn)。前一段時(shí)間在網(wǎng)上找到了一款前端性能優(yōu)化分析工具——Browser Insight，里面的功能相當(dāng)全面，而且可以針對(duì)多個(gè)使用場(chǎng)景，包括：PC端，移動(dòng)微信，移動(dòng)瀏覽器，移動(dòng)webview，還是 真實(shí)的用戶體驗(yàn)，也就是說(shuō)，用戶訪問(wèn)你的網(wǎng)頁(yè)是什么樣的，從這個(gè)工具中體現(xiàn)出的就是什么樣子的。

基于 JavaScript 這個(gè)維度 Bi 做的也是相當(dāng)豐富了。

首先是 腳本錯(cuò)誤 板塊。Bi 里面可以從不同的時(shí)間維度查看被監(jiān)控頁(yè)面出現(xiàn)過(guò)的腳本錯(cuò)誤，具體信息包括：發(fā)生時(shí)間、設(shè)備類型、報(bào)錯(cuò)的瀏覽器及其版本號(hào)、錯(cuò)誤堆棧信息都可以看到，不論是 線上還是線下測(cè)試或者頁(yè)面維護(hù) 都是夠用了。

不但能看到時(shí)間、系統(tǒng)、瀏覽器等，還可以具體定位到出錯(cuò)的代碼行，這個(gè)確實(shí)很方便。

圖 2.Bi 腳本錯(cuò)誤

其次是頁(yè)面響應(yīng)時(shí)間板塊，這個(gè)算是意外的收獲了。通過(guò)響應(yīng)時(shí)間板塊里面的慢加載追蹤，可以看到本次慢加載的頁(yè)面資源加載情況，然后我們就知道該優(yōu)化哪個(gè)頁(yè)面的哪些 js 、css、img等。

圖 3.Bi 資源列表-時(shí)序圖

五.前端優(yōu)化？用戶體驗(yàn)？

各位看客，如果你真能堅(jiān)持看到這里，是否會(huì)覺(jué)得這篇更像解決用戶體驗(yàn)問(wèn)題的文章?但是講心里話，前端優(yōu)化的最終目的，難道不是為了改善用戶體驗(yàn)嗎？

任何基于用戶體驗(yàn)的方案，都可以叫前端優(yōu)化技術(shù)。

不管使用多么好的機(jī)器、多么高的技術(shù)，響應(yīng)速度問(wèn)題總是避免不了的，因此糾結(jié)于什么技術(shù)來(lái)解決是不實(shí)際的。但是有一款好的工具，使用一些小技巧，也可以改善用戶等待的體驗(yàn)。

比如，我們?yōu)槊總€(gè)非 _target 的超鏈接或者表單的點(diǎn)擊，添加點(diǎn)擊事件處理，處理邏輯也很簡(jiǎn)單，就是設(shè)置 3 秒超時(shí)，顯示等待對(duì)話框。如果在 3 秒內(nèi)頁(yè)面發(fā)生跳轉(zhuǎn)，那么這個(gè)等待對(duì)話框就不會(huì)出現(xiàn)，否則會(huì)彈出提示用戶等待，從而及時(shí)的將響應(yīng)反饋給用戶，減少用戶空白等待時(shí)間。

這并不是什么高深的技術(shù)，但是運(yùn)用這個(gè)技巧，卻可以大大的改善用戶體驗(yàn)。

各位，我們優(yōu)化的目的，就是不要讓用戶一直得不到響應(yīng)，避免空白等待，讓用戶體驗(yàn)越來(lái)越好。