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

React這類框架？

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

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

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

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

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

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

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

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

升級HTTP1.1到HTTP2

沒有升級之前是這樣的

升級到HTTP2.0之后是這樣的

那么怎么升級呢？升級也是需要條件的。

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

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

server {
   listen 443 ssl http2
   .
   .
   .
}

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

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

從上面的圖中可以看出，傳輸列和大小列數(shù)據(jù)都是相等的，也就是說文件多大，就傳輸多大，完全沒有壓縮，像其中1.4M這樣的大文件，壓縮就很有必要了。更何況這還是一個簡單的博客網(wǎng)站。這是拖慢速度的元兇之一。所以我們很有必要進行g(shù)zip壓縮。那么我們怎么開啟gzip呢？是不是很難？其實也很簡單，nginx原本就支持，我們只需要簡單的配置就好。同樣的修改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ū)數(shù)量和大小，可以不設(shè)置，使用默認值就好。
• gzip_comp_levelgzip壓縮級別,到了等級6之后就很難提高了。
• gzip_min_length當返回內(nèi)容大于此值時才會使用gzip進行壓縮,以K為單位,當值為0時，所有頁面都進行壓縮
• gzip_types壓縮類型

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

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

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

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

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

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

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

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

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

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

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

最新評論