搭建ssr服务器教程本地服务器搭建

了解我们如何为每个Webiny网站获得出色的SEO支持，以及如何在无服务器环境中使用SSR使其超快运行。

我确实意识到这是一篇很长的文章，请相信我不是故意写的很长。据我了解，有些人可能没有时间通篇读完，下面我准备了一个简短的内容概要：

好消息是，使用Webiny，上面提到的都可以处理并定期更新维护一些方法，如果您觉得不错的话，可以经常来Webiny查阅。

这就是内容概要的全部内容了，如果您想更深入地研究该主题，或者只是想看看我们尝试过的无服务器方法和实现成果，我建议您继续往下看。

在Webiny，我们的使命是创建一个平台，使开发人员能够构建无服务器应用程序。换句话说，我们希望为开发人员提供适当的工具和流程，以便使用无服务器技术的开发更加轻松，高效和愉悦。最重要的是，我们还希望构建一个包含插件乃至现成应用程序的生态系统，这将进一步减少开发时间和成本。

为了应用程序便于快速开发，Webiny实际上提供了一些基本的应用供开发人员使用，其中之一就是我们的PageBuilder应用程序。我不想浪费您的时间，这也不是一篇做广告的文章，我们已经为此工作了相当长的时间（并将继续这样做），尽管面临许多挑战，但无疑，最有趣的挑战之一就是以最佳方式为用户展示页面。换句话说，尽可能快地展示页面，当然，还对搜索引擎优化（SEO）提供了出色的支持。

为了实现上述目标，我们不仅要利用无服务器技术，而且要利用现代的单页应用程序（SPA）方法来构建网站和应用程序。但是事实证明，同时实现和使用所有上述提到的可能有点难度。

SPA很酷，但是它们有一个严重的缺点：SEO支持不好，这是因为它们完全是客户端渲染的，这意味着如果我们不能完全依靠客户端渲染（CSR）来渲染我们的应用程序我们该怎么做呢？在无服务器环境中，我们如何处理服务器“传统上”完成的工作？我们如何实现“无服务器端渲染”？

在本文开始时，我直接放弃讲一些不是那么重要的内容，如果您想要拥有一个现代，快速，可扩展且经过SEO优化的单页应用程序，那么您肯定需要关注这些内容，我会讲我们真正想要为我们的用户提供些什么。

在本文中，我想介绍一下我们尝试几种方法去做，也会讲哪一种方法是最适合我们的解决方案。您会看到没有一个方案能解决所有问题，像灵丹妙药一样，您选择的解决方案将取决于您正在构建的应用程序以及它自身的要求和条件。

单页应用程序，我们将介绍它们的主要功能，优点/缺点，并且总体上，我们还将讨论Web上的不同渲染方法。如果您是来这里购买严格的无服务器产品的，或者您已经有足够的使用SPA的经验，请跳转至“选择什么？”这个部分，我们将说明我们决定尝试使用哪种渲染方法，以及如何在无服务器环境中实现它们。

尽管我们确实计划探索其他云提供商，但在Webiny，我们目前主要与AWS合作，因此您将要看到的也是将是针对于AWS的一些实践。但是，如果您不使用AWS，我仍然认为您应该能够阅读本文并使用类似的服务在您的云中构建所有内容。

如果您是网络开发人员，那么我很确定您已经熟悉单页应用程序（SPA）的概念。但是，让我们快速了解一下它的一些主要功能和优势。

每个SPA的主要功能都是客户端渲染（CSR）。这意味着所有用户界面（HTML）都是在用户浏览器内部生成的，而不是在某种后端（服务器，容器，函数等等…（ツ）/¯）上生成的。最酷的是，不需要整个页面刷新，这意味着当您在应用程序中的其他位置交互操作时，仅这部分页面被重新渲染，而没有刷新整个页面，这样会有更好的体验。

如果您曾经使用过PHP，尤其是在过去，那么您可能会记得那些长的Smarty/Twig模板文件，其中包含HTML，CSS，JS，也许是一些if语句，可能是对数据库的一两个调用，以及一些类似的别的什么东西。如果你问我，那真是一团糟。

有了SPA，整个应用程序代码将变得更加整洁。这次我们有两个单独的代码库，一个代表实际的SPA，另一个代表应用程序连接的后端或API。

SPA易于维护，尤其是在无服务器环境中。创建应用的生产版本后，基本上唯一要做的就是将其上传到您选择的静态文件存储中，例如AmazonS3。而且，如果您希望给您的应用和静态资源提供更快的服务，那么可以将CDN引入到后端体系结构，这种方式也很容易执行。但是，如果您的应用程序依赖于API，值得注意的是，该应用程序将与您的API速度一样快，如果API速度很慢，那么SPA也将变慢，尽管服务速度非常快。

如图所示，SPA确实具有很多优点。但是它也有其自身的不足之处，下面我不得不吐槽下它最大的缺点。

每当您创建公开的网站（SPA或非SPA）时，显然都希望拥有链接预览。换句话说，当您分享您的网站链接时，例如社交媒体网站（如Facebook），您希望获得的是如下图所示的预览：

但是，如果您以前从未使用过SPA，则可能会收到下图的空链接预览，并不是上图完整的链接预览：

毫无疑问，您会开始检查代码，很快，您就能看到最初访问您的网站时提供的index.html

我们可以看到，上面代码中没有太多内容，只有一些基本的HTML标签和一些网站的Java和CSS文件的链接。这是意料之中的，因为这个初始HTML文档实际上是我们应用程序构建的一部分，也就是说，该文档不是动态生成的，用户每次访问我们的网站时都存在的。

首先是下载初始的SPAHTML，与常规用户不同，网络爬虫不会等到SPA完全初始化，才获取生成的HTML，他们只会分析最初提供给他们的HTML，仅此而已。这就是Facebook的网络爬虫无法生成完整的链接预览的原因，因为初始内容根本没有包含足够的信息。

尽管搜索引擎也在寻求可能的解决方案了来应对SPA初始化没有包含足够的信息的问题，但到目前为止，我们仍然不能完全依赖这些解决方案。实际上，我已经看到几个示例，其中介绍了SPA大大降低了SEO质量的结果，例如：

嗨，伙计…想象一下您在一个项目上花费了三个月，在发布之前，您意识到自己根本没有SEO支持。

到目前为止，只有一种可靠地解决此问题的方法，那就是为网络爬虫提供有价值的HTML。换句话说，当网络爬虫访问您的网站时，最初提供的HTML必须包含诸如页面标题，适当的meta标记，页面内容（正文）之类的。例如：

但是，实现这一目标的最佳方法是什么？我们是否需要在每个页面请求上动态生成HTML的服务器？还是我们可以使用其他方法？

实际上，在web上渲染应用程序有多种方法。，这是Google博客上的一篇文章，我看过好多遍了，写的非常好，它可以帮助您很好地了解不同的渲染方法，并为您提供每种方法的利弊信息。

早先我们都知道一种方法，就是后端返回一个简单的HTML，在用户的浏览器中进行应用初始化。这种方法不适合做SEO，但是如果构建网页的时候不需要进行SEO（例如管理员登陆页面），那么它仍然是一种不错的方法。

如果您曾经与Gatsby一起工作过，则可能对这种方法很熟悉。基本上，一旦我们准备好部署您的网站，便会开始构建过程，该过程会预先生成应用程序的所有页面，然后可以将其上传到静态文件存储中，例如亚马逊S3。

由于构建的页面包含完整的HTML，并且不会动态生成任何内容，因此该应用将以超快的速度提供服务，最重要的是，它将拥有出色的SEO支持。

这种方法的要点是，每当需要进行更改时，即使更改很小，也需要从头开始完全重建所有内容，而在较大的项目上，这可能会花费一些时间。因此，如果您经常进行更改，那么对您来说这可能不是一种超级方便的方法。

通过这种方法，我们在服务器端的每个初始页面请求上动态生成HTML。注意这里的“initial”一词。我们的意思是，服务器端HTML的生成只会在初始页面请求（例如用户在浏览器中输入URL或刷新整个页面时）的时候，有趣的是，在收到初始HTML之后，会初始化完整的CSRSPA，这意味着该时间点的所有HTML都会在用户的浏览器中生成，因此仍然可以创建出色的用户体验。这种方法也称为“同构渲染”。

听起来很不错，但要注意，采用这种方法时，您实际上需要为应用创建两个独立的生产版本，一个仍将在用户浏览器中提供并执行，而另一个将在后端执行以动态生成HTML。创建两个版本的原因是不同的环境，也就是说在NodeJS后端中运行浏览器代码根本行不通（反之亦然）。

尽管有时无法简单地设置SSR，但是一旦学习了一些技巧，您就可以了（设置是，性能完全是另一回事）。使用诸如Next.js之类的框架可以大大节省您的时间。