23年通天塔搭建頁前端性能優(yōu)化階段分享

前言

通天塔搭建頁項(xiàng)目是用來搭建各類活動(dòng)頁面，比較老且業(yè)務(wù)復(fù)雜的項(xiàng)目，可優(yōu)化點(diǎn)還是非常多的。今年側(cè)重對運(yùn)營頁首屏加載的性能優(yōu)化，在保證系統(tǒng)穩(wěn)定可控、需求持續(xù)迭代前提下，最終提升了58.8%速度。

回顧一年的不斷探（cai）索（keng），得出的感受的是：

選擇大于努力了，努力的方向不對，想取得成果就會(huì)越來越費(fèi)勁，事倍功半；方向選對了，事半功倍。

性能優(yōu)化是長期的工程，需要優(yōu)先確立正確的分析方法，真正且更早地找出系統(tǒng)的癥結(jié)所在，而不是想當(dāng)然或者僅停留于表面現(xiàn)象來下判斷。

市面上有很多性能優(yōu)化方案，數(shù)不勝數(shù)，但如果開始就只是模仿一些邊邊角的優(yōu)化，雖然也會(huì)略有效果，但不一定能給系統(tǒng)解決核心卡頓問題，不能給系統(tǒng)帶來質(zhì)的提升，甚至到后面優(yōu)化效果越來越差，這些優(yōu)化可能會(huì)沖突、可能變成負(fù)優(yōu)化。而且如果不去優(yōu)先分析核心的問題，可能就會(huì)一直忽視核心問題，導(dǎo)致系統(tǒng)長期處于低效低體驗(yàn)的狀態(tài)，隨著業(yè)務(wù)復(fù)雜變得越來越卡。

常見分析工具

1，網(wǎng)絡(luò)分析功能 Network

分析不同類型資源大小、優(yōu)先級、時(shí)間細(xì)分?jǐn)?shù)據(jù)、請求和響應(yīng)詳情、緩存利用情況。還可以模擬不同網(wǎng)絡(luò)環(huán)境。

https://developer.chrome.com/docs/devtools/network?hl=zh-cn

從瀑布流Waterfall比較直觀看出，資源等待時(shí)間、加載時(shí)間、加載時(shí)機(jī)，對頁面整體加載有一個(gè)總覽。

2，性能面板 Performance

分析網(wǎng)頁在運(yùn)行時(shí)（而不是加載）時(shí)的性能。具體分析頁面每個(gè)階段哪些方法在執(zhí)行，哪些資源在加載，很容易看出哪里在阻塞。

也可以用來設(shè)置不同的cpu和網(wǎng)絡(luò)環(huán)境。由于開發(fā)者電腦一般性能比較好，模擬較差性能和網(wǎng)絡(luò)也是有必要的。

https://developer.chrome.com/docs/devtools/performance?hl=zh-cn

官網(wǎng)給出分析順序是，

1）先看 摘要Summary 標(biāo)簽頁，分析到底是加載、執(zhí)行腳本、渲染、繪制哪一個(gè)最占時(shí)間，再去決定主要優(yōu)化方向。

如果是加載速度慢，再去分析網(wǎng)絡(luò)、資源大小、加載優(yōu)先級、緩存等。

如果是執(zhí)行腳本慢，再去分析代碼執(zhí)行順序，看哪些任務(wù)執(zhí)行時(shí)間長或者執(zhí)行次數(shù)過多。

如果是渲染速度慢，還要具體分析，

（a）渲染dom太多則可以考慮虛擬滾動(dòng) ；

（b）圖片的原因則考慮優(yōu)化圖片格式、壓縮圖片大小、圖片懶加載、低質(zhì)量圖片過渡、圖片異步解碼；

（注：優(yōu)化圖片格式是指選擇壓縮率高、解碼速度快、同時(shí)畫質(zhì)良好的圖片格式）

（c）重新計(jì)算樣式導(dǎo)致強(qiáng)制自動(dòng)重排，需要盡量避免大型、復(fù)雜的布局和布局抖動(dòng)；

https://web.dev/articles/avoid-large-complex-layouts-and-layout-thrashing?utm_source=devtools&hl=zh-cn#avoid-forced-synchronous-layouts

還有其他方式可專注優(yōu)化可視區(qū)域的渲染。

2）再展開主要Main部分。開發(fā)者工具會(huì)向您顯示主線程上的活動(dòng)隨時(shí)間變化的火焰圖。x 軸表示一段時(shí)間內(nèi)的記錄。每個(gè)條形都代表一個(gè)事件。橫條越寬，表示事件用時(shí)越長。y 軸表示調(diào)用堆棧。如果您看到事件相互堆疊，則表示上層事件導(dǎo)致了下層事件。

3）放大上方Overview，找到任務(wù)右上角的紅色三角形，定位到耗時(shí)較長的任務(wù)，再定位到具體的方法中。

對于長任務(wù)，官網(wǎng)還有進(jìn)一步優(yōu)化建議：

https://web.dev/articles/optimize-long-tasks?utm_source=devtools&hl=zh-cn

3，打包分析 webpack-bundle-analyzer

主要分析js打包，查看具體打包情況,考慮如何對體積過大的包“瘦身”。

常用手段有懶加載、全局引入第三方插件、刪除冗余包、刪除重復(fù)打包。

webpack bundle analyzer zoomable treemap

4，代碼覆蓋率 Coverage

可以分析不同資源使用率情況。對于低使用率且較大體積的文件，考慮懶加載、移除無效代碼。

5，燈塔面板 Lighthouse

Lighthouse 是 Google 開發(fā)的一款自動(dòng)化的開源工具，用于提升網(wǎng)頁質(zhì)量。您可以針對任何公開網(wǎng)頁或需要身份驗(yàn)證的網(wǎng)頁運(yùn)行它。它包含對性能、無障礙功能、漸進(jìn)式 Web 應(yīng)用、搜索引擎優(yōu)化 (SEO) 等方面的審核。

https://developer.chrome.com/docs/lighthouse/overview?hl=zh-cn

主要是給頁面綜合評分，還有FCP、LCP、TBT、CLS分析。如果評分還有不足的地方，那就還有較大優(yōu)化的空間。

也可以像 webpack-bundle-analyzer 裝在本地運(yùn)行。

主要優(yōu)化方向

1，加快資源請求速度

2，減少請求資源大小

3，減少請求資源數(shù)量

4，優(yōu)化代碼邏輯

5，優(yōu)化業(yè)務(wù)邏輯

1，加快請求資源速度

1）充分利用緩存

個(gè)人體驗(yàn)感覺，緩存帶給頁面性能提升是最明顯的。

資源類：http緩存、cdn緩存、service worker；

數(shù)據(jù)類：cookie、localStorage、sessionStorage、indexDB；

像base64的圖片可以當(dāng)數(shù)據(jù)類存儲(chǔ)。

還有函數(shù)內(nèi)部的緩存；

2）http相關(guān)優(yōu)化

http/https1.0、1.1版本下需要減少同域名下的請求

不同瀏覽器支持并發(fā)的情況不一樣，比如chrome瀏覽器http/https1.0、1.1版本下有并發(fā)請求限制，在同一域名情況下：

- 同一get請求的并發(fā)數(shù)是1，即只有上一個(gè)請求結(jié)束，才會(huì)執(zhí)行下一次請求，否則即在隊(duì)列中等待請求；

- 不同的get/post的請求的并發(fā)數(shù)量是6個(gè)，當(dāng)達(dá)到6個(gè)時(shí)，其余的在隊(duì)里中等待請求；

所以需要把資源分布放在多個(gè)域名下，類似cdn1.jd.com，cdn2.jd.com，cdn3.jd.com。

如果有條件的盡量升級http2或者h(yuǎn)ttp3，可實(shí)現(xiàn)多路復(fù)用：通過該功能，在一條連接上，您的瀏覽器可以同時(shí)發(fā)起無數(shù)個(gè)請求，并且響應(yīng)可以同時(shí)響應(yīng)。另外，多路復(fù)用中支持了流的優(yōu)先級（Stream dependencies）設(shè)置，允許客戶端告知服務(wù)器最優(yōu)資源，可以優(yōu)先傳輸。

升級后還有其他優(yōu)點(diǎn)，比如也會(huì)對請求頭壓縮，進(jìn)一步提升請求速度。

3）預(yù)解析資源 Prefetch

html代碼里加入這樣的 link 標(biāo)簽實(shí)現(xiàn)預(yù)解析，類似以下：

<link rel="dns-prefetch" >
<link rel="dns-prefetch" >
<link rel="dns-prefetch" >

普遍來說合理的dns prefetching能對頁面性能帶來50ms ~ 300ms的提升。

4）預(yù)加載資源 Preload

比如字體文件

5）所有資源走CDN

不止是靜態(tài)資源，有條件的話，盡量讓所有資源都走CDN，有效提升加載速度，減少白屏?xí)r間。

2，減少請求資源大小

首先，我們先用分析下哪些模塊代碼比較大，需要優(yōu)化。

1）盡量按需加載模塊，盡量避免整個(gè)包都引入

比如：

（a）一些比較明顯的全局引入，代碼里存在的*引入。

import * as xxxx-ui from 'xxxx-ui'

const Button = xxxx-ui['Button']

最好都改成按需加載，確保打包時(shí)候不會(huì)把整個(gè)庫都打進(jìn)去。

import { Button } from 'xxxx-ui'

只要支持基于 ES modules 的 tree shaking，就會(huì)有按需加載的效果。

不過有的引入比較隱蔽，不容易直接發(fā)現(xiàn)，只有進(jìn)行打包分析后才能實(shí)際發(fā)現(xiàn)多種情況打包了多余的包。

（b）引入子包寫法不正確

比如引入加密包不正確，引入導(dǎo)致打包體積很大。

import crypto from 'crypto'
const str = 'xxxxxxxxx'
const sign = crypto.createHash('md5').update(str).digest('hex')

實(shí)際只用了crypto的md5方法，但卻把整個(gè)crypto包和其依賴的包都打包進(jìn)代碼里。

后續(xù)改成只引入crypto的md5方法就能起到一樣的效果。

import md5 from 'crypto-js/md5' 
const str = 'xxxxxxxxx'
const sign = md5(str).toString()

就可以把上面這個(gè)js里絕大部分的代碼都省去了，最后把這個(gè)js在Gzipped下從190KB減少到3KB。

類似的lodash也有這樣的情況，通過改變寫法，也可以改善打包大小，在Gzipped下從幾十KB減少到幾KB。

只需改寫下，單個(gè)引入lodash里的方法

比如，antd3.0的組件引用也有類似問題，需要改寫引用代碼按需加載組件；

比如，僅修改通天塔列表cms項(xiàng)目里所有的data-kit引入方法，就讓整體打包js體積縮小了50%；

（c）引入某個(gè)包的樣式文件也有可能導(dǎo)致整個(gè)包都打包進(jìn)來

比如打包分析和排查代碼時(shí)，發(fā)現(xiàn) braft-editor這個(gè)編輯器實(shí)際沒有使用了，但引入樣式的代碼沒注釋掉，導(dǎo)致整個(gè)braft-editor包都被打包進(jìn)來。后續(xù)注釋掉，直接節(jié)省Gzipped下114KB體積。

// 引入編輯器樣式
import 'braft-editor/dist/index.css'

??注意：如果發(fā)現(xiàn)按照上述幾種方法，修改了引入方法，但打包分析里依然還是完整引入，那么這里情況就會(huì)比較復(fù)雜，只能上網(wǎng)找類似問題了。有可能是想不到的其他地方隱晦全量引入，也有可能是寫法還是不對，也有可能是打包配置不對，甚至有可能就是那個(gè)包的版本實(shí)際不支持按需引入。

2）不重要的代碼模塊懶加載（dynamic import）

比如 React.lazy，

常規(guī)引入：

import Header from './Component/Header'
<Header />

懶加載處理后：

const Header = React.lazy(() => import(/* webpackChunkName:"Header" */ './Component/Header'))
<React.Suspense fallback="">
    <Header />
</React.Suspense>

fallback可以為空，也可以用一些Spin（加載中）、Skeleton（骨架）或者簡化業(yè)務(wù)組件來占位、過渡。

??注意1：還是不能濫用，主要針對低優(yōu)先級或者體積過大的模塊、組件。

??注意2：實(shí)際發(fā)現(xiàn)setTimeout也可以懶加載一些文件，不過不太推薦使用。

setTimeout(() =>  import(/* webpackChunkName: 'xxx'*/ './xxx.less' ), 500)

3）使用更精簡的代碼或者包替代原先的包

（a）原生方法或者手寫方法（保證性能的前提下）

比如，在安全性不重要的場景下，可以只用原生的編碼方法atob、btoa或者再封裝的方法來替代加密包的方法；

（b）更小的包

比如，使用 Day.js 替換 momentjs 優(yōu)化打包大小，但是打包多一個(gè)配置，這是antd里介紹的配置；

4）不重要的插件改成全局引入第三方插件

根據(jù)需要適時(shí)請求，插件方法掛在window全局下，避免產(chǎn)生直接依賴。

同時(shí)給script標(biāo)簽加上 async 或者 defer屬性，避免腳本阻塞頁面。

（從表現(xiàn)形式上來說，async 的優(yōu)先級比 defer 高，也就是如果同時(shí)存在這 2 個(gè)屬性，那么瀏覽器將會(huì)以 async 的特性去加載此腳本。）

<script src="https://cdn1.jd.com/xxx.js" async></script>

比如這個(gè)生成excel文件的插件，打包在項(xiàng)目里就會(huì)很重。放在cdn上，不隨項(xiàng)目打包版本更新，每次加載后還能有較長緩存時(shí)間。

??注意1：有的時(shí)候，確實(shí)把第三方包抽出來了，但是調(diào)用方法時(shí)，還是使用import引用了，這時(shí)可能存在第三方包沒加載導(dǎo)致的import報(bào)錯(cuò)，此時(shí)需要嚴(yán)格控制時(shí)機(jī)。個(gè)人建議非關(guān)鍵的包不輕易使用webpack的externals，一般就掛在window下，不產(chǎn)生直接依賴，可以等較晚時(shí)候直接調(diào)用（建議調(diào)用時(shí)，trycatch包一下，調(diào)用出錯(cuò)就看下面兜底方案）；

??注意2：第三方的cdn，可能會(huì)在有的區(qū)域、有的網(wǎng)絡(luò)加載不出來資源。這時(shí)可能要考慮加載失敗時(shí)，重新加載或者切換備用的下載鏈接。包括上面的懶加載，都有資源加載失敗的情況。對于慢網(wǎng)和cdn故障等情況，要盡可能做多重兜底；

推薦一個(gè)兜底方案的鏈接： https://zhuanlan.zhihu.com/p/459698050

5）壓縮資源大小

（a）壓縮圖片大小；

- 直接壓縮工具壓縮；

- 對象存儲(chǔ)（OSS）壓縮或者裁剪圖片；

- 版本較高瀏覽器使用webp格式圖片；

（b）Gzip壓縮（Gzip 對一般純文本內(nèi)容可壓縮到原大小的 40％）；

- nginx服務(wù)器中配置；

- http2頭部壓縮；

（c）Brotli壓縮（Brotli 的性能相比 Gzip 提高了 17-25%）；

??注意：使用 Brotli 壓縮所有資源非常耗費(fèi)計(jì)算資源和時(shí)間，在最高壓縮級別下，會(huì)讓服務(wù)器等待動(dòng)態(tài)資源。服務(wù)器開始發(fā)送響應(yīng)所花費(fèi)的時(shí)間會(huì)抵消文件大小減少帶來的任何潛在收益，也就是說會(huì)延長 TTFB 的時(shí)間。

（d）第三方插件都使用壓縮版的；

（e）壓縮html文件（包含其中內(nèi)聯(lián)的script、style代碼）；

比如，配置 HtmlWebpackPlugin 的 minify。

6）放棄對老瀏覽器支持

@babel/polyfill為了彌補(bǔ)低版本瀏覽器中缺失的特性，會(huì)導(dǎo)致打包體積變大。就算配置按需注?（useBuiltIns: "usage"），還是會(huì)比較大。有條件還是早點(diǎn)放棄低版本瀏覽器。

7）刪除多余的語言包

多數(shù)語言包是不需要被打包進(jìn)來的，可以打包分析檢查一遍。

8）字體文件壓縮

一個(gè)完整字體文件都有幾MB，而一般項(xiàng)目里只有少數(shù)文本需要用到特殊字體，可以利用類似Fontmin把需要的文字單獨(dú)拎出來。

如果字?jǐn)?shù)較少也考慮圖片替代，和其他圖片合并。

9）打包移除多余代碼

（a）Tree Shaking 刪除多余代碼

webpack3可以配置，webpack4+的mode: procution下自帶。其他打包工具也有支持。

??注意1：使用 ES2015 模塊語法（即 import 和 export）。

??注意2：確保沒有編譯器將 ES2015 模塊語法轉(zhuǎn)換為 CommonJS。比如lodash就是基于commonjs，所以才有上文《減少請求資源大小》中把整個(gè)lodash包都打進(jìn)去的情況。

??注意3：在項(xiàng)目的 package.json 文件中添加 "sideEffects" 屬性。

https://webpack.docschina.org/guides/tree-shaking/

（b）移除生產(chǎn)環(huán)境的 console.log、debugger、注釋

new UglifyJsPlugin({
    uglifyOptions: {
        compress: {
            drop_console: true,
            drop_debugger: true
        }
    }
})

10）生產(chǎn)環(huán)境選擇適當(dāng)source-map方案，控制打包體積

根據(jù)實(shí)際情況，需要考慮源代碼要不要隱藏，調(diào)試要不要更友好。

3，減少請求資源數(shù)量

1）js類

合并js請求：配置webpack里splitChunks的cacheGroups，把必用的公共依賴打包到一起，類似：

2）圖片類

（a）多個(gè)圖片合并成雪碧圖；

（b）圖標(biāo)類圖片盡量使用矢量圖標(biāo)庫iconfont（盡量按需配置、按需打包）；

（c）可css、svg繪制的，盡量用css、svg實(shí)現(xiàn)；

（d）非可視區(qū)域的圖片懶加載；

比如利用loading屬性

3）埋點(diǎn)或者不緊急不重要的上報(bào)延遲發(fā)送

埋點(diǎn)的信息，可以先全局存起來，等頁面基本加載完成后，再加載埋點(diǎn)插件，上報(bào)埋點(diǎn)信息。減少首屏情況下，發(fā)送大量埋點(diǎn)上報(bào)。

4，優(yōu)化代碼邏輯

1）業(yè)務(wù)代碼邏輯

（a）有些數(shù)據(jù)會(huì)非常大，盡量分頁優(yōu)先請求或者加載渲染涵蓋可視區(qū)域范圍前幾個(gè)、前十幾個(gè)，讓首屏的展示速度更快一點(diǎn)，后續(xù)再用完整數(shù)據(jù)覆蓋或者增量渲染；

（b）非權(quán)限類的請求可以放在更早的位置發(fā)出，非阻塞性的請求可以先請求再等較晚時(shí)候處理邏輯，業(yè)務(wù)優(yōu)先級低的請求可以放在頁面渲染完成以后發(fā)出；

（c）不同優(yōu)先級的組件，可以分不同階段加載、處理邏輯，讓關(guān)鍵模塊優(yōu)先渲染、頁面整體過渡效果更好；

（d）如果存在前置的頁面，可以在前置的頁面空閑時(shí)間提前加載后續(xù)頁面的數(shù)據(jù)，甚至是資源；

（e）復(fù)雜的渲染和數(shù)據(jù)處理，也可以考慮遷移到服務(wù)端來做；

（f）全局引入的第三方插件如果有業(yè)務(wù)場景限制，可以按需動(dòng)態(tài)加載，而不是每次加載所有第三方插件。理論上，其他代碼也可以這樣處理，只是同一路由下，有一定難度，比如服務(wù)端按需渲染。

2）通用代碼邏輯

（a）循環(huán)、遞歸嵌套層級太深太多的話很容易造成卡頓；

（b）循環(huán)使用時(shí)，確認(rèn)是否可以提前中斷循環(huán)，而不是把每個(gè)循環(huán)都走完；

（b）有的方法比較耗費(fèi)性能，類似深拷貝、字符串拼接，注意使用次數(shù)；

（c）檢視下手寫的方法是否可以用lodash等成熟庫的方法替代，可能性能更好；

（d）不同模塊里相同或者相似的代碼，提取成公共方法或者組件；

（e）監(jiān)聽器、計(jì)時(shí)器最好控制數(shù)量，配套退出機(jī)制，及時(shí)清除；

（f）高頻觸發(fā)事件，最好用防抖和節(jié)流；

以上都可以用性能分析（Performmance）、打印埋點(diǎn)、大量數(shù)據(jù)驗(yàn)證優(yōu)化效果，可以適當(dāng)評估實(shí)際性能差異，再做取舍。

------------------------------------------------------分割線----------------------------------------------------------

（以上都是正常的性能優(yōu)化，下面試圖換個(gè)角度）

5，優(yōu)化業(yè)務(wù)邏輯

一個(gè)成熟項(xiàng)目應(yīng)該是，由合理產(chǎn)品規(guī)劃、穩(wěn)定技術(shù)架構(gòu)、統(tǒng)一設(shè)計(jì)交互組成的。

這三個(gè)方面，都應(yīng)該是優(yōu)化項(xiàng)目的方向，而不是單純技術(shù)思路。

對于大部分項(xiàng)目，其實(shí)已經(jīng)做過或多或少的優(yōu)化，但可能依然有卡頓。

對于大部分文章，其實(shí)主要集中于純技術(shù)，也都很少去思考產(chǎn)品規(guī)劃是否合理、業(yè)務(wù)邏輯是否合理。

對于大部分開發(fā)，其實(shí)也是更關(guān)心如何更好實(shí)現(xiàn)技術(shù)，很少參與產(chǎn)品規(guī)劃和設(shè)計(jì)交互。

技術(shù)可以解決問題，但是不是唯一途徑。

單個(gè)頁面承載功能是有限的，首屏加載的資源和數(shù)據(jù)也是有限的，普通用戶的網(wǎng)絡(luò)和設(shè)備性能也是有限的。

可以考慮以下點(diǎn)：

（a）針對大多數(shù)用戶使用習(xí)慣，優(yōu)先提供簡化易懂易用的常用交互，同時(shí)把專業(yè)垂直復(fù)雜的冷門交互單獨(dú)拎出來；

（b）有的業(yè)務(wù)模塊邏輯非常重的，可以獨(dú)立出來，或者拆分成多級、多個(gè)模塊；

（c）對于功能繁雜的頁面，應(yīng)該把不重要的業(yè)務(wù)模塊遷出、收起、延后展示；

（d）通過埋點(diǎn)確認(rèn)沒人使用的業(yè)務(wù)模塊，應(yīng)該考慮下線；

（e）低使用頻率的功能控制加載次數(shù)，類似版本更新功能，每次打開頁面都會(huì)請求最新配置接口數(shù)據(jù)，可以設(shè)置間隔一段時(shí)間才能重新請求，或者跟隨版本號更新后才能重新請求一次；

（f）分析用戶群體絕大部分的常用設(shè)備、常用瀏覽器，有意引導(dǎo)用戶使用現(xiàn)代瀏覽器，逐步放棄對低版本設(shè)備、低版本瀏覽器支持；

總有一些問題，需要開發(fā)來推動(dòng)業(yè)務(wù)改動(dòng)吧。

結(jié)語

感謝諸位閱讀至此！文章倉促，有不足之處，還望多多指點(diǎn)。

性能優(yōu)化之路漫漫且學(xué)無止盡，本文只能提供一些初步想法，具體落地還要看實(shí)際場景。

參考資料

Chrome文檔：

網(wǎng)絡(luò)分析功能 https://developer.chrome.com/docs/devtools/network?hl=zh-cn

性能面板 https://developer.chrome.com/docs/devtools/performance?hl=zh-cn

燈塔面板 https://developer.chrome.com/docs/lighthouse/overview?hl=zh-cn

Chrome DevRel：

優(yōu)化耗時(shí)較長的任務(wù) https://web.dev/articles/optimize-long-tasks?utm_source=devtools&hl=zh-cn

避免大型、復(fù)雜的布局和布局抖動(dòng) https://web.dev/articles/avoid-large-complex-layouts-and-layout-thrashing?utm_source=devtools&hl=zh-cn#avoid-forced-synchronous-layouts

Webpack：

打包分析 https://github.com/webpack-contrib/webpack-bundle-analyzer

Tree Shaking https://webpack.docschina.org/guides/tree-shaking/

知乎：

Chrome DevTools 代碼覆蓋率功能詳解 https://zhuanlan.zhihu.com/p/26281581

最完備的懶加載錯(cuò)誤兜底方案 https://zhuanlan.zhihu.com/p/459698050

Antd：

按需加載 https://3x.ant.design/docs/react/getting-started-cn#%E6%8C%89%E9%9C%80%E5%8A%A0%E8%BD%BD

使用 Day.js 替換 momentjs 優(yōu)化打包大小 https://3x.ant.design/docs/react/getting-started-cn#%E4%BD%BF%E7%94%A8-Day.js-%E6%9B%BF%E6%8D%A2-momentjs-%E4%BC%98%E5%8C%96%E6%89%93%E5%8C%85%E5%A4%A7%E5%B0%8F

作者：京東零售李振綱

來源：京東云開發(fā)者社區(qū) 自猿其說 Tech 轉(zhuǎn)載請注明來源

posted @ 2024-01-15 15:47 京東云技術(shù)團(tuán)隊(duì) 閱讀(182) 評論(0) 收藏舉報(bào)

刷新頁面返回頂部

23年通天塔搭建頁前端性能優(yōu)化階段分享

前言

常見分析工具

1，網(wǎng)絡(luò)分析功能 Network

2，性能面板 Performance

3，打包分析 webpack-bundle-analyzer

4，代碼覆蓋率 Coverage

5，燈塔面板 Lighthouse

主要優(yōu)化方向

1，加快請求資源速度

2，減少請求資源大小

3，減少請求資源數(shù)量

4，優(yōu)化代碼邏輯

5，優(yōu)化業(yè)務(wù)邏輯

結(jié)語

參考資料

公告

2，性能面板 Performance

3，打包分析 webpack-bundle-analyzer

1，加快請求資源速度

2，減少請求資源大小

4，優(yōu)化代碼邏輯

5，優(yōu)化業(yè)務(wù)邏輯