這是一個(gè)加載慢慢慢慢慢到不行的網(wǎng)站，據(jù)說是由一位低級(jí)程序員魚皮開發(fā)的，等了幾分鐘都沒加載完：

你能想到多少種辦法，來拯救這個(gè)網(wǎng)站的加載速度呢？

我能想到 至少 12 種，如果你能想到更多方法，先受我一拜，你真的很厲害；如果你想到的方法比我少，那么這期內(nèi)容，一定會(huì)讓你有收獲。

下面我們就來聊聊《網(wǎng)站性能優(yōu)化》。

如何測(cè)量網(wǎng)站性能？

衡量網(wǎng)站性能的指標(biāo)非常多，比如首屏加載時(shí)間、白屏?xí)r間、可交互時(shí)間等等。

但這里為了幫助大家理解，我們主要關(guān)注用戶最直觀能感受到的 網(wǎng)站加載時(shí)長。

怎么測(cè)量網(wǎng)站加載時(shí)長呢？

最簡單的方法就是按 F12 打開瀏覽器的開發(fā)者工具，切換到 Network 網(wǎng)絡(luò)面板，刷新頁面就能看到每個(gè)資源的加載時(shí)間了。

當(dāng)然，還有更專業(yè)的網(wǎng)站性能分析工具，在本期的最后會(huì)分享。

網(wǎng)站性能優(yōu)化的關(guān)鍵

雖然網(wǎng)站性能優(yōu)化的方法非常多，但思路很簡單。

問個(gè)問題，大家都收過快遞吧？快遞是怎么送到你家的呢？

首先，商家從倉庫把商品打包，然后通過物流網(wǎng)絡(luò)和快遞員配送到你手里，你拆開包裹就能使用了。

訪問網(wǎng)站也是一樣的：從服務(wù)器獲取到網(wǎng)站文件，然后在瀏覽器中加載。

要讓網(wǎng)站訪問更快，我們可以從三個(gè)方向來優(yōu)化：

• 網(wǎng)站傳輸更快
• 網(wǎng)站體積更小
• 網(wǎng)站加載更快

下面我們就按照這些方向，來優(yōu)化現(xiàn)在這個(gè)要加載 3 分多鐘的辣雞網(wǎng)站，看看最后能優(yōu)化到多少秒。

一、網(wǎng)站傳輸優(yōu)化

想要更快獲取到網(wǎng)站文件，我們可以按照網(wǎng)站文件傳輸?shù)穆窂?服務(wù)器 => 網(wǎng)絡(luò)傳輸 => 客戶端 進(jìn)行優(yōu)化。

升級(jí)服務(wù)器配置

毫無疑問，從服務(wù)器獲取網(wǎng)站文件是需要網(wǎng)絡(luò)的，服務(wù)器帶寬越大，網(wǎng)速越快，網(wǎng)站文件下載越快。

所以如果你不知道怎么優(yōu)化網(wǎng)站性能，最簡單粗暴的方法就是加錢！升級(jí)服務(wù)器的帶寬！

比如我把 2M 帶寬的小水管升級(jí)到 8M，網(wǎng)站加載時(shí)長就從 3 分鐘優(yōu)化到了 40 秒，速度優(yōu)化了 4 倍多！

不過一般來說，對(duì)于個(gè)人小網(wǎng)站，1-5M 就夠用了，畢竟帶寬挺貴的。

有同學(xué)會(huì)問了，光升級(jí)帶寬就夠了么？升級(jí)內(nèi)存、CPU、硬盤有沒有用？

這就要看你網(wǎng)站的類別了，對(duì)于純靜態(tài)網(wǎng)站來說，服務(wù)器要做的就是把網(wǎng)站文件發(fā)送出去，這個(gè)過程主要受帶寬限制。但如果你的網(wǎng)站有復(fù)雜的后端邏輯，那 CPU 和內(nèi)存就很重要了。

CDN 緩存加速

如果用戶離我們的網(wǎng)站服務(wù)器較遠(yuǎn)，傳輸網(wǎng)站文件的時(shí)間就會(huì)更長，很影響體驗(yàn)。

如何解決這個(gè)問題呢？我們不妨類比一下網(wǎng)購，平臺(tái)會(huì)在全國建立區(qū)域倉庫，提前把熱門商品分配到各地倉庫，用戶下單后從最近的倉庫發(fā)貨，而不是都從總倉發(fā)貨，就能更快收貨。

這就是 CDN 內(nèi)容分發(fā)網(wǎng)絡(luò)的原理，提前從源服務(wù)器獲取到網(wǎng)站文件并緩存到全國各地的節(jié)點(diǎn)，用戶訪問時(shí)就可以直接從最近的節(jié)點(diǎn)獲取資源。不僅延遲更低，而且能同時(shí)支持更多用戶的訪問。

我們使用云服務(wù)平臺(tái)配置一下 CDN，指定原始網(wǎng)站服務(wù)器作為源站。

然后設(shè)置緩存，可以只緩存圖片等媒體資源，也可以緩存整套網(wǎng)站文件，這里我全都要。

試一下效果，首次訪問會(huì)比較慢，因?yàn)?CDN 節(jié)點(diǎn)還沒有緩存，需要從網(wǎng)站服務(wù)器拉取文件；之后速度就飚起來了，直接從 40 秒優(yōu)化到了 6 秒，性能優(yōu)化了 6 倍多！效果顯著。

不過 CDN 可是把雙刃劍，按流量計(jì)費(fèi)，鑒于我被刷了上萬元流量費(fèi)的血淚經(jīng)驗(yàn)，建議 CDN 能不用就不用，即使要用 CDN 也要做好訪問頻率限制、用量封頂配置和監(jiān)控告警。

瀏覽器緩存

除了 CDN 外，但還有一個(gè)更徹底的優(yōu)化方案：讓網(wǎng)站文件根本不用傳輸！

這就是 瀏覽器緩存 的作用，將已經(jīng)請(qǐng)求過的網(wǎng)站文件存儲(chǔ)到用戶本地，下次再訪問網(wǎng)站時(shí)，都不用去找服務(wù)器了，直接從本地加載資源。

我們可以通過 Web 服務(wù)器的 HTTP 緩存頭配置或者 CDN 的瀏覽器緩存過期配置來更改緩存策略，更新不頻繁的網(wǎng)站緩存時(shí)間可以設(shè)置長一些。

我這里設(shè)置為 1 小時(shí)，效果很明顯，直接從 6 秒優(yōu)化到了 1.69 秒，不過理論上還可以更快。

這樣一來，我們就形成了一個(gè)完整的網(wǎng)站緩存體系：CDN 緩存解決地理距離問題，瀏覽器緩存解決重復(fù)訪問的問題。實(shí)際情況下兩種方法建議結(jié)合使用。

升級(jí) HTTP 協(xié)議

此外，想要升級(jí)網(wǎng)站傳輸?shù)乃俣?，可以升?jí)請(qǐng)求協(xié)議到 HTTP/2。

相比于 HTTP/1.1，HTTP/2 最大的改進(jìn)是 多路復(fù)用。HTTP/1.1 雖然可以建立多個(gè)連接，但每個(gè)連接內(nèi)的請(qǐng)求必須按順序處理，容易產(chǎn)生隊(duì)頭阻塞問題。而 HTTP/2 在單個(gè)連接上就能同時(shí)處理多個(gè)請(qǐng)求，真正實(shí)現(xiàn)了并行傳輸。

升級(jí) HTTP/2 的方式很簡單，只需要在 Web 服務(wù)器（比如 Nginx）添加配置：

server {
   listen 443 ssl http2;  # 開啟HTTP/2支持
   server_name your-domain.com;
   
   ssl_certificate /path/to/cert.pem;
   ssl_certificate_key /path/to/key.pem;
   
   # 其他配置...
}

如果你用的是 CDN，只需要在 CDN 配置頁面一鍵開啟 HTTP/2 即可：

測(cè)試一下效果，這次沒有用到本地緩存，網(wǎng)站加載時(shí)長也從 6 秒縮短到了 1.6 秒，性能優(yōu)化了 3 倍多！

僅僅點(diǎn)了一下按鈕，速度就上來了，是不是沒想到？

那你可能問了，現(xiàn)在不是還有 HTTP/3 嗎？

HTTP/3 確實(shí)更先進(jìn)，它基于 QUIC 協(xié)議，有更快的連接建立速度、更好的多路復(fù)用性能和更少的隊(duì)頭阻塞問題，但兼容性和穩(wěn)定性還需要時(shí)間驗(yàn)證，選用 HTTP/2 就足夠了。

至此，在沒有改變網(wǎng)站本身的情況下，我們就已經(jīng)把網(wǎng)站加載時(shí)間優(yōu)化到了秒級(jí)！

二、網(wǎng)站體積優(yōu)化

如果把網(wǎng)站文件當(dāng)做貨物，體積越小，自然傳送越快。

如何優(yōu)化網(wǎng)站文件體積呢？

核心就 2 個(gè)字 —— 壓縮。

網(wǎng)站資源壓縮

首先可以壓縮網(wǎng)站引用的媒體資源，比如圖片、音視頻、字體文件等等。

很多朋友都知道這個(gè)道理，但是經(jīng)常忽略。不信打開瀏覽器控制臺(tái)看看你們自己的網(wǎng)站，有哪些資源可以進(jìn)一步優(yōu)化呢？

對(duì)很多網(wǎng)站來說，圖片是消耗流量較多的一類資源，因此我們性能優(yōu)化時(shí)，要重點(diǎn)關(guān)注圖片。

只需要把 JPG 和 PNG 的圖片統(tǒng)一壓縮為 WebP（或 AVIF）格式，這樣就能減少 20% 以上的文件體積；想追求更高的壓縮比例，還可以調(diào)整圖片壓縮的質(zhì)量，一般 80% 左右對(duì)原圖的影響是可以接受的。

舉個(gè)例子，我讓 AI 通過編寫 Python 腳本批量壓縮網(wǎng)站內(nèi)的圖片，總體積直接減少了 20 多倍！

再次訪問網(wǎng)站時(shí)，相比之前從服務(wù)器加載耗時(shí) 40 秒，這次直接縮短到了 2 秒！竟然跟使用 CDN + HTTP 2 的效果旗鼓相當(dāng)，優(yōu)化了 20 倍！

而且不仔細(xì)看的話，你能分辨出來優(yōu)化前后圖片的區(qū)別么？

需要注意的是，如果你的網(wǎng)站允許用戶自主上傳圖片，一定要在后端服務(wù)器對(duì)這些圖片進(jìn)行壓縮，否則可能就會(huì)出現(xiàn)下圖這種慘狀：一個(gè)用戶頭像都消耗了 5M 流量。

網(wǎng)站代碼壓縮

除了引用的資源外，網(wǎng)站代碼本身也是可以壓縮的。

代碼壓縮的原理很好理解，去掉代碼中的空格、注釋、換行，把變量名縮短就可以了。舉個(gè)例子：

雖然網(wǎng)站代碼壓縮的工具網(wǎng)上一抓一大把（比如 Minifier 和 JSCompress），但一般我們不需要手動(dòng)壓縮代碼。對(duì)于獨(dú)立的 CSS 和 JS 腳本文件，可以直接使用 官方提供的 Min 壓縮版本。

而對(duì)于目前主流的 Vue / React 前端工程化項(xiàng)目，一般會(huì)使用打包工具（比如 Vite / Webpack）自動(dòng)對(duì)代碼文件進(jìn)行優(yōu)化、壓縮和打包。

比如經(jīng)典的 Tree Shaking（搖樹優(yōu)化），就像搖樹一樣，通過靜態(tài)分析，把代碼中沒用到的地方 “搖” 掉，從而減小 JS 文件體積。

來試試看，我的網(wǎng)站項(xiàng)目使用了 Vite 作為打包工具，添加這么一段配置，然后構(gòu)建和部署項(xiàng)目。

對(duì)比一下，效果立竿見影！原本 363 KB 的代碼，壓縮后只有 159 KB，減少到了一半！

網(wǎng)站加載時(shí)長也進(jìn)一步縮短到了 1.62 秒，又優(yōu)化了 20%。

Gzip 傳輸壓縮

除了手動(dòng)壓縮外，還可以在網(wǎng)站傳輸時(shí)利用 Gzip 實(shí)現(xiàn)自動(dòng)壓縮。

它的原理也很簡單，瀏覽器和服務(wù)器之間有個(gè)約定：

1）瀏覽器請(qǐng)求網(wǎng)站時(shí)通過請(qǐng)求頭告訴服務(wù)器：“我支持 gzip 壓縮”。

示例 Accept-Encoding 請(qǐng)求頭：

GET /index.html HTTP/1.1
Host: codefather.cn
Accept-Encoding: gzip, deflate, br

2）服務(wù)器收到這個(gè)請(qǐng)求，如果開啟了 gzip 壓縮，會(huì)把文件壓縮后再發(fā)送，并且通過響應(yīng)頭告訴瀏覽器：“這是壓縮過的”。

示例 Content-Encoding 響應(yīng)頭：

HTTP/1.1 200 OK
Content-Type: text/html
Content-Encoding: gzip
Content-Length: 1024

3）瀏覽器收到文件后，會(huì)自動(dòng)進(jìn)行解壓。

讓我們測(cè)試一下，開啟 gzip 的方式很簡單，只需要在 Web 服務(wù)器中添加配置：

# 開啟gzip壓縮
gzip on;

# 啟用gzip壓縮的HTTP版本
gzip_http_version 1.1;

# 壓縮級(jí)別 (1-9)
# 1: 最快壓縮，壓縮率最低
# 9: 最慢壓縮，壓縮率最高
# 6: 平衡壓縮速度和壓縮率的推薦值
gzip_comp_level 6;

# 小于1KB的文件不壓縮
# 小文件壓縮后可能反而變大，且消耗CPU資源
gzip_min_length 1024;

然后我們利用 CURL 工具分別發(fā)送不開啟 Gzip 和開啟 Gzip 的兩個(gè)請(qǐng)求：

# 開啟 Gzip - 詳細(xì)版
curl -H "Accept-Encoding: gzip" -w "Gzip: %{size_download} bytes" -o /dev/null -s http://love.codefather.cn/assets/index-d746a13e.js

# 不開啟 Gzip - 詳細(xì)版  
curl -H "Accept-Encoding: identity" -w "原始: %{size_download} bytes" -o /dev/null -s http://love.codefather.cn/assets/index-d746a13e.js

發(fā)現(xiàn)開啟 Gzip 壓縮后，文件大小能減少一半多！

但由于我們網(wǎng)站的代碼文件體積本來就不大，所以開啟 gzip 后的優(yōu)化效果不會(huì)那么明顯，但仍然建議開啟。

三、網(wǎng)站加載優(yōu)化

前面我們優(yōu)化了網(wǎng)站傳輸和網(wǎng)站體積，HTML 等網(wǎng)站文件能更快到達(dá)用戶瀏覽器。但瀏覽器接下來還需要加載腳本、圖片等大量資源，并且動(dòng)態(tài)請(qǐng)求后端數(shù)據(jù)。

這個(gè)過程也是可以優(yōu)化的，也是最有意思的，我們可以通過很多策略來優(yōu)化網(wǎng)站的加載速度。

加載策略

首先是幾種典型的加載策略，目標(biāo)是 讓用戶在合適的時(shí)機(jī)獲得合適的內(nèi)容。

1、延遲加載

懶加載 是最常用的延遲加載技術(shù)，核心思想很簡單：用戶看不到的內(nèi)容就先不加載。這種策略特別適合長頁面和圖片較多的網(wǎng)站。

比如我們通過 HTML 圖片標(biāo)簽自帶的 lazy 屬性實(shí)現(xiàn)懶加載：

<img src="image.jpg" loading="lazy" alt="懶加載圖片">

如果想實(shí)現(xiàn)更嚴(yán)格的懶加載，可以采用 Intersection Observer 來觀察圖片是否進(jìn)入視窗

測(cè)試一下效果，首屏只用了 339 毫秒就加載完成了，加載時(shí)長又縮短了 5 倍！

當(dāng)用戶滾動(dòng)頁面到對(duì)應(yīng)的位置時(shí)，圖片才開始加載，不僅大幅減少了首屏加載時(shí)間，而且節(jié)約了流量。

2、按需加載

利用 代碼分割 技術(shù)，可以把原本龐大的代碼包拆分成多個(gè)小模塊，根據(jù)用戶實(shí)際需要的功能來加載對(duì)應(yīng)代碼。

比如之前網(wǎng)站所有頁面的 CSS 和 JS 文件是合并在一起的，現(xiàn)在可以按照頁面分割成多個(gè)小文件，訪問哪個(gè)頁面就加載哪個(gè)頁面的代碼：

// 傳統(tǒng)方式：一次性加載所有頁面代碼
import UserProfile from './UserProfile.vue'

// 代碼分割：訪問頁面時(shí)才加載對(duì)應(yīng)代碼
const UserProfile = () => import('./UserProfile.vue')

這樣一來，訪問網(wǎng)站首頁時(shí)，只按需加載和首頁有關(guān)的部分代碼，減少了網(wǎng)站首次加載的文件體積，首屏加載速度就能大幅提升，縮短到 162 毫秒，又優(yōu)化了 1 倍！

之后當(dāng)訪問其他頁面時(shí)，才會(huì)加載對(duì)應(yīng)的網(wǎng)站文件。

3、分層加載

這個(gè)策略的核心是 先快后好，先讓用戶立即看到內(nèi)容，再根據(jù)情況提升質(zhì)量，避免用戶等待的焦慮感。常見的實(shí)現(xiàn)方式有 2 種。

首先是 縮略圖。在列表頁顯示低清小圖，用戶點(diǎn)擊某個(gè)感興趣的內(nèi)容后再加載高清大圖，這樣幾乎不影響用戶體驗(yàn)，又節(jié)省了流量。實(shí)現(xiàn)方法很簡單，為每個(gè)高清原圖額外生成一個(gè)縮略圖，不同的頁面加載不同的圖片就好。

這樣一來，首屏加載的資源更小，加載時(shí)長縮短到了 118 毫秒，又優(yōu)化了 25%！

還有一種更高級(jí)的策略 —— 漸進(jìn)式加載，先加載低質(zhì)量內(nèi)容，再自動(dòng)加載高質(zhì)量內(nèi)容。比如圖片會(huì)先顯示一個(gè)模糊的預(yù)覽，然后逐漸變清晰。這樣用戶不會(huì)看到空白區(qū)域和頁面錯(cuò)位，瀏覽體驗(yàn)更絲滑。

4、預(yù)加載

這個(gè)策略的核心是 預(yù)判用戶需求，在用戶需要訪問之前就把資源準(zhǔn)備好，讓體驗(yàn)更流暢。

只需要一行代碼，就能指定預(yù)加載的資源：

<link rel="prefetch" href="next-page.js" rel="external nofollow" >

舉個(gè)典型的場(chǎng)景，比如用戶瀏覽博客網(wǎng)站的文章列表時(shí)，可以預(yù)加載幾篇文章詳情頁，這樣用戶點(diǎn)擊時(shí)幾乎秒開。

但我建議使用預(yù)加載前，最好先對(duì)網(wǎng)站的結(jié)構(gòu)和訪問情況進(jìn)行分析，關(guān)鍵是要把握好度。預(yù)加載太少效果不明顯，預(yù)加載太多又會(huì)產(chǎn)生流量浪費(fèi)。就像你提前為客人準(zhǔn)備了第二天的飯，結(jié)果人家當(dāng)天就走了。

請(qǐng)求優(yōu)化

除了幾種加載策略外，還有個(gè)比較高級(jí)的技巧 —— 請(qǐng)求合并。

當(dāng)你要多次調(diào)用后端接口來請(qǐng)求數(shù)據(jù)時(shí)，由于瀏覽器對(duì)同一域名有并發(fā)請(qǐng)求數(shù)限制（一般是 6 個(gè)左右），可能會(huì)產(chǎn)生請(qǐng)求排隊(duì)和阻塞，導(dǎo)致數(shù)據(jù)加載耗時(shí)過長。這時(shí)，我們可以讓后端提供一個(gè)聚合接口，一個(gè)接口返回某個(gè)頁面需要的所有數(shù)據(jù)。不過這需要你跟后端關(guān)系不錯(cuò)，否則你就只能自己搭個(gè) Node.js 中間層來做請(qǐng)求聚合了。

請(qǐng)求網(wǎng)站小圖標(biāo)也是類似的，與其一個(gè)個(gè)請(qǐng)求圖標(biāo)文件，不如利用 CSS 雪碧圖 特性，把所有小圖標(biāo)合并為一張圖片，然后在前端利用 CSS 的 background-position 來加載圖片的指定位置。

這樣只需要請(qǐng)求 1 次，就達(dá)到了同樣的效果，網(wǎng)站的加載時(shí)長也會(huì)進(jìn)一步縮短。

性能分析關(guān)鍵

通過前面分享的這些網(wǎng)站優(yōu)化技巧，最終我們網(wǎng)站的加載時(shí)間竟然 從 180 秒優(yōu)化到了 118 毫秒，性能提升了 1500 多倍！效果還是非常炸裂的，弱網(wǎng)環(huán)境也能很快訪問網(wǎng)站。

但這就是極限了么？

可別忘了，我們的體積優(yōu)化和加載優(yōu)化并沒有使用 CDN 進(jìn)行演示，那如果我們同時(shí)開啟 CDN 和 HTTP 2，效果又如何呢？

結(jié)果可能讓大家失望了，經(jīng)過我的多次測(cè)試，性能并沒有明顯的提升。我們對(duì)網(wǎng)站本身的優(yōu)化越多，傳輸數(shù)據(jù)量就更小，再加上各種不穩(wěn)定因素，CDN 在提速方面的效果可能就沒那么明顯了。這就是為什么我建議大家先對(duì)網(wǎng)站本身進(jìn)行優(yōu)化，CDN 還是要謹(jǐn)慎使用。

雖然方法教給大家了，怎么合理運(yùn)用這些方法進(jìn)行優(yōu)化，是需要大家持續(xù)探索的。記住，性能優(yōu)化一定是 “針對(duì)具體場(chǎng)景，先分析再優(yōu)化”。因此我們也一定要準(zhǔn)備一些網(wǎng)站性能分析的工具，我一般會(huì)優(yōu)先使用瀏覽器開發(fā)者工具內(nèi)置的 Lighthouse，使用很方便。點(diǎn)擊一鍵分析，就能幫你進(jìn)行全面的網(wǎng)站性能評(píng)估，還給出了很多優(yōu)化建議，有一些不正是我們今天分享到的方法么？

此外，還有一些免費(fèi)工具也可以試試看：

• GTmetrix - 詳細(xì)的瀑布圖分析
• WebPageTest - 全球多節(jié)點(diǎn)測(cè)試

最后

OK 以上就是本期內(nèi)容，雖然這并不是所有的網(wǎng)站優(yōu)化方法（還有后端優(yōu)化、Web Workers、Service Worker、WebAssembly 等等），但已經(jīng)能夠覆蓋絕大多數(shù)優(yōu)化場(chǎng)景了。大家可以按照上面提到的方法，一步步按需優(yōu)化自己的網(wǎng)站。

這篇文章魚皮總共寫了 5000 多字，如果對(duì)你有幫助，記得 點(diǎn)贊收藏 支持一下！大家反饋不錯(cuò)的話，我后續(xù)會(huì)繼續(xù)分享 后端性能優(yōu)化的一條龍服務(wù)，絕對(duì)干貨滿滿，我們下期見。

到此這篇關(guān)于網(wǎng)站性能分析優(yōu)化實(shí)例（網(wǎng)站加載慢）的文章就介紹到這了,更多相關(guān)網(wǎng)站性能分析優(yōu)化內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論