#优质博文 #前端
SSR Deep Dive for React Developers

AI 摘要：本文通过案例项目逐步解析 React 中 SSR、预渲染、水合和 SSG 的实现原理、性能成本及优缺点，并探讨无 JavaScript 环境对 SEO 和社交预览的影响。

#react #SSR

via Nadia Makarevich

Developerway

SSR Deep Dive for React Developers

Explore step-by-step how Server-Side Rendering (SSR), pre-rendering, hydration, and Static Site Generation (SSG) work in React, their costs, performance impact, benefits, and trade-offs.

#优质博文 #前端
Why we ditched Next.js and never looked back

AI 摘要：Northflank 团队因 Next.js 的性能和开发体验问题放弃该框架，改用自建 React SSR 方案后实现 4-6 倍性能提升。

本文由云平台服务商 Northflank 团队撰写，分享了他们从 Next.js 迁移到自研 React SSR 方案的全过程。文章首先阐述了团队对性能、可靠性和开发体验的严苛要求，指出 Next.js 在营销站点和实时应用场景中的表现均未达预期。通过对比测试数据（如首屏渲染时间从 2.1s 缩短至 0.5s），团队验证了自研方案在性能上的显著优势。文中批评 Next.js 存在框架定位摇摆、缓存机制低效、编译过程复杂等问题，并揭露了其 Server Actions 功能隐藏的运维成本。最后，团队建议开发者根据实际需求选择技术栈，强调 SSR 并非必须依赖框架实现。

Conclusion
- 反对技术宗教化，提倡根据业务需求选择架构
- 指出 SSR 本质是技术决策而非框架依赖
- 预告后续将开源路由和渲染工具

#SSR #react #nextjs #性能优化

via Will Stewart, Tom Snelling

Northflank — Deploy any project in seconds, in our cloud or yours.

Why we ditched Next.js and never looked back | Blog — Northflank

When we started running into issues with Next.js, we did what any sane team would do: we tried to fix them. Then we tried again. Then we realized the problem was Next.js itself. So we pulled the plug.

#优质博文 #前端 #nextjs #SSR #性能优化 #vps
How much traffic can a pre-rendered Next.js site really handle?

我经常说类似这样的话：“一个预渲染的网站可以轻松地服务数百个并发用户”，因为，嗯，我从未见过它失败。

但是它实际上能处理多少流量呢？我的网站能否真正应对像 Hacker News 首页这样的流量激增？它与服务器端渲染相比如何？而且，为了避开 SSR，我们真的值得费尽周折吗？

我四处寻找关于 Next.js 性能的硬性数据，但令人惊讶的是，可靠的数字很难找到。因此，我在自己的网站上做了一些测试，结果并不像我所预期的。而且，时机恰到好处，我关于谷歌翻译干扰 React 的文章第二天就登上了 Hacker News 的首页。

AI 摘要：预渲染 Next.js 网站在高并发下进行性能测试，对比 SSR 表现，并探讨服务器升级选型问题。

文章内容
本文通过大量实验数据对比了 Next.js 预渲染与服务器端渲染（SSR）的性能。作者首先使用 k6 工具在 VPS 上对预渲染首页进行负载测试，结果显示单页面请求的性能远低于预期，仅能支撑有限的并发访问。文章详细解析了页面加载时各个请求（HTML、CSS、图片、JS 等）带来的额外流量负担，并通过 Docker 水平扩展进一步测试性能提升，结果有限。随后，作者观察到来自 Hacker News 的意外流量峰值，并由此探讨各种替代方案：Cloudflare、Vercel、家用服务器、VPS，最终转向性价比较高的 Dedicated Server。测试表明，专用服务器在处理请求数量和响应速度上均有显著提升，而 SSR 在相同配置下明显吃不消。最后，作者总结出预渲染模式在扩展性上具有明显优势，并预告将来针对“hug of death”现象及其他优化方案进行进一步探索。

via React Status 420

Martijn Hols

How much traffic can a pre-rendered Next.js site really handle? by Martijn Hols

How much traffic can a self-hosted Next.js site handle? I ran load tests, uncovered surprising limits, and compared pre-rendering with SSR.

#react #新标准 #前端 #SSR #vercel
What’s new in React 19

人 工 摘 要
React 19 带来了许多新特性，提升了性能和开发体验。主要更新包括：
1. 服务器组件 (Server Components)：通过服务器渲染组件，加快初次加载时间，减少客户端 JavaScript 传输量，改善 SEO。
2. Actions：新的函数取代传统事件处理程序，支持在客户端和服务器执行。
3. 新的 hook ：如 useActionState 、 useOptimistic 等，简化状态管理与表单处理。
4. 改进的资源预加载：优化页面加载速度。
5. ref as a prop： 不再需要 forwardRef，不再需要 <Context.Provider> 。您可以直接使用 <Context> 。
7. useDeferredValue 中添加了 initialValue 选项。提供后， useDeferredValue 将使用该值进行初始渲染并安排在后台重新渲染，返回 deferredValue 。
8. React 19 将原生提升和渲染标题、链接和元标签，甚至是嵌套组件。不再需要第三方解决方案来管理这些标签。
9. React 19 允许使用优先级 precedence 控制样式表的加载顺序。这使得将样式表放在组件附近更容易，React 只会在使用时加载样式表。
10. 更好的错误报告
- 通过删除重复的错误消息来改进错误处理。（以前，React 会抛出两次错误。一次是最初的错误，第二次是自动恢复失败，然后是错误信息。 ）
- 通过记录单个不匹配错误而不是多个错误来改善水合错误。错误消息还包括有关如何修复错误的信息。

#优质博文 #前端 #react #ssr #nextjs
Shiki 性能优化 - 按需加载语法解析

AI 摘要：这篇文章介绍了如何为 Shiki 代码高亮库实现按需加载语言解析器的功能，以减少加载时间和流量消耗。通过改造现有的组件代码，使其能够在需要时才加载特定的语言模块。此外，文章也探讨了在 Next.js 应用中如何处理 Shiki 组件的服务端渲染问题，以及如何避免页面在首次加载时的布局移动（CLS）。这些优化措施有助于提升页面性能和用户体验。

via innei

innei.in

Shiki 性能优化 - 按需加载语法解析

Shiki 是一个非常优秀的代码高亮库。 https://github.com/shikijs/shiki 众所周知，代码高亮库包含了众多的语言解析器，导致加载比较缓慢，并且加载太多无用的解析器造成大量流量浪费。 这一节我们来实现按需加载 Shiki 需要的语言解析器。 动态加载 开始之前