自我们开始使用SPA（单页应用程序）以来已有12多年了。这种方法对于DX（开发人员的经验）是革命性的。但是，就网络性能而言，我们经历了与前所未有不同的下降，导致了互动性的灾难性时期。即使到现在，我们也看到了使用仅依靠水疗中心的框架构建的应用程序。这些框架试图改善其渲染方法。在本文中，我们将解释网络上渲染的演变，最终以一种新的渲染技术的聚光灯为顶点，许多人认为这将彻底改变网络性能。
例如，网络开发的历史通常始于总的SSR，PHP和JQUERY。在那段时间里，DX（开发人员的经验）具有挑战性，并且充满了错误，并且该代码很复杂且难以调试。尽管本文不会大量深入研究这些方面，但值得注意的是，这些工具为开发人员提供了有关其应用程序架构的完全自主权。因此，任何性能问题通常都是其代码错误的结果。相比之下，使用水疗中心（单页应用程序），通常是框架本身成为主要性能问题的根本原因。
客户端渲染（CSR）
单页应用程序（SPA）标志着Web开发的重大转变，这是构建Web应用程序的真正革命。最初，我们对提供的出色UX感到兴奋。但是，随着时间的流逝，我们开始遇到性能瓶颈，因为我们已经开始将SPA用于启动关键应用程序（例如Ecomceers），而启动非常重要。我们的应用程序花费了更长的时间才能变得可见和互动。通常，一开始就会向用户打招呼，被迫等待。我们的应用程序越依赖JavaScript，这些延迟就越长。遗憾的是，随着我们扩大应用程序的扩展，我们经常牺牲性能。这种增加的复杂性在很大程度上源于一个根部问题：JavaScript的局限性。
这里的问题是，是因为什么？这是因为我们应该等待浏览器下载，执行和渲染应用程序的所有JavaScript，即可见和互动，此图向我们显示了它的工作方式：
图像来源：https://www.youtube.com/watch?v=k-A2VfuUROg&feature=youtu.be
为了应对这些绩效挑战，我们尝试了各种方法，例如懒惰加载，预加载和代码分裂。但是，正如历史所具有的那样，这些增强不足。
服务器端渲染（SSR）
如前所述，SSR是一种传统的渲染方法。但是，重新审视这种应对某些挑战的方法至关重要。主要关注的是性能，促使SSR运作方式的重新想象。
解决了水疗问题后，Angular和React等框架试图增强其向浏览器传递页面内容的方法。他们没有发送空白的HTML，然后下载JavaScript以供整个Web应用程序执行，而是选择在服务器上生成网页。该服务器渲染的页面包含来自数据库或API的HTML，CSS以及数据。一旦将其发送给客户端，我们就有一个可见的页面，完全可见，但不幸的是没有互动，因此应在客户端交付和执行JavaScript，以便将处理程序添加到DOM节点中，它测量了我们页面将两次可见。此过程称为水合，重新执行应用程序代码以使静态页面交互式。简单地说，DOM将用JavaScript“水合”。
图像来源：https://developers.google.com/web/updates/2019/02/rendering-on-the-web
由于较大的HTML有效载荷，交互式的时间与水疗中心（即使不是更长的话）相当。这标志着一个广泛的旅程的开始，在此期间，所有框架都将努力尽可能优化水合过程。
静态站点生成（SSG）
对于专注于需要最小交互和特征内容的内容的网站，SSR可能是个过度的。它可能会阻碍第一个字节的时间，而CSR可能会对我们的核心网络生命力产生负面影响。这要求采用另一种方法，引入静态站点生成（SSG）。使用SSG，为每条潜在路线的构建时间生成了HTML页面。因此，如果有3,000篇文章，则将在构建阶段为每个页面生成一个单独的HTML页面。
图像来源：https://www.patterns.dev/posts/incremental-static-rendering
这种方法似乎具有出色的性能，但很明显它具有缺点。例如，每次在数据库中创建新文章时，整个网站都必须重建和重新部署，以使用户可以访问该文章，这是另一种方法。
增量静态场地生成（ISSG）
名称很明确，目标更清楚，ISSG是解决我们对SSG的问题，我们不需要重建和重新启动我们的网站，使用ISSG，我们将能够添加新页面以及更新现有页面。
重要的是要注意，SSG或ISSG最适合需要最小交互并且不经常更新页面内容的网站。尽管这些渲染方法在SEO和性能方面表现出色，但对于需要与API进行广泛互动或对页面状态进行频繁更改的Web应用程序并不理想。
尽管这些方法旨在达到高峰性能，但它们并不适合所有情况。因此，需要一种更通用的方法，可以解决更广泛的情况。
进行性水合
SSR中进行性水合的概念很简单：增强水合过程。借助传统的服务器端渲染，当页面可见时，它并不意味着按钮最初无法正常工作。这是因为我们必须等待在客户端下载和执行的整个JavaScript代码。但是，顾名思义，渐进的水合允许我们页面的分步保湿。这意味着水合发生在DOM内的节点。结果，有些按钮可能会立即变得互动，而另一些按钮由于正在进行的水合过程而落后。此过程结束后，整个页面就可以实现交互性。
图像来源：https://www.patterns.dev/posts/progressive-hydration
此方法很好，但是它仍然以一种更好的方式使用水合。挑战在于猜测用户可能与下一页交互的页面的哪一部分。很棒的用户可以快速使用页面的部分，但是如果他们想使用其他零件，他们可能必须等待。在整个页面准备就绪之前，他们不会获得完整的互动。
流服务器端渲染
我们刚刚深入研究了渐进的水合，其中DOM逐步进行了水合。现在，想象一个方案，其中还逐步完成了包括HTML和CSS在内的网页的整个渲染过程。
使用此方法，我们发送了大量的HTML和JavaScript，以尽快绘制用户界面。这样可以确保用户几乎可以立即与页面的各个部分进行交互。该技术可有效地最大程度地减少第一个字节的时间（TTFB），这是有益的。
选择性水合
到目前为止，我们已经讨论过的每种服务器端渲染技术都有其优点，但它们并不是一定程度的全部解决方案。考虑一个我们希望使用具有组件的SSR渲染的页面，该组件需要数据从外部API上进行的初始负载。这意味着将呈现服务器上的HTML延迟，这不是理想的。
输入选择性水合。该方法没有在等待数据密集型组件时停止整个页面的渲染，而是首先将其他组件发送给客户端。当浏览器等待有关特定组件的服务器提供的数据时，这些组件是渲染和交互式的。
图像来源：https://github.com/reactwg/react-18/discussions/37
显然，其他组件的水合过程继续不间断。这种方法可以提高性能，而不会对我们网站的其他部分产生负面影响。
React服务器组件
在反应世界中，这标志着革命性的转变。 RSC推出了一种新的方法来构建Web应用程序，从而改变了组件的管理和更有效的管理方式。
RSC更中心以增强客户端渲染，仅提供必要的内容。对于典范，如果仅在特定条件下可见组件，而不是在客户端做出决定，则可以确定服务器端。这避免了将组件发送给客户端，从而使网络性能受益，因为无需下载和执行永远不会显示的组件。
RSC的大小为零，使我们能够渲染以前可能需要JavaScript库进行构造的静态内容。过去，这是对客户端进行的，使用库来用于不需要交互性的内容。使用RSC，我们可以处理此服务器端，仅产生静态内容而没有其他捆绑尺寸。
有关更多详细信息：https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md#zero-bundle-size-components
使用RSC，我们将获得对后端的安全，完全访问后端，因为服务器组件永远不会交付给客户端。这种方法使我们可以直接从数据库获取数据，从而消除了端点的需求。
有关更多详细信息：https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md#full-access-to-the-backend
RSC增强了用户体验（UX）和开发人员体验（DX）。在RSC中，所有导入都会自动成为代码拆分点，从而消除了对其他配置的需求。这不仅有助于开发人员的工作，而且可以提高性能，因为服务器确定是否应渲染组件。
有关更多详细信息：https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md#automatic-code-splitting
要深入研究RSC，您可以考虑阅读此RFC：https://github.com/reactjs/rfcs/blob/main/text/0188-server-components.md
岛屿建筑（部分水合）
现在，我们处于一个新时代，是一个0 JavaScript的时代，即岛建筑，这是一种建立网站的新方式，而无需在第一个负载中补充我们所有网站，这种岛屿建筑的概念首先普及了。通过Astro框架，使用一种称为部分水合的技术。
部分水合的概念使开发人员能够确定已加载哪些方面以及何时提供快速交互性。这是通过仅在需要的地方放置一些客户端JS来完成的。部分水合绝对是明智而实用的策略。我们的网页最初以纯HTML从服务器发送到客户端。默认情况下，JavaScript不会发货。
在Astro的示例中，指导原则是建立浏览器可以自行补充的互动岛。我们可以通过独立处理每个组件（Island）来优化页面加载JavaScript。
重复性
在我们较早的讨论中，我们深入研究了各种框架如何优化水合过程。传统上，水合是网站性能的瓶颈，通常是改进的焦点。但是，不仅是增强现有的东西，还可能是时候对我们的方法进行革命性转变了。问题不仅仅在于更快地做它，而且可能完全没有做任何事情。
引入“可重复性”。这个名字本身给出了一个线索：“停止和恢复”。这个概念表明，在服务器停止的地方接下来，消除了传统水合过程的重复性。 Reomability的主要目标是最佳性能，强调简约的JavaScript和纯HTML。
考虑页面底部的联系表。传统方法预加载必要的JavaScript，而部分水合则略微改善了这一点。但是，通过重新效能，JavaScript仅在直接交互时加载，例如单击发送按钮。在新兴框架Qwik的支持下，这种创新的观点为Web应用程序开发提供了重新介绍，专注于可扩展性而无需牺牲性能。
如果我们尝试深入思考上面的图，我们将了解卷轴问题，扩展。如果我们有广泛的Web应用程序，则需要大量时间来加载水合。
在Qwik中如何完成？在Qwik中，有用于优化性能的代码提取。对于我们页面上的每个事件，链接了一个特定的JavaScript文件。如果没有采取操作，例如按下按钮，则不会加载其JavaScript。 Qwik不仅在交互时加载文件。
初始交互式页面加载后，它通过服务工作者预先下载了当前页面的必要JavaScript代码，并将其存储在浏览器的缓存中。这样可以防止恒定的服务器请求。取而代之的是，它从缓存中拉出，或者如果尚未可用，则将其从服务器中获取，这称为预取。与其他使用JavaScript陷入初始负载的框架不同，Qwik保持互动性，而无需等待JavaScript下载。
使用这种方法，诸如FCP，LCP和TTI之类的核心Web生命力直接通过框架体验了显着的增强，而无需开发人员干预或特定的优化技术。相比之下，许多其他框架需要手动优化，从代码分配和懒惰加载到缓存等等。
Qwik从开发人员那里消除了这种压力。他们可以仅关注应用程序开发，而不是陷入配置。该框架照顾其余的，确保优化的性能。这种创新的方法不仅通过提高性能来增强用户体验（UX），还可以简化开发人员体验（DX）。
有关更多详细信息，您可以阅读本文：