Skip to content

Keep input responsive while highlighting heavy code threads - #1160

Draft
jorgemanrubia wants to merge 2 commits into
mainfrom
fix-code-highlight-perf
Draft

Keep input responsive while highlighting heavy code threads#1160
jorgemanrubia wants to merge 2 commits into
mainfrom
fix-code-highlight-perf

Conversation

@jorgemanrubia

Copy link
Copy Markdown
Member

A comment thread with many or large code blocks could lock up the page on load: the view would take a long time to appear and then input and scrolling were frozen until it finished. The reporter saw this on iOS and macOS Safari and suspected the Prism syntax highlighter.

They were right about where the cost lives. highlightCode() — the helper host apps call to syntax-highlight rendered Action Text content — walked every code block and ran Prism over all of them in a single synchronous pass. The more (or bigger) the code blocks, the longer that one uninterruptible task held the main thread, and while it ran the browser could neither paint nor process input. On a heavy thread that window stretches into seconds, which is exactly the freeze that was reported.

A previous change (#1087) removed an O(controllers × blocks) blow-up and made the helper idempotent, but the remaining work was still done all at once. This change spreads it out: the helper now processes blocks in small time-budgeted chunks and hands control back to the browser between them, so the page stays responsive while highlighting catches up. The visible code appears progressively instead of after one long stall.

Measured in headless Chromium on a rendered thread of code blocks, counting frames the browser managed to paint while highlighting ran:

Thread Before After
50 blocks × 40 lines 0 frames (frozen) 6 frames
100 blocks × 60 lines 0 frames (frozen), 271ms single blocking task 15 frames, no JS task over 50ms

highlightCode() now returns a Promise so callers can await completion if they want to; the documented fire-and-forget usage in a Stimulus connect() keeps working unchanged.

Fixes Basecamp card #10020780336: Rendering issue, possibly due to Prism syntax highlighter?

highlightCode() ran Prism over every <pre data-language> in one synchronous
pass. On a heavy thread with many or large code blocks, that single
uninterruptible task monopolizes the main thread, freezing input and scrolling
until it finishes — the symptom reported for slow comment threads on Safari.

Measured in headless chromium on a rendered thread of code blocks:

- 50 blocks x 40 lines: 0 frames painted during highlighting (frozen) -> 6
- 100 blocks x 60 lines: 0 frames painted (frozen), 271ms single blocking task
  -> 15 frames painted, no >50ms JS task

Process blocks in time-budgeted chunks (8ms) and yield to the event loop with a
MessageChannel macrotask between chunks, so the browser can paint and handle
input while highlighting continues. highlightCode() now returns a Promise;
fire-and-forget callers (the documented Stimulus connect() usage) are
unaffected. highlightElement() stays synchronous, and its data-highlighted guard
keeps concurrent runs from double-highlighting a block.
@jorgemanrubia jorgemanrubia self-assigned this Jun 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant