初探 Qwik - HTML 优先框架

在Builder.io，我们借助强大的可视化编辑器，帮助非开发人员构建和编辑速度超快的网站。我们的可视化编辑器的一大亮点在于，我们可以使用不同的技术（从 Angular 到 WebComponents，以及介于两者之间的所有框架）生成相同的网站。我们输出的代码针对速度进行了优化，我们的网站比绝大多数手工构建的网站速度更快。我们对此感到非常自豪。我们的产品专注于电商，而电商追求速度！

获得良好的互动时间很难

即使代码优化到极致，电商网站也很难在PageSpeed Insights上获得满分，除非它们只提供静态 HTML 页面。这就是为什么大多数电商网站的 PageSpeed Insights 评分都在 20 分左右，并且处于红色区域。只有最优秀的、能够专注于速度的网站，才能将网站速度提升到 50 到 60 分，甚至达到黄色区域。使用 Builder.io 也能让您的网站达到 50 到 60 分的黄色区域。但我们力求做得更好！

纯 HTML 速度很快

好吧，如果我们提供静态 HTML，我们可以做得更好。这几乎肯定会让我们得到满分 100 分。毕竟，PageSpeed Insights 显示的分数是根据浏览器在页面可交互之前必须执行的代码量来衡量的。通过删除所有 JavaScript 执行，我们可以获得 100 分的满分，顺利通过！但是，问题就在这里。这些页面是静态的。我们需要页面动态地传递内容，使其充满互动性和活力。我们该如何提供静态 HTML 来获得高分，同时又能提供丰富的互动性呢？

介绍 Qwik - HTML 优先框架

隆重推出 Qwik，一个以 DOM 为中心、可恢复的开源 Web 应用框架。它专注于 HTML 服务器端渲染的可恢复性和代码的细粒度延迟加载，旨在实现最佳的可交互时间。好吧，要阐述的内容很多，远远超出了我们这篇博文所能涵盖的范围。因此，我们将把它分成一系列博文，并在接下来的几周内陆续发布。但是，Qwik 的基本目标是通过尽可能延迟 JavaScript 的执行来充分利用浏览器的延迟加载功能，从而专注于可交互时间指标。这与现有框架形成了鲜明对比，这些框架更多地将服务器端渲染和可交互时间视为事后诸葛亮，而不是驱动所有其他设计决策的首要目标。Qwik 的目标是在最慢的移动设备上将可交互时间压缩到眨眼之间。我们希望为用户提供静态页面，使其速度更快，同时保留所有交互性。我们想鱼与熊掌兼得！

可重放框架承担了太多工作

几乎没有电商网站在 PageSpeed Insights 上获得 100 分是有原因的。原因是所有现有框架在设计时都没有考虑到可交互时间。它们具有复杂的引导过程，需要下载并执行大量代码才能使页面实现交互。没错，大多数框架支持服务器端渲染以快速呈现初始内容，但它们需要做的第一件事就是下载页面上的所有模板并执行它们，使页面重新焕发活力并使其具有交互性。这种下载和执行正是现有真实网站无法获得 100 分的原因。当前的框架集是可重放的，因为它们需要在客户端重放所有服务器端渲染的工作才能使网站具有交互性。而且，随着网站变得越来越复杂，可重放性的成本也会随之增加。

可恢复性来拯救

Qwik 背后的基本理念是可续传。它可以从服务器中断的地方继续运行。客户端只需执行极少量的代码。qwikloader 会获取服务器端渲染生成的静态 HTML 并继续执行，它的大小不到 1kb，执行时间不到 1ms。我想你可能想再读一遍最后一句话。是的，我们需要执行的代码量非常小，执行时间甚至不到眨眼。最棒的是，无论你的应用程序变得多大，这些代码都将保持不变。当你以尽可能小的块与网站交互时，网站的所有其他交互内容都会被延迟下载。

了解更多

我们的首要目标是为客户开发这项技术。但该技术将以开源形式开发，任何人都可以将其用于任何用途。虽然它将被设计为一个通用的 Web 框架，但我们会优先考虑客户的需求。

我相信您一定迫不及待地想了解更多信息。我们诚邀您体验 StackBlitz Web 容器演示。（StackBlitz 的团队能够在浏览器中运行 Node.js，并允许我们演示服务端渲染，这是该框架的关键部分，真是太棒了。向他们致敬！）您也可以在这里找到开源仓库。需要说明的是，该仓库目前处于概念验证阶段，尚未准备好进行大规模使用，因为我们预计很多内容会随着时间的推移而发生变化。尽管如此，我们还是想听听您的想法。所以，欢迎加入我们在 Discord 服务器上的讨论。

在接下来的几周里，我们将深入探讨 Qwik 背后的诸多独特理念，解读它的运作原理和独特之处。敬请期待！