How VS Code Achieves Lightning‑Fast Startup: Front‑End Performance Secrets

TL;DR

Opening points

VS Code aims to let users start editing as quickly as possible.

Startup speed improvements are a collection of many small tweaks, not a single silver bullet.

Monaco Editor began in late 2011 as an experiment to build a developer tool that runs in the browser.

About startup performance optimization

Basic rules

Measure, measure, measure; establish a baseline using the Performance API and instrument key startup milestones.

Monitor each release and react quickly to regressions.

Test on an old ThinkPad to ensure VS Code starts within 1.8 seconds.

Focus on loading code and running the program rather than low‑level Electron or V8 details.

Ensure code loads fast

Bundle with Rollup/Webpack into a single file (≈400 ms saved).

Compress code (≈100 ms saved).

Use V8 cached data to store compiled bytecode (≈400 ms saved).

Prioritize lifecycle phases; render the file explorer and editor first.

Use requestIdleCallback for non‑critical work (see "Idle Until Urgent").

Perceived performance tricks

Switch to MouseDown instead of MouseUp/Click for tab changes.

Render breadcrumbs and status bar early when opening large files to give the impression of a fast UI.

No silver bullet

VS Code is one of the few desktop editors built entirely with web technologies. Since its inception, performance‑first has been a core principle. While not as fast as Sublime Text, its performance is acceptable and continuously improving.

Many open‑source editors now separate the UI (web‑based) from a native core (e.g., TextBuffer), allowing different UI frameworks such as Electron or Qt.

The author initially looked for "black magic" but found that the key is systematic measurement and incremental improvements.

Key takeaways

Prioritize loading the file tree and editor so the cursor appears instantly.

Collect detailed performance metrics for every release.

Address bottlenecks promptly.

Performance work is ongoing; VS Code tags like perf and startup‑perf on GitHub track related issues.

Where to start?

Key web performance metrics include:

Abbr

Full name

Description

FCP

First Contentful Paint

First byte of DOM content rendered.

LCP

Largest Contentful Paint

Render time of the largest text or image block.

FID

First Input Delay

Time until the UI responds to the first user interaction.

FCI

First CPU Idle

First moment the CPU is idle.

TTI

Time to Interactive

Time until the page is fully interactive.

For editors, the most relevant metric is the time from clicking the icon to being able to type, which VS Code targets at 1 second (≈500 ms for hot start).

Measuring starts with console.time or the newer Performance API at critical points. VS Code’s Startup Performance command shows total time (~2 s) and TTI (~977 ms).

Load and execute JavaScript as fast as possible

General front‑end performance rules apply:

Reduce bundle size (minify HTML/CSS/JS).

Reduce HTTP requests and enable gzip.

Use modern bundlers (Webpack, Rollup) and code‑splitting.

These steps aim to minimize JavaScript load time, crucial for SPA‑style applications.

V8 Code Cache

V8 Code Cache stores the result of the first compilation, allowing subsequent loads to skip parsing and compilation. VS Code uses the AMD loader with built‑in V8 cache support. For most apps, simply import v8-compile-cache at the entry point.

import 'v8-compile-cache';

After these optimizations, VS Code’s JS bundle load time dropped from ~1.5 s to ~0.5 s.

Lifecycle: Smarter ordering

VS Code splits its startup into four phases to prioritize critical UI: Starting: low‑level dependencies. Ready: core services instantiated. Restored: editor and UI state restored. Eventually: editor fully usable.

Core code (simplified):

// src/vs/workbench/common/contributions.ts
start(accessor: ServicesAccessor): void {
  const instantiationService = this.instantiationService = accessor.get(IInstantiationService);
  const lifecycleService = this.lifecycleService = accessor.get(ILifecycleService);
  [LifecyclePhase.Starting, LifecyclePhase.Ready, LifecyclePhase.Restored, LifecyclePhase.Eventually]
    .forEach(phase => {
      this.instantiateByPhase(instantiationService, lifecycleService, phase);
    });
}

instantiateByPhase(instantiationService: IInstantiationService, lifecycleService: ILifecycleService, phase: LifecyclePhase): void {
  if (lifecycleService.phase >= phase) {
    this.doInstantiateByPhase(instantiationService, phase);
  } else {
    lifecycleService.when(phase).then(() => this.doInstantiateByPhase(instantiationService, phase));
  }
}

IdleCallback

// busy busy busy busy
// busy busy busy busy
// busy busy busy busy
requestIdleCallback((deadline) => {
  // idle idle idle idle
  // idle idle idle idle
  // idle idle idle idle
});
// busy busy busy busy
// busy busy busy busy
// busy busy busy busy

requestIdleCallback

lets the browser run low‑priority tasks during idle periods, avoiding UI jank compared to setTimeout. A timeout can be supplied to guarantee execution after a maximum delay.

requestIdleCallback(processPendingAnalyticsEvents, { timeout: 2000 });

Generally let the browser decide when to run the callback; a timeout may disrupt ordering.

Perceived Performance: Small tricks

For heavy operations like opening a large file, render the editor tab and breadcrumb first so the UI feels responsive.

Switching tabs using MouseDown instead of MouseUp saves ~50 ms, making the UI feel faster.

Do not replace every click handler with MouseDown ; complex UI may need drag handling.

Conclusion and preview

The talk emphasized systematic measurement, smart re‑ordering, and perception‑enhancing tricks rather than deep‑dive technical hacks. Applying these ideas helped the KAITIAN project cut its startup from ~3 seconds to under 500 ms, with a future detailed post promised.

References

CovalenceConf 2019: Visual Studio Code – The First Second

Web Dev: https://web.dev/

Idle Until Urgent

Using requestIdleCallback

V8 Code Cache

New JavaScript techniques for rapid page loads