#IFR 性能数据 v0.5

本页收录支撑首屏直出（IFR）与元素模板的全部测量数据。每轮 campaign 回答一个问题：

关于配置命名。第 1、2 轮 campaign 早于 enableIFR 默认联动元素模板的改动。 本页各列已映射为今天的产品配置：原始报告中的 ifr 即今天的 IFR without ET（显式 enableElementTemplates: false），ifr+et 即今天的默认 enableIFR: true。第 3b 轮始终显式设置两个开关。完整方法学与原始数据： 策略基准、 全示例扫描、 真实浏览器验证、 大应用复测。

#1. 策略阶梯

结论：元素模板是渲染成本的拐点。纯 IFR 重放的 JS 成本与完整渲染相当 （解释器下每千元素约 8–11 ms）；ET 砍掉 7–15×；Vapor 式设计还能再买 2–3×、贴到 PAPI 地板。这就是 ET 默认随 IFR 开启的原因：它攻击的正是 IFR 给主线程新增的唯一真实成本——loadTemplate 内的同步首屏渲染。

七种渲染策略被逐一原型化，对同样的逻辑首屏、经同一 Element PAPI 表面测量， 渲染文档逐字节一致。场景约 1000–1400 元素：static-heavy（99.7% 模板 静态）、content（卡片流，37%）、list（v-for，12%）。

#Warm 渲染耗时，--jitless V8（解释器 ≈ 主线程引擎代理）

#Cold 首次执行，--jitless（模拟设备一次性首帧）

#需要跨线程传输的 ops 载荷

原型保留作参考：ifr-direct 已被 ET 吸收（模板实例化天然蕴含持句柄直接 应用）；Vapor 设计仍是跟踪中的 endgame——其原型省略了 reactive-effect 簿记，数字应读作乐观上界。

#2. 全示例扫描

结论：这轮测的是 IFR 的成本和语义安全性，不是收益。代价是 bundle gzip ×2.26、TTI 上界 ×1.36；安全性结论是 22/23 个示例在全部配置下渲染出 逐字节一致的文档。逐项 FCP 列是持平的（中位 ×1.04）——这本身就是发现： IFR 是双线程架构优化，单进程 harness 里没有后台启动和 IPC 可供移除。 请把持平的 FCP 读作"JS 工作量守恒"的证据，真正的收益量化见第 3 节。

每个示例以三种配置构建，作为真实 bundle 的两半在 PAPI-over-jsdom 环境中 执行（每项 5 次取中位，--jitless，主线程 parse 剔除，等价于 lepus 字节码 预编译）。

（FCP/TTI 单位 ms。networking 首帧 0 节点——fetch 驱动型，即文档标注 "不建议开 IFR"的画像。todomvc-codex 测量时应用代码线程不兼容，之后已在 example 层修复。）

#Bundle 体积（gzip，KiB）——最主要的成本

主线程段从 ~17 KiB（仅 worklet 注册）增长到 78–195 KiB（Vue 运行时 + 应用 副本）；ET 在此之上仅增加约 1%。这次扫描还发现并修复了三个真实 bug （SystemInfo 覆写、数字样式烘焙绕过 auto-px 归一化、CSS Modules 令主线程 bundle 崩溃）——单为正确性，把每种真实应用形状过一遍双线程管线也是值得的。

#3. 真实线程

结论：有了真实线程边界，IFR 在内容优先屏幕上获胜——按 example 集与宿主， FCP 约 −8% 到 −26%，中位分别为 −19%（十个 demo）与 −12%（后续七应用集）。 收益来源是把后台启动 + IPC 从关键路径移除。小屏上两种 IFR 配置（带/不带 ET）的 web FCP 通常只差几个百分点：ET 更清晰的实测优势仍在渲染成本与 ops 载荷（第 1 节）以及原生冷启动。

环境：Lynx for Web——后台运行时跑在真实 Web Worker 中、真实 postMessage IPC、headless Chromium。FCP = <lynx-view> 插入 → 首次绘制内容，7 个全新 浏览器 context 取中位。下面两档节流出自同一会话，以当前开关语义测量 （enableIFR: true = IFR + ET；显式 opt-out = IFR without ET）。绝对毫秒 数随宿主负载在会话间漂移；组内比值才是稳定的度量。

#ReactLynx 对照组

ReactLynx 没有 IFR 关闭开关，用空主线程首屏 + 完整后台渲染忠实模拟"关闭"。 先看与第 2 节相同的单进程 harness：ReactLynx 同样持平——参照实现在 没有线程边界时同样无法展示自己的招牌特性：

真实线程下两个框架都赢，且是同一量级：ReactLynx 探针（85 节点）从 97.7 ms 降到 75.2 ms（−23%），正落在下方 Vue examples 的区间内。

#完整矩阵——无 CPU 节流

（FCP 单位 ms。中位：默认配置 −19%，不带 ET −15%——两种配置的逐项 差异会在不同运行间翻转，应读作噪声。此处 Hacker News 行早于 shell IFR， 见 §3b。）

#4× CPU 节流

本轮的两个读法：

1. 内容优先的屏幕在节流下保住收益（hello-world −16…−18%、todomvc-day1 −10%、swiper −10%），而 FCP 由 CSS 处理或大 bundle 主导的屏幕压缩到 接近零——节流的 CPU 放大了 web 平台付在 FCP 路径上的 bundle 解析项。
2. 反转画像在两档节流都可能复现——当首屏几乎没有同步 chrome 时。上表 Hacker News 行在整段跳过 IFR mount 时满速 +14%、节流 +9…11%；改为 shell IFR（始终 mount、挡住 fetch）后，满速约 −12%——见 §3b。原生 预编译 lepus 字节码会把构成反转的解析项压小。

#距离单线程裸 Web 有多远？

单线程原生基线（plain Vue 用 @vue/runtime-dom；plain Preact 用 ReactLynx 同款 fork 指回真实 DOM）把剩余差距拆开。以 ReactLynx 探针屏、无节流为例：

线程边界的成本约 23 ms，IFR 移除的正是这一片。与裸 Web 的剩余差距是 web 宿主的仿真层——每个宿主自己的常数项；原生 Lynx 的平台层是原生代码， 不付这笔。

#3b. 大应用复测

结论：小内容优先屏仍按第 3 节理解；产品级应用加入后，把中位读成区间。 第二轮 Lynx for Web（显式 off / et / ifr / ifr-et；hello-world、 TodoMVC、gallery、Hacker News、AI Chat、Elk）满速内容优先中位约 −12% ——仍落在第 3 节 −8%…−26% 的逐项带内，但低于 −19% 的套件中位。4× 节流下 Elk / AI Chat 约 +25% 到 +44%，七应用中位略偏正。gzip 仍约 ×2.2–2.5（此处中位 ×2.23，相对第 2 节 ×2.26）。

跨 §3 与 §3b：把 −12% 到 −19% 当作 Lynx for Web 上合理的内容优先中位带， 而不是单一的 −19% 标题。ET-only 体积约免费（~+1%）、web FCP 接近持平； ET 默认随 IFR 开启，依据仍是策略阶梯的渲染成本（复测约 6–15×）， 不是小屏 web FCP。

原始 JSON 与写评： packages/ifr-bench/reeval/。

#4. 原生引擎观察

全示例套件已在原生模拟器（LynxExplorer，Lynx SDK 1.4 / PrimJS）上验证： 24/25 通过、0 次 hydration mismatch，No IFR 与 IFR+ET 视觉一致（SSIM ≥ 0.9977；scoped CSS、烘焙 inline style 与 auto-px 语义在原生引擎全部正确）。 单次冷启动录屏显示 IFR 首帧内容提前约 0.3 s（gallery）到约 1.2 s（7guis） ——是机制方向的确认，不作为稳定 benchmark。

#复现

# 策略阶梯 + 正确性 oracle
pnpm --filter vue-lynx-ifr-bench run check
pnpm --filter vue-lynx-ifr-bench run bench

# 全示例扫描
node packages/ifr-bench/examples-sweep/orchestrate.mjs <dir>
node packages/ifr-bench/examples-sweep/sweep.mjs <dir>

# 真实浏览器（Lynx for Web）测量，含 plain-web 基线
node packages/ifr-bench/web-harness/run-browser.mjs <bundlesDir> [runs] [throttle]

# §3b 用的四配置聚焦重建（含 ai-chat / elk）
node packages/ifr-bench/reeval/orchestrate-focused.mjs <dir>