建站
咨詢
售后
建站咨詢
新聞中心
在建立那些嚴(yán)重依賴于JavaScript網(wǎng)站的時(shí)候，有時(shí)我們會(huì)為自己發(fā)送的內(nèi)容付出一些隱形的成本。在本篇文章中，我會(huì)介紹一些可以幫助你提升網(wǎng)站在移動(dòng)設(shè)備上加載和運(yùn)行速度的實(shí)用規(guī)則。
我們提供的服務(wù)有：成都網(wǎng)站設(shè)計(jì)、網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)、微信公眾號(hào)開(kāi)發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、大安市ssl等。為超過(guò)千家企事業(yè)單位解決了網(wǎng)站和推廣的問(wèn)題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的大安市網(wǎng)站制作公司
tl;dr：更少的代碼 = 更少的解析/編譯 (parse/compile)+ 更少的傳送 + 更少的解壓縮
網(wǎng)絡(luò)
大多數(shù)開(kāi)發(fā)人員考慮JavaScript成本的時(shí)候，考慮的都是下載和執(zhí)行成本。通過(guò)線路發(fā)送的JavaScript字節(jié)越多，所需時(shí)間就越長(zhǎng)，用戶連接就越慢。
即使是在發(fā)達(dá)國(guó)家，這也可能是一個(gè)問(wèn)題，因?yàn)橛脩魧?shí)際上用的有效網(wǎng)絡(luò)連接類型可能并不是3G、4G或者Wifi。表面上你可能連的是咖啡店的Wifi，但實(shí)際上連到的是只有2G速度的蜂窩熱點(diǎn)。
你可以通過(guò)以下的幾種方式來(lái)降低JavaScript的網(wǎng)絡(luò)傳輸成本：
- 只傳送用戶需要的代碼。可用代碼拆分(Code-splitting)。
- 優(yōu)化壓縮代碼(ES5的Uglify，ES2015的babel-minify或者uglify-es)
- 高度壓縮(用Brotli~q11，Zopfli或gzip)。Brotli的壓縮比優(yōu)于gzip。它可以幫CertSimple節(jié)省17%的壓縮JS的字節(jié)大小，以及幫LinkedIn減少4%的加載時(shí)間。
- 移除無(wú)用的代碼。用 Chrome DevTools代碼覆蓋率功能來(lái)查找未使用的JS代碼。對(duì)于精簡(jiǎn)代碼，可參閱tree-shaking， Closure Compiler的高端模式(advanced optimizations)和類似于 lodash-babel-plugin的微調(diào)庫(kù)插件，或者像Moment.js這類庫(kù)的Webpack的ContextReplacementPlugin。用babel-preset-env & browserlist來(lái)避免現(xiàn)代瀏覽器中已有的轉(zhuǎn)譯(transpiling)功能。高級(jí)開(kāi)發(fā)人員可能會(huì)發(fā)現(xiàn)仔細(xì)分析Webpack打包(bundle)有助于他們識(shí)別和調(diào)整不必要的依賴關(guān)系。
- 緩存HTTP代碼來(lái)減少網(wǎng)絡(luò)傳輸量。確定腳本最佳的緩存時(shí)間(例如：max-age)和提供驗(yàn)證令牌(Etag)來(lái)避免傳送無(wú)變化的字節(jié)。用Service Worker緩存一方面可以讓應(yīng)用程序網(wǎng)絡(luò)更加靈活，另一方面也可以讓你能夠快速訪問(wèn)像V8代碼緩存這樣的功能。長(zhǎng)期緩存可以去了解下Webpack帶哈希值文件名(filename hashing)。
(減少向用戶發(fā)送JavaScript量的最佳做法。)
解析/編譯
下載成功后，JavaScript**絕大部分的時(shí)間都消耗在JS引擎對(duì)下載代碼的解析/編譯**上。在Chrome DevTools中，解析和編譯是下面性能面板(Performance panel)中黃色“腳本”時(shí)間的一部分。
Bottom-Up/Call Tree允許我們?nèi)ゴ_切地查看解析/編譯所用時(shí)間：
(Chrome DevTools性能面板下級(jí)菜單>Bottom-U。啟動(dòng)V8的Runtime Call Stats，就能看到不同階段的時(shí)間消耗，比如解析/編譯所用時(shí)間。)
但是，這為什么會(huì)是個(gè)問(wèn)題?
耗費(fèi)很長(zhǎng)的時(shí)間在解析/編譯代碼上，會(huì)嚴(yán)重延遲用戶與你網(wǎng)站的交互時(shí)間。你發(fā)送的JavaScript越多，在網(wǎng)站實(shí)現(xiàn)交互前所用的解析/編譯的時(shí)間就會(huì)越長(zhǎng)。
即使是同樣多的字節(jié)，瀏覽器處理JavaScript也會(huì)比處理等大小的圖片和網(wǎng)頁(yè)字體消耗更高的成本——Tom Dale
相比于JavaScript，處理等字節(jié)的圖片所需要的時(shí)間成本很高(因?yàn)閳D片仍需要解碼!)但是在一般的移動(dòng)設(shè)備上，反而是JS更有可能對(duì)頁(yè)面的交互產(chǎn)生負(fù)面的影響。
(JavaScript字節(jié)和圖像字節(jié)耗費(fèi)的時(shí)間成本不同。圖像通常不會(huì)阻塞主線程，也不會(huì)在解碼和光柵化的時(shí)候阻止接口進(jìn)行交互。然而JS會(huì)因?yàn)榻馕?、編譯和執(zhí)行的時(shí)間消耗阻滯交互性。)
當(dāng)我們說(shuō)解析和編譯的速度變慢的時(shí)候，要注意具體的網(wǎng)絡(luò)端和設(shè)備端的情況，在這里我們針對(duì)的是普通手機(jī)。普通用戶所使用手機(jī)的CPU和GPU速度比較慢，沒(méi)有L2/L3緩存，甚至可能會(huì)有內(nèi)存限制。
網(wǎng)絡(luò)功能和設(shè)備功能并不總是相匹配的。有速度驚人的光纖連接的用戶不一定會(huì)有最好的CPU來(lái)解析和評(píng)估發(fā)送到他們的設(shè)備的JavaScript。反過(guò)來(lái)也是如此…你可能有糟糕的網(wǎng)絡(luò)連接，但卻有快速的CPU。 – Kristofer Baxter，LinkedIn
在JavaScript Start-up Performance一文中，我曾提到過(guò)在低端和高端硬件上解析~1MB解壓縮過(guò)(簡(jiǎn)單)的JavaScript所需要消耗的時(shí)間。市面上的普通手機(jī)和運(yùn)行速度最快的手機(jī)相比，解析/編譯代碼的所用的時(shí)間會(huì)有2-5倍的差距。
(在不同級(jí)別的臺(tái)式和移動(dòng)設(shè)備上解析1MB的JavaScript包(經(jīng)gzip壓縮，大小約為250KB )。當(dāng)分析解析成本時(shí)，我們需要考慮的是解壓后的數(shù)據(jù)量，例如?250KBgzip壓縮過(guò)的JS解壓縮后約為?1MB的代碼。)
那解析/編譯真實(shí)網(wǎng)站的時(shí)間差異又會(huì)是怎樣呢，比如CNN.com網(wǎng)站?
在高端的iPhone 8上解析/編譯CNN網(wǎng)站的JS大約花費(fèi)了4秒，相比于普通手機(jī)(Moto G4)的13秒左右。這可以顯著地影響用戶與CNN網(wǎng)站實(shí)現(xiàn)完全交互的速度。
(蘋果公司的A11仿生芯片和更普通的Android硬件中的Snapdragon 617的解析時(shí)間上的性能比較
這就突出了在普通硬件(比如Moto G4)上測(cè)試的重要性，而不僅僅是在自己恰好有的手機(jī)上測(cè)試?；谧约嚎蛻粼械脑O(shè)備和網(wǎng)絡(luò)條件來(lái)進(jìn)行優(yōu)化是很重要的。
分析可以使你更加深入了解自己真實(shí)客戶訪問(wèn)網(wǎng)站所用的移動(dòng)設(shè)備的級(jí)別和這些設(shè)備CPU/GPU的局限性。
我們真的發(fā)送了太多的JavaScript了嗎?呃…真有可能:)
用HTTP Archive(qian500K站點(diǎn))來(lái)分析移動(dòng)設(shè)備上JavaScript的狀態(tài)時(shí)，我們可以看到，50%的站點(diǎn)需要14秒才能取得交互。這些網(wǎng)站光是用來(lái)解析和編譯JS的時(shí)間就長(zhǎng)達(dá)4秒。
考慮到獲取和處理JS和其他資源所耗費(fèi)的時(shí)間，也就不奇怪用戶可能需要在頁(yè)面可用之前等待一段時(shí)間了。我們絕對(duì)可以在這個(gè)方面做的更好。
從網(wǎng)頁(yè)中刪除不必要的JavaScript可以減少傳輸時(shí)間、CPU密集型解析和編譯以及潛在的內(nèi)存消耗，同時(shí)也有助于加快網(wǎng)頁(yè)的交互速度。
執(zhí)行時(shí)間
不光是解析和編譯會(huì)有時(shí)間成本。執(zhí)行JavaScript(在解析/編譯之后運(yùn)行代碼)也是需要在主線程上進(jìn)行的操作之一。長(zhǎng)的執(zhí)行時(shí)間也會(huì)延遲用戶與你網(wǎng)站的交互時(shí)間。
如果腳本執(zhí)行的時(shí)間超過(guò)了50ms，那么延遲交互的時(shí)間將會(huì)是下載、編譯和執(zhí)行JS所需時(shí)間的總和——Alex Russell
為了解決這個(gè)問(wèn)題，可以將JavaScript腳本分為幾個(gè)小塊來(lái)執(zhí)行，以避免鎖定主線程。探索一下是否可以減少腳本執(zhí)行過(guò)程中進(jìn)行中工作量的可能性。
減少JavaScript交付成本的模式
當(dāng)你試圖降低JavaScript解析/編譯和網(wǎng)絡(luò)傳輸所用時(shí)間時(shí)，類似于基于路由分塊和PRPL這些模式也會(huì)有用。
PRPL是一種通過(guò)激進(jìn)的(aggresive)代碼分割和緩存來(lái)優(yōu)化交互性的模式：
為了能將PRPL的影響以視覺(jué)化方式表現(xiàn)出來(lái)。
我們用V8引擎中的Runtime Call Stats分析了流行移動(dòng)網(wǎng)站和progressive Web Apps(PWA)的加載時(shí)間。正如我們所看到的，解析部分(用橙色表示)是很多網(wǎng)站頁(yè)面加載時(shí)產(chǎn)生顯著時(shí)間消耗的部分。
Wego網(wǎng)站就使用了PRPL來(lái)保持較低的路由解析時(shí)間，讓頁(yè)面交互得以快速的進(jìn)行。以上的很多站點(diǎn)都試圖采用代碼分割和性能預(yù)算來(lái)降低JS的消耗。
JavaScript的其他消耗
JavaScript還可以通過(guò)其他方式來(lái)影響頁(yè)面性能：
- 存儲(chǔ)。頁(yè)面可能會(huì)因?yàn)槔厥?GC，garbage colleciton)，頁(yè)面可能會(huì)出現(xiàn)畫面中斷卡頓(junk)和暫停。因?yàn)楫?dāng)一個(gè)瀏覽器回收內(nèi)存的時(shí)候，JS的執(zhí)行也會(huì)被中止，所以經(jīng)常回收垃圾的瀏覽器會(huì)比我們想象中的更頻繁地中止JS的執(zhí)行。在這種情況下，可以通過(guò)避免內(nèi)存溢出和頻繁內(nèi)存回收來(lái)保持頁(yè)面的流暢。
- 在運(yùn)行時(shí)，長(zhǎng)時(shí)間的運(yùn)行JavaScript會(huì)阻塞主線程，導(dǎo)致頁(yè)面沒(méi)有響應(yīng)。這種情況下，可以將腳本的工作量分成多個(gè)小的板塊(具體可用requestAnimationFrame()或者requestIdleCallback()進(jìn)行任務(wù)調(diào)度)來(lái)執(zhí)行，以此減少頁(yè)面響應(yīng)的問(wèn)題。
Progressive Bootstrapping
很多網(wǎng)站將優(yōu)化內(nèi)容可視性作為保證交互性所需代價(jià)的一部分。為了在JavaScript有大體積包體時(shí)改善首屏性能，開(kāi)發(fā)人員有時(shí)會(huì)先用服務(wù)器端渲染幫助客戶提前看到頁(yè)面內(nèi)容，然后再在JavaScript最終執(zhí)行完成后“升級(jí)”附加上事件處理程序。
但是值得注意的是，這樣做也是有代價(jià)的。你1)通常會(huì)發(fā)送一個(gè)更大的HTML響應(yīng)來(lái)增加交互性，2)在一段時(shí)間內(nèi)，用戶會(huì)處在一半的頁(yè)面交互體驗(yàn)缺失的奇怪狀況下，直到JavaScript處理完成。
Progressive Bootstrapping或許會(huì)是一個(gè)更好的處理方式。瀏覽器請(qǐng)求一個(gè)最少化的功能頁(yè)面(僅由當(dāng)前路由所需要的HTML/JS/CSS組成)。當(dāng)有更多的資源請(qǐng)求的時(shí)候，應(yīng)用程序則可以懶加載(lazy-load)和解鎖更多的功能。
Progressive Bootstrapping visual by Paul Lewis
僅加載可視區(qū)域內(nèi)的代碼是其中的關(guān)鍵。PRPL和Progressive Bootstrapping模式均可以用來(lái)實(shí)現(xiàn)這一點(diǎn)。
結(jié)論
傳輸腳本的大小對(duì)低端網(wǎng)絡(luò)至關(guān)重要，而解析時(shí)間對(duì)于CPU有局限性的設(shè)備很重要。降低傳輸腳本的大小和減少解析消耗時(shí)間是有必要的。
有團(tuán)隊(duì)發(fā)現(xiàn)采用嚴(yán)格的性能預(yù)算可以成功降低他們JavaScript的傳輸和解析/編譯的時(shí)間消耗。
(考慮一下在我們所做的架構(gòu)決策下，JS有多大的空間可以讓我們的應(yīng)用程序具有邏輯)
如果你正在建一個(gè)用于移動(dòng)設(shè)備上的站點(diǎn)，請(qǐng)盡可能的在代表性硬件上開(kāi)發(fā)，保持較低的JavaScript解析/編譯的時(shí)間成本，并采用性能預(yù)算來(lái)確保團(tuán)隊(duì)對(duì)自身JavaScript的成本關(guān)注。
網(wǎng)站標(biāo)題：關(guān)注JavaScript的成本
文章來(lái)源：http://www.5511xx.com/article/dhjscip.html
