Editor becomes sluggish and VS Code core processes use 2.4x CPU / 2x disk I/O with this extension enabled, in a workspace that is almost entirely non-HTML

[SCPUNber]

---

Environment

Item	Value
VS Code	1.134.0 (110a328ea54b42367b803ec53ee0bf52ef26b419, 2026-08-18)
OS	Windows 11, 10.0.26200
CPU / RAM	AMD Ryzen 9 5900X (24 threads) / 63.9 GB, 37 GB free
Extension	ecmel.vscode-html-css 2.0.14 (latest on Marketplace)
Settings	all defaults — css.enabledLanguages: ["html"], css.styleSheets: [], css.autoValidation: "Never"
Workspace	198 files: py(55) pyc(42) md(41) txt(32) json(9) html(7) pdf(5); no CSS files
Extensions installed	49

Steps to reproduce

1. Open a workspace where HTML is a small minority of the files (here: 7 HTML files out of 198, no CSS).
2. Enable ecmel.vscode-html-css 2.0.14 with default settings.
3. Open a Markdown file — not an HTML file. Leave it focused.
4. Generate light filesystem activity outside the workspace folder: write an empty file repeatedly, ~200 writes/sec for 30 seconds.
5. Sample per-process CPU time and I/O operation counts before and after (Windows: Get-CimInstance Win32_Process + Get-Process).
6. Repeat the identical run with the extension disabled and compare.

Expected

With no HTML editor open and only 7 HTML files in the workspace, the extension should contribute little or no measurable load to VS Code's main and renderer processes.

Actual

CPU and disk I/O in VS Code's core processes roughly double to quadruple. The editor becomes sluggish for text selection.

Metric (30 s, ~6,000 writes)	Extension absent	Extension present	Ratio
Total CPU across VS Code processes	18.0 %	43.3 %	x2.4
main process CPU	1.9 %	14.0 %	x7.4
renderer process CPU	9.3 %	19.2 %	x2.1
Disk I/O operations	18,592	37,250	x2.0

Both rows come from consecutive steps of Help: Start Extension Bisect on the same machine, same VS Code build, and the same synthetic load — the only difference is which subset of extensions was enabled.

The extension host process itself stayed at 0.1–0.2 % CPU in every run. The cost does not appear as the extension computing; it appears as work in VS Code's core processes.

How the extension was identified

Followed https://github.com/microsoft/vscode/wiki/Performance-Issues :

1. Launched a clean instance with --disable-extensions --user-data-dir <temp>. Typing and text selection were fast.
2. Ran F1 > Help: Start Extension Bisect on the normal window. Binary search over 49 extensions identified this extension.

Ruled out by measurement (not assumed)

Hypothesis	Measurement	Result
Memory pressure	63.9 GB total, 37 GB free (41.7 % used)	ruled out
CPU saturation	max 2.9 % per process at rest	ruled out
Garbage collection	GC events total ~2.4 s across a 91 s DevTools trace	ruled out
GPU / raster	GPUTask avg 0.34 ms, RasterTask avg 0.15 ms	ruled out
state.vscdb WAL growth	0.00 MB growth over 20 s	ruled out
Screen-reader mode	editor.accessibilitySupport: "off" resolves to AccessibilitySupport.Disabled; compute() returns it without consulting the environment	ruled out
terminal.integrated.sendKeybindingsToShell	affects terminal focus only; symptom is in the editor	ruled out
VS Code version	reproduced on both 1.124.2 and 1.134.0	ruled out
Keyboard input path	DevTools trace: RawKeyDown median 1.0 ms, KeyUp median 0.8 ms, Char median 8.0 ms; no keyboard event over 100 ms	ruled out

Note on the DevTools trace: it contained 572 mouse events over 100 ms, but all of them fall inside 8 seconds that coincide with the profiler's own disabled-by-default-devtools.screenshot events. They are an artifact of the recording, not the symptom. Stated here so they are not mistaken for evidence.

Hypothesis (not verified)

The extension declares "activationEvents": ["onStartupFinished"] and its default css.enabledLanguages is ["html"], yet the cost appears with no HTML editor open and lands in the core processes rather than the extension host. This suggests file watching, workspace scanning, or IPC traffic that runs regardless of the active language. I did not verify this and the maintainers are better placed to confirm it.

Not claimed

• No CPU profile of the extension host was captured, so the responsible code path is not identified.
• A separate symptom — Japanese IME input-method switching failing or lagging — was reported by the user but could not be reproduced under measurement; keyboard latency measured normal. Any connection to this extension is unverified and is not being asserted here.
• No claim that the extension is defective for its intended use. This report is only about the cost incurred in a workspace that is almost entirely non-HTML.

Question

Is this cost expected? Is there a setting that scopes the extension's background work to workspaces that actually contain HTML/CSS?