SpiritCode.blog

Why VS Code Is Slow (And How I Fixed It For Good)

Why VS Code Is Slow (And How I Fixed It For Good)

Add Post

Meta description: I diagnosed why VS Code was lagging on my machine and fixed it with real configs, not guesses. Here’s exactly what slowed it down and how I solved each cause.

Last updated: June 19, 2026

A few months ago, I opened a mid-sized React Native project in VS Code and watched the editor freeze for nearly four seconds every time I typed a single character. Autocomplete lagged behind my keystrokes, the Git sidebar took forever to refresh, and switching tabs felt like wading through mud. I assumed it was my laptop’s fault — until I profiled the editor itself and found three extensions, one misconfigured setting, and a bloated node_modules folder were the real culprits.

This isn’t a generic “disable some extensions” listicle. I’m going to walk through exactly how I diagnosed VS Code performance issues using its built-in profiler, what I found, and the specific fixes that brought my startup time down from 11 seconds to under 2.

TL;DR

  • Use VS Code’s built-in Process Explorer and Extension Bisect to find the exact extension or process eating your CPU — don’t guess.
  • File watchers on large node_modules or .git directories are the single biggest cause of VS Code slowness for JavaScript and Python projects.
  • Disabling unused language servers, trimming files.exclude/files.watcherExclude, and switching to the TypeScript workspace version instead of the bundled one solved most of my lag.

Why VS Code Performance Issues Happen In The First Place

VS Code is built on Electron, which means it’s running a full Chromium renderer plus a Node.js backend for every window you open. That’s powerful — it’s why extensions can do almost anything — but it also means every misbehaving extension, every file watcher, and every language server process adds real overhead. On a small project you’ll never notice. On a monorepo with 40,000 files, it adds up fast.

In my case, the project had a node_modules directory with over 38,000 files, a .git folder with years of history, and six extensions running language servers simultaneously (ESLint, Prettier, Tailwind CSS IntelliSense, GitLens, Python, and a Docker extension I wasn’t even using on that project). Each one was watching the filesystem independently.

Pro Tip: Before changing any settings, run code --status from your terminal. It dumps memory usage per extension host process and immediately tells you if one extension is dominating CPU or RAM.

Prerequisites

To follow along, you’ll need:

  • VS Code version 1.90 or later (I’m running 1.96 as of this writing)
  • Access to the Command Palette (Ctrl+Shift+P / Cmd+Shift+P)
  • A terminal in your project root
  • Optional but useful: htop or Task Manager open alongside VS Code so you can correlate CPU spikes with actions in the editor

[INTERNAL LINK: related article]

Step-by-Step: Diagnosing and Fixing VS Code Slowness

Step 1: Run the Built-In Performance Profiler

Open the Command Palette and run Developer: Show Running Extensions. This view ranks every active extension by activation time and CPU usage. In my case, GitLens showed an activation time of 1,200ms and was responsible for a background process that scanned the entire commit history on every file save — something I didn’t know it was doing.

For a deeper look, run Developer: Startup Performance. This shows you the exact breakdown of what happened between launching VS Code and the editor becoming interactive — extension loading, workspace folder scanning, and Git status checks are usually the worst offenders.

code --status

This command, run from your terminal (not inside VS Code), prints a table of every extension host process with its PID, CPU%, and memory. I found one zombie Python language server process still running from a window I’d closed two days earlier, eating 1.4GB of RAM.

Step 2: Use Extension Bisect to Isolate the Problem

If Developer: Show Running Extensions doesn’t make the culprit obvious, use:

Command Palette → Developer: Extension Bisect

This disables half your extensions, asks if the problem persists, and binary-searches down to the single extension causing the slowdown. It took me three rounds to confirm GitLens’s “automatic blame annotation” feature was the main drag on typing latency in large files.

Step 3: Fix File Watcher Overload

This was the single biggest fix for me. VS Code watches your entire workspace for file changes by default, and on JS/TS projects that means watching every file inside node_modules unless you tell it not to. Add this to your workspace .vscode/settings.json:

{
  "files.watcherExclude": {
    "**/node_modules/**": true,
    "**/.git/objects/**": true,
    "**/.git/subtree-cache/**": true,
    "**/dist/**": true,
    "**/.next/**": true,
    "**/coverage/**": true
  },
  "search.exclude": {
    "**/node_modules": true,
    "**/dist": true,
    "**/.next": true
  },
  "files.exclude": {
    "**/.git": true,
    "**/.DS_Store": true
  }
}

After adding this, my CPU usage during idle (no typing, just the editor sitting open) dropped from a steady 14% to nearly 0%.

Important: files.exclude hides files from the Explorer sidebar but does NOT stop them from being watched or indexed. You need files.watcherExclude and search.exclude separately — this distinction tripped me up the first time.

Step 4: Switch to the Workspace TypeScript Version

By default, VS Code bundles its own TypeScript version for IntelliSense, which can be older than the one your project uses and sometimes runs slower on large codebases. Switch to your project’s local version:

Command Palette → TypeScript: Select TypeScript Version → Use Workspace Version

On my project (TypeScript 5.4.5 locally vs. the bundled 5.3.x), this alone shaved roughly 800ms off autocomplete response time on large .tsx files.

Step 5: Disable Unused Language Servers Per-Workspace

I had the Python extension active even on JavaScript-only projects because it was installed globally. Extensions don’t need to run everywhere. Right-click any extension in the Extensions panel and choose Disable (Workspace) instead of uninstalling it — this keeps it available for other projects while freeing resources here.

Step 6: Clear the Workspace Storage Cache

Over time, VS Code accumulates cached data per workspace that can balloon to hundreds of megabytes and slow down workspace loading. On Linux:

du -sh ~/.config/Code/User/workspaceStorage/* | sort -rh | head -10

I found one workspace folder consuming 2.1GB of cached data from an old debugging session. Deleting stale entries (after closing VS Code) reclaimed disk I/O overhead on startup.

Real-World Tips I Use In Production

  • I keep a separate, minimal settings.json profile for large monorepos using VS Code’s Profiles feature (Ctrl+Shift+P → Profiles: Create Profile), so I don’t have to manually disable extensions every time I open a big project.
  • I disabled auto-save with afterDelay and switched to onFocusChange — constant auto-save was triggering ESLint and Prettier on every keystroke pause, doubling CPU load during heavy editing sessions.
  • For Docker-heavy projects, I only enable the Remote Containers extension inside a dedicated profile, since it spins up background processes that are pure overhead on projects that don’t use containers.

Common Errors I Ran Into (And How I Fixed Them)

Error: Extension host terminated unexpectedly This showed up in the Output panel under “Extension Host” right after I enabled GitLens’s deep blame feature on a repo with 12,000+ commits. The fix was disabling gitlens.currentLine.enabled and gitlens.codeLens.enabled for that workspace specifically.

Error: High CPU from rg (ripgrep) processes Running code --status showed multiple rg processes stuck at 100% CPU. This happens when search indexing collides with a file watcher loop on a symlinked directory. The fix was adding the symlinked path explicitly to search.exclude.

Error: IntelliSense just stops working with no error message This turned out to be the TypeScript server silently crashing on a type definition file with a circular reference. Running TypeScript: Restart TS Server from the Command Palette fixed it temporarily, but the real fix was correcting the circular type import.

[SOURCE: https://code.visualstudio.com/docs/getstarted/settings] [SOURCE: https://github.com/microsoft/vscode/wiki/Performance-Issues]

FAQ

Q: Why is VS Code slow when opening large projects? A: It’s almost always file watchers scanning node_modules or .git, combined with multiple extensions running language servers simultaneously on every file in the workspace.

Q: Does disabling extensions actually speed up VS Code? A: Yes — disabling extensions per-workspace (not globally) is one of the fastest ways to cut both startup time and idle CPU usage, especially extensions with background blame or linting features.

Q: How do I check what’s making VS Code slow? A: Run code --status in your terminal, or use Developer: Show Running Extensions inside VS Code to see CPU and memory usage per extension.

Q: Does VS Code Remote SSH cause performance issues? A: It can, since it runs a full extension host on the remote machine. Network latency between your local UI and the remote server compounds any slowness already present in the project itself.

Q: Will reinstalling VS Code fix slow performance? A: Rarely. Most slowness comes from workspace-specific settings, extension configuration, or cached data — not corruption in the VS Code installation itself

About the Author

I’m a senior software engineer with eight years of experience building and maintaining production JavaScript, TypeScript, and Python applications, with a focus on developer tooling and DevOps workflows. I spend a lot of my week inside VS Code, Docker, and CI pipelines, and I write about the practical fixes I find along the way. You can find more deep dives like this one on SpiritCode.