先区分三种成本

Yggdrasil 在 2026-10-28 至 2026-10-29 的历史测试中，首屏同时受资源总字节数、请求数量、请求优先级影响。只压缩单个 WASM 文件，无法解决其余两类成本。

以下是特定站点、CDN 套餐和测试链路下的观察，不是 EdgeOne 的通用性能承诺；本文整理时未重新跑性能测试。

no-cache 不等于边缘会帮忙做条件请求

当时的测试发现：源站本身支持 304，但经过该站点的 EdgeOne 配置，no-cache 入口资源仍返回 200 全量，回访没有获得预期的传输节省。

因此，需要长期浏览器缓存的入口必须使用内容寻址文件名，并返回 immutable，而不是期待 CDN 代替客户端完成重新验证。

特别注意构建顺序：cargo-leptos 当时生成的入口哈希不是最终内容的摘要。入口 JS、WASM、分包加载器之间互相引用，后续改写引用后，原文件名就不再表示最终内容。

项目在发布装配阶段，根据入口三件套的最终组合内容生成摘要并重命名，完成后才允许入口走 immutable。固定路径资源则统一使用内容摘要版本表，不手写版本号。

分包不是越碎越快

当时的站点测试中，同一客户端发往 EdgeOne 的并发小请求呈现近似逐个处理的行为，请求数增加会放大排队成本。

项目采用带 chunk-merge 补丁的 wasm-split，并把 WASM_SPLIT_CHUNK_LOAD_COST 设置为 8192。该轮记录中，首页分包由 60 个减少为 21 个。

这是特定部署条件下的取舍：适度合并降低请求开销，也可能增加页面要下载的共享字节。应同时测冷访问、回访和不同路由，而不是只追求最少文件或最小单文件。

preload 也会抢首屏关键资源

历史排查中，SSR 为调用过的懒函数展开大量分包 preload，还存在重复条目。移动弱网下，这些请求会与 CSS 争带宽。

项目取消全量分包 preload，只输出当前路由所需的视图分包，并使用 fetchpriority=“low”。这保留了提前取数的收益，同时降低与样式资源竞争的风险。

入口 WASM、分包加载器与路由视图分包是不同角色，不能把它们混成“所有资源一律高优先级”。

看似网络慢，也要检查源站连接

项目还定位过 nginx keepalive 复用连接时额外约 40ms 的响应延迟。Axum 监听连接启用 TCP_NODELAY 后消除该项成本。

这提醒我们：瀑布图里的等待时间不一定都是 CDN 排队，也可能来自源站 TCP 行为。需要分别测源站、代理和 CDN 路径。

测量时容易踩的坑

  • 工作站透明代理会影响线上时延，避免把单次数据当成稳定结论。
  • Chromium 在当时使用 ignoreHTTPSErrors 的测试场景中未按预期写入 HTTP 缓存，可能污染回访实验。
  • 本地 HTTP/2 代理可能转发条件请求，与线上 CDN 的缓存行为不同。
  • 固定带宽、CPU 降速、冷暖缓存条件，并检查实际响应头与传输字节。
  • 发布后预热 CDN 有帮助，但不能替代客户端冷访问验证。

来源

Yggdrasil 2026-10-28、2026-10-29 首屏性能排障记录；内容寻址与分包优化相关历史提交 d0384418、d8911fe3、ff4e9cdb、204aabed、122b3d3e。数值仅作为当时实验结果。