我有一支技术全面、经验丰富的小型团队，专注高效交付中等规模外包项目，有需要外包项目的可以联系我

还记得拨号上网那清脆的一按，接着是嘶嘶作响的调制解调器吗？一旦连上，网页几乎“嗖”地一下就出来了——不是云养电子宠物的热梗，就是某个个人主页里跳个不停的仓鼠 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 年代”，而是克制地使用强力工具：在该简单时保持简单。

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

全栈AI·探索：涵盖动效、React Hooks、Vue 技巧、LLM 应用、Python 脚本等专栏，案例驱动实战学习，点击二维码了解更多详情。

最后：

20个前端开发者必备的响应式布局

深入React:从基础到最佳实践完整攻略

python 技巧精讲

React Hook 深入浅出

CSS技巧与案例详解

vue2与vue3技巧合集