還記得撥號(hào)上網(wǎng)那清脆的一按，接著是嘶嘶作響的調(diào)制解調(diào)器嗎？一旦連上，網(wǎng)頁幾乎“嗖”地一下就出來了——不是云養(yǎng)電子寵物的熱梗，就是某個(gè)個(gè)人主頁里跳個(gè)不停的倉鼠 GIF。

時(shí)間快進(jìn)到今天：家里光纖拉滿，結(jié)果一個(gè)“很簡單”的 React 頁面還得等 3 秒+ 。

這是怎么肥四？

冷冰冰的數(shù)字

事實(shí)可能會(huì)讓你一驚：90 年代典型網(wǎng)站 2–5 KB 就能打包完事，比你今天隨手發(fā)的任意一張高質(zhì)量照片都小得多。

對(duì)比下今天的 React：框架本體（壓縮后）就差不多 30 KB 起步，后面還有你的業(yè)務(wù)代碼、樣式、圖片，以及那一堆“離不開”的 npm 依賴。

最近審了個(gè)“極簡”待辦（todo）應(yīng)用，整包 847 KB。做個(gè)參照：初代 DOOM 的安裝包 2.39 MB——那可是一整套 3D 射擊游戲（認(rèn)真）。

90 年代的配方：簡單到“暴力”

當(dāng)年的建站流程清清楚楚：

1. 寫點(diǎn) HTML
2. 要是講究，再加點(diǎn) CSS
3. 最多弄個(gè)小 JS 做圖片 rollover
4. FTP 上傳
5. 完成 ?

沒有構(gòu)建、沒有打包、沒有轉(zhuǎn)譯，也更沒有虛擬 DOM。瀏覽器拿到你的 HTML，自上而下邊讀邊畫。體積幾乎是一切性能問題的核心，大家都明白。

一份典型請(qǐng)求長這樣：

GET /index.html      (2.1 KB)
GET /style.css       (0.8 KB)
GET /banner.gif      (1.2 KB)
GET /background.jpg  (3.1 KB)

總計(jì)：4 次請(qǐng)求 / 7.2 KB / 漸進(jìn)式渲染

現(xiàn)代 React 應(yīng)用：完全不同的物種

來看看現(xiàn)在常見的加載序列：

GET /index.html          (1.2 KB)
GET /bundle.js           (847 KB)   <-- 先等這個(gè)大塊頭
GET /vendor.bundle.js    (312 KB)
GET /runtime.bundle.js   (23 KB)
GET /main.css            (89 KB)
GET /fonts.woff2         (156 KB)
GET /api/initial-data    (45 KB JSON)

總計(jì)：7+ 次請(qǐng)求 / ~1,473 KB / JS 執(zhí)行前基本空白

默認(rèn)情況下，大體量 JavaScript 的解析與執(zhí)行會(huì)阻塞渲染。當(dāng)瀏覽器忙著下載并跑完近 1.5 MB 的腳本時(shí)，用戶看到的通常只有空白或轉(zhuǎn)圈。

不過話說回來，這些 JS 可不只是“擺設(shè)”。它們?cè)跒g覽器里搭起了一整套運(yùn)行時(shí)：狀態(tài)管理、虛擬 DOM diff、事件系統(tǒng)、路由、甚至實(shí)時(shí)數(shù)據(jù)同步。

真正的瓶頸：下載之后發(fā)生了什么

體積只是第一關(guān)，更致命的是執(zhí)行階段。

90 年代的網(wǎng)站不需要客戶端運(yùn)算：HTML 早就“畫好了”?，F(xiàn)代 React 應(yīng)用卻要：

• 解析上百 KB 的 JS
• 構(gòu)建虛擬 DOM
• 執(zhí)行組件生命周期
• 計(jì)算初始狀態(tài)
• 發(fā)起數(shù)據(jù)請(qǐng)求
• 虛擬 DOM ? 真實(shí) DOM 對(duì)齊
• 應(yīng)用樣式并觸發(fā)布局

某次分析里，React 首屏渲染本身僅 ~50ms，但等待服務(wù)器用了 ~560ms；再加上 JS 的解析/執(zhí)行，在移動(dòng)端輕松再添 200–500ms。

可我們?yōu)槭裁催€要這么做？

別急著把 <table> 和內(nèi)聯(lián)樣式翻出來。 當(dāng)年的網(wǎng)頁本質(zhì)是電子傳單：展示信息、表單提交，結(jié)束。今天的 Web 是跑在瀏覽器里的軟件，它們可以：

• 無刷新實(shí)時(shí)更新
• 維護(hù)復(fù)雜應(yīng)用狀態(tài)
• 流暢處理交互
• 多標(biāo)簽同步
• Service Worker 離線工作
• 體驗(yàn)逼近原生 App

讓你用 90 年代的技術(shù)去造 Slack、Figma、Google Docs/Sheets？基本不可能。用戶期待與功能需求已經(jīng)完全變了。

性能的“代價(jià)與收益”

1 秒內(nèi)加載完成的站點(diǎn)，轉(zhuǎn)化率往往是 5 秒站點(diǎn)的 3 倍。這讓現(xiàn)代開發(fā)陷入一對(duì)矛盾：

• 我們想要 React 帶來的交互力；
• 又必須把首屏速度拉回來。

于是衍生出一整套性能工程：

• SSR（服務(wù)端渲染）
• SSG（靜態(tài)生成）
• 代碼分割 / 懶加載
• Tree Shaking 清除未用代碼
• PWA 緩存策略
• Critical CSS 內(nèi)聯(lián)

諷刺的是：我們用越來越復(fù)雜的構(gòu)建鏈路與優(yōu)化手段，努力在保住現(xiàn)代能力的同時(shí)，找回當(dāng)年那點(diǎn)簡單 + 快。

什么時(shí)候“簡單”仍是王道

很多場(chǎng)景里，90 年代思路仍然無敵：

• 博客、文檔、營銷頁、以內(nèi)容為主的站點(diǎn)——很可能根本不需要 React。
• 用 Hugo 等靜態(tài)站點(diǎn)生成器，首屏 <100ms 輕輕松松，同時(shí)還保留：

• 自適應(yīng)布局
• 圖片優(yōu)化
• 內(nèi)容發(fā)布流程
• SEO 友好
• 表單處理

一句話：最快的 React，也敵不過一份寫得講究的純靜態(tài) HTML 的首次加載。物理定律依然是物理定律。

甜蜜地帶：現(xiàn)代工具，經(jīng)典準(zhǔn)則

最快的現(xiàn)代網(wǎng)站，幾乎都在復(fù)刻 90 年代的性能原則：

• 減小首包：激進(jìn) code split，一切非關(guān)鍵都懶加載
• 漸進(jìn)渲染：能展示就先展示，別等“全都準(zhǔn)備好”
• 高效緩存：靜態(tài)資源合理設(shè)置緩存策略與版本號(hào)
• 以測(cè)促優(yōu)：沒有度量，談不上優(yōu)化

Next.js / Gatsby / SvelteKit 等工具，正努力在“開發(fā)體驗(yàn)像 React”與“性能像 90s”之間，找到平衡。

結(jié)論

90 年代網(wǎng)站更快，不是它們“更高級(jí)”，而是目標(biāo)不同、規(guī)則不同：把內(nèi)容盡快送到用戶眼前，是那個(gè)時(shí)代的頭號(hào)追求。

現(xiàn)代 React 應(yīng)用追求的是可維護(hù)性、交互體驗(yàn)、復(fù)雜功能。是的，性能要付出代價(jià)，但收益也是真實(shí)的。

關(guān)鍵在于用對(duì)地方： 給“關(guān)于我們”做個(gè)靜態(tài)頁還上 React，就像開著法拉利去取快遞——能到，但包袱太重。

真正的啟示不是“回到 90 年代”，而是克制地使用強(qiáng)力工具：在該簡單時(shí)保持簡單。

很多時(shí)候，最容易的答案，恰恰是最好的答案。