之前由于工作中用不到ssr和seo相关知识，对这方面也只是略有了解，仅限于ssr服务端渲染有利于seo搜索。最近被测试同学问到了，只能简单聊一下，下来后顺便查询了相关知识点，记录分享于此。
QA：什么是SSR技术？
SSR是一种流行的前端技术策略，主要是为了改善首次页面加载时间和搜索引擎优化。在SSR中，当用户请求一个页面时，页面的初始内容是在服务器上生成的，然后再发送到客户端浏览器。这样用户就能更快地看到页面的内容，而不是等待客户端JavaScript库（例如React或Vue）加载和执行后才渲染页面。
详细拆分具体步骤如下：
1. 用户请求页面：
当用户请求一个网页时（例如通过输入URL或点击一个链接），请求被发送到服务器。
2. 服务器生成HTML：
在服务器上，应用程序（通常使用一个前端框架，如React, Vue等）会生成这个页面的HTML。这涉及到运行JavaScript代码，访问API获取数据，以及将数据插入模板来生成HTML。
3. 发送到客户端：
生成的HTML页面被发送回发出请求的客户端浏览器。
4. 浏览器展示内容：
客户端浏览器接收到HTML，并渲染页面内容。用户现在可以看到快速加载的页面，而不用等待所有的JavaScript文件和数据加载完毕。
5. 客户端接管：
随后，客户端的JavaScript被加载并执行。此时，页面变得可交互。前端框架“接管”页面，用户之后的所有交互（例如，点击按钮、链接、或表单提交）通常会被客户端处理，不再进行全页面的重新加载。
6. SPA 模式：
当页面的初始内容被加载和渲染之后，网站通常作为一个单页应用程序(SPA)运行，即所有的页面导航和用户交互都不再触发全页面刷新，而是利用AJAX或Fetch API来异步加载后续数据。
当然，服务端渲染也有自己的优缺点：
优点：
- 快速显示内容：用户不需要等待所有JS文件和数据加载完成，就能看到页面内容。
- SEO：搜索引擎能够更好地索引服务器渲染的页面，因为爬虫能直接抓取到完整的渲染内容。
缺点：
- 服务器压力：服务器需要为每一个请求都生成页面，这可能会增加服务器的计算负担。
- 复杂性：SSR的实施通常涉及到更多的技术和代码复杂性（比如，要解决浏览器和服务器代码的同构问题）。
- 运行时问题：在服务器端和客户端之间保持代码的一致性（同构）可能引入一些运行时问题。
QA：那么服务器渲染是不是意味着服务端会渲染并加载项目的所有前端页面，并一次性返回给前端呢？
不是的，SSR 并不意味着服务端加载了页面的所有资源，它主要包括：
-
生成HTML结构：在服务器上生成当前请求页面的HTML结构，并嵌入所需的初始数据。
-
CSS处理：通常，CSS也会在服务器端处理，并且内联在生成的HTML中。
-
初始数据加载：服务器可能会加载所需的初始数据，这样在生成的HTML页面中，可以直接渲染出完整的内容，而不是占位符。
-
JavaScript脚本：虽然核心内容和样式已在服务器端渲染，但客户端依然会加载JavaScript脚本，以便页面在客户端变得可交互。
可以知道只有首屏页面是在服务端渲染好的，这样有利于降低首屏加载时间，因为浏览器可以在下载完HTML之后立即开始渲染页面。一旦页面在客户端被加载并且JavaScript被解析和执行，前端框架将在客户端接管页面，进一步的导航和用户交互将由客户端管理，类似于单页面应用(SPA)的行为。
QA：假如用vue框架的时候，服务端是如何解析vue代码的呢？
对于特定的语法，其实是需要特定的框架来解析的，vue语言需要Nuxt.js来作为后端解析器，Nuxt.js为Vue.js提供了一个抽象层，使得Vue组件可以在服务器端运行和渲染。
结合Nuxt，以上首屏资源加载过程如下：
1. 请求处理
当用户请求一个页面时，请求首先到达服务器，并由Nuxt.js接管。
2. 服务器端渲染
Nuxt.js在服务器上执行Vue代码。它运行Vue组件的asyncData和fetch方法，用于在服务器端获取所需的数据。
- 随后，它执行Vue组件的渲染方法，生成HTML内容。CSS也在此阶段被处理，并可选择性地嵌入到HTML中。
4. 发送HTML到客户端
生成的HTML（包含了已解析的数据）和CSS被发送到客户端的浏览器。用户此时能看到完全渲染的页面。
5. 客户端接管
随着JavaScript的加载和执行，Vue在客户端“激活”，接管页面的交互操作。Vue会识别服务器渲染的HTML，并附加事件处理程序，而不重新渲染DOM，这被称为“客户端混合”。
6. SPA模式
之后，任何页面导航（例如，通过Vue Router）通常以单页应用程序（SPA）的形式进行，即，页面的部分内容通过AJAX异步加载，而不是重新加载整个页面。
7. 状态管理（可选）
对于需要全局状态管理的应用，Nuxt.js通常会和Vuex（Vue的状态管理库）一起使用。Nuxt.js提供了将服务器端的状态传递到客户端的机制。
QA：SSR服务端渲染只针对首屏加载么？
是的，服务端渲染通常主要关注首屏渲染，这是因为SSR的主要优势之一就是能够加快首屏的加载速度，并为搜索引擎优化（SEO）提供更多的帮助。以Vue为例，首屏加载完毕之后，客户端的JavaScript代码会被下载和执行，Vue会在客户端接管页面的管理，增强页面的交互性。一旦Vue在客户端激活，并且接管了页面的管理，应用的后续导航和交互通常会作为一个单页应用程序（SPA）来进行。此时，页面不再执行服务端渲染，而是在客户端动态更新。为后续的页面导航和内容更新，Vue会动态地向服务器请求数据（例如，通过AJAX）并在客户端更新页面的内容，而不是重新从服务器加载整个新页面。
QA：仅仅为了首屏加载效率，就使用SSR技术，成本是不是太高了？
确实，实现服务器端渲染（SSR）通常会带来额外的复杂性和成本，决定是否使用SSR通常取决于项目的具体定位和目标受众。
QA：SEO的工作原理是怎样的，SSR渲染为啥有利于SEO？
1. 搜索引擎爬虫的工作原理
- 抓取和解析：搜索引擎爬虫首先抓取一个页面的HTML内容，然后解析这些内容以理解其结构和信息。
- 内容索引：爬虫会索引页面的内容，并在其数据库中存储关于页面内容和结构的信息，以便在将来用户查询时快速检索。
- 执行JavaScript（有限的） ：一些现代的搜索引擎爬虫，例如Googlebot，能够执行JavaScript，但这样做会消耗更多的资源，也可能不如直接解析HTML那样精确。
2. 服务器端渲染（SSR）对SEO的好处
- 即时可用的内容：SSR发送到客户端的HTML已经包含了首页的所有内容，这样搜索引擎爬虫就能直接抓取和理解这些内容。
- 快速的加载速度：SSR页面通常更快地展示主要内容，这不仅对用户体验有利，也是搜索引擎评价网站性能的一个重要指标。
3. 对比服务端渲染，客户端渲染（CSR）可能对SEO不利的方面
- 延迟的内容渲染：CSR通常需要等待JavaScript脚本下载、执行并且渲染内容，这可能导致搜索引擎爬虫在第一次抓取时看不到页面的实际内容，比如一些依赖js执行填充的内容。
- 资源密集型：即便爬虫能够执行JavaScript，这通常更加资源密集型，且可能不会获取到页面的完整内容，尤其是如果内容是依赖于用户交互或其他异步操作的情况下。
- 可能的解析问题：即使爬虫能执行JavaScript，也可能因各种原因解析不准确，比如代码的兼容性问题或运行时错误等。
尽管服务器端渲染对SEO更有利，但客户端渲染仍然需要通过采用合适的策略和工具来实现更好的SEO，SSR渲染只是优化SEO的一个方面。
QA：爬虫抓取一个页面的html，这个动作，是从哪里抓取？服务端么？
是的，爬虫抓取一个页面的HTML是从服务器端进行的。当爬虫（比如Googlebot）决定要抓取一个页面时，它会发起一个HTTP请求到相关网站的服务器。这个过程包括以下几个步骤：
-
发送请求：爬虫向目标网站的服务器发送一个HTTP GET请求，请求的是页面的URL。
-
接收响应：服务器响应这个请求，并返回页面的HTML内容。
-
解析内容：爬虫接收到响应后，将解析返回的HTML内容，理解其结构、内容及其他相关信息。
-
索引内容：爬虫将解析出的内容索引到搜索引擎的数据库中，便于将来的搜索查询。
如果一个网站使用的是服务器端渲染（SSR），那么服务器会返回一个包含完整内容的HTML文档。如果是客户端渲染（CSR），服务器可能只返回一个包含基本结构的HTML文档，真实的内容将通过客户端JavaScript在浏览器中填充。对于一些能够处理JavaScript的现代爬虫来说，它们将尝试执行JavaScript来获取和理解动态加载的内容。但这一过程可能不如直接解析完整HTML内容那么准确和高效。因此，对SEO要求较高的站点通常倾向于使用SSR或使用预渲染的策略来确保爬虫可以直接获取到内容丰富的HTML。
QA：爬虫是如何知道该请求哪个网站的地址呢？
爬虫发现和决定抓取哪些网站地址（URL）通常基于以下几种方式和策略：
1. 通过链接抓取
- 爬取现有的URLs：爬虫会抓取已知的、已经被索引的网页URL，然后提取这些网页上的所有其他链接（即a标签的href属性指向的URL）。
- 递归爬取：通过这种方法，爬虫不断发现新的链接，然后继续爬取这些新发现的链接上的其他链接，以此类推，形成一个递归的抓取过程。
2. 网站地图（Sitemaps）
- 提供URL列表：网站所有者可以通过创建XML网站地图来告诉爬虫哪些页面是可以被抓取的。一个网站地图通常包含一个网站上所有希望被搜索引擎索引的URL的列表。
- 提交到搜索引擎：这些网站地图可以通过网站管理员工具（例如Google Search Console）提交给搜索引擎，以便搜索引擎爬虫知道哪些URL可用于抓取和索引。
3. 从其他源获取URLs
- 从其他网站或目录获取：爬虫也可能获取其他网站或在线目录上列出的URL，从而开始抓取新的网站内容。
- 社交媒体和其他平台：爬虫可能会扫描社交媒体平台和其他在线平台，以找到新网站或新内容的链接。
4. 通过用户提交
- 搜索引擎提交：一些搜索引擎允许用户手动提交新的URL，从而引导爬虫去抓取这些新提交的URL。
- 使用API：某些搜索引擎可能也提供API，允许开发者或网站拥有者提交新的URL或网站地图。
5. 监控变化
- 检测变化：对于已知的URL，爬虫可能会定期重新抓取这些URL，来检测网页内容是否有变化，确保索引的内容是最新的。
通过这些方式和策略，搜索引擎的爬虫能够不断地发现新的URL，更新旧的URL，从而维护和更新其搜索索引。
总结：
- SSR不是整个前端项目，主要针对首屏内容，后续内容在客户端加载后会由对应的代码接管，还是和普通项目一样的加载逻辑
- SSR主要是为了加快首屏内容的加载速度
- SSR是在服务端就已经填充好首屏内容了
- SSR有优点也有缺点，缺点是对服务端资源的压力，开发成本较高，技术选型需结合实际项目定位和成本预算
- 如果是使用的框架开发，对应的后端SSR也需要特定的框架适配解析，比如Nuxt.js
- SEO对首页的加载速度有要求，首页内容越完整约有利于SEO搜索和排名
- SEO是通过URLs直接请求服务端内容
- 一个新的网站想要被搜索引擎搜索到，有多种方式暴露给外部网络，包括主动提交、社交媒体宣传、使用API提交等
