Source post used

Primary source: https://linear.app/changelog/2021-03-31-startup-performance-improvements

Context source: https://linear.app/changelog/2021-05-20-improving-performance-for-large-workspaces

https://performance.dev/how-is-linear-so-fast-a-technical-breakdown

1) Techniques from the post

From the startup-performance post, the concrete techniques are:

Refactor and optimize startup data loading (especially pre-warmed clients with local DB data).

Switch build system to improve bundle output (Linear moved Parcel → Rollup; for us this means evaluating best bundling config/tooling for startup + size).

Lazy-load infrequently used app code and infrequently used data.

Target modern browser/runtime capabilities to avoid shipping legacy transforms/polyfills where unnecessary.

Improve dead code elimination (tree-shaking).

Code-split by route/feature boundaries.

Preload code before it is needed (intent-based prefetch/preload).

Scale/architecture follow-up from the large-workspace post:

Treat large-workspace scaling as first-class architecture work (not only micro-optimizations).

Continuously profile and remediate hot paths for large datasets.

2) What fits Web vs Electron

Notes:

Web has more network variance pressure, so preload strategy must be bandwidth-aware.

Electron has stronger control of runtime (Chromium version) and benefits heavily from deterministic startup work and memory discipline.

3) Per-app priority / criticality

Legend: P0 = must do now, P1 = should do next, P2 = nice follow-up

4) Phased implementation plan

Phase 0 — Baseline & guardrails (1 week)

Define SLOs: warm startup, cold startup, first interactive list, memory steady-state.

Add measurement in both apps (same metric names; per-workspace-size segmentation).

Create “small / medium / large workspace” test fixtures.

Exit criteria: Reliable baseline dashboards + repeatable local benchmark script.

Phase 1 — Startup critical path (1–2 weeks)

Reduce synchronous startup work.

Defer non-critical initialization.

Optimize local data hydration path for pre-warmed sessions.

Exit criteria: Meaningful warm-start improvement on both Web and Electron.

Phase 2 — Bundle strategy (1–2 weeks)

Audit bundle graph by route/feature.

Enforce route/feature code splitting.

Tighten modern targets and tree-shaking settings.

Exit criteria: Lower initial JS bytes and faster cold start.

Phase 3 — Lazy data/code + preload strategy (1–2 weeks)

Lazy-load rarely used views/features/data.

Add intent-based preloading (hover/soon-to-open routes/workflows).

Cap aggressive prefetch on constrained networks.

Exit criteria: Faster perceived navigation with no significant bandwidth regressions.

Phase 4 — Large-workspace scalability hardening (2+ weeks, parallel track)

Profile pathological large-workspace flows.

Rework heavy list/filter/sync hot paths.

Add scalability regression tests in CI datasets.

Exit criteria: No severe degradation moving from medium to large workspace fixtures.

Phase 5 — Rollout & regression control (ongoing)

Feature-flag each major perf change.

Roll out progressively (internal → beta cohort → % rollout).

Alert on startup, interaction latency, and memory regressions.

Exit criteria: Stable production metrics post-rollout.

Recommended immediate execution order

Phase 0 + Phase 1 (highest ROI, lowest product risk).

Phase 2 + Phase 3 (bundle and loading behavior).

Phase 4 in parallel once baseline instrumentation is stable.

Keep Phase 5 always on.