当我们用react或vue完成应用开发之后，我们还会考虑SEO的问题，对于所有SPA应用而言，SEO都是非常痛苦的，但是从产品市场的角度，SEO是必不可少的。传统的做法是在SPA基础上新增一个与原来SPA（代码层面）完全无关的博客系统，例如挂一个wordpress，再在主站html源代码中有指向该博客站的链接，通过博客站来带动整站的SEO表现。但这种方案会使得技术栈割裂，两个系统甚至无法做深度的融合。相对的，比较理想的做法是，在原始SPA的基础上开辟出类似博客的子目录，既能有大量内容的输出，也能够在同一套技术体系下进行迭代。另一种比较前卫的方案，是采用前端技术SSR或SSG来实现在服务端将原本空无一物的SPA渲染为自带内容的html。这种方案在前端届获得了巨大推崇，并衍生出一大堆SSR或SSG的方案。然而，在我看来，SSR方案存在很多弊病，虽然next.js等框架取得了巨大成功，但是不要忘了，这些框架的目标是为了实现真正意义上的“全栈”开发，而不是为了弥合SPA的不足，因此，不要把next.js等的成功，归结于SSR的成功。本文将从SSR/SSG的问题出发，并结合Vue应用的实际情况，提出一种基于nodejs来为SPA做SEO的方案，希望能够帮助到遇到相同问题的朋友。
SSR/SSG的弊病
首先来聊一聊SSR和SSG。在早些年angularjs的时代，我们做SPA开发，并没有SEO的需求，这些应用大多用在企业级或不对外公开的内部环境中。而随着react和vue等框架的火爆，那些不用在封闭环境中的网站，也开始采用react和vue来进行开发，原因其实是需要我们深思的，一方面社区的蓬勃发展，让我们做技术选型时有更多的考虑，例如组件库的盛行，这些由社区提供的免费基础建设，使得它们在对比时，具有优势；另一方面，随着求职jd上对这些框架的要求，其他的很多技术在发展中被逐渐淘汰，开发人员很多都只会react或vue框架，因此，即使在追求秒开、体验佳的C端应用中，它们也被广泛应用（即使在我看来不应该在这些场景下使用）。也正是这些情况的发展，使得前端界面的开发，越来越多基于vue或react，但这会让企业在面临SEO需求的时候必然出现问题，因此，才出现了SSR的方案。
SSR简单讲就是在服务端通过识别组件内容来组装出对SEO友好的html字符串，直接输出给浏览器展示。与此同时，SSR细分领域还探索出如何加快首屏渲染等细枝末节的技术。从技术原理讲，SSR需要在服务端执行真正的渲染逻辑，它不是简单的字符串拼接，而是照其生命周期启动了渲染程序，经过一系列运行时的运行后，最终得到字符串。不过衍生而来的问题非常多，例如前端应用往往依赖浏览器特定接口，这些程序如何在服务端被执行？前端往往通过ajax拉取数据进行渲染，服务端渲染时如何处理这些异步等待过程？如何解决框架在服务端渲染时所消耗的性能问题？
对于开发人员而言，最让人受不了的是，在客户端跑的好好的，一开始做SSR改造，总会遇到这样那样的问题，这种烦恼有的时候令人炸毛。而且，当SSR服务端运行起来之后，如果公司的运维是另外一个团队，还很有可能因为这类服务不够标准而被运维阻挠或直接驳回。几乎所有的大公司运维团队，都对nodejs的运维感到头疼，上线后各种无法预料的崩溃，从而带来的各种兜底兜底再兜底方案，以及性能上的不如人意，导致整个团队在这件事上不停灭火又无可奈何。这种消耗对开发本身的积极性打击也是存在的，我也是因此而放弃了SSR方案。
为了寻找折中方案，SSG被提出来，简单讲，就是在SSR的基础上，把实时服务端渲染，通过技术调整，实现前置渲染，避免实时渲染所带来的性能问题和稳定性问题。SSG在用户访问时，生成用于构建页面的素材，而这些素材以静态文件的形式存储在磁盘上。生成界面时，则是通过这些素材的拼接来完成。这种方案解决了SSR实时渲染所带来的问题，而且由于以静态文件的形式存储，使得下次用户访问时速度可以比首次访问成倍提升。看上去SSG方案解决了我们的问题，但是当开发人员准备上这套方案时，发现其难度和带来的问题并不比SSR少很多，因为它本质上是在SSR基础上做的改进。对于开发体验而言，SSR所存在的问题，SSG同样存在，同样会令开发者抓狂。在同一段代码中，还要区分服务端和客户端的思维割裂感，使得开发过程痛苦不已。
有人可能会反对，因为next.js等框架已经取得了成功，为什么你竟敢如此大胆，妄加评论？全栈框架，或者类似astro这样的融合框架，它们已经跳脱出前端开发的范畴，它们有自己的范式和硬性规定，你在使用它们时，也会经常感到不爽。对于前端开发人员而言，最舒服的方式，我想还是SPA这种，完全在浏览器环境下运行的方式。既然如此，有没有什么方法，可以让我们完全用浏览器前端开发的思维完成前期开发，不做任何修改的情况下，再附加一套方案，实现可被接受的SEO效果呢？
如何用nodejs为SPA做SEO
Vue社区的SSR和SSG并没有react社区那样火热，可选择方案没有很多，那么，我们就以vue应用的SEO来进行讲解，从而可以让你更好的理解我是如何用简单的nodejs方案实现vue应用的SEO的。这也就意味着，同样的路子，可以被用在其他任何（包括但不限于react）框架上。
基本思路
在开始之前，我们来思考，vue的SPA应用是怎么工作的？在vite项目中，有一个index.html，当完成build之后，这个index.html会被作为模板，插入构建好的js, css入口链接。当我们将dist目录上传到服务器后，用户访问网站，拉取dist/index.html，之后运行js和css。js中包含了vue的启动程序，vue会在#root元素中渲染对应路由的DOM树，用户即可看到对应的界面。
有意思的是，vue不像react一样，要求挂载的根节点内容必须是空的，我们可以把用户看到的界面DOM树中的innerHTML拿出来，并把根节点的部分拷贝出来，贴到dist目录下的index.html中，此时，你在打开dist/index.html会发现看到了用户看到的界面一致的结果。除了在js代码中对html, head等节点有细微操作，生产环境中，几乎所有的变化就在根节点内部的DOM。因此，以SEO为目的，我们只需要以dist/index.html为模板，在根节点内部插入每一个路由对应的内容即可。这样，爬虫每次访问一个url，我们就返回该url完整的html给它；而用户访问该url时，由于js会被执行，vue应用会被启动，覆盖根节点的内容（vue在这点上做的比react好很多，hydrate心智负担很小），用户几乎对改动无感，甚至觉得页面打开更快了。
这个思路和SSG非常相似，都是提前生成好每一个url的完整html。只不过SSG对编程的侵入较大，代码中需要区分client-side和server-side。而本方案的精髓就在于，我们在nodejs层面，以index.html作为模板，根据保存好的内容来填充内部内容，返回含有页面内容的html结果，从而使之具有和SSR几乎一致的效果。而由于nodejs作为中间层，是后置的，相当于在我们原有的代码基础上穿了一层衣服。当我们脱掉这层衣服，拿出原始的代码，它又还原成原始的vue在浏览器跑的SPA代码。这对我们下文做高可用架构来说，几乎是完美的。
具体实施
首先是对index.html做小修改，具体如下：
<style>[v-cloak] { display: none; }</style>
<div id="app" v-cloak><!--vue-app-content--></div>
我们在#app元素内添加了<!--vue-app-content-->注释，它的作用是在后来为nodejs提供插入内容的位置。
另外，我们使用v-cloak来解决页面闪动的问题。当我们在服务端进行渲染时，由于html出来的速度比css文件加载的快，就会导致页面打开时样式没有生效，直到css文件完成加载之后页面才会恢复正常，这个期间，就会出现页面闪动。这对于习惯了vue开发的同学来说并不常见，因为js文件的加载往往慢的多。
接下来是设计一套保存html内容的策略。
在vue代码中，需要做seo的页面内，增加一个上传html的逻辑。当然，这里需要做一些策略，例如只有特定身份的人才能上传，上传前要做一些逻辑判断，如我们通过nodejs层在已经完成服务端渲染的页面上做一些标记，vue代码中发现这些标记就不上传，另外，还可以增加上传前比较预备上传的内容和已经存在内容的hash等等。
总之，我们在vue代码层面，把#app的内容上传到服务端，为后面nodejs在服务端渲染做准备。
async function snapshot(key) {
// 如果该页面已经有seo的keywords了，那么就不再往下处理
if (document.querySelector('meta[name=keywords]')) {
return;
}
const app = document.querySelector('#app');
if (app) {
const innerHTML = app.innerHTML;
const fragment = document.createDocumentFragment();
const div = document.createElement('div');
div.innerHTML = innerHTML;
fragment.appendChild(div);
div.querySelectorAll('[no-snapshot]').forEach((el) => {
el.parentNode?.removeChild(el);
});
const text = div.innerHTML;
fragment.removeChild(div);
const hash = md5(text);
const [, data] = await asyncOf(getSnapshot(key));
// 当hash不同时，表示内容发生了变化，因此提供新的快照
if (data && data !== hash) {
await setSnapshot(key, text);
}
// 没有快照
else if (data === null) {
await setSnapshot(key, text);
}
}
}
在服务端，我们需要设计一个store（或者文件）来存储由上述函数上传的快照内容。存储的key基于url做md5处理。下面我们就会把这些保存好的内容块和前面的index.html进行融合，实现服务端SEO化输出。
接下来就是nodejs层面的修改。
这里指如何让nodejs输出完整的html内容，你还需要自己去做一些存储方面的设计。
我们基于express架设了nodejs中间层，用以完成不同url路由的输出。
app.get('/*', async (req, res, next) => {
const locale = getLang(req);
// 当无法判定语言时，返回原始vue的启动页面
if (!locale) {
next();
return;
}
const { path } = req;
const uri = `${path}?lang=${locale}`;
const key = md5(uri);
const snapshot = await getSnapshot(key);
// 只有当存在快照时，才进行SEO的处理，否则不处理
if (!snapshot) {
next();
return;
}
const index = getIndex();
// seo keywords, description，这个部分在上文没有讲到，阅读代码很容易理解
const i18n = new I18n({ locale });
const title = i18n.t('SITE_TITLE');
const subtitle = i18n.t('SITE_SUBTITLE');
const description = i18n.t('SITE_DESCRIPTION');
const keywords = i18n.t('SITE_KEYWORDS');
const seo = index.replace(/<title>.*?<\/title>/, `<title>${title} | ${subtitle}</title>`).replace('<!--site-meta-->', `<meta name="keywords" content="${keywords}" />\n <meta name="description" content="${description}" />`);
const html = seo.replace('<!--vue-app-content-->', snapshot);
res.set('Content-Type', 'text/html');
res.send(html);
});
将上面这条路由规则，放置在express.static之前，那么当执行到上面的next()时，就会回落到原始的vue SPA入口。
最后是nginx配置优化。
我们原先可能只是将/api/反向代理到了nodejs服务上，现在，我们需要把要做SEO的也反向代理到nodejs服务上，例如网站首页。
location = / {
...
}
location ~ ^/(api|blog)/ {
...
}
上面列举了几个，你还可以根据你自己的需求来添加。
高可用服务架构设计
正如前文所说，nodejs的服务被广大运维人员嫌弃，如何才能突围而出呢？我们要用云原生等把nodejs服务封装起来，让运维干自己熟悉的活，而不用管具体nodejs服务的内部业务逻辑。同时，我们要解决nodejs服务挂掉后，如何保障应用还能继续使用的问题，也就是我们要有兜底方案。
首先，我们要从不使用任何方案的原始前端部署方案出发。
上面是我们原始的vue SPA应用部署后的请求流程。如何在不影响原有可用性的基础上进行改造呢？我的方案如下：
这套方案的特色，就是原来前端的同学该怎么发版本还是怎么发版本，完全不需要考虑新增的逻辑。起主要渲染作用的nodejs程序，在开发层面反而是一条旁路，对主线开发没有丝毫影响，也不会对用户侧的可用性产生任何副作用，甚至性能问题都不需要考虑。相比于SSR框架需要在服务端进行运行时的渲染，本方案则完全是字符串替换如此简单的操作，性能上属于是碾压级对比。另外，对比SSR框架而言，这套方案还有一个好处，就是想要做SEO的url才走nodejs渲染，不想做的，可以直接回来走老的流程。相比SSR或SSG，这套方案理解起来很简单，成本也低很多。
结语
对于读者朋友们而言，看到如此简单却行之有效的方案，可能会好奇，难道它不存在什么缺陷吗？我想，这要看具体的场景。对于需要SEO的站点而言，往往是企业的门户、产品类网站等，每一套技术方案都有自己的适用场景，你不可以在超出它本质目标的基础上，在其他方面对它做太多的要求。而本文提出的方案，主打一个快速、高效、简单容易理解、成本低。我知道在海外，很多创业公司都是nodejs全栈，但我们国内的很多企业，但凡有自己的技术班子，往往都是前后端分离，因此，类似next.js这样的全栈框架，在国内反而市场很小，起码对于更喜爱浏览器环境的前端的同学，是不感冒的。我们国内的技术和海外的技术存在差异，这是很正常的事，我们应该着眼于问题，以较低的成本解决它，而不是盲目的跟风用复杂的代码架构来创造更多的风险点。
