Frontend burns 20–45% of a CPU core while completely idle (continuous per-frame Layout/Paint + timer churn)

[agresja]

Environment

• Blinko: v1.8.8, self-hosted, official Docker image, behind an nginx reverse proxy (HTTPS)
• Client: Google Chrome 150.0.7871.114 on Ubuntu 26.04, running Blinko as an installed PWA ("open as window"); also reproduces in a regular tab
• Hardware: Framework 13 laptop (i7-1260P) — relevant only because the constant CPU burn is what made this visible (fan noise / battery)

Symptom

The Blinko renderer process consumes ~20–45% of one CPU core continuously while the app is fully idle — no user input, no visible UI changes, window unfocused. Measured with OS-level per-process CPU sampling over 12-second windows, repeatedly, across several days:

• With the background animation setting enabled: up to ~47% of a core
• With background animation disabled: still ~20–35% of a core, sustained indefinitely
• The burn is network-silent — no polling/requests while idle, so it's purely a client-side render/timer loop
• Persists across page reloads, fresh browser starts, and a full OS reboot (every fresh renderer process shows the same signature)

Isolation done (why I believe it's Blinko's frontend, not my setup)

• Extensions ruled out: reproduced in a PWA window with all extensions disabled (Grammarly, which inflates editor CPU on its own, was explicitly disabled in all profiles — the burn is unchanged without it)
• Differential test: closing only the Blinko window removes exactly the hot renderer process; reopening it brings a new one with the same idle burn
• Other PWAs/tabs on the same machine idle at <1–8% of a core

DevTools Performance profile (idle on /?path=todo)

An idle recording (no interaction) shows the page doing per-frame layout and paint work with no visible change. Bottom-up top buckets:

• Layout ≈ 1.4 s, Paint ≈ 1.1 s, Layerize ≈ 0.9 s of self-time dominating the recording
• Constant timer churn: repeated Timer fired / repeatEvent entries with setInterval/clearInterval cycles

So something re-invalidates layout every frame even when the UI is static. Possible suspects from the outside:

• an animation loop that keeps running even when the "background animation" setting is off (the setting reduces but does not eliminate the burn),
• the frosted-glass / backdrop-filter styling forcing continuous compositing (related: 可不可以新增一个去掉毛玻璃效果的设置，毛玻璃在web上太卡了 || Can you add a new setting to remove the frosted glass effect? ​​Frosted glass is too stuck on the web #673),
• a requestAnimationFrame/interval loop that never idles when the document is unfocused/hidden.

Steps to reproduce

1. Self-host Blinko v1.8.8 (Docker), open it in Chrome (tab or installed PWA), log in
2. Leave it on the main or todo view, hands off the keyboard
3. Watch chrome:// Task Manager (Shift+Esc) or an OS process monitor → the Blinko renderer sits at 20–45% of a core forever
4. DevTools → Performance → record ~15 s without touching anything → continuous Layout/Paint/Layerize + timer activity

Expected

An idle note-taking app should draw ~0% CPU (Chrome throttles hidden/static pages to that; Blinko's constant layout invalidation defeats it). On laptops the current behavior means permanent fan noise and measurable battery drain for a pinned PWA.

Happy to attach full DevTools traces or run instrumented builds if that helps.

Trace-20260711T135900.json.gz

---

Environment

• Blinko: v1.8.8, self-hosted, official Docker image, behind an nginx reverse proxy (HTTPS)
• Client: Google Chrome 150.0.7871.114 on Ubuntu 26.04, running Blinko as an installed PWA ("open as window"); also reproduces in a regular tab
• Hardware: Framework 13 laptop (i7-1260P) — relevant only because the constant CPU burn is what made this visible (fan noise / battery)

Symptom

The Blinko renderer process consumes ~20–45% of one CPU core continuously while the app is fully idle — no user input, no visible UI changes, window unfocused. Measured with OS-level per-process CPU sampling over 12-second windows, repeatedly, across several days:

• With the background animation setting enabled: up to ~47% of a core
• With background animation disabled: still ~20–35% of a core, sustained indefinitely
• The burn is network-silent — no polling/requests while idle, so it's purely a client-side render/timer loop
• Persists across page reloads, fresh browser starts, and a full OS reboot (every fresh renderer process shows the same signature)

Isolation done (why I believe it's Blinko's frontend, not my setup)

• Extensions ruled out: reproduced in a PWA window with all extensions disabled (Grammarly, which inflates editor CPU on its own, was explicitly disabled in all profiles — the burn is unchanged without it)
• Differential test: closing only the Blinko window removes exactly the hot renderer process; reopening it brings a new one with the same idle burn
• Other PWAs/tabs on the same machine idle at <1–8% of a core

DevTools Performance profile (idle on /?path=todo)

An idle recording (no interaction) shows the page doing per-frame layout and paint work with no visible change. Bottom-up top buckets:

• Layout ≈ 1.4 s, Paint ≈ 1.1 s, Layerize ≈ 0.9 s of self-time dominating the recording
• Constant timer churn: repeated Timer fired / repeatEvent entries with setInterval/clearInterval cycles

So something re-invalidates layout every frame even when the UI is static. Possible suspects from the outside:

• an animation loop that keeps running even when the "background animation" setting is off (the setting reduces but does not eliminate the burn),
• the frosted-glass / backdrop-filter styling forcing continuous compositing (related: 可不可以新增一个去掉毛玻璃效果的设置，毛玻璃在web上太卡了 || Can you add a new setting to remove the frosted glass effect? ​​Frosted glass is too stuck on the web #673),
• a requestAnimationFrame/interval loop that never idles when the document is unfocused/hidden.

Steps to reproduce

1. Self-host Blinko v1.8.8 (Docker), open it in Chrome (tab or installed PWA), log in
2. Leave it on the main or todo view, hands off the keyboard
3. Watch chrome:// Task Manager (Shift+Esc) or an OS process monitor → the Blinko renderer sits at 20–45% of a core forever
4. DevTools → Performance → record ~15 s without touching anything → continuous Layout/Paint/Layerize + timer activity

Expected

An idle note-taking app should draw ~0% CPU (Chrome throttles hidden/static pages to that; Blinko's constant layout invalidation defeats it). On laptops the current behavior means permanent fan noise and measurable battery drain for a pinned PWA.

Happy to attach full DevTools traces or run instrumented builds if that helps.

Trace-20260711T135900.json.gz

[dosubot]

Hi @agresja! I'm Dosu and I'm helping the Blinko's Org team.

Your profiling is thorough and very helpful. I dug into the codebase and can confirm several likely contributors to the idle CPU burn you're seeing:

1. Polling timers without visibility-based throttling
Multiple setInterval loops continue firing even when the page is hidden/unfocused and have no document.hidden guard:

• Android shortcuts polling at 800ms [1]
• Embedding progress polling at 2000ms [2]
• Task status polling at 1000ms [3]
• Music player progress at 100ms [4]

Only a single component in the entire app (DefaultModelsSection) implements the Page Visibility API to pause work when the tab is hidden [5]. Everything else keeps ticking.

2. backdrop-filter: blur(8px) (.glass-effect class)
This is applied on several pages and forces continuous GPU compositing even for a static scene [6]. Combined with any layout invalidation from the timers above, it can turn a cheap no-op frame into a full composite pass every tick. This matches the Layerize bucket you saw in the trace.

3. Background animation (ShaderGradient)
The "background animation" setting controls a @shadergradient/react water-plane shader [7]. Disabling it does set animate='off' [8], which should stop the shader loop — but this component is only rendered on public pages (signin, signup, share) [9] [10]. If you're seeing burn on /?path=todo with the setting already off, it's likely not the ShaderGradient but rather the timer churn + backdrop-filter combination.

Root cause summary for your /?path=todo idle burn: The constant Timer fired → layout invalidation → backdrop-filter compositing loop. The timers keep running, trigger minor DOM/style recalcs, and backdrop-filter prevents the compositor from skipping frames.

Potential fixes:

• Wrap all polling intervals with a document.hidden check (or pause/resume via visibilitychange listener)
• Consider replacing backdrop-filter with a pre-blurred static background image or limiting it to pages that truly need it
• Add will-change: transform isolation to glass-effect elements to reduce the compositing blast radius
• Gate timers that are feature-specific (embedding progress, task status) so they only run while those features are actively in use

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.