在 React 单页应用里折腾了大半年我最终下定决心把核心站点的渲染层整体切换到 Next.js目标只有一个解决首屏加载过慢的问题。如果你接触过服务端渲染一定见过那些“首屏直出”“SSR 零配置”的宣传词但真正落到业务上从数据海底捞一个接口、改一段生命周期、验证一次 LCP 达标每个环节都有不少坑。这篇文章就是我从“CSR 白屏 5 秒”到“SSR 首屏 1.2 秒”的完整实战记录完整拆解 Next.js 服务端渲染的核心原理、改造步骤和性能调优手段适合卡在首屏性能瓶颈、正在评估 SSR 方案或打算用 Next.js 重构项目的团队参考。我先说结论服务端渲染不是银弹但它确实是解决首屏过慢最直接的路径。优化前我的页面在低端 Android 机上 Lighthouse Performance 只有 43 分LCP 4.8 秒FCP 2.9 秒切换到 Next.js SSR 并配上一套合理的缓存和加载策略后同一台测试机上 LCP 降到了 1.4 秒Performance 91 分。整个过程我踩了不少坑文末我也整理了一份常见问题速查表希望能帮你少走弯路。1. 首屏加载过慢的根因与可量化指标1.1 为什么传统 CSR 会导致首屏慢在分析 Next.js 之前我们先回到最朴素的“慢”上。传统 React 单页应用CSR的页面加载链路是这样的浏览器先向服务器请求一个 HTML 文档这个文档通常只有一个空的 root 节点和一堆 script 标签然后浏览器继续下载所有 JavaScript 文件再解析、执行这些脚本最后 React 才在浏览器端把虚拟 DOM 渲染成真实 DOM。这段链路有三个天然的性能瓶颈。第一JS 文件太大。一个中大型业务项目打完包后主 bundle 动辄 1MB 起步gzip 后也有 200KB 以上这在弱网环境下下载就需要好几秒。第二请求瀑布流。很多页面的首屏数据是在 React 组件挂载后才通过 useEffect 发起的这意味着 HTML 加载完、JS 下载完、React 执行完、数据请求发出去、数据返回、组件重新渲染整个链路是串行的层层叠加白屏时间特别长。第三浏览器主线程长时间被 JS 解析和执行占用即使用户看到了首屏内容也无法立即交互这对应的是 TTI可交互时间指标糟糕。我在优化前统计过自己业务的请求瀑布流HTML 文档 200msJS 下载 1.8sJS 执行 900ms首屏数据接口 600ms渲染 300ms加起来接近 4 秒才出现首个有意义的画面这还不算接口慢和图片加载。这 4 秒里用户看到的就是白屏或 loading这在移动端尤其致命。1.2 用 FCP、LCP 和 TTI 量化首屏问题优化之前你要先把“首屏慢”变成可量化的数字否则改完没法验收。我比较推荐关注三个指标FCPFirst Contentful Paint页面上出现第一个文本或图片的时间代表用户“终于看到东西了”LCPLargest Contentful Paint页面上最大内容通常是一张图或一大段文本绘制完成的时间代表用户“看到主要内容了”TTITime to Interactive页面完全可交互的时间需要结合 FCP 和长任务分析反映操作卡顿情况。这三个指标的测量工具实验室数据用 Lighthouse 6.0 以上版本线上真实数据用web-vitals库。你不需要关心底层的 PerformanceObserver 细节直接安装web-vitals在_app.tsx里上报即可import { reportWebVitals } from next/web-vitals; reportWebVitals((metric) { console.log(metric.name, metric.value); // 这里可以接入自己的监控平台比如发送到日志服务 });我当时的优化目标定得很朴素LCP 从 4.8s 降到 2.5s 以内FCP 控制在 1.8s 以内TTI 不超过 3.5s。目标要写在卡片上后面每个优化动作都对着这些数字看效果。2. Next.js 渲染模式选型SSR、SSG 还是 ISR2.1 三种渲染模式的核心原理对比Next.js 能解决首屏问题本质上是把“把 JS 渲染 HTML”这件事从用户的浏览器搬到了服务器。它根据渲染时机不同提供了三种模式这里我建议先理解原理再决定用哪种服务端渲染SSR每次用户请求页面时服务器都动态执行 React 组件生成完整的 HTML 返回给浏览器。浏览器收到的就是带内容的完整页面不需要等待 JS 执行就能看到首屏。静态站点生成SSG在构建时把页面渲染成静态 HTML部署到 CDN 上。用户请求时直接返回静态文件速度最快但因为完全静态不适合内容频繁变化的场景。增量静态生成ISR在 SSG 的基础上允许页面在后台按需重新构建把“静态页”和“动态数据”做了一个折中。用户先看到旧版本后台重新生成新版本下次请求就是新内容。我用一个表格直观对比一下模式渲染时机数据新鲜度响应速度适用场景SSR每次请求实时渲染实时中等受服务器性能影响个性化页面、实时数据、登录态SSG构建时渲染一次构建后固定极快可走 CDN博客、文档站、营销页ISR构建时渲染按需重新生成可配置的延迟更新极快可走 CDN电商商品页、新闻列表、半动态内容2.2 什么场景才真正需要 SSR我见过一个比较常见的错误一提到首屏慢就盲目把所有页面改成 SSR。SSR 是有代价的它让每次请求都变成了一次服务器端渲染计算服务器压力会明显上升而且如果服务器到数据库或第三方 API 的链路慢TTFB首字节时间会很难看。我做选型时的判断标准有三条。第一页面是否有动态数据。纯展示型落地页直接上 SSG没必要动用服务器。第二数据实时性要求多高。允许 60 秒乃至几分钟的延迟ISR 是性价比最高的只有像或者“当前用户专属数据”这种必须实时拿最新值的才值得上 SSR。第三SEO 和首屏体验是否强依赖直出内容。内容型站点、电商详情页明显受益于直出 HTML而后台管理系统这类强交互应用首屏渲染压力不是核心矛盾SSR 反而会让开发复杂度上升。我的实际选择是首页、详情页用了 SSG ISR需要登录态的页面和搜索结果页用了 SSR其他工具型页面保持纯客户端渲染。这是成本和收益平衡后的结果并不是一味追逐全站 SSR。3. 实战落地从 CSR 到 SSR 的完整改造3.1 初始化 Next.js 项目与目录结构规划我以实际改造的“博客列表页”来完整演示整个链路。首先初始化一个 Next.js 项目这里使用 App Router它是 Next.js 13.4 之后默认推荐的方式npx create-next-applatest ssr-demo --typescript --eslint --app --tailwind --src-dir执行后会生成一个src/app的目录结构。App Router 下的核心思路是每个目录代表一个路由目录下的page.tsx就是这个路由的页面组件它默认是服务端组件Server Component也就是天然运行在服务器上的代码。这意味着你可以直接把数据请求写在页面组件里不需要 useEffect。目录结构我规划如下src/ app/ page.tsx // 首页列表 article/ [id]/page.tsx // 文章详情页 layout.tsx // 全局布局 loading.tsx // 路由级 loading components/ lib/ api.ts // 数据请求封装这里有一个容易被忽视的细节layout.tsx里如果有需频繁变化的全局数据会影响所有子页面的 SSG 静态化所以我建议把布局拆得克制一点尽量不要在根布局里放个性化数据。3.2 核心改造把数据请求从客户端移到服务端以文章列表页为例改造前使用纯客户端请求的伪代码大概是这样的// 改造前CSR——useEffect fetch export default function HomePage() { const [list, setList] useStateArticle[]([]); useEffect(() { fetch(/api/articles).then(res res.json()).then(setList); }, []); return ArticleList list{list} /; }这段代码在浏览器里执行时页面先是空白的等 JS 加载完、fetch 完成、setState 触发渲染后列表才会出现。每次刷新都要重复这个过程。改成 App Router Server Component 之后// 改造后SSR——直接在服务端组件里读取数据 import { ArticleList } from /components/ArticleList; // 这个 async 函数直接运行在 Node.js 服务器上 export default async function HomePage() { const list await fetchArticles(); return ArticleList list{list} /; }你可能会觉得这没什么区别不都是先拿数据再渲染吗但关键区别在于执行位置。改造后的代码是在服务器上完成 fetch 和渲染的浏览器最终拿到的是一段已经包含完整 HTML 的文档用户不需要等待任何 JS 下载和执行就能直接看到文章列表。从 Network 面板看HTML 响应内容从原来的一行空格变成了几百 KB 的真实内容。如果你还在用 Pages Router对应的写法是getServerSidePropsexport async function getServerSideProps() { const list await fetchArticles(); return { props: { list } }; } export default function HomePage({ list }) { return ArticleList list{list} /; }两种写法在“解决首屏白屏”这件事上效果一致区别在于 App Router 的 Server Component 更细粒度允许你在一个页面内混合服务端和客户端组件灵活性更高。3.3 改造后必须检查的请求链路改完之后我先在 Chrome DevTools 的 Network 面板里做了一次加载对比结果非常明显原来HTML 请求后紧跟一个大的 JS bundle 请求然后才是/api/articles数据请求数据返回后页面才渲染现在只有一个 HTML 请求响应里直接带着文章列表内容后续 JS bundle 请求变成了水合Hydration用的不是首屏渲染的前置条件。但这里有一个隐患如果你在服务端组件里请求的接口响应很慢服务器返回 HTML 的时间也会被拖慢导致 TTFB 上升。换句话说SSR 是把“浏览器的负担”转移到了“服务器的负担”但网络瀑布流没有被消除只是被挪了个位置。这时候你就需要做接口缓存和 HTTP 缓存我在第 4 节会详细讲。还要提醒一个常见坑如果页面里用了浏览器专属对象比如window、localStorage在服务端组件里直接访问会直接报错。正确做法是把它们隔离到客户端组件中或者在useEffect里访问或者使用 Next.js 的dynamic动态加载并关闭 SSR。4. 首屏性能的进阶优化手段4.1 用 next/dynamic 做代码分割和按需加载把数据逻辑移到服务端并不代表万事大吉。如果整个页面打包成一个大的 JS bundle浏览器下载 JS 的时间依然会拖慢交互尤其是水合Hydration阶段。此时怎么做代码分割就显得非常重要。Next.js 内置了next/dynamic它基于 React.lazy 做了封装。我通常会把非首屏的组件、弹窗、编辑器、图表库这类“体积大但非关键”的模块都拆出去。使用方式如下import dynamic from next/dynamic; // 这个 Markdown 编辑器只有在被使用时才会下载对应的 JS const MarkdownEditor dynamic(() import(/components/MarkdownEditor), { loading: () p加载编辑器.../p, ssr: false, // 如果组件依赖 window需要关闭服务端渲染 });代码分割带来的收益直接体现在 JS 体积上优化前首屏 bundle 950KB拆分后首屏核心部分只有 340KBMarkdown 编辑器、代码高亮、图表库全部被拆到了异步加载里。Lighthouse 里的“Reduce JavaScript execution time”这项得分从红色变成了绿色。4.2 图片和字体优化隐藏的首屏杀手图片往往是 LCP 指标的大头。一个 2MB 的 hero 图片无论服务端渲染多快浏览器下载图片都要花时间。Next.js 的next/image组件内置了响应式图片、WebP/AVIF 转换、懒加载、优先加载和占位符功能。我建议所有站内静态图片统一换成next/imageimport Image from next/image; export default function Hero() { return ( Image src/images/hero.png alt封面图 width{1200} height{600} priority classNamerounded-lg / ); }priority属性会告诉 Next.js 这张图是首屏 LCP 元素需要预加载不要加loadinglazy。这样能明显缩短 LCP 的时间。非首屏图片则保持默认的懒加载避免首屏带宽被无关图片抢占。字体是另一个容易被忽略的点。默认情况下浏览器下载字体文件时会阻塞文本渲染造成 FOIT不可见文本闪烁。Next.js 的next/font会在构建时自动优化字体并设置了合理的font-display策略import { Inter } from next/font/google; const inter Inter({ subsets: [latin] }); export default function Layout({ children }: { children: React.ReactNode }) { return html langzh-CN className{inter.className}{children}/html; }如果使用第三方字体建议自托管到本地避免额外的字体 CDN 请求造成跨域网络开销和阻塞。4.3 缓存策略与流式渲染SSR 页面虽然解决了首屏白屏但每次请求都实时渲染服务器压力大TTFB 也可能变高。解决方法是分级缓存。第一层是 HTTP 缓存。对于非个性化、允许一定延迟的页面在页面响应头上设置Cache-Control: s-maxage60, stale-while-revalidate120这样 CDN 可以缓存页面 60 秒过期后用户可以看到旧页面同时后台触发重新渲染。Next.js 中可以通过generateMetadata或路由处理器里自定义响应头实现。第二层是数据缓存。在服务端组件里请求接口时我使用 Next.js 内置的fetch扩展能力设置请求复用和缓存时间const res await fetch(https://api.example.com/articles, { next: { revalidate: 60 }, // 60秒内复用同一份数据超过后后台重新验证 });这意味着同一时间段内大量用户访问页面不会重复请求同一个接口而是复用第一次的结果服务器压力大幅下降。第三层是流式渲染。App Router 支持 React 18 的 Suspense 流式渲染服务器可以先把页面的骨架和首屏内容返回给浏览器慢的数据区域用 Suspense 包裹成一个单独的流等数据准备好后再补充发送。举个实际例子我的文章详情页中评论区数据比较慢我就把它单独包在 Suspense 里import { Suspense } from react; import { CommentList } from /components/CommentList; export default function ArticlePage() { return ( article h1文章标题/h1 p文章正文……/p Suspense fallback{div评论区加载中.../div} CommentList / /Suspense /article ); }通过这样的方式文章正文可以第一时间返回并展示用户不需要等待最慢的评论区接口。这个体验在弱网环境下提升非常明显。5. 常见问题与排查技巧实录5.1 常见问题速查表我把这次改造中遇到的典型问题整理成了表格希望能帮那些同样在踩坑的同学快速定位现象可能原因解决方案页面打开后 HTML 是空的浏览器只有 loading用了客户端组件但没关闭 SSR或在服务端组件里用了 useEffect检查组件是否应该是 Server Component把数据请求移到 async 组件中报错Text content does not match server-rendered HTML服务端和客户端渲染结果不一致通常是日期格式、随机数等使用suppressHydrationWarning或在客户端组件中二次挂载后渲染接口被重复请求两次一次在服务器一次在浏览器fetch 逻辑写在了客户端组件里或者 Server Component 与 Client Component 边界没有划分好确认数据请求组件是 Server Component客户端组件用 props 接收数据SSR 页面 TTFB 很长超过 2 秒服务端数据请求慢且没有缓存用next: { revalidate }、HTTP 缓存或上游接口加缓存层首屏 JS 仍然很大没有做代码分割或者依赖了体积大的第三方库使用next/dynamic按需加载用包分析工具检查 bundle 组成低端机上仍然白屏一段时间水合阶段时间长客户端 JS 执行阻塞主线程精简客户端组件层级减少不必要的交互组件必要时对局部组件关闭 SSR5.2 我踩过的几个坑第一个坑是“服务端把接口请求打爆了”。最初我把所有详情页都改成了 SSR但那个页面的数据接口响应要 400ms并且没有任何缓存。上线后流量一上来Node.js 服务器瞬间压力拉满用户的 TTFB 从 800ms 涨到了 5 秒。后来我分了三步解决给接口数据加了 60 秒的revalidate缓存把部分页面的 SSG 开关重新打开给 SSR 页面加了 CDN 边缘缓存。经过这轮调整服务器的请求量直接降了一个数量级。第二个坑是“服务端组件和客户端组件傻傻分不清”。我给页面写了一个接收listprops 的ArticleList组件这个组件内部又用了useState做筛选所以它是一个客户端组件。结果我在这个客户端组件里又直接调用了fetch导致服务端渲染一遍、浏览器又请求一遍数据请求量翻倍首屏时间不升反降。正确做法是数据获取放在服务端组件里客户端组件只负责交互和展示数据通过 props 传递。记住这个边界能省下很多调试时间。第三个坑是“ISR 页面更新不及时”。文章发布后页面上新文章要等 revalidate 时间到了才出现这导致运营人员以为系统出 bug 了。这不是 bug是你的数据新鲜度策略。我的解决方法是在内容管理系统里加入 webhook调用 Next.js 的revalidatePath或revalidateTag接口内容发布后主动触发页面重建这样既有静态页的速度又保证了内容及时更新。5.3 一个值得尝试的混合渲染策略讲了这么多最后分享一个我在生产环境稳定运行了三个月的混合渲染策略。并不是所有页面都适合全套 SSR我最终的分层方案是静态营销页、活动页、帮助中心SSG纯静态输出CDN 缓存文章列表页、详情页SSG ISRrevalidate 60 到 300 秒内容发布后 webhook 触发重建搜索结果页、个人中心、实时数据看板SSR配套 Redis 做数据缓存页面本身不缓存或短缓存复杂交互组件编辑器、图表、地图CSR dynamic按需加载并且关闭首屏 SSR。这套方案兼顾了首屏速度、数据新鲜度和服务器成本。优化完成后整个站点的 Lighthouse Performance 从平均 49 分提升到 90 分以上核心页面 LCP 稳定在 1.5 秒以内TTI 控制在 3 秒内首屏加载过慢的问题才算真正画上了句号。根据我这次改造的个人经验Next.js 服务端渲染解决首屏问题本质上不是“用 A 替换 B”的简单操作而是让渲染时机和数据获取位置更合理能构建时生成的就不要请求时渲染能缓存的数据就不要重复请求能异步流式输出的就不要阻塞首屏。只要想清楚这一层你的项目不管用 App Router 还是 Pages Router都能踩出一条自己的优化路径。希望我的这份实战记录能给你的方案选型和技术落地省下一点时间。
Next.js 服务端渲染实战：从 CSR 白屏 5 秒到 SSR 首屏 1.2 秒
在 React 单页应用里折腾了大半年我最终下定决心把核心站点的渲染层整体切换到 Next.js目标只有一个解决首屏加载过慢的问题。如果你接触过服务端渲染一定见过那些“首屏直出”“SSR 零配置”的宣传词但真正落到业务上从数据海底捞一个接口、改一段生命周期、验证一次 LCP 达标每个环节都有不少坑。这篇文章就是我从“CSR 白屏 5 秒”到“SSR 首屏 1.2 秒”的完整实战记录完整拆解 Next.js 服务端渲染的核心原理、改造步骤和性能调优手段适合卡在首屏性能瓶颈、正在评估 SSR 方案或打算用 Next.js 重构项目的团队参考。我先说结论服务端渲染不是银弹但它确实是解决首屏过慢最直接的路径。优化前我的页面在低端 Android 机上 Lighthouse Performance 只有 43 分LCP 4.8 秒FCP 2.9 秒切换到 Next.js SSR 并配上一套合理的缓存和加载策略后同一台测试机上 LCP 降到了 1.4 秒Performance 91 分。整个过程我踩了不少坑文末我也整理了一份常见问题速查表希望能帮你少走弯路。1. 首屏加载过慢的根因与可量化指标1.1 为什么传统 CSR 会导致首屏慢在分析 Next.js 之前我们先回到最朴素的“慢”上。传统 React 单页应用CSR的页面加载链路是这样的浏览器先向服务器请求一个 HTML 文档这个文档通常只有一个空的 root 节点和一堆 script 标签然后浏览器继续下载所有 JavaScript 文件再解析、执行这些脚本最后 React 才在浏览器端把虚拟 DOM 渲染成真实 DOM。这段链路有三个天然的性能瓶颈。第一JS 文件太大。一个中大型业务项目打完包后主 bundle 动辄 1MB 起步gzip 后也有 200KB 以上这在弱网环境下下载就需要好几秒。第二请求瀑布流。很多页面的首屏数据是在 React 组件挂载后才通过 useEffect 发起的这意味着 HTML 加载完、JS 下载完、React 执行完、数据请求发出去、数据返回、组件重新渲染整个链路是串行的层层叠加白屏时间特别长。第三浏览器主线程长时间被 JS 解析和执行占用即使用户看到了首屏内容也无法立即交互这对应的是 TTI可交互时间指标糟糕。我在优化前统计过自己业务的请求瀑布流HTML 文档 200msJS 下载 1.8sJS 执行 900ms首屏数据接口 600ms渲染 300ms加起来接近 4 秒才出现首个有意义的画面这还不算接口慢和图片加载。这 4 秒里用户看到的就是白屏或 loading这在移动端尤其致命。1.2 用 FCP、LCP 和 TTI 量化首屏问题优化之前你要先把“首屏慢”变成可量化的数字否则改完没法验收。我比较推荐关注三个指标FCPFirst Contentful Paint页面上出现第一个文本或图片的时间代表用户“终于看到东西了”LCPLargest Contentful Paint页面上最大内容通常是一张图或一大段文本绘制完成的时间代表用户“看到主要内容了”TTITime to Interactive页面完全可交互的时间需要结合 FCP 和长任务分析反映操作卡顿情况。这三个指标的测量工具实验室数据用 Lighthouse 6.0 以上版本线上真实数据用web-vitals库。你不需要关心底层的 PerformanceObserver 细节直接安装web-vitals在_app.tsx里上报即可import { reportWebVitals } from next/web-vitals; reportWebVitals((metric) { console.log(metric.name, metric.value); // 这里可以接入自己的监控平台比如发送到日志服务 });我当时的优化目标定得很朴素LCP 从 4.8s 降到 2.5s 以内FCP 控制在 1.8s 以内TTI 不超过 3.5s。目标要写在卡片上后面每个优化动作都对着这些数字看效果。2. Next.js 渲染模式选型SSR、SSG 还是 ISR2.1 三种渲染模式的核心原理对比Next.js 能解决首屏问题本质上是把“把 JS 渲染 HTML”这件事从用户的浏览器搬到了服务器。它根据渲染时机不同提供了三种模式这里我建议先理解原理再决定用哪种服务端渲染SSR每次用户请求页面时服务器都动态执行 React 组件生成完整的 HTML 返回给浏览器。浏览器收到的就是带内容的完整页面不需要等待 JS 执行就能看到首屏。静态站点生成SSG在构建时把页面渲染成静态 HTML部署到 CDN 上。用户请求时直接返回静态文件速度最快但因为完全静态不适合内容频繁变化的场景。增量静态生成ISR在 SSG 的基础上允许页面在后台按需重新构建把“静态页”和“动态数据”做了一个折中。用户先看到旧版本后台重新生成新版本下次请求就是新内容。我用一个表格直观对比一下模式渲染时机数据新鲜度响应速度适用场景SSR每次请求实时渲染实时中等受服务器性能影响个性化页面、实时数据、登录态SSG构建时渲染一次构建后固定极快可走 CDN博客、文档站、营销页ISR构建时渲染按需重新生成可配置的延迟更新极快可走 CDN电商商品页、新闻列表、半动态内容2.2 什么场景才真正需要 SSR我见过一个比较常见的错误一提到首屏慢就盲目把所有页面改成 SSR。SSR 是有代价的它让每次请求都变成了一次服务器端渲染计算服务器压力会明显上升而且如果服务器到数据库或第三方 API 的链路慢TTFB首字节时间会很难看。我做选型时的判断标准有三条。第一页面是否有动态数据。纯展示型落地页直接上 SSG没必要动用服务器。第二数据实时性要求多高。允许 60 秒乃至几分钟的延迟ISR 是性价比最高的只有像或者“当前用户专属数据”这种必须实时拿最新值的才值得上 SSR。第三SEO 和首屏体验是否强依赖直出内容。内容型站点、电商详情页明显受益于直出 HTML而后台管理系统这类强交互应用首屏渲染压力不是核心矛盾SSR 反而会让开发复杂度上升。我的实际选择是首页、详情页用了 SSG ISR需要登录态的页面和搜索结果页用了 SSR其他工具型页面保持纯客户端渲染。这是成本和收益平衡后的结果并不是一味追逐全站 SSR。3. 实战落地从 CSR 到 SSR 的完整改造3.1 初始化 Next.js 项目与目录结构规划我以实际改造的“博客列表页”来完整演示整个链路。首先初始化一个 Next.js 项目这里使用 App Router它是 Next.js 13.4 之后默认推荐的方式npx create-next-applatest ssr-demo --typescript --eslint --app --tailwind --src-dir执行后会生成一个src/app的目录结构。App Router 下的核心思路是每个目录代表一个路由目录下的page.tsx就是这个路由的页面组件它默认是服务端组件Server Component也就是天然运行在服务器上的代码。这意味着你可以直接把数据请求写在页面组件里不需要 useEffect。目录结构我规划如下src/ app/ page.tsx // 首页列表 article/ [id]/page.tsx // 文章详情页 layout.tsx // 全局布局 loading.tsx // 路由级 loading components/ lib/ api.ts // 数据请求封装这里有一个容易被忽视的细节layout.tsx里如果有需频繁变化的全局数据会影响所有子页面的 SSG 静态化所以我建议把布局拆得克制一点尽量不要在根布局里放个性化数据。3.2 核心改造把数据请求从客户端移到服务端以文章列表页为例改造前使用纯客户端请求的伪代码大概是这样的// 改造前CSR——useEffect fetch export default function HomePage() { const [list, setList] useStateArticle[]([]); useEffect(() { fetch(/api/articles).then(res res.json()).then(setList); }, []); return ArticleList list{list} /; }这段代码在浏览器里执行时页面先是空白的等 JS 加载完、fetch 完成、setState 触发渲染后列表才会出现。每次刷新都要重复这个过程。改成 App Router Server Component 之后// 改造后SSR——直接在服务端组件里读取数据 import { ArticleList } from /components/ArticleList; // 这个 async 函数直接运行在 Node.js 服务器上 export default async function HomePage() { const list await fetchArticles(); return ArticleList list{list} /; }你可能会觉得这没什么区别不都是先拿数据再渲染吗但关键区别在于执行位置。改造后的代码是在服务器上完成 fetch 和渲染的浏览器最终拿到的是一段已经包含完整 HTML 的文档用户不需要等待任何 JS 下载和执行就能直接看到文章列表。从 Network 面板看HTML 响应内容从原来的一行空格变成了几百 KB 的真实内容。如果你还在用 Pages Router对应的写法是getServerSidePropsexport async function getServerSideProps() { const list await fetchArticles(); return { props: { list } }; } export default function HomePage({ list }) { return ArticleList list{list} /; }两种写法在“解决首屏白屏”这件事上效果一致区别在于 App Router 的 Server Component 更细粒度允许你在一个页面内混合服务端和客户端组件灵活性更高。3.3 改造后必须检查的请求链路改完之后我先在 Chrome DevTools 的 Network 面板里做了一次加载对比结果非常明显原来HTML 请求后紧跟一个大的 JS bundle 请求然后才是/api/articles数据请求数据返回后页面才渲染现在只有一个 HTML 请求响应里直接带着文章列表内容后续 JS bundle 请求变成了水合Hydration用的不是首屏渲染的前置条件。但这里有一个隐患如果你在服务端组件里请求的接口响应很慢服务器返回 HTML 的时间也会被拖慢导致 TTFB 上升。换句话说SSR 是把“浏览器的负担”转移到了“服务器的负担”但网络瀑布流没有被消除只是被挪了个位置。这时候你就需要做接口缓存和 HTTP 缓存我在第 4 节会详细讲。还要提醒一个常见坑如果页面里用了浏览器专属对象比如window、localStorage在服务端组件里直接访问会直接报错。正确做法是把它们隔离到客户端组件中或者在useEffect里访问或者使用 Next.js 的dynamic动态加载并关闭 SSR。4. 首屏性能的进阶优化手段4.1 用 next/dynamic 做代码分割和按需加载把数据逻辑移到服务端并不代表万事大吉。如果整个页面打包成一个大的 JS bundle浏览器下载 JS 的时间依然会拖慢交互尤其是水合Hydration阶段。此时怎么做代码分割就显得非常重要。Next.js 内置了next/dynamic它基于 React.lazy 做了封装。我通常会把非首屏的组件、弹窗、编辑器、图表库这类“体积大但非关键”的模块都拆出去。使用方式如下import dynamic from next/dynamic; // 这个 Markdown 编辑器只有在被使用时才会下载对应的 JS const MarkdownEditor dynamic(() import(/components/MarkdownEditor), { loading: () p加载编辑器.../p, ssr: false, // 如果组件依赖 window需要关闭服务端渲染 });代码分割带来的收益直接体现在 JS 体积上优化前首屏 bundle 950KB拆分后首屏核心部分只有 340KBMarkdown 编辑器、代码高亮、图表库全部被拆到了异步加载里。Lighthouse 里的“Reduce JavaScript execution time”这项得分从红色变成了绿色。4.2 图片和字体优化隐藏的首屏杀手图片往往是 LCP 指标的大头。一个 2MB 的 hero 图片无论服务端渲染多快浏览器下载图片都要花时间。Next.js 的next/image组件内置了响应式图片、WebP/AVIF 转换、懒加载、优先加载和占位符功能。我建议所有站内静态图片统一换成next/imageimport Image from next/image; export default function Hero() { return ( Image src/images/hero.png alt封面图 width{1200} height{600} priority classNamerounded-lg / ); }priority属性会告诉 Next.js 这张图是首屏 LCP 元素需要预加载不要加loadinglazy。这样能明显缩短 LCP 的时间。非首屏图片则保持默认的懒加载避免首屏带宽被无关图片抢占。字体是另一个容易被忽略的点。默认情况下浏览器下载字体文件时会阻塞文本渲染造成 FOIT不可见文本闪烁。Next.js 的next/font会在构建时自动优化字体并设置了合理的font-display策略import { Inter } from next/font/google; const inter Inter({ subsets: [latin] }); export default function Layout({ children }: { children: React.ReactNode }) { return html langzh-CN className{inter.className}{children}/html; }如果使用第三方字体建议自托管到本地避免额外的字体 CDN 请求造成跨域网络开销和阻塞。4.3 缓存策略与流式渲染SSR 页面虽然解决了首屏白屏但每次请求都实时渲染服务器压力大TTFB 也可能变高。解决方法是分级缓存。第一层是 HTTP 缓存。对于非个性化、允许一定延迟的页面在页面响应头上设置Cache-Control: s-maxage60, stale-while-revalidate120这样 CDN 可以缓存页面 60 秒过期后用户可以看到旧页面同时后台触发重新渲染。Next.js 中可以通过generateMetadata或路由处理器里自定义响应头实现。第二层是数据缓存。在服务端组件里请求接口时我使用 Next.js 内置的fetch扩展能力设置请求复用和缓存时间const res await fetch(https://api.example.com/articles, { next: { revalidate: 60 }, // 60秒内复用同一份数据超过后后台重新验证 });这意味着同一时间段内大量用户访问页面不会重复请求同一个接口而是复用第一次的结果服务器压力大幅下降。第三层是流式渲染。App Router 支持 React 18 的 Suspense 流式渲染服务器可以先把页面的骨架和首屏内容返回给浏览器慢的数据区域用 Suspense 包裹成一个单独的流等数据准备好后再补充发送。举个实际例子我的文章详情页中评论区数据比较慢我就把它单独包在 Suspense 里import { Suspense } from react; import { CommentList } from /components/CommentList; export default function ArticlePage() { return ( article h1文章标题/h1 p文章正文……/p Suspense fallback{div评论区加载中.../div} CommentList / /Suspense /article ); }通过这样的方式文章正文可以第一时间返回并展示用户不需要等待最慢的评论区接口。这个体验在弱网环境下提升非常明显。5. 常见问题与排查技巧实录5.1 常见问题速查表我把这次改造中遇到的典型问题整理成了表格希望能帮那些同样在踩坑的同学快速定位现象可能原因解决方案页面打开后 HTML 是空的浏览器只有 loading用了客户端组件但没关闭 SSR或在服务端组件里用了 useEffect检查组件是否应该是 Server Component把数据请求移到 async 组件中报错Text content does not match server-rendered HTML服务端和客户端渲染结果不一致通常是日期格式、随机数等使用suppressHydrationWarning或在客户端组件中二次挂载后渲染接口被重复请求两次一次在服务器一次在浏览器fetch 逻辑写在了客户端组件里或者 Server Component 与 Client Component 边界没有划分好确认数据请求组件是 Server Component客户端组件用 props 接收数据SSR 页面 TTFB 很长超过 2 秒服务端数据请求慢且没有缓存用next: { revalidate }、HTTP 缓存或上游接口加缓存层首屏 JS 仍然很大没有做代码分割或者依赖了体积大的第三方库使用next/dynamic按需加载用包分析工具检查 bundle 组成低端机上仍然白屏一段时间水合阶段时间长客户端 JS 执行阻塞主线程精简客户端组件层级减少不必要的交互组件必要时对局部组件关闭 SSR5.2 我踩过的几个坑第一个坑是“服务端把接口请求打爆了”。最初我把所有详情页都改成了 SSR但那个页面的数据接口响应要 400ms并且没有任何缓存。上线后流量一上来Node.js 服务器瞬间压力拉满用户的 TTFB 从 800ms 涨到了 5 秒。后来我分了三步解决给接口数据加了 60 秒的revalidate缓存把部分页面的 SSG 开关重新打开给 SSR 页面加了 CDN 边缘缓存。经过这轮调整服务器的请求量直接降了一个数量级。第二个坑是“服务端组件和客户端组件傻傻分不清”。我给页面写了一个接收listprops 的ArticleList组件这个组件内部又用了useState做筛选所以它是一个客户端组件。结果我在这个客户端组件里又直接调用了fetch导致服务端渲染一遍、浏览器又请求一遍数据请求量翻倍首屏时间不升反降。正确做法是数据获取放在服务端组件里客户端组件只负责交互和展示数据通过 props 传递。记住这个边界能省下很多调试时间。第三个坑是“ISR 页面更新不及时”。文章发布后页面上新文章要等 revalidate 时间到了才出现这导致运营人员以为系统出 bug 了。这不是 bug是你的数据新鲜度策略。我的解决方法是在内容管理系统里加入 webhook调用 Next.js 的revalidatePath或revalidateTag接口内容发布后主动触发页面重建这样既有静态页的速度又保证了内容及时更新。5.3 一个值得尝试的混合渲染策略讲了这么多最后分享一个我在生产环境稳定运行了三个月的混合渲染策略。并不是所有页面都适合全套 SSR我最终的分层方案是静态营销页、活动页、帮助中心SSG纯静态输出CDN 缓存文章列表页、详情页SSG ISRrevalidate 60 到 300 秒内容发布后 webhook 触发重建搜索结果页、个人中心、实时数据看板SSR配套 Redis 做数据缓存页面本身不缓存或短缓存复杂交互组件编辑器、图表、地图CSR dynamic按需加载并且关闭首屏 SSR。这套方案兼顾了首屏速度、数据新鲜度和服务器成本。优化完成后整个站点的 Lighthouse Performance 从平均 49 分提升到 90 分以上核心页面 LCP 稳定在 1.5 秒以内TTI 控制在 3 秒内首屏加载过慢的问题才算真正画上了句号。根据我这次改造的个人经验Next.js 服务端渲染解决首屏问题本质上不是“用 A 替换 B”的简单操作而是让渲染时机和数据获取位置更合理能构建时生成的就不要请求时渲染能缓存的数据就不要重复请求能异步流式输出的就不要阻塞首屏。只要想清楚这一层你的项目不管用 App Router 还是 Pages Router都能踩出一条自己的优化路径。希望我的这份实战记录能给你的方案选型和技术落地省下一点时间。
