Web应用程序的客户端与服务器端与预渲染

本文概述

客户提交的申请
服务器端渲染(SSR)
预渲染
仅客户端渲染通常是不够的

最近, 前端社区中发生了一些事情。借助React及其内置的服务器端水化功能, 服务器端渲染越来越受到青睐。但这并不是唯一以超快速的第一字节时间(TTFB)评分为用户提供快速体验的解决方案：预渲染也是一种不错的策略。这些解决方案与完全由客户端渲染的应用程序有什么区别？

客户提交的申请

由于存在Angular, Ember.js和Backbone之类的框架, 因此前端开发人员倾向于将所有内容呈现在客户端。得益于Google及其”读取” JavaScript的能力, 它可以很好地运行, 甚至对SEO友好。

使用客户端呈现解决方案, 你可以将请求重定向到单个HTML文件, 服务器将在不包含任何内容(或带有加载屏幕)的情况下传递请求, 直到获取所有JavaScript并让浏览器在呈现内容之前编译所有内容。

在良好且可靠的互联网连接下, 速度非常快, 而且效果很好。但它可以做得更好, 并且不必那样做。这就是我们将在以下各节中看到的内容。

服务器端渲染(SSR)

SSR解决方案是很多年前我们经常做的事情, 但是倾向于忘记使用客户端渲染解决方案。

使用旧的服务器端渲染解决方案, 你可以构建一个网页(例如使用PHP), 服务器可以编译所有内容, 包括数据, 并向客户端提供完全填充的HTML页面。它既快速又有效。

但是……每次导航到另一条路线时, 服务器都必须重新做一遍工作：获取PHP文件, 对其进行编译并提供HTML, 而所有CSS和JS都会将页面加载延迟几百毫秒或甚至整秒钟。

如果可以使用SSR解决方案加载第一页, 然后使用框架通过AJAX进行动态路由, 仅获取必要的数据, 该怎么办？

这就是为什么SSR在社区中越来越受欢迎的原因, 因为React通过一个易于使用的解决方案RenderToString方法推广了此问题。

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

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

SSR用于获取数据并使用服务器的可靠Internet连接来预填充具有自定义内容的页面。也就是说, 服务器本身的互联网连接要比使用lie-fi的用户更好, 因此它能够在将数据传递给用户之前进行预取和合并。

通过预填充的数据, 使用SSR应用程序还可以解决客户端渲染的应用程序在社交共享和OpenGraph系统方面存在的问题。例如, 如果你只有一个index.html文件要交付给客户端, 则它们将只有一种元数据类型—最有可能是你的首页元数据。如果你要共享其他路线, 则不会在上下文中体现出来, 因此你的路线都不会显示在其他网站上, 而不会向用户展示与用户分享的适当的用户内容(描述和预览图片)。

预渲染

通用应用程序的强制性服务器可能对某些应用程序具有威慑作用, 而对于小型应用程序来说可能会显得过分杀伤力。这就是为什么预渲染可以成为真正不错的选择的原因。

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

问题在于, 由于这不是SSR, 因此你此时没有要显示的用户特定数据, 它只是按原样直接在第一个请求上发送的静态(有些通用)文件。因此, 如果你具有用户特定的数据, 则可以在此处集成设计精美的框架以向用户显示其数据即将到来, 从而避免他们感到沮丧：

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

为什么？

对于单页应用程序, 你需要将所有请求重定向到根文件, 然后框架使用其内置的路由系统将用户重定向。因此, 第一页加载始终是相同的根文件。

为了使预渲染解决方案起作用, 你需要告诉代理, 某些路由需要特定的文件, 而并非始终是根index.html文件。

例如, 假设你有四个路线(/, / about, / jobs和Blog), 并且所有路线都有不同的布局。你需要四个不同的HTML文件来将框架交付给用户, 然后让用户使用React / Preact / etc。用数据补水。因此, 如果将所有这些路由都重定向到根index.html文件, 则页面在加载过程中会产生不愉快的毛刺感, 从而使用户看到错误页面的骨架, 直到完成加载并替换布局为止。例如, 当用户要求具有类似Pinterest的画廊的其他页面时, 用户可能会看到只有一列的主页框架。

解决方案是告诉你的代理, 这四个路由中的每一个都需要一个特定的文件：

https://my-website.com→重定向到根index.html文件
https://my-website.com/about→重定向到/about/index.html文件
https://my-website.com/jobs→重定向到/jobs/index.html文件
https://my-website.com/blog→重定向到/blog/index.html文件

这就是为什么该解决方案对小型应用程序有用的原因-你可以看到如果拥有几百页的页面将是多么痛苦。

严格来说, 这样做不是强制性的-你可以直接使用静态文件。例如, https：//my-website.com/about/可以在不进行任何重定向的情况下工作, 因为它会在其目录内自动搜索index.html。但是, 如果你具有参数网址, 则需要此代理-https://my-website.com/profile/guillaume将需要使用其自己的布局将请求重定向到/profile/index.html, 因为profile / guillaume / index.html不存在, 将触发404错误。

简而言之, 上面介绍的渲染策略具有三个基本视图：加载屏幕, 框架以及最终渲染后的整个页面。

根据策略的不同, 有时我们会使用所有这三个视图, 有时我们会直接跳转到完全渲染的页面。仅在一个用例中, 我们被迫使用另一种方法：

方法	着陆(例如/)	静态(例如/ about)	固定动态(例如/ news)	参数化动态(例如/ users /：user-id)
客户端渲染	正在加载→已满	正在加载→已满	载入中→骨架→完整	载入中→骨架→完整
预渲染	充分	充分	骨架→满	HTTP 404 (page not found)
用代理预渲染	充分	充分	骨架→满	骨架→满
固态继电器	充分	充分	充分	充分