企业官网的技术选型，这些年常被简化成一道二选一：上 CMS 动态渲染，还是做纯静态页面。找外包公司问价，报动态的说静态"不方便你自己改内容"；报静态的说动态"又慢又贵还没必要"。老板听完只会更糊涂——我到底该选哪个？
其实这个问题问错了方向。真正该问的是：我这个站上的每一个页面，它展示的内容有多久变一次？因为静态与动态的取舍，本质上是"渲染发生在什么时候"的取舍，而这个时间差直接决定了你的网站在移动端的打开速度、在搜索引擎里的抓取表现，以及三年后的维护成本。
这篇把三种渲染方式讲清楚，用可查的性能指标和浏览器官方的门槛值来支撑选择，最后交代一下我们自己是怎么做的（一个跑在生产环境上的混合方案）。文中的门槛值来自 Google 的 Core Web Vitals 定义；页面真实分布数据来自 HTTP Archive 每年发布的《网络年鉴》（Web Almanac）以及 Google Web.dev 对其的引用；而"静态还是服务端渲染"的取舍原则，引的是 Vue.js 与 Next.js 官方文档里的原话——这两家做框架的公司，对自己产品该在什么时候用哪套方案，说得比大多数博主诚实。
一、先把术语讲清楚：三种"页面是怎么来的"
客户端渲染（CSR）：服务器先返回一个几乎空壳的 HTML 加上一大包 JavaScript，浏览器把脚本跑起来之后才把内容拼出来。好处是交互体验顺滑、前端应用化；代价是第一屏必须等 JS 下载、解析、执行完，浏览器在初期看到的是白屏。
服务端渲染（SSR）：每次有人访问，服务器现算一份完整的 HTML 返回。Next.js 的官方描述很直白：SSR 会在"每次页面请求时重新生成页面的 HTML"，因此 CDN 无法缓存该页面，速度会比较慢，但内容始终是最新的。
静态生成（SSG，也叫预渲染）：HTML 在构建阶段就生成好，之后每次访问都直接复用这份现成文件。Next.js 把它标为推荐做法，理由很实际——CDN 不需要额外配置就能缓存静态生成的页面。
而判断该用哪一个，Vue.js 官方文档里有一段几乎可以打印出来贴在会议室墙上的话："如果你调研 SSR 只是为了优化为数不多的营销页面的 SEO（例如 / 、/about 和 /contact 等），那么你可能需要 SSG 而不是 SSR。"同一页还补充了 SSG 的定位：它保留了与 SSR 相同的首屏性能表现，但因为输出的是静态 HTML 与资源文件，花销比 SSR 应用更小、也更容易部署；关键词是"静态"——SSG 只适合提供在构建时就已知、且多次请求之间不会变化的数据，每当数据变了都需要重新部署。
这段话的价值在于，它把很多企业主踩的坑点破了：一家公司官网首页、关于我们、产品介绍、联系方式这四个页面上，有多少内容是真的每天在变的？绝大多数答案是"一个月改一次，或者半年一次"。为了半年一次的更新，去承担每一次访问都现场计算的开销，这笔账从一开始就不划算。
二、性能门槛已经不是"越快越好"，而是有硬指标
2012 年前后，网页优化靠的是经验和直觉；现在它有明确的量化门槛。Google 的 Core Web Vitals 给出了一个"良好"站点应当达到的区间：LCP（最大内容绘制）低于 2.5 秒，首次内容绘制 FCP 低于 1.8 秒，TBT（总阻塞时间）低于 300 毫秒。
而实际大盘表现离这个门槛有多远？HTTP Archive 的数据显示，2025 年 Web 应用的平均首屏加载时间已突破 3.2 秒，而用户在响应超过 2 秒时就会开始产生明显焦虑感。也就是说，今天大多数网站是**整体处在门槛线之外**的。
再看两个特别能说明"静态化为什么有效"的数据。第一个关于 JavaScript：Lighthouse 的统计显示，移动端页面的中位数加载了 162 KB 完全没有被使用的 JavaScript，而在第 90 百分位上这个数字达到 604 KB；这些未使用代码大约占页面加载脚本总量的 35%。这个数字意味着：你网站打开慢，很大一部分原因是它下载了三分之一永远不会执行的代码——而这些代码大多来自"为了做成一个应用"而引入的框架开销，而不是业务本身的需要。第二个关于图片：Google Web.dev 引用《2024 年网络年鉴》指出，73% 的移动网页，其 LCP 元素就是一张图片；在 LCP 表现较差的网页里，第 75 百分位的 LCP 图片在客户端的加载延迟达到 1,290 毫秒，这个数字"超过了快速体验预算的一半"；同时有 35% 的图片，其 URL 在初始 HTML 响应里根本检测不到（既不在 <img src> 里，也没有 preload 声明），导致浏览器的预加载扫描器无法尽早发现它们；而只有 15% 的合格网页使用了 fetchpriority 属性去给关键资源提优先级。
把这三组数字连起来看，结论非常明确：那 35% "在初始 HTML 里看不见"的图片，正是客户端渲染的典型后果——HTML 送过来时是空壳，图片地址要等 JS 跑起来才出现在 DOM 里，浏览器再怎么优化也只能干等。把内容写进初始 HTML，就是最朴素也最有效的性能优化，而静态生成恰好天生做到了这一点。
三、什么时候必须动态：别把结论用反
静态不是万能答案，反过来用也会出事。以下三类页面，静态化是自找麻烦。
第一类是内容必须实时准确的页面：库存、价格、订单状态、账户余额、任何用户专属数据。Vue 官方那句限定说得很清楚，SSG 只能用于"数据在构建期间就是已知的、并且在多次请求之间不能被改变"的场景。把实时数据硬做成静态，你会得到一个大号的错误信息展示板。
第二类是带写入动作的交互：表单提交、登录、后台管理、在线下单。这些走的是服务器逻辑，与页面用哪种渲染方式无关，它们本来就该动态。
第三类是页面数量极大且高频变动的情况。静态生成的成本随页面总数与变更频率上升——每次变更都要重新构建。如果一个站有几万个 SKU 页、每小时都在改价，全站重新生成的时间开销会盖掉它带来的收益。
反过来，企业官网里最常见的九到十个栏目——首页、关于我们、产品与服务、解决方案、新闻案例、联系我们、招聘、行业观察页——都属于"内容型、低频变更、SEO 敏感"，恰好是静态最能打的区域。
四、我们自己的做法：动态后台 + 静态前台
与其纸上谈兵，不如说一下美辰这套站群跑在生产环境上的结构，因为它正是上面那个"二选一"的第三种答案。
网站的内容管理端是标准的动态系统：文章、案例、服务页、SEO 元数据都在后台维护，编辑与发布走数据库，需要权限、需要表单、需要实时保存，这些一点都不静态。但对外提供访问的那一层不是动态页面——一条命令会把全站内容渲染成纯静态 HTML，按域名分发到各自的站点目录，服务器直接把这些文件交给访客和搜索引擎。
这样做的收益是具体的。第一，访客拿到的是完整的初始 HTML，不需要等 JS 拼装，首屏与 LCP 天然占优，也顺手解决了前面说的"35% 图片 URL 初始不可见"这个问题。第二，多个域名、多套语言的站点可以共用同一份内容库：一处维护、多站生效，不必为每个域名单独搭一套程序，运维面大幅收窄。第三，静态文件对抗流量波动的能力远高于动态渲染——不需要缓存中间件，也不存在数据库被打穿的风险。第四，也是最直接的一点：对搜索引擎友好，抓到的就是完整页面，不存在"爬虫得先执行 JS 才看得见内容"这一层不确定性。
代价当然要说清楚：内容一改，静态副本必须重新生成，否则线上看到的还是旧页面。这个坑我们踩过，后来把它固化成一条硬规矩——改完后台内容或模板，立刻重跑生成命令，不接受"我以为已经生效了"。对企业客户来说，这条纪律应当写进交付验收标准里，因为它就是"动态后台 + 静态前台"这个方案唯一的运维复杂度所在。
这套做法并不是我们把静态吹成万能。我们的看板类页面（比如站群运行实况那种需要真实数据的模块）仍然是动态取数的；后台本身完全是动态系统。真正的经验只有一句：同一个网站里，不同页面该用不同的渲染策略——需要 SEO 与速度的内容页走静态，需要实时与写入的功能页走动态。Next.js 把这叫"混合渲染"，而它被官方列为可用能力而不是实验特性，本身就说明这不是妥协方案，而是成熟方案。
五、一份可以直接用的决策清单
如果你正在为企业官网或者多语言站群定技术方案，把下面这几个问题按顺序过一遍，答案基本会自己浮出来。
先量页面，不要先选框架。把全站页面列出来，给每个标注"内容多久变一次"。半年一变和每分钟一变的页面混在同一套架构里，是成本和性能双输的开始。
用硬指标验收，不要听形容词。合同或验收单上写 LCP、FCP、TBT 的具体阈值，而不是"打开要快"。移动端 LCP 压到 2.5 秒以内是有共识、可测量、能被第三方工具复现的目标；写不出数字的性能承诺，等于没写。
问清"改了内容之后多久能生效"。这一问直接暴露对方是纯静态、纯动态还是混合方案，以及他们的发布流程是否可控。静态方案必须回答"重新生成的动作由谁触发、多久跑一次"；答不上来的，会在你第一次临时改价时出问题。
看后台是不是给非技术同事用的。官网真正的长期使用成本不在建设费，在改内容的效率。如果每次换张 banner 都要找开发，三年下来这笔沟通成本会远超当初省下的建站钱。
把多站、多域名的维护成本一次问完。如果未来要做区域站、行业站、外贸站矩阵，务必在选型阶段就问：新增一个域名是复制一套代码，还是在同一套内容库里加一条站点档案？这两种答案的长期成本相差极大。
回到最初那个二选一。真正的答案是：企业官网的绝大多数页面应该静态化，剩下那一小撮真正需要实时和交互的页面才动态。判断依据不是技术偏好，而是每个页面的内容变更频率。把这条线画对了，你的官网会同时拿到首屏速度、抓取友好度和低运维成本；画错了，就只能在三者之间来回取舍——而大多数网站的慢与贵，就是这么来的。
