单页SPA应用程序的曙光
在过去几年中,单页应用程序(SPA)模型已经越来越流行。可以理解,这种方法在速度,服务质量方面提供了一定的收益,并为客户Web开发的新模式奠定了基础。
我认为,众所周知,SPA可以在浏览器中运行,并且在使用过程中不需要重新加载页面。
好想法!但是,当然有陷阱。
在最常见的情况下(如果您有任何有关react或vue的教程),index.html主页包含几乎为空的HTML文件,其中包含少量CSS,JavaScript,字体等,这些文件对于整个项目都是全局的。
这是问题所在:
- 在初始渲染期间,用户将不得不等待整个代码库和所有资源被加载(当然,有一些例外,您可以实现所谓的js / css块的动态加载,但这是另一回事了)
- 一些无法等待异步请求加载的搜寻器或解析器只会看到所有页面空白
反正你懂这个意思:
<!DOCTYPE html>
<html>
<head>
<title>My first SPA app</title>
<script src="https://cdn__"></script>
</head>
<body>
<div id="app"></div>
<script>
...
,
...
</script>
</body>
</html>
服务器端渲染SSR
客户端渲染(CSR)使用浏览器来渲染所有应用程序内容并从API等中检索数据,而SSR使用服务器。也就是说,所有相同的呈现和数据检索都由服务器(使用Express,Next,Vue SSR,Nuxt或其他方法的NodeJS)处理,然后通过HTML标记,样式,脚本和从API接收的数据进行响应,发送到浏览器。
因此,您可以利用两种方法:速度/ SEO和交互性/ UX。
那么,什么是水合/补液?
补液是SSR和CSR之间的一种桥梁。
网页性能的指标是First Contentful Paint(FCP)(大致翻译后,听起来像是“首次重要渲染”),即浏览器开始显示任何文本,图像(包括背景)的时间。这些是用户将在页面上看到的第一个元素。当您在Chrome中使用Lighthouse创建报表时,在效果标签下,您将立即看到该指标。
在服务器上生成内容所花费的时间将是“第一内容绘画”时间。
此后,客户端JavaScript立即开始执行以创建功能完善的客户端应用程序(在大多数情况下,流行的框架是虚拟dom和用于管理它的绑定接口)。
此时,无需在客户端上重新呈现整个DOM,但是有必要添加丢失的事件,方法,在某些情况下还需要添加未在服务器上呈现的元素。
正是这个过程被称为水合/再水合。可以在《 Vue SSR指南》(也有俄语)中找到更详细的描述,但是具有此特定框架的某些功能。
性能
但是在这一部分中,会出现一些问题。补液有一定的缺点-它是交互作用之前的时间或交互时间,这可以在我们所熟知的Lighthouse Chrome浏览器中看到。即使您在服务器端完美地组织了所有工作,并且页面具有快速的内容首次呈现,用户也只能在CSR补液后与之交互,这有时会很慢。就UX而言,这是一个很大的缺点。
最大潜在首次输入延迟的另一个指标是第一次输入延迟(FID)-网页性能指标之一,它描述了从用户首次开始与网页进行互动的时间开始即经过的时间。 e。单击链接,按钮或使用基于JavaScript的控件,直到Web浏览器可以响应交互为止(由mozilla定义)。
补液时间直接影响该指标。而且页面上的组件和逻辑越多,该指标的增长速度就越快。
一种解决方案是用于水合作用的惰性负载。
在Vue SSR / NuxtJS中实现类似方法的示例是vue-lazy-hydration包(在npm存储库中),该功能仅在浏览器视口的可见部分实现水合,仅在滚动页面时才“水合”其余部分。对于采用这种封装的建议还对HABR在教程中创建的Nuxt.js在线商店,为此笔者安东·莫斯科斯基我要表示我特别的感谢。在他的文章中,Lighthouse Chrome实现了100%的性能。