JavaScript在移動端網站運行慢？咋辦？

時間 2019-11-30

原文原文鏈接

做者介紹：Addy osmani html

就任谷歌Chrome團隊，致力於讓網站運行速度更快，他參與的項目包括——lighthouse前端

隨着移動互聯網快速發展，移動端網站的頁面效果也愈來愈絢，可是交互體驗或多或少有些「遲鈍」？這是爲啥呢？vue

首先JavaScript運行在手機瀏覽器上會產生不小的系統開銷，因爲這個問題存在，Addy osmani 將會帶着你們探討移動端網站的腳本問題，讓其在大多數手機瀏覽器上運行更快，更輕。 java

咱們在構建交互式網站天然少不了JavaScript, 爲了達到更好的交互，咱們讓用戶瀏覽器加載了太多的JavaScript腳本。不知道你們是否有這樣的瀏覽體驗：咱們在手機瀏覽器上刷網頁，點擊連接或者滑動頁面時，網頁一點反應都沒。這種經歷，想必你們都有，由於對於手機瀏覽器來講，運行加載JavaScript會消耗不小的系統資源，所以延遲了用戶的交互響應，今天我將會給你們介紹一些有效的方法策略，提高用戶在手機端的使用體驗。react

太多的「交互」，讓網站更臃腫！

當你的用戶用手機訪問你的網站時，你的網站讓用戶的瀏覽器加載了大量的文件，其中不少是腳本文件。也許你爲了方便開發或者爲了更炫的效果，引入了腳本庫或插件庫，歷來沒有檢查確認到底加載了多少腳本，體積有多大？加載的腳本是否對用戶有用？對於咱們多說前端客來講，咱們是如此的喜歡JavaScript，可是咱們不得不正視它會消耗不小的系統資源。webpack

很多熱門的網站，向用戶的瀏覽器發送了大於1MB的腳本文件。只有爲數很少的網站進行了腳本文件壓縮，使腳本體積大小降到350KB左右，那些未壓縮腳本的網站，若是腳本超過1MB大小，您的用戶至少須要等待14秒的時間才能正常使用你的網站。（部分熱門移動網站腳本加載分析報告：https://beta.httparchive.org/reports/loading-speed）git

爲何這麼慢？用戶大多數是在不穩定的移動網絡加載你的網站，腳本加載完了，須要手機CPU進行運行處理。github

如下是目前大多數網站存在的問題：web

使用了用戶界UI框架（例如bootstrap）
客戶端框架或交互依賴框架（React,vue）
Polyfills（可是現代瀏覽器並不須要）
未壓縮的腳本工具庫（例如moment.js）

隨着需求的增長，腳本的數量也在增長，體積也再不斷變大，所以頁面運行的時間也愈來愈長！npm

現代網頁加載時...

一個網頁加載時，對於用戶來講：網頁是否還在加載？加載的內容是否有用？功能是否能用？當網頁的內容一點點呈現給用戶時：導航顯示一部分出來，服務器是否還在正常發送內容？當文本和其餘非可見的內容，是否是用戶須要的，內容加載完了，用戶可否正常的點擊和滑動？

所謂的交互式頁面，必須快速響應用戶的輸入，所以javaScript腳本應該快速響應用戶的交互，不管用戶點擊連接仍是滾動瀏覽頁面，用戶都須要頁面快速響應本身的行爲。

爲了最大化的知足產品業務需求，您可能要求用戶的客戶端運行不少事件，因爲JavaScript語言的特色，主線程上的事件延遲了交互元素的呈現，對於許多公司來講縮短交互時間是一個不小的挑戰。

什麼纔是好的交互目標？

咱們Chrome團隊認爲，在大多數中等手機設備（https://calendar.perfplanet.com/2017/time-to-interactive-measuring-more-of-the-user-experience/），3G或4G的網絡環境下，5秒內完成用戶的交互響應，這就是良好的交互目標。你可能會說：咱們的用戶都是用高端的手機和使用快速的網絡。可是咱們所謂的用戶呢？——在使用「快速」的咖啡店的共享wifi或移動的車箱裏訪問咱們的網站，他們的手機實際只能獲取2G或3G的速度。

哪些網站開始減小腳本的體積，縮短了用戶的交互時間？

Pinterest.com 將原先的腳本從2.5MB減小至200KB如下，交互時間從23秒減小至5.3秒（https://medium.com/dev-channel/a-pinterest-progressive-web-app-performance-case-study-3bd6ed2e6154），正式因爲這個改進，網站的收入增加了44%，註冊量增長753％，移動網絡用戶的活躍度增加了103%（https://medium.com/@Pinterest_Engineering/a-one-year-pwa-retrospective-f4a2f4129e05）；autotrader網站將腳本的體積減小了56%，縮短了50%的交互時間。（engineering.autotrader.co.uk/2017/07/24/…）。

對於一個移動網站時，不只要考慮腳本的體積大小，響應時間，還要考慮移動變化不穩定的手機網絡和大多數終端手機的硬件環境。

爲何JavaScrip的代價如此之高？

咱們都清楚一個請求發送至服務器後，服務器會逐步返回一些HTML內容，在逐步解析渲染DOM時發現標記不一樣的資源（CSS,JavaScript）以及圖片資源，而後完成這些文件的下載和處理。

若是要讓JavaScript快速相應用戶的交互，咱們必需要讓腳本快速的加載和編譯執行，因爲JavaScript須要快速完成編譯才能執行用戶的響應，這個過程必然會影響延遲用戶的交互體驗。

還有一點須要記住，網絡上同等的資源，消耗的系統資源卻不一樣。一個200KB的圖片絕對不等於一個200KB的腳本消耗的資源，下載這些資源時間可能相同，可是消耗的資源成本卻不同。

不一樣類型的手機

現實就是這樣，並不是每一個人都用得起高端手機，還有大部分用戶使用中低端手機。因爲中低端手機CPU,GPU的限制，處理JavaScript等資源的時間也不一樣。所以咱們應該在真實的手機環境和網絡環境下測試相當重要。檢查分析您的用戶訪問行爲相當重要，若是您沒法購買太多中低端手機進行測試，你可使用這個在線網站工具WebPageTest（webpagetest.org/easy），進行在線測試。（如下是小編前端達人www.qianduandaren.com的測試效果）

瞭解你的網站受衆十分重要，並不是每一個網站都要知足低端手機在2G的環境下表現良好，你應該保證你的大多數用戶快速加載你的網站。

如何減小JavaScript腳本的發送

Code splitting（代碼分割）技術——將會幫你拆解大的JavaScript腳本文件，實現了腳本的按需加載（lazy-load）。這樣有效的避免了將單個「main.js」整個站點的腳本文件發送給用戶。

將代碼引入站點的最佳方法是動態import()，相關介紹請點擊查看developers.google.com/web/updates…，下面這個例子使咱們常見的靜態引入方法：

import {add} from './math' 
console.log(add(30, 15)); 複製代碼

若是使用動態import()，咱們能夠按需加載引入math腳本文件，例如實現點擊一個按鈕動態引入math腳本

const btn= document. getElementByld('load); btn.addEventListener('click',()=>{ import('./math').then(math =>{ console.log(math.add(30, 151)); }); }); 複製代碼

使用webpack構建的項目也能很方便的實現按需加載，具體如何使用能夠點擊查看www.jianshu.com/p/b3b8fb8a2…這篇文章。代碼分割同時能夠應用在路由加載、組件加載、頁面加載等方面，如下分別是使用React,Vue,Angular使用Code splitting的使用指南：

React——medium.freecodecamp.org/code-splitt…
VueJS——router.vuejs.org/zh/guide/ad…
Angular——angular.io/guide/lazy-…

若是你正在使用React,我很高興向您推薦推薦React Loadable(github.com/jamiebuilds…),實現了動態高效的加載組件，如下代碼是咱們使用靜態方法引入gallery組件：

import GalleryComponent from ‘./GalleryComponent’; 
const My Component=()=>( 
<GalleryComponent/> 
); 複製代碼

使用React Loadable後，咱們改下上面的代碼：

import Loadable from 'react-loadable’; const LoadableGallerycomponent= Loadable({ loader: ()= >import('./GalleryComponent'), loading: ()=><div>Loading...</div>, }); const MyComponent=()=> <LoadableGalleryComponent/> ); 複製代碼

最近許多大型團隊正在使用Code splitting方法改寫重寫他們的手機端網站，並取得巨大的成果。好比Twitter他們背後優化的故事——blog.twitter.com/engineering…，Tinder背後優化的故事——medium.com/@addyosmani…，他們都經過此項技術將交互時間縮短了50%。

Next.js[react](github.com/zeit/next.j…),Preact CLI(github.com/developit/p…) ,PWA starter kit(github.com/polymer/pwa…) 這些框架設計之初的首要目標就是解決移動端網站的性能問題，讓代碼快速加載響應用戶的交互。

值得慶幸的事情，JavaScript生態爲咱們提供了分析打包後全部組件與組件的依賴關係的可視化工具，幫助咱們分析。好比：

Webpack Bundle Analyzer( www.npmjs.com/package/web…)
Source Map Explorer(github.com/danvk/sourc…)
Bundle Buddy (github.com/samccone/bu…)

優化，監控

若是你不肯定你的JavaScript性能是否有問題，你可使用Chrome提供的Lighthouse——是一個Google開源的自動化工具，主要用於改進網絡應用（移動端）的質量。目前測試項包括頁面性能、PWA、可訪問性（無障礙）、最佳實踐、SEO。Lighthouse會對各個測試項的結果打分，並給出優化建議，這些打分標準和優化建議能夠視爲Google的網頁最佳實踐。

還有一件值得你監控和關注的事情，就是檢查有沒有將未使用的代碼發送給用戶, code coverage(developers.google.com/web/updates…)——谷歌瀏覽器開發者工具中的代碼覆蓋率面板，此面板內會告訴你哪些代碼未使用，哪些又是使用了的。這樣能夠精簡掉未使用的代碼來減少頁面的大小。

這些工具對於識別須要分割代碼及哪些須要延長加載非關鍵腳本是很是有價值的，慶幸的是有一套標準的評估指標指引優化——timkadlec.com/2014/11/per…

設計合理的優化指標

定義一個可衡量可測試的優化目標相當重要，有個標準的行爲指南有助指引整個團隊圍繞着目標不斷的改善用戶交互體驗。指標主要包含如下幾個方面：

里程碑時間——頁面加載完，具有響應用戶的時間。
數量指標——JavaScript腳本大小，多少文件請求數，圖片數量和大小
基於規則的指標分數——咱們能夠經過專業的工具Lighthouse或WebPageTest等工具進行相關的評分。

績效指標對於團隊來講，最大的挑戰並非技術而是公司的文化，咱們須要開會不斷的圍繞目標進行討論，向業務運營團隊諮詢他們指望的目標並接受各類相關質疑，同時向工程技術人員傳達會議目標讓其解決瓶頸問題，雖然過程有些痛苦，可是對項目的推動仍是有很大的幫助。

那麼有什麼樣的工具可以幫助咱們決策制定合理化目標並生成可視化的報告呢，你可使用 lighthouse CI project （github.com/ebidel/ligh…），Calibre（calibreapp.com/），treo（treo.sh/），speedcurve(speedcurve.com)