8.现代框架对SEO的深度影响

1. 引言

Next和Nuxt是两个热度和使用度都最高的现代Web开发框架，它们分别基于React和Vue构建，也代表了这两个生态的全栈框架。Next是由Vercel公司开发的React框架，而Nuxt则是Vue的服务器端渲染框架。它们都致力于简化开发流程，提高应用性能，并为SEO优化提供了许多内置功能。

2. Next和Nuxt页面渲染机制

Next和Nuxt都提供了常见的四种渲染方式，SSR、SSG、IRR、SCR。但在细节上有非常大的区别。

1. 服务器端渲染（SSR）：

   • 优点：搜索引擎可以直接抓取完整的HTML内容，有利于SEO快速建立索引。
   • 实现：
     • Next (App Router)：默认所有组件都是服务器组件，自动SSR。
     • Nuxt：通过asyncData或fetch。

2. 静态站点生成（SSG）：

   • 优点：预渲染页面，加载速度快，对SEO非常有利。
   • 实现：
     • Next (App Router)：使用generateStaticParams函数进行静态生成。
     • Nuxt：在nuxt.config.ts中的 routeRules 可直接配置。

3. 增量静态再生（ISR）：

   • 优点：结合了SSG的性能优势和动态内容的新鲜度，有利于SEO。
   • 实现：
     • Next (App Router)：通过在页面文件中导出revalidate变量实现。
     • Nuxt：在nuxt.config.ts中的 routeRules 可直接配置。

4. 客户端渲染（CSR）：

   • 缺点：不利于SEO，因为初始HTML内容较少。
   • 实现：
     • Next (App Router)：使用'use client'指令将组件标记为客户端组件。
     • Nuxt：默认支持。 最终来看两个框架在实际编写的时候都是混合渲染，可以一部分服务端一部分客户端，但纯粹的讨论开发体验的话Nuxt是更自然的写法，不需要特意去处理服务端和客户端边界问题 在页面中只要使用await useFetch + Lazy的属性配置，而哪些组件在客户端渲染，哪些组件在服务端渲染是自动处理的，我们只需要想往常往下写就可以。 这确实也是Vue生态的传统艺能，简单易用强DX，但也会在某些更复杂和特殊场景下这种高度化的封装会带来一些从根本上无法解决的问题。 Next相比之下，写法上会难受不少，一个原因是边界的写法，另外一个是有时候要手动处理水合问题。

3. 两个框架的体验以及Seo问题大合集

3.1. Next App SSR路由跳转缓慢

在整个Next进行路由跳转的时候是会经历这样一个流程

1. 触发路由变更：用户点击链接或通过编程方式触发路由变更。

2. 请求RSC Payload：Next.js首先请求新路由的RSC（React Server Components）payload。这个payload包含了服务器组件的结构和数据。

3. 显示加载状态：在RSC payload请求完成，如果存在loading.js文件，Next.js会显示其中定义的加载UI。

4. 处理RSC Payload：客户端接收RSC payload并开始处理。

5. 流式渲染：如果使用了流式渲染（例如通过React Suspense），部分内容可能开始显示。

6. 客户端组件加载：开始加载和执行标记为 'use client' 的客户端组件。

7. 水合（Hydration）：客户端React开始水合过程，使静态HTML变为可交互的组件。

8. 数据获取：如果有任何客户端数据获取（例如在useEffect中），这些操作会在此时执行。

9. 路由更新完成：新页面完全加载并可交互，loading.js中的UI被新页面内容完全替换。

这就会导致一个非常严重的问题，因为RSC Payload是直接来自服务端，在Rsc Payload完成前是不会有Loading的，就会导致页面停滞一会，尤其是第一次渲染，且prefetch在这种场景也没用，而这段时间是对于用户是没有任何反馈的（如果没有加进度条之类的过度效果），也就是说路由反应晦涩（点一下需要反应）。

如图（3G网速）： ![next loading