背景和目标

Tab system 引入后，工作台不再只有一个前台页面。用户可以同时打开多个 workstream、子应用和对象页，系统背后也会同时存在更多 route、runtime、iframe、SDK 和后台任务。性能问题因此不再是“某个页面慢”，而是三条用户路径分别要守住。

图 0：一个通用工作台里的 tab system 演示。性能问题之所以变复杂，是因为多个工作对象可以同时保持打开，但只有当前 tab 应该可交互并占用前台资源。

业务目标和技术目标分开看：

优化原则：

先判断当前用户路径，再决定资源应该前移、延后、保活还是取消。每个性能收益都要能在瀑布或 timing 图里看到 blocker 的移动、消失或缩短。

图 P1：Performance optimization map。它把优化分成首屏关键路径、热切换、后台压力三类，也列出几个被拒绝的伪收益。

结论和收益

注意两点：

1. 严格 preview FMP、strict tab-switch、本地 C02 gate 不混在一起算总收益。
2. “移动了资源”不自动等于收益。只有用户指标变好，并且图里能解释原因，才算保留。

测量口径

FMP 严格对比使用同一套环境：

• authenticated preview environment；
• target preview-lane headers；
• browser cache disabled；
• CPU 4x throttle；
• 4G network throttle；
• 同一批 route 和同一类最终 FMP marker；
• 失败实验保留记录，不把回滚项算收益。

Tab switch 使用 v3 指标，不再只看“点击后 frame 显示用了多久”：

这次优化里最重要的测量修正是：旧指标可能显示几十毫秒，但 strict probe 会看到可见后还有上百到上千毫秒 long task。后续只接受能降低 post-visible blocking 或最终 FMP 的优化。

Measurement & Gates：验证 Harness 和 E2E 用例

收益不是来自一次手测。我们把验证拆成三套 harness，每套只回答一个问题。

E2E 用例保护的是“优化没有破坏 tab system 的正确性”。mock-off 集成用例通过 preview-lane routing 连接真实后端，不把 mock 数据误当成 preview 结果。

What Changed：优化地图

这张表不是 commit 清单，而是后面章节的索引。每一行都按同一个顺序写：先写问题，再写 blocker 或原因，再写方案，最后写证据和防误判。

第一类：First Load / FMP

1. 清掉不属于当前首屏的工作

问题是：用户等待当前 route 首屏时，网络和主线程却在为其它 future path 或低优 SDK 付费。方案不是固定 sleep，而是用 route-specific first-screen ready 判断哪些工作可以移到首屏后。

图 P2：Critical-path cleanup waterfall。它是基于严格 FMP loop 的模式图，用来解释 cleanup pattern：host uploader 从 7/7 pre-FMP 路径移到 0/7，非当前 Seto entry fanout 在受影响路径从 5 移到 0。图里的 example route 不是单一路由精确 trace，精确 route delta 见后面的 Scheduling 和 Official Forecast。

实现思路：

1
2
3
4
5
6
7
8

// 挂载在 route first-screen ready 之后。
// 这里只调度“不属于当前首屏”的工作，避免把真正首屏依赖延后。
afterFirstScreenReady(() => {
  scheduleLowPrioritySdkInit();
  scheduleUploaderInit();
  scheduleNonCurrentSetoPreload();
});

关键点是：延后的是“不属于当前首屏”的工作，不是盲目把所有资源都推后。

2. Scheduling：route chunks 从晚发现变成提前发现

问题是：Scheduling route chunks 到 6785ms-15464ms 才被 sandbox 发现，覆盖最终 FMP 窗口。原因不是网络一定慢，而是浏览器太晚知道这些 chunks 是当前首屏需要的资源。

Scheduling FMP 从 14773ms 到 11926ms，降低 2847ms / 19.3%。

图 P3：Scheduling route chunks waterfall。Before 里 route chunks 在 6785ms-15464ms 才被发现并覆盖 FMP 窗口；After 里对应 chunks 作为 link resource 在 1928ms-1961ms 启动。

代码策略：

1
2
3
4
5
6
7
8
9
10
11
12

// 挂载在 route resolver 识别到 Scheduling 路由后。
// 只提前当前路由首屏需要的 chunks，不做 family-wide preload。
if (currentRouteMatches('/scheduling/schedule')) {
  preloadRouteChunks([
    'schedule route chunk',
    'schedule view panel chunk',
  ]);

  // 依赖 core data 的请求仍然等 core data 可用后再发，避免错误并行。
  prefetchScheduleViewPanelAfterCoreData();
}

为什么有效：

• route chunks 和首屏 data 不是必须串行；
• 提前启动 route chunks 后，它可以和 shell/data 并行；
• FMP 剩余时间主要是 Seto runtime、数据和渲染，不再是“浏览器晚发现代码”。

3. Official Forecast：CSS 是 route-critical，不能等到最后

问题是：Official Forecast 的 CSS 在 13789ms-14988ms 这个非常晚的窗口才出现，最终 marker 会等 late stylesheet discovery。方案是只提前首屏必需的 CSS，而不是盲目提前所有 route JS。

Official Forecast FMP 从 14271ms 到 11612ms，降低 2659ms / 18.6%。

图 P4：Official Forecast CSS waterfall。Before 里 CSS 在 13789ms-14988ms 这个非常晚的窗口才出现；After 里 CSS 在 1872ms-2632ms 提前启动，和 route code/data 并行。

代码策略：

1
2
3
4
5
6

// 只在 Official Forecast route 命中时提前样式。
// 这个 CSS 影响首屏稳定，因此属于 route-critical asset。
if (currentRouteMatches('/scheduling/official_forecast')) {
  preloadStylesheet('official forecast critical css');
}

为什么有效：

• 这不是普通“多 preload 一个资源”；
• 这个 CSS 直接影响首屏最终渲染稳定；
• 它从 FMP 前最后一段等待中移走后，最终 marker 不再等 late stylesheet discovery。

4. 反例：Swimlane chunk 不是收益

有一次我们把 Swimlane chunk 从 pre-FMP 移走，表面上看 waterfall 更干净：pre-FMP count 7/7 -> 0/7。但严格跑下来平均 FMP 反而 +1217ms，load-start 也更差，所以回滚。

这个反例要放在正文里，因为它说明一件事：性能优化不是整理瀑布图。资源少了但用户更慢，就是失败。

第二类：Hot Tab Switch

热切换的问题不是“frame 有没有显示”，而是“用户看到后能不能操作”。所以 v3 要看 post-visible blocking。

图 P5：Hot tab switch causality。Before 中，冷 runtime 在点击后加载，frame 已经 visible 之后仍有 1193.7ms blocking；After 中，idle prewarm 把主要准备工作移到点击前，post-visible blocking 降到 8.7ms。

1. Idle prewarm

问题是：冷切换时，用户点击后才开始加载 runtime、恢复视图、等待 iframe/subapp ready。frame 即使先显示出来，后面仍可能被 long task 卡住。方案是首屏完成后，在 idle 窗口准备最近可能切回的 runtime。

实现策略：

1
2
3
4
5
6
7

// 挂载在首屏 ready 之后。
// native runtime 较轻，可以更早排队；Seto sandbox 更重，需要更谨慎。
afterFirstScreenReady(() => {
  queuePrewarm(nativeTabs, { delay: 1000 });
  queuePrewarm(setoTabs, { delay: 3000, primeLifecycle: true });
});

为什么有效：

• 目标 runtime 的部分加载、初始化、生命周期 prime 在用户点击前完成；
• 用户点击后不再把大量 subapp loading 和 long task 放到可见之后；
• prewarm 只跑在首屏后，不能抢首屏。

2. Runtime-aware prewarm

这里的取舍是：所有 runtime 立刻预热最简单，但 Seto sandbox 更重，容易把后台优化变成前台压力。最终策略是 native 更早，Seto 更谨慎。

这说明 warm pool 和 idle prewarm 不能只看“是否提前加载”，还要看 runtime 类型、当前前台压力、切换是否正在 settling。

3. 暂停 hidden prewarm，消掉前台 spike

问题是：用户切到 Supervisor 时，hidden/background Audit Workbench、xlsx、Slardar 等任务同时抢主线程。方案是给前台 tab 一个 lease：只要前台正在切换或还没稳定，后台任务必须让路。

1
2
3
4
5
6
7
8

// 所有 hidden prewarm 和后台 SDK 任务执行前都要检查。
// async import 之后也要重查，因为下载期间前台状态可能已经变了。
function shouldRunBackgroundTask(tabId) {
  if (foregroundTabHasLease() && tabId !== focusedTabId) return false;
  if (tabSwitchIsSettling()) return false;
  return true;
}

收益：

这说明后台优化必须有前台优先级。预热如果抢了当前 tab，就是负优化。

第三类：Background Pressure

问题是：hidden tab 仍然可能活着，Notification、WebSocket、Tea、Slardar、visit、storage health、AIS 这些任务如果按普通单页应用的方式启动，会在用户切换时制造新的 long task。方案是统一进入 foreground-aware scheduler。

1
2
3
4
5
6
7
8
9
10
11
12

// 后台任务不能直接执行，必须先进入统一仲裁。
function scheduleWorkspaceBackgroundTask(task, options) {
  requestIdleCallback(() => {
    if (shouldDeferWorkspaceBackgroundTask(options.tabId)) {
      retryLater();
      return;
    }

    task();
  });
}

异步任务还要在 import / loader 前后重查：

1
2
3
4
5
6
7
8
9
10
11

async function safeLoadSdk() {
  if (shouldDefer()) return retryLater();

  const sdk = await importSdk();

  // import 可能花几百毫秒。回来时前台 tab 可能已经开始切换。
  if (shouldDefer()) return retryLater();

  sdk.init();
}

这些改动的价值是防止未来某个 SDK 变成新的 tab-switch 卡顿源。它们是系统稳定性的底座，不应该被夸成 FMP 主收益。

被拒绝的优化

Engineering Review Lens：可复用方法

1. 先分路径。 FMP、tab switch、background pressure 是三类问题，不能用同一把尺子。
2. 再定资源归属。 当前首屏需要的资源前移；不属于当前首屏的资源延后；未来可能需要的资源只能 idle prewarm。
3. 画因果图再写结论。 图里必须能看到 blocker 前移、消失、缩短或移到 FMP 后。
4. 接受失败。 资源移动但 FMP 变差，就回滚。
5. 本地 gate 和 preview 收益分开写。 本地 C02 是防回归，不是线上收益。

最终，Tab System 的性能收益不是靠单点技巧，而是靠三套机制同时成立：

• 首屏关键路径只保留当前 route 必要工作；
• 热切换有 bounded runtime cache 和 idle prewarm；
• 后台任务必须服从 foreground scheduler。

这套机制比单点优化更重要，因为 Workspace 只会接入更多子应用、更多 SDK、更多 runtime。没有路径分类和资源仲裁，tab 越多，系统越容易失控。