331次请求每秒 vs 2022次。这不是实验室里的数字游戏，是GitHub Actions跑出来的真实数据。一个基于Vite的React SSR框架Pareto，把Next.js按在地上摩擦了。
「静态渲染之王」的软肋被找到了
Next.js在静态SSR场景确实稳，这是公认的事实。但业务代码里哪有纯静态页面？一旦数据加载进场，局面彻底反转。
Pareto的吞吐量飙升到Next.js的9.3倍，是React Router（Remix）的2.9倍。开发者@childrentime团队在CI里搭了套自动化基准测试，每次PR都跑一遍，硬件、Node版本、并发连接数全部锁死。四组场景覆盖最常见的SSR负载，用autocannon压测100连接、30秒。
真正的杀招是流式渲染。Pareto能扛住2022 req/s，Next.js只有331 req/s，差距拉到6.5倍。React Router稍好点，也就800出头。
换算成服务器账单更直观：峰值2000 req/s的产品页，Pareto单台机器搞定，Next.js得堆6台加负载均衡。流式SSR仪表盘场景，1台Pareto对标7台Next.js。
延迟数据更扎心。100并发下，Pareto的数据加载p99是702毫秒，Next.js直接飙到7.82秒。99%的Pareto用户半秒内看到页面，Next.js那边每100人就有1个等将近8秒——这转化率得掉多少，产品经理不敢算。
62KB vs 248KB：移动端生死线
客户端JS体积是另一张底牌。Pareto打包出来62KB，Next.js接近250KB，正好四分之一。
4G网络（约5Mbps）下，Pareto 100毫秒下载完开始渲染，Next.js要370毫秒。3G环境差距彻底撕裂：330毫秒对1.2秒。用户手指已经划到下一个竞品了，你的JS还没下完。
这背后是Vite的功劳。Pareto从诞生就押注流式优先，没背着历史包袱。Next.js的架构决策要照顾几百万存量项目，船大难掉头。
但别急着喊「颠覆」。Pareto的生态位很明确：数据密集型、流式渲染、对延迟敏感的场景。静态博客、营销页，Next.js依然更省心。
开源基准测试背后的阳谋
整套测试套件挂在GitHub上，任何人能复现。这不是慈善，是精准打击——用可验证的数据替代口水战。
团队放了个具体场景：SaaS仪表盘峰值10000 req/s。按他们的测算，Pareto需要的服务器数量是Next.js的六分之一，React Router的三分之一。云厂商按实例计费的话，这笔账CFO能看懂。
启动命令倒是极简：npx create-pareto my-app，三步进开发模式。但迁移成本才是隐形门槛。Next.js的存量项目、Vercel的生态绑定、团队的学习曲线，都是真实阻力。
Pareto的赌注是：流式SSR会成为默认选项，而非高级特性。Next.js 14推了Partial Prerendering，React Router搞了单文件模式，大家都在往这个方向挤。区别只在于，有人从第一天就为这个场景设计，有人在兼容旧代码里找平衡。
基准测试的残酷之处在于，它不问情怀，只问数字。当702ms和7.82s摆在一起，技术选型会自我修正。
最后留个缺口：这套测试跑在Node 22、4核Ubuntu上。你的生产环境什么配置？实际业务的水位线，可能比实验室数据更复杂——还是说你已经跑过类似的压测，结果跟这差很远？
热门跟贴