你并不需要SSR框架,简单Nodejs策略解决Vue应用SEO问题

广告位招租
扫码页面底部二维码联系

当我们用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这样的全栈框架,在国内反而市场很小,起码对于更喜爱浏览器环境的前端的同学,是不感冒的。我们国内的技术和海外的技术存在差异,这是很正常的事,我们应该着眼于问题,以较低的成本解决它,而不是盲目的跟风用复杂的代码架构来创造更多的风险点。

2024-11-20 126 ,

为价值买单,打赏一杯咖啡

本文价值1.26RMB