商品说明对所有访客相同，但登录者看到的配送地址可能不同。查询地址较慢，是否连商品说明也必须等候？本文用虚构的书籍销售页，探讨如何判断共享正文与用户专属区域的分界。介绍的是 Astro 的服务器岛屿，和在浏览器让按钮运作的客户端岛屿，角色并不相同。
1. 分清初始文件与稍后抵达的区域
Astro 官方服务器岛屿文件说明如何延后特定组件的服务器渲染，通过独立请求取得结果。初始 HTML 包含核心正文与等候时的显示，另一个响应抵达后再替换该区域。这需要能在服务器处理请求的适配器。
在书籍销售页，可以把书名、作者、介绍留在共享文件，只选配送地址摘要作为候选区域。访客等地址时仍可阅读这是什么书。相反，若必须知道订单总额才能理解付款按钮，就应一并设计价格与付款操作的关系。把可见元素切成小方块，并不代表功能分离已完成。
设计成败取决于先呈现什么。若正文几乎空白，大部分都延后，访客便要等多个加载标示。先列出首屏必须回答的问题，以及较晚出现也无妨的信息。服务器岛屿改变的是等候的位置，并不会自动让数据库查询本身变快。
2. fallback 也是完整画面的一部分
以下是展示使用方式的小例子，前提是 UserDelivery 组件与适配器已另外实现。
---
import UserDelivery from '../components/UserDelivery.astro';
---
<UserDelivery server:defer>
<p slot="fallback">正在确认配送地址信息。</p>
</UserDelivery>fallback 并非出现一下就消失的装饰，而是访客真正会阅读的初始内容。预留接近地址卡最终大小的空间，说明正在等什么。尚未取得信息便先显示「可配送」，可能与实际响应矛盾。未知状态和确认结果也应在视觉上区分。
例如未登录者可能需要「登录后可查看已存储的配送地址」的提示。网络缓慢与未登录是不同状态。分别决定文案与前往的路径，可减少开发时随手放的文字残留在正式画面。
3. 保持小而清楚的数据边界
调用组件时，只传入显示与查询所需的值。若传入全部订单历史却只输出一个姓名，应先考虑减少数据依赖。有些值可放在公开正文，另一些只能在认证后查询。把值的传递路径与画面输出范围放在同一份清单确认。
服务器岛屿的请求位于独立的执行上下文。逻辑若需要目前页面地址，应考虑由原页面明确传入所需路径。若把岛屿内的请求 URL 当成原商品页 URL，可能产生错误的各页推荐或返回链接。实现时通过开发者工具确认实际请求地址较安全。
设想处理书号与用户识别信息的虚构案例：书号用来查询共享推荐资料，用户信息则由服务器依认证状态处理，分清角色。即使采用加密传递格式，也不能取代服务器的权限检查。应把接收输入的位置，与最终决定允许访问的位置分开记录。
4. 缓存依画面的对象决定
共享书籍介绍和个人配送地址很难套用同一套缓存政策。MDN 的 HTTP 缓存指南说明共享与私有缓存的差别。比起数据是否一样，应先判断响应是否可以让任何人看到。
用两个测试账号开启相同页面，确认第一人的地址不会显示给第二人。也检查退出登录后返回或刷新的情况。这项测试检查缓存服务器、浏览器及应用程序认证处理共同运作的结果，不能只读组件文件就断定安全。
即使是共享书籍推荐，也需要内容变更时的更新途径。应决定是否暂时容许旧推荐，或管理员修改后立即替换。不要只写「开启缓存」，而要记录对象、存储位置、容许的过期程度、失效条件，方便其他开发者审查。
5. 先测试慢速连线与失败
不能只靠正常连线开启一次的结果评估页面。延迟地址请求、使其失败、变更登录状态，再确认各画面。检查核心正文能否阅读、加载区是否不断把下一个按钮推开，以及依赖失败信息的操作是否仍可执行。
| 测试情境 | 访客应理解的状态 |
|---|---|
| 配送地址查询缓慢 | 等候什么，以及可否先读其他内容 |
| 尚未认证 | 是否看得到登录提示与共享说明 |
| 查询失败 | 能否找到复原途径，而非只有空白画面 |
| 账号变更 | 是否残留前一位用户的信息 |
若多个岛屿互等结果，也应重新评估分离方式。取得地址后再查运费，接着才绘出付款提示，可能造成等待请求接连发生。此时把相关信息合并为一次服务器作业，或等用户要求时才查询，可能更合适。分离数量多，不代表结构就好。
6. 用相同条件比较导入前后的收益
比较记录要分开写首段正文出现、地址显示完成、可操作时点及错误状态。即使初始文件更快出现，地址卡大幅位移或开始付款更晚，体验仍可能朝另一方向变化。不要只留一个平均值，也记下慢速案例究竟等了什么。
挑选候选区域的问题越具体越好。「这个信息晚来，仍能先读书籍介绍吗？」比「网站是不是静态页面？」更有助于实现判断。配合Astro 按需渲染指南确认部署环境后，先从一个小型用户专属区域开始，验证到实际失败情况。