引言：官网不是产品，别用同一套技术
很多 SaaS 团队在立项时只问一个问题：「官网和产品能不能共用一套代码？」答案是可以，但「能共用」不等于「该共用」。
官网承担的是营销职能——它要被搜索引擎收录、要被访客秒懂、要被用户在微信群里转发。而 SPA（Single Page Application，单页应用）是给「登录后的产品」量身定制的前端形态：交互密集、需要客户端状态、对 SEO 无要求。把营销官网套进 SPA 的壳子里，等于让一个销售员穿上了工程师的防火服——能穿，但一开口就露馅。
本文从四个维度，拆解为什么 SaaS 官网不建议做成 SPA。
一、SEO：SPA 的多波渲染，让内容迟迟进不了索引
SPA 最大的问题不在「能不能被搜索引擎收录」，而在「多久才能被收录」。
Google 采用**两波索引（two-wave indexing）**机制：第一波先抓取你返回的��始 HTML，第二波再把页面放入渲染队列、用无头浏览器执行 JavaScript 后补抓内容。问题是——
- 你的 SPA 首页返回的往往只是一个
<div id="root"></div>空壳，第一波抓不到任何正文； - 真正的内容要等第二波渲染，而渲染队列可能积压数小时、数天甚至数周；
- Googlebot 执行脚本还有超时上限（渲染预算），复杂的页面可能只渲染到一半就被放弃；
- 大量页面进入「已抓取但未收录（Crawled – currently not indexed）」状态。
结果就是：SaaS 官网辛辛苦苦写好的产品介绍、定价逻辑、帮助文档，在搜索引擎眼里存在感极低。而如果你的产品数据、用户评价是靠异步接口加载的，爬虫极可能完全看不到。
更麻烦的是，很多 SPA 用 hash 路由（#/pricing），把整个站点压成一个 URL，爬虫把整个产品目录当成「一页」处理；而每个页面又需要独立的 HTTP 状态码和 canonical 标签才能被正确解析，SPA 默认做不到。
结论：搜索引擎优先奖励「HTML 里就有内容、JS 只是增强」的页面。SPA 把内容和 JS 深度绑定，等于主动给 SEO 设障碍——你的竞争对手用 SSR 一秒进索引，你要等一周，排名怎么可能抢得过。
二、性能：Core Web Vitals 与首次渲染的「白屏税」
官网的第一屏决定转化，而 SPA 恰恰把最干净的内容藏在了最重的技术之后。
客户端渲染（CSR）的流程是：浏览器先拿到一个几乎为空的 HTML → 下载动辄数百 KB 的 JS 包 → 解析执行 → 才真正渲染出文字、图片和按钮。在移动端，这一串串行请求会带来明显的白屏期（blank white screen）。
一组来自行业测试的数据：
- 主流框架的「Hello World」最小 JS 包都超过 200KB（Next.js 约 248KB、Remix 约 228KB、Nuxt 约 191KB）——这还只是空项目，业务越重，包越大；
- 实测中，大型 SPA 首屏可能要在 JS 包完全解析后才出现内容，白屏时间可达数秒甚至更长；
- Google 官方也承认，多页应用（MPA）在结构上对 Core Web Vitals 更有利——整页跳转能命中更多缓存资源，能改善用于统计的 75 分位分布；
- SPA 的 hydration（注水）会占用主线程，访客可能看到页面「看起来加载完了」，但点按钮毫无响应——这就是被 INP/TTI 惩罚的场景。
结论：对转化至关重要的 LCP（最大内容渲染）、CLS（布局偏移）、INP（交互延迟）三项指标，SPA 默认全部是劣势。而官网偏偏是访客第一次见到你品牌的地方——第一印象就白屏三秒，谁还有耐心注册？
三、社交分享：链接在微信、LinkedIn、Slack 里「无人认领」
官网内容很大一部分流量来自社交分享。你把产品介绍发给客户、发到群里、发到朋友圈——对方看到的缩略图、标题、描述，决定的可是你品牌的门面。
问题是：社交平台爬虫（微信、LinkedIn、X、Slack、WhatsApp）基本不执行 JavaScript。 它们只读取服务器第一次返回的 HTML。SPA 返回的是一张空页面，没有og:title、og:image、og:description，于是——
- 分享出来的是白板或默认占位图，标题写着「React App」或一堆乱码；
- 没有缩略图、没有摘要，点击率直线下降；
- 即便你费劲给 SPA 加了 Opengraph 标签，如果标签不是放在首次响应的 HTML 里，照样失效。
结论：官网的本职就是「被转发」。如果分享出去是一张白板，等于你的销售在朋友圈替你发了一条空广告。而 SSR/SSG 生成的页面，社交爬虫一抓一个准，缩略图、标题、描述全部到位。
四、转化率与心智：每慢一秒，都在烧钱
以上技术问题最终都会落到同一个词上——转化率。
- 有统计显示，页面加载延迟 1 秒，转化率约下降 7%；
- 100ms 的延迟可能带来约 1% 的收入损失；
- 53% 的移动端用户在页面加载超过 3 秒后选择离开；
- 单体 JS 包超过 2MB，在移动端很容易出现多秒的首屏加载。
对于 SaaS 官网，每一秒都对应着真实的注册、试用、成单机会。请权衡一下：用 SPA「省下的开发工时」，是否真的值得用「流失的曝光和转化」去偿还？答案通常是不值。
五、那到底该怎么搭？——SSR/SSG + SPA 混合架构
解决方式不是「放弃一切前端框架」，而是把你真正需要的技术用在正确的地方。主流成熟方案是混合架构（hybrid）：
| 区域 | 建议方案 | 原因 |
|---|---|---|
| 官网的公共页（首页、定价、博客、文档） | SSR 或 SSG（预渲染 HTML） | 内容进索引、秒开、社交缩略图齐全 |
| 登录后的产品区（用户后台/仪表盘 app.copyark.com） | SPA / 客户端组件 | 交互密集、无需 SEO，性能只用保证登录用户 |
业内框架的官方文档也明确认可这一分工：Next.js 官方文档说，营销页用 SSG/SSR 是「最适合 SEO」的选择，而 CSR 更适合「不需要进入搜索引擎索引」的登录后页面。很多时候，你甚至可以在同一个 Next.js 工程里，让/pricing、/blog走服务端渲染，让/app走认证后客户端渲染——代码没多写几行，SEO 和性能问题却迎刃而解。
结语：官网是「门面」，请用「门面」的架构
一句话总结：SaaS 官网不只是「网站」，它是你的销售漏斗。 做漏斗的地方，要的是被看见、被秒懂、能被分享。SPA 省下的是开发的一时半会儿，付出的却是 SEO 排名的长期失利、Core Web Vitals 的不达标、社交分享的白板——这些恰恰是决定 SaaS 早期获客成败的命门。
把 SPA 留给登录后的产品，把 SSR/SSG 留给门面。这个看似「技术洁癖」的选择，往往才是 SaaS 团队做过最划算的一笔技术投资。