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

時間快進到今天：家里光纖拉滿，結果一個“很簡單”的 React 頁面還得等 3 秒+ 。

這是怎么肥四？

冷冰冰的數字

事實可能會讓你一驚：90 年代典型網站 2–5 KB 就能打包完事，比你今天隨手發的任意一張高質量照片都小得多。

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

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

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

當年的建站流程清清楚楚：

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

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

一份典型請求長這樣：

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

總計：4 次請求 / 7.2 KB / 漸進式渲染

現代 React 應用：完全不同的物種

來看看現在常見的加載序列：

GET /index.html          (1.2 KB)
GET /bundle.js           (847 KB)   <-- 先等這個大塊頭
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)

總計：7+ 次請求 / ~1,473 KB / JS 執行前基本空白

默認情況下，大體量 JavaScript 的解析與執行會阻塞渲染。當瀏覽器忙著下載并跑完近 1.5 MB 的腳本時，用戶看到的通常只有空白或轉圈。

不過話說回來，這些 JS 可不只是“擺設”。它們在瀏覽器里搭起了一整套運行時：狀態管理、虛擬 DOM diff、事件系統、路由、甚至實時數據同步。

真正的瓶頸：下載之后發生了什么

體積只是第一關，更致命的是執行階段。

90 年代的網站不需要客戶端運算：HTML 早就“畫好了”。現代 React 應用卻要：

• 解析上百 KB 的 JS
• 構建虛擬 DOM
• 執行組件生命周期
• 計算初始狀態
• 發起數據請求
• 虛擬 DOM ? 真實 DOM 對齊
• 應用樣式并觸發布局

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

可我們為什么還要這么做？

別急著把 <table> 和內聯樣式翻出來。 當年的網頁本質是電子傳單：展示信息、表單提交，結束。今天的 Web 是跑在瀏覽器里的軟件，它們可以：

• 無刷新實時更新
• 維護復雜應用狀態
• 流暢處理交互
• 多標簽同步
• Service Worker 離線工作
• 體驗逼近原生 App

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

性能的“代價與收益”

1 秒內加載完成的站點，轉化率往往是 5 秒站點的 3 倍。這讓現代開發陷入一對矛盾：

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

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

• SSR（服務端渲染）
• SSG（靜態生成）
• 代碼分割 / 懶加載
• Tree Shaking 清除未用代碼
• PWA 緩存策略
• Critical CSS 內聯

諷刺的是：我們用越來越復雜的構建鏈路與優化手段，努力在保住現代能力的同時，找回當年那點簡單 + 快。

什么時候“簡單”仍是王道

很多場景里，90 年代思路仍然無敵：

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

• 自適應布局
• 圖片優化
• 內容發布流程
• SEO 友好
• 表單處理

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

甜蜜地帶：現代工具，經典準則

最快的現代網站，幾乎都在復刻 90 年代的性能原則：

• 減小首包：激進 code split，一切非關鍵都懶加載
• 漸進渲染：能展示就先展示，別等“全都準備好”
• 高效緩存：靜態資源合理設置緩存策略與版本號
• 以測促優：沒有度量，談不上優化

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

結論

90 年代網站更快，不是它們“更高級”，而是目標不同、規則不同：把內容盡快送到用戶眼前，是那個時代的頭號追求。

現代 React 應用追求的是可維護性、交互體驗、復雜功能。是的，性能要付出代價，但收益也是真實的。

關鍵在于用對地方： 給“關于我們”做個靜態頁還上 React，就像開著法拉利去取快遞——能到，但包袱太重。

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

很多時候，最容易的答案，恰恰是最好的答案。