毫无疑问，用户体验会受到感知加载时间的影响。随着今天更重的前端发展，客户端渲染感觉不是很快。针对这样的情况，预渲染可能是一种非常好的策略，这些解决方案与完全由客户端呈现的应用程序之间有什么区别？

　　由于 Angular、Ember.js 和 Backbone 等框架的存在，前端开发人员倾向于在客户端渲染所有内容。

　　使用客户端渲染解决方案，你将请求重定向到单个 HTML 文件，服务器将在没有任何内容（或带有加载屏幕）的情况下传递它，直到你获取所有 JavaScript 并让浏览器在渲染内容之前编译所有内容。在良好且可靠的互联网连接下，它非常快且运行良好。但它可以好得多，而且做到这一点并不难。这就是我们将在以下部分中看到的内容。

　　使用旧的服务器端渲染解决方案，你构建了一个网页（例如使用 PHP），服务器编译所有内容，包含数据，并将完全填充的 HTML 页面交付给客户端。它快速而有效。但是……每次你导航到另一条路线时，服务器都必须重新做一遍：获取 PHP 文件，编译它，然后交付 HTML，所有的 CSS 和 JS 将页面加载延迟到几百毫秒或甚至整秒。

　　如果你可以使用 SSR 解决方案进行第一个页面加载，然后使用框架通过 AJAX 进行动态路由，只获取必要的数据会怎样？

　　这就是 SSR 在社区中越来越受到关注的原因，因为 React 通过一个易于使用的解决方案普及了这个问题：RenderToString 方法。

　　这种新型 Web 应用程序称为通用应用程序或同构应用程序。关于这些术语的确切含义以及它们之间的关系仍然存在一些争议，但许多人可以互换使用它们。

　　无论如何，该解决方案的优势在于能够使用相同的代码开发应用程序服务器端和客户端，并使用自定义数据为用户提供真正快速的体验。缺点是需要运行服务器。

　　SSR 用于获取数据并使用自定义内容预填充页面，利用服务器的可靠互联网连接。也就是说，服务器自己的互联网连接比使用 lie-fi 的用户更好），因此它能够在将数据交付给用户之前预取和合并数据。

　　使用预先填充的数据，使用 SSR 应用程序还可以解决客户端呈现的应用程序在社交共享和 OpenGraph 系统中存在的问题。例如，如果你只有一个 index.html 文件要交付给客户端ssr与clash订阅转换，那么他们将只有一种类型的元数据——很可能是你的主页元数据。当你想要分享不同的路线时，这不会被上下文化，因此你的任何路线都不会显示在其他网站上，并带有用户希望与全世界分享的正确用户内容（描述和预览图片）。

　　通用应用程序的强制性服务器对某些人来说可能是一种威慑，而对于小型应用程序来说可能是过度的。这就是为什么预渲染可以是一个非常好的选择。

　　我通过 Preact 和它自己的 CLI 发现了这个解决方案，它允许你编译所有预先选择的路由，以便你可以将完全填充的 HTML 文件存储到静态服务器。借助 Preact/React 补水功能，你可以为用户提供超快速体验，而无需使用 Node.js。

　　问题是，因为这不是 SSR，所以此时你没有用户特定的数据要显示——它只是一个静态（有点通用）文件，直接在第一个请求上发送，原样。因此，如果你有特定于用户的数据，你可以在此处集成一个设计精美的骨架，向用户展示他们的数据即将到来，以避免他们感到沮丧。

　　还有一个问题：为了使这项技术起作用，你仍然需要使用代理或其他东西来将用户重定向到正确的文件。

　　客户端呈现的应用程序是我们现在应该避免的，因为我们可以为用户做得更好。在这种情况下，做得更好就像预渲染解决方案一样简单。