Background And Goals

After the tab system was introduced, Workspace no longer had only one foreground page. Users can keep multiple workstreams, subapps, and objects open, while the host may keep more routes, runtimes, iframes, SDKs, and background tasks alive. Performance is therefore no longer one question of “is this page slow?” It is three separate user paths.

Figure 0: A generic workbench using browser-like tabs. The performance problem starts because multiple work items can stay open, while only the focused tab should stay interactive and own foreground resources.

Business goals and technical constraints:

Optimization principle:

First identify the user path. Then decide whether a resource should start earlier, move later, stay warm, or be cancelled. Every accepted win must show the blocker moving, disappearing, shrinking, or moving after the visible path.

Figure P1: Performance optimization map. The map separates first-screen critical path, hot tab switch, and background pressure, and also lists false wins that were rejected.

Results

Two guardrails:

1. Strict preview FMP, strict tab switch, and local C02 gate are not combined into one total number.
2. Moving resources is not a win by itself. We only keep a change when the user metric improves and the diagram explains why.

Measurement Contract

Strict FMP comparisons used the same setup:

• authenticated preview environment;
• target preview-lane headers;
• browser cache disabled;
• CPU 4x throttle;
• 4G network throttle;
• same route set and same final FMP marker semantics;
• failed experiments kept in the record and excluded from wins.

Tab switch uses v3 metrics instead of only “how long after click until the frame appears.”

The most important measurement repair was separating visible from interactive. Old metrics could report tens of milliseconds while strict probe still found hundreds or thousands of milliseconds of post-visible long task. After this repair, only changes that reduce post-visible blocking or final FMP are accepted.

Measurement & Gates: Harness And E2E Coverage

These wins did not come from one manual run. We split validation into three harnesses, each answering one question.

E2E cases protect correctness while performance changes move work around. Mock-off integration connects through preview-lane routing to the real backend instead of mistaking mock data for preview evidence.

What Changed: Optimization Map

This table is not a commit list. It is an index for the rest of the article. Each row follows the same chain: problem, blocker/cause, solution, evidence, and guardrail.

Category 1: First Load / FMP

1. Remove Work That Does Not Belong To The Current First Screen

Problem: while the user waits for the current route’s first screen, network and main-thread time can be spent on future paths or low-priority SDKs. The solution is not a fixed sleep. It is route-specific first-screen readiness: only work that is not part of the current first screen can move after FMP.

Figure P2: Critical-path cleanup waterfall. This is a strict FMP-loop pattern chart. It explains how host uploader moved from 7/7 pre-FMP routes to 0/7, and non-current Seto entry fanout moved from 5 affected routes to 0. The example route is illustrative; exact route deltas are covered by Scheduling and Official Forecast.

Implementation sketch:

1
2
3
4
5
6
7
8

// Mounted after route first-screen ready.
// Only schedule work that does not belong to the current first screen.
afterFirstScreenReady(() => {
  scheduleLowPrioritySdkInit();
  scheduleUploaderInit();
  scheduleNonCurrentSetoPreload();
});

The key is that we defer non-current work, not all work.

2. Scheduling: Route Chunks Moved From Late Discovery To Early Discovery

Problem: Scheduling route chunks were discovered at 6785ms-15464ms, overlapping the final FMP window. The root cause was not simply slow network; the browser learned too late that these chunks were required for the current first screen.

Scheduling FMP moved from 14773ms to 11926ms, a -2847ms / -19.3% improvement.

Figure P3: Scheduling route chunks waterfall. Before, route chunks were discovered at 6785ms-15464ms and covered the FMP window. After, matching chunks started as link resources at 1928ms-1961ms.

Code strategy:

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

// Mounted after route resolver identifies the Scheduling route.
// Preload only chunks needed by this first screen, not the whole route family.
if (currentRouteMatches('/scheduling/schedule')) {
  preloadRouteChunks([
    'schedule route chunk',
    'schedule view panel chunk',
  ]);

  // This still waits for core data; do not prefetch dependent data too early.
  prefetchScheduleViewPanelAfterCoreData();
}

Why it works:

• route chunks and first-screen data do not have to be fully serial;
• early route chunk discovery lets code loading run in parallel with shell/data;
• the remaining FMP window is Seto runtime, data, and render, not late code discovery.

3. Official Forecast: Route-Critical CSS Cannot Wait Until The End

Problem: Official Forecast CSS appeared at 13789ms-14988ms, so the final marker waited for late stylesheet discovery. The solution is not “preload everything”; it is only to start the stylesheet that stabilizes the first screen.

Official Forecast FMP moved from 14271ms to 11612ms, a -2659ms / -18.6% improvement.

Figure P4: Official Forecast CSS waterfall. Before, CSS appeared at 13789ms-14988ms. After, CSS started at 1872ms-2632ms and ran in parallel with route code/data.

Code strategy:

1
2
3
4
5
6

// Only when Official Forecast route matches.
// This CSS affects first-screen stability, so it is route-critical.
if (currentRouteMatches('/scheduling/official_forecast')) {
  preloadStylesheet('official forecast critical css');
}

Why it works:

• this is not generic “add more preload”;
• the CSS directly affects final first-screen stability;
• moving it away from the final wait window removes a late FMP blocker.

4. Counterexample: Swimlane Chunk Was Not A Win

One experiment moved the Swimlane chunk out of pre-FMP. The waterfall looked cleaner: pre-FMP count 7/7 -> 0/7. Strict runs showed average FMP got worse by +1217ms, and load-start also regressed, so the change was reverted.

This counterexample matters because performance optimization is not waterfall beautification. Fewer resources with slower users is a failure.

Category 2: Hot Tab Switch

The hot-switch target is not “the frame appears.” It is “the user can operate after seeing the frame.” That is why v3 measures post-visible blocking.

Figure P5: Hot tab switch causality. Before, the cold runtime loaded after click, and the frame still had 1193.7ms blocking after becoming visible. After, idle prewarm moved the main preparation work before click, reducing post-visible blocking to 8.7ms.

1. Idle Prewarm

Problem: cold switch loaded runtime, restored view, and waited for iframe/subapp ready after the user clicked. The frame could appear first, but long tasks still blocked interaction. The solution is to prepare likely return targets during idle windows after first screen.

Implementation sketch:

1
2
3
4
5
6
7
8

// Mounted after first-screen ready.
// Native runtime is lighter, so it can enter the queue earlier.
// Seto sandbox is heavier and needs a more conservative delay.
afterFirstScreenReady(() => {
  queuePrewarm(nativeTabs, { delay: 1000 });
  queuePrewarm(setoTabs, { delay: 3000, primeLifecycle: true });
});

Why it works:

• part of runtime loading, initialization, and lifecycle priming happens before click;
• click no longer puts large subapp loading and long tasks after visibility;
• prewarm only runs after first screen, so it does not steal FMP budget.

2. Runtime-Aware Prewarm

The tradeoff is explicit: prewarming every runtime immediately is simple, but Seto sandbox is heavier and can turn a background optimization into foreground pressure. The final policy warms native runtimes earlier and Seto runtimes more carefully.

Warm pool and idle prewarm must consider runtime type, foreground pressure, and whether a switch is settling. “Preload earlier” is not automatically good.

3. Pause Hidden Prewarm To Remove Foreground Spikes

Problem: while the user switched to Supervisor, hidden/background Audit Workbench, xlsx, Slardar, and related work competed on the main thread. The solution is a foreground lease: while the foreground tab is switching or not settled, background tasks must yield.

1
2
3
4
5
6
7
8

// Every hidden prewarm and background SDK task checks before running.
// Async import must re-check after loading because foreground state can change.
function shouldRunBackgroundTask(tabId) {
  if (foregroundTabHasLease() && tabId !== focusedTabId) return false;
  if (tabSwitchIsSettling()) return false;
  return true;
}

Impact:

This proves the scheduling rule: prewarm that steals from the current tab is a negative optimization.

Category 3: Background Pressure

Problem: hidden tabs can still be alive, and SDKs such as Notification, WebSocket, Tea, Slardar, visit, storage health, and AIS can create future tab-switch long tasks if they run like a normal single-page app. The solution is a foreground-aware scheduler.

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

// Background work cannot run directly. It goes through one arbiter.
function scheduleWorkspaceBackgroundTask(task, options) {
  requestIdleCallback(() => {
    if (shouldDeferWorkspaceBackgroundTask(options.tabId)) {
      retryLater();
      return;
    }

    task();
  });
}

Async tasks must re-check around import / loader:

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

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

  const sdk = await importSdk();

  // Import can take hundreds of milliseconds.
  // By the time it returns, the foreground tab may be switching.
  if (shouldDefer()) return retryLater();

  sdk.init();
}

These changes prevent future SDK work from becoming a tab-switch jank source. They are the stability base, not inflated FMP wins.

Rejected Optimizations

Engineering Review Lens

1. Split by path first. FMP, tab switch, and background pressure are different problems and need different measurements.
2. Assign resource ownership. Current first-screen resources move earlier; non-current first-screen work moves later; future resources can only run through idle prewarm.
3. Draw causality before writing the conclusion. The chart must show the blocker moving, disappearing, shrinking, or moving after FMP.
4. Accept failures. If a resource moves but FMP gets worse, revert it.
5. Keep local gates and preview wins separate. C02 is a regression gate, not an online/preview win.

The tab system performance gains do not come from one trick. They come from three mechanisms working together:

• the first-screen critical path keeps only current-route required work;
• hot switching uses bounded runtime cache plus idle prewarm;
• background work yields to the foreground scheduler.

This mechanism matters more than any single optimization. Workspace will keep adding more subapps, SDKs, and runtimes. Without path classification and resource arbitration, more tabs would make the system progressively less predictable.