快捷導(dǎo)航

React 首頁(yè)加載慢問(wèn)題性能優(yōu)化案例詳解

更新時(shí)間：2021年09月09日 09:02:00 作者：丁柒葉

這篇文章主要介紹了React 首頁(yè)加載慢問(wèn)題性能優(yōu)化案例詳解,本篇文章通過(guò)簡(jiǎn)要的案例,講解了該項(xiàng)技術(shù)的了解與使用,以下就是詳細(xì)內(nèi)容,需要的朋友可以參考下

學(xué)習(xí)了一段時(shí)間React，想真實(shí)的實(shí)踐一下。于是便把我的個(gè)人博客網(wǎng)站進(jìn)行了重構(gòu)。花了大概一周多時(shí)間，網(wǎng)站倒是重構(gòu)的比較成功，但是一上線啊，那個(gè)訪問(wèn)速度啊，是真心慢，慢到自己都不能忍受，那么小一個(gè)網(wǎng)站，沒(méi)幾篇文章，慢成那樣，不能接受。我不是一個(gè)追求完美的人，但這樣可不行。后面大概花了一點(diǎn)時(shí)間進(jìn)行性能的研究。才發(fā)現(xiàn)慢是有原因的。

React這類框架？

目前主流的前端框架React、Vue、Angular都是采用客戶端渲染（服務(wù)端渲染暫時(shí)不在本文的考慮范圍內(nèi)）。這當(dāng)然極大的減輕了服務(wù)器的壓力。相對(duì)的瀏覽器的壓力就增加了。這就意味著大量的js文件需要在本地運(yùn)行。而從服務(wù)器下載這些大的js文件需要時(shí)間。再運(yùn)行這些js又需要時(shí)間。這是首頁(yè)加載慢的本質(zhì)原因。當(dāng)然只是首頁(yè)，因?yàn)楹罄m(xù)有緩存的存在，相對(duì)就很快了。那么如何提升速度呢？無(wú)非從兩個(gè)方向入手

提高下載靜態(tài)資源的速度
優(yōu)化代碼提高運(yùn)行速度

在具體優(yōu)化之前先說(shuō)說(shuō)我博客網(wǎng)站的服務(wù)器配置。

阿里云服務(wù)器ECS
系統(tǒng)Ubuntu 16.04
CPU：1核
內(nèi)存：1GB
MYSQL數(shù)據(jù)庫(kù)
Nginx版本1.16.1

測(cè)試環(huán)境采用火狐瀏覽器,優(yōu)化之前訪問(wèn)速度是這樣的

是不是很慢，慢到懷疑人生。一篇兩千多字的博文頁(yè)面加載完需要6s的時(shí)間，下面我們就從我自己的博客出發(fā)一步一步的進(jìn)行優(yōu)化。

提升下載靜態(tài)資源的速度

提升下載靜態(tài)資源的速度的方法有很多。升級(jí)HTTP1.1到HTTP2.0,開啟gzip數(shù)據(jù)壓縮，上cdn等，這些都是最有效提升速度的方法。自己的網(wǎng)站也主要從這些方面去一一的優(yōu)化來(lái)提高速度的。

升級(jí)HTTP1.1到HTTP2

沒(méi)有升級(jí)之前是這樣的

升級(jí)到HTTP2.0之后是這樣的

那么怎么升級(jí)呢？升級(jí)也是需要條件的。

openssl 1.0.2+ （OpenSSL 1.0.2 開始支持 ALPN）
Nginx 1.9.5+

不知道nginx和openssl版本的可以通過(guò)
nginx -V
查看,以上的條件滿足后，那就簡(jiǎn)單了，只需要在nginx配置文件中添加http2

server {
   listen 443 ssl http2
   .
   .
   .
}

即可，是不是很簡(jiǎn)單，然后再重啟一下nginx服務(wù)器就可以了。（該升級(jí)對(duì)訪問(wèn)速度的提升不大。）

開啟gzip數(shù)據(jù)壓縮

從上面的圖中可以看出，傳輸列和大小列數(shù)據(jù)都是相等的，也就是說(shuō)文件多大，就傳輸多大，完全沒(méi)有壓縮，像其中1.4M這樣的大文件，壓縮就很有必要了。更何況這還是一個(gè)簡(jiǎn)單的博客網(wǎng)站。這是拖慢速度的元兇之一。所以我們很有必要進(jìn)行g(shù)zip壓縮。那么我們?cè)趺撮_啟gzip呢？是不是很難？其實(shí)也很簡(jiǎn)單，nginx原本就支持，我們只需要簡(jiǎn)單的配置就好。同樣的修改nginx配置文件

server {
    listen 443 ssl http2
    #...中間省略很多
    gzip on;
    gzip_buffers 32 4k;
    gzip_comp_level 6;
    gzip_min_length 200;
    gzip_types text/css text/xml application/javascript application/json;
}

其中

gzip on表示gzip壓縮開啟。
gzip_buffers 32 4k表示處理請(qǐng)求壓縮的緩沖區(qū)數(shù)量和大小，可以不設(shè)置，使用默認(rèn)值就好。
gzip_comp_levelgzip壓縮級(jí)別,到了等級(jí)6之后就很難提高了。
gzip_min_length當(dāng)返回內(nèi)容大于此值時(shí)才會(huì)使用gzip進(jìn)行壓縮,以K為單位,當(dāng)值為0時(shí)，所有頁(yè)面都進(jìn)行壓縮
gzip_types壓縮類型

同樣的再重啟一下nginx服務(wù)器就好

從圖中可以看出，大大的提升了速度。再觀察傳輸和大小這一欄，兩者大小差異就很大了。完成了這兩步，速度已經(jīng)從以前的6s減少到2秒左右了。
（該升級(jí)對(duì)訪問(wèn)速度提升最大。）

注意： 當(dāng)然更好的方法是使用cdn加速。把靜態(tài)資源cdn化。更能大大的提升速度。

優(yōu)化代碼提高運(yùn)行速度

在多次請(qǐng)求測(cè)試中。發(fā)現(xiàn)依舊有很多文件很小，但是運(yùn)行起來(lái)卻相當(dāng)耗時(shí)，當(dāng)然這和React創(chuàng)建DOM樹等操作有關(guān)，不過(guò)我們還是可以再看看代碼上有沒(méi)有其他可以優(yōu)化的空間。對(duì)于這么一個(gè)小網(wǎng)站來(lái)說(shuō)也太慢了，我想我寫的代碼一定有很耗時(shí)的操作，果不其然。網(wǎng)站中這段代碼

const markdownHtml = marked(content_mark || '');

把markdown轉(zhuǎn)成html過(guò)程中需要耗費(fèi)些時(shí)間，如果文章內(nèi)容很大，這個(gè)時(shí)間也是不容忽視的。
測(cè)試了這篇JS數(shù)組轉(zhuǎn)字符串實(shí)現(xiàn)方法解析字?jǐn)?shù)比較多的文章，竟然花費(fèi)了我整整100多ms，按照慣例這也是不能容忍的。

這種情況我們?cè)诒４鎚arkdown的時(shí)候就可以直接保存兩份數(shù)據(jù)，一份原markdown數(shù)據(jù)，一份markdown轉(zhuǎn)成html后的數(shù)據(jù)。頁(yè)面渲染的時(shí)候直接獲轉(zhuǎn)換后的html代碼，這樣節(jié)約了轉(zhuǎn)換時(shí)間。

我們還可以利用React的懶加載，在用webpack打包的時(shí)候進(jìn)行代碼的分割，減少首屏加載的體積。

當(dāng)然加載過(guò)程中提升用戶體驗(yàn)也是重要的一環(huán)，雖然不能有效的提升運(yùn)行速度，但可以使用戶更加愉悅。所謂歡樂(lè)不覺時(shí)光過(guò)嘛。

到此這篇關(guān)于React 首頁(yè)加載慢問(wèn)題性能優(yōu)化案例詳解的文章就介紹到這了,更多相關(guān)React 首頁(yè)加載慢問(wèn)題性能優(yōu)化內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: