群岛架构：选择性水合

岛屿架构由 Jason Miller 于 2020 年提出，它将网页视为以静态 HTML 为主、其中嵌入相互隔离的交互“岛屿”。静态 HTML 海洋会原样发送到浏览器。只有交互式岛屿会下载并执行 JavaScript，因此 JavaScript 负载与实际交互量成正比。

每个岛屿都是一个独立完成水合的组件。服务器会将岛屿的初始 HTML 与页面其余部分一起渲染。当岛屿的 JavaScript 加载后，它只会为该组件子树进行水合。岛屿周围的 HTML 从不会被 JavaScript 触碰，是真正的静态内容。

在采用岛屿架构的博客文章页面中，一个点赞按钮岛屿的 JavaScript 负载可能只有 5kb。同一个页面如果构建为 React SPA，可能会发送 200kb 以上的 JavaScript 来为整个页面进行水合。岛屿方案让负载与交互量成正比，而不是与页面大小成正比。

Astro 是领先的岛屿架构框架，支持在同一页面上使用不同框架构建岛屿。您可以让 React 岛屿、Vue 岛屿和原生 JavaScript 岛屿并列存在。每个岛屿都会独立打包，因此用户只需下载可见岛屿所使用的框架代码。

client:load 指令会在页面加载时立即为岛屿进行水合。对于立即可见且需要交互的岛屿，请使用它，例如导航菜单或包含搜索输入框的主视觉区域。这是优先级最高的水合策略。

client:idle 指令会等待浏览器主线程空闲（关键内容加载完成之后），然后再为岛屿进行水合。这非常适合首屏以下的组件或不需要立即使用的次要交互，例如社交分享栏。

client:visible 指令会使用交叉观察器，仅在岛屿滚动进入视口时才为其进行水合。这非常适合位于页面深处的岛屿，例如评论区或相关产品轮播图，因为许多用户可能永远不会看到它们。直到确实需要时，JavaScript 才会加载。

client:only 指令会完全跳过服务器端渲染，只在浏览器中渲染岛屿。对于使用浏览器专用 API（窗口、文档）或依赖挂载时客户端状态的组件，这是必要的。代价是该岛屿不会生成服务器渲染的 HTML。

岛屿架构通过确保仅为真正具有交互性的组件加载和执行 JavaScript，解决了完整水合带来的问题。包含点赞按钮的博客文章只需为点赞按钮岛屿进行水合；客户端不会执行 1200 字文章文本、页眉和页脚所需的任何 JavaScript。

每个岛屿都有自己隔离的状态。由于岛屿属于彼此独立的 React 树，因此不能直接共享 React 状态。这是有意为之：如果两个组件需要共享状态，就应该将它们合并到同一个岛屿中。岛屿之间可以通过网址参数、DOM 事件或轻量级状态库进行通信。

从 React SPA 迁移到岛屿架构的网站（例如 Astro 文档网站）报告了显著改进：JavaScript 负载减少 70% 至 90%，移动设备上的 TTI 提前 2 至 4 秒，Lighthouse 性能分数也从 60 分提升到 90 分以上。这些收益在内容密集型页面上最为明显。

哪个 Astro 水合指令只会在组件滚动进入视口时对其进行水合？

岛屿架构将页面的大部分内容保留为静态 HTML，只对彼此隔离的交互组件进行水合。Astro 提供了多种水合指令：client:load（立即执行）、client:idle（空闲后执行）、client:visible（滚动进入视口时执行）以及 client:only（仅在客户端渲染）。每个岛屿都会独立进行水合，因此 JavaScript 的用量取决于交互程度，而不是页面大小。