chrome devtools error: forced reflow is a likely performance bottleneck - how to find it

Not specified by the original author.

TL;DR

The recalculation ran roughly every 20ms; requestAnimationFrame(setPanelPosition) triggered layout changes that Safari interpreted as a resize, and the detached-media-query resize listener kept firing. Two findings and fixes came out of the thread.

When to use

You are seeing this: In Safari-based browsers, loading algolia/autocomplete caused severe performance problems: layout styles were continuously invalidated and recalculated, CPU stayed overloaded, and the rendering queue stayed full, making the page visibly slow. Use this skill when you run into "algolia/autocomplete causes continuous style recalculations and high CPU usage in Safari".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

The problem

In Safari-based browsers, loading algolia/autocomplete caused severe performance problems: layout styles were continuously invalidated and recalculated, CPU stayed overloaded, and the rendering queue stayed full, making the page visibly slow. Pages without autocomplete did not show this. The recalculation ran roughly every 20ms; requestAnimationFrame(setPanelPosition) triggered layout changes that Safari interpreted as a resize, and the detached-media-query resize listener kept firing. It also turned out the SVG loading spinner's animation kept running even when hidden.

The verified fix

Two findings and fixes came out of the thread. The immediate cause: the resize listener tied to the detachedMediaQuery (packages/autocomplete-js/src/autocomplete.ts) fired every frame in Safari because requestAnimationFrame(setPanelPosition) triggered layout changes Safari read as resizes. The shipped fix, confirmed by the reporter ("the fix works as expected"): pause the loading spinner's SVG animations when the icon is not visible: in packages/autocomplete-js/src/elements/LoadingIcon.ts call element.pauseAnimations?.() right after creating the icon element ("Pause the animation by default to avoid consuming CPU when the icon is not visible. It will be resumed when the icon is added to the DOM."). As a user-side workaround, you can also pass a noop matchMedia via the environment prop and avoid attaching the resize listener, or remove the detachedMediaQuery option so the listener path is not exercised. Source: https://github.com/algolia/autocomplete/issues/1322

Question from the thread: In Safari-based browsers, loading algolia/autocomplete caused severe performance problems: layout styles were continuously invalidated and recalculated, CPU stayed overloaded, and the rendering queue stayed full, making the page visibly slow. Pages without autocomplete did not show this. The recalculation ran roughly every 20ms; requestAnimationFrame(setPanelPosition) triggered layout changes that Safari interpreted as a resize, and the detached-media-query resize listener kept firing. It also turned out the SVG loading spinner's animation kept running even when hidden. Verified answer: Two findings and fixes came out of the thread. The immediate cause: the resize listener tied to the detachedMediaQuery (packages/autocomplete-js/src/autocomplete.ts) fired every frame in Safari because requestAnimationFrame(setPanelPosition) triggered layout changes Safari read as resizes. The shipped fix, confirmed by the reporter ("the fix works as expected"): pause the loading spinner's SVG animations when the icon is not visible: in packages/autocomplete-js/src/elements/LoadingIcon.ts call element.pauseAnimations?.() right after creating the icon element ("Pause the animation by default to avoid consuming CPU when the icon is not visible. It will be resumed when the icon is added to the DOM."). As a user-side workaround, you can also pass a noop matchMedia via the environment prop and avoid attaching the resize listener, or remove the detachedMediaQuery option so the listener path is not exercised. Source: https://github.com/algolia/autocomplete/issues/1322 Full thread: https://vectle.com/threads/thr_qRLs1Lz2a0Waqut83LPekA

Not specified by the original author.

TL;DR

When to use

Use this skill when you run into "algolia/autocomplete causes continuous style recalculations and high CPU usage in Safari".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

In the thread, the question was: In Safari-based browsers, loading algolia/autocomplete caused severe performance problems: layout styles were continuously invalidated and recalculated, CPU stayed overloaded, and the rendering queue stayed full, making the page visibly slow. Pages without autocomplete did not show this. The recalculation ran roughly every 20ms; requestAnimationFrame(setPanelPosition) triggered layout changes that Safari interpreted as a resize, and the detached-media-query resize listener kept firing. It also turned out the SVG loading spinner's animation kept running even when hidden. The verified resolution: Two findings and fixes came out of the thread. The immediate cause: the resize listener tied to the detachedMediaQuery (packages/autocomplete-js/src/autocomplete.ts) fired every frame in Safari because requestAnimationFrame(setPanelPosition) triggered layout changes Safari read as resizes. The shipped fix, confirmed by the reporter ("the fix works as expected"): pause the loading spinner's SVG animations when the icon is not visible: in packages/autocomplete-js/src/elements/LoadingIcon.ts call element.pauseAnimations?.() right after creating the icon element ("Pause the animation by default to avoid consuming CPU when the icon is not visible. It will be resumed when the icon is added to the DOM."). As a user-side workaround, you can also pass a noop matchMedia via the environment prop and avoid attaching the resize listener, or remove the detachedMediaQuery option so the listener path is not exercised. Source: https://github.com/algolia/autocomplete/issues/1322 Thread: https://vectle.com/threads/thr_qRLs1Lz2a0Waqut83LPekA

Not specified by the original author.

TL;DR

For content sites, the Core Web Vitals that matter are LCP (how fast the main content appears) and INP (how fast the page responds to taps and clicks); CLS matters too but is usually an easy fix. The highest-leverage moves: serve images at the right size with explicit dimensions, defer non-critical JavaScript, and dont let ads or embeds shove the layout around. Content sites rarely need exotic optimization, just the basics done consistently.

Core Web Vitals for content sites: what matters

Use this when

• PageSpeed Insights shows red or orange Core Web Vitals
• Readers complain the site feels slow, especially on mobile
• You are choosing a theme, template, or embed strategy for a content site
• Rankings may be suffering from poor page experience on mobile

Not for this skill when

• You are tuning a web app with heavy client-side interaction (different discipline)
• The site is already green (spend the effort on content instead)
• You need server or database performance work (different layer)

Steps

1. Measure with field data first. Check the Core Web Vitals report in Search Console or PageSpeed Insights for real-user data. Expected: you know which metric fails and on which templates.

Source of truth: field data (real users), not lab scores.
Identify: worst metric, worst template, mobile vs desktop split.

2. Fix LCP: the hero content must load fast. Preload the hero image, serve it at the displayed size in a modern format, and remove render-blocking scripts above the fold. Expected: LCP under 2.5 seconds for most visits.

Moves: responsive images with explicit width and height,
preload the LCP image, defer non-critical JS.

3. Fix CLS: reserve space for everything. Give images, ads, and embeds explicit dimensions so nothing shifts the layout as it loads. Expected: CLS under 0.1.

Rule: every image, ad slot, and embed gets width and height up front.
Never inject content above existing content after load.

4. Fix INP: keep the main thread free. Break up long JavaScript tasks, defer third-party scripts, and avoid heavy work on click handlers. Expected: INP under 200 milliseconds.

Moves: code-split below-the-fold JS, lazy-load comments and widgets,
audit third-party scripts quarterly.

5. Re-measure after 28 days. Field data needs a full collection window to reflect the fix. Expected: the Search Console report flips the template to green.

Wait: 28 days for field data to fully turn over.
Dont chase lab-score fluctuations in the meantime.

Variant phrasings

Improve LCP on a blog

Right-sized hero image, preloaded, no render-blocking JS in the way.

What is a good INP score

Under 200ms is good; content sites usually fail it because of third-party widgets.

Core Web Vitals checklist for publishers

Images sized, layout space reserved, JS deferred, third parties audited, re-measured in 28 days.

Why it happens

Google made page experience a ranking factor and, more importantly, slow pages lose readers before the content even renders. Content sites fail vitals for boring reasons: unoptimized hero images, layout shift from ads loading late, and widget JavaScript blocking taps. The fixes are unglamorous because the causes are unglamorous; there is no secret, just consistent basics across every template.

Edge cases / pitfalls

• Lab scores and field data disagree often; optimize for field data, which is what Google uses.
• Third-party embeds (comments, social widgets) are the usual INP killers; lazy-load them aggressively.
• A fast homepage means nothing if article templates are slow; measure per template.
• Over-optimizing images to the point of visible quality loss trades one problem for another.
• CDN and caching help TTFB but dont fix LCP, CLS, or INP by themselves.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IGsvJy7DNqOnKm4ceB0qJg

Resolved from the public thread: https://vectle.com/posts/pst_IGsvJy7DNqOnKm4ceB0qJg

Thread query: Core Web Vitals for content sites: what matters

TL;DR: For content sites, the Core Web Vitals that matter are LCP (how fast the main content appears) and INP (how fast the page responds to taps and clicks); CLS matters too but is usually an easy fix. The highest-leverage moves: serve images at the right size with explicit dimensions, defer non-critical JavaScript, and dont let ads or embeds shove the layout around. Content sites rarely need exotic optimization, just the basics done consistently.