Continuous style recalculations and high CPU usage in Safari

[wannevancamp]

Description

In Safari-based browsers, loading algolia/autocomplete causes severe performance and rendering issues. Layout styles are continuously invalidated and recalculated, the CPU stays overloaded, and the rendering queue is permanently full. This delays user interactions and makes the page visibly slower. Pages without algolia/autocomplete do not experience these CPU-intensive rendering problems.

Reproduction

Steps

1. Open Safari browser
2. Go to a webpage where algolia/autocomplete is active ex. https://www.algolia.com/doc/ui-libraries/autocomplete/introduction/getting-started/
3. Open the developer tools > Timelines
4. Click the red dot to record a session
5. You will see a high CPU load and continuous rendering of the layout.

screencast.2025-08-26.22-11-29.mp4

Expected behavior

In browsers like Chrome or Firefox, this continuous rendering and high CPU usage does not occur. In Safari, however, it causes visible DOM rendering delays, which are especially noticeable on older devices or pages with many DOM elements.

Environment

• OS: Tested on macOS, though other operating systems may be affected as well
• Browser: Safari
• Autocomplete version: v1.19.2

[Haroenv]

Interesting, this has not been reported before. Did you investigate which style continuously gets set?

Might be related to this part of code:

autocomplete/packages/autocomplete-js/src/utils/setProperties.ts

Lines 54 to 56 in de8a195

	if (!oldValue || value[name] !== oldValue[name]) {
	setStyle(dom.style, name, value[name]);
	}

but as far as I can tell this only gets called when the style actually needs to change if I put a breakpoint in it. Not routinely as I can also see in the timeline.

[jonahstefanovic]

@Haroenv
This behavior is linked to the "detachedMediaQuery" option in the exported autocomplete function. When removed, Safari stops continously recalculating the styles. In particular, the bug just happens when this
props.value.core.environment.matchMedia(props.value.renderer.detachedMediaQuery).matches
is false.

[Haroenv]

looks like that indeed could be the case, as

autocomplete/packages/autocomplete-js/src/autocomplete.ts

Lines 276 to 294 in de8a195

	runEffect(() => {
	const onResize = debounce<Event>(() => {
	const previousIsDetached = isDetached.value;
	isDetached.value = props.value.core.environment.matchMedia(
	props.value.renderer.detachedMediaQuery
	).matches;
	if (previousIsDetached !== isDetached.value) {
	update({});
	} else {
	requestAnimationFrame(setPanelPosition);
	}
	}, 20);
	props.value.core.environment.addEventListener('resize', onResize);
	return () => {
	props.value.core.environment.removeEventListener('resize', onResize);
	};
	});

is in a resize listener, maybe that wrongly fires every frame?

Thanks for finding a workaround at least!

[jonahstefanovic]

That may very well be the case.. This is especially annoying because we don't even need the detached modal, yet not providing it or providing a value that is "true" messes with our implementation of the search. We could also avoid registering listeners and executing code that'll never be used if there was an option like "detachable?" for the autocomplete function instead of only a media query but I'm happy for a fix either way :)

[Haroenv]

I think you can work around the issue by passing matchMedia to the environment prop as a noop (that just returns true or false depending on your use case), as well as implementing the addEventListener to skip actually attaching a resize listener. Could that work?

[wannevancamp]

The recalculation runs every 20 ms. It appears that requestAnimationFrame(setPanelPosition); triggers layout changes, which Safari interprets as a resize.

Possible solutions:

1. Use a ResizeObserver instead of relying on the global window.resize event. This should help prevent false resize triggers in Safari.
2. Call setPanelPosition only when the panel’s dimensions have actually changed.

As @jonahstefanovic pointed out, there is at least a workaround, but hopefully one of these solutions can be implemented in the core of this package.

[Haroenv]

I'm happy to accept a PR that makes this optional, as that would be good for everyone.

ResizeObserver doesn't work unfortunately as that doesn't have sufficient browser support for our targets.

I've checked and actually removed all calls to setPanelPosition as well as the media query, but I still see the continuous recalculation of style:

diff --git a/packages/autocomplete-js/src/autocomplete.ts b/packages/autocomplete-js/src/autocomplete.ts
index 4cbc3e1f..0bda1ba4 100644
--- a/packages/autocomplete-js/src/autocomplete.ts
+++ b/packages/autocomplete-js/src/autocomplete.ts
@@ -41,12 +41,7 @@ export function autocomplete<TItem extends BaseItem>(
   const onStateChangeRef =
     createRef<AutocompleteOptions<TItem>['onStateChange']>(undefined);
   const props = reactive(() => getDefaultOptions(optionsRef.current));
-  const isDetached = reactive(
-    () =>
-      props.value.core.environment.matchMedia(
-        props.value.renderer.detachedMediaQuery
-      ).matches
-  );
+  const isDetached = reactive(() => false);
 
   const autocomplete = reactive(() =>
     createAutocomplete<TItem>({
@@ -273,72 +268,6 @@ export function autocomplete<TItem extends BaseItem>(
     };
   });
 
-  runEffect(() => {
-    const onResize = debounce<Event>(() => {
-      const previousIsDetached = isDetached.value;
-      isDetached.value = props.value.core.environment.matchMedia(
-        props.value.renderer.detachedMediaQuery
-      ).matches;
-
-      if (previousIsDetached !== isDetached.value) {
-        update({});
-      } else {
-        requestAnimationFrame(setPanelPosition);
-      }
-    }, 20);
-    props.value.core.environment.addEventListener('resize', onResize);
-
-    return () => {
-      props.value.core.environment.removeEventListener('resize', onResize);
-    };
-  });
-
-  runEffect(() => {
-    if (!isDetached.value) {
-      return () => {};
-    }
-
-    function toggleModalClassname(isActive: boolean) {
-      dom.value.detachedContainer.classList.toggle(
-        'aa-DetachedContainer--modal',
-        isActive
-      );
-    }
-
-    function onChange(event: MediaQueryListEvent) {
-      toggleModalClassname(event.matches);
-    }
-
-    const isModalDetachedMql = props.value.core.environment.matchMedia(
-      getComputedStyle(
-        props.value.core.environment.document.documentElement
-      ).getPropertyValue('--aa-detached-modal-media-query')
-    );
-
-    toggleModalClassname(isModalDetachedMql.matches);
-
-    // Prior to Safari 14, `MediaQueryList` isn't based on `EventTarget`,
-    // so we must use `addListener` and `removeListener` to observe media query lists.
-    // See https://developer.mozilla.org/en-US/docs/Web/API/MediaQueryList/addListener
-    const hasModernEventListener = Boolean(isModalDetachedMql.addEventListener);
-
-    hasModernEventListener
-      ? isModalDetachedMql.addEventListener('change', onChange)
-      : isModalDetachedMql.addListener(onChange);
-
-    return () => {
-      hasModernEventListener
-        ? isModalDetachedMql.removeEventListener('change', onChange)
-        : isModalDetachedMql.removeListener(onChange);
-    };
-  });
-
-  runEffect(() => {
-    requestAnimationFrame(setPanelPosition);
-
-    return () => {};
-  });
-
   function destroy() {
     instancesCount--;
     cleanupEffects();

Am I missing something? Is there more that should be deleted?

[wannevancamp]

@Haroenv, I assumed that setPanelPosition was triggering the recalculations, but it might be caused by something else. At the moment, I have not been able to identify the exact root cause.

[nussjustin-hmmh]

I don't see the high CPU usage on my machine, but I can see the endless style recalculations.

I found the cause to be the loading spinner SVG.

Even when the element is not rendered (as the parent is hidden, though the same happens when the SVG itself is hidden) Safari/WebKit will still force a style recalculation with every frame of animation.

It doesn't even need the Algolia JS or CSS. This is enough to reproduce:

<div hidden>
    <svg viewBox="0 0 100 100" width="20" height="20">
        <circle cx="50" cy="50" fill="none" r="35" stroke="currentColor"
                stroke-dasharray="164.93361431346415 56.97787143782138" stroke-width="6">
            <animateTransform attributeName="transform" type="rotate" repeatCount="indefinite" dur="1s"
                              values="0 50 50;90 50 50;180 50 50;360 50 50"
                              keyTimes="0;0.40;0.65;1"></animateTransform>
        </circle>
    </svg>
</div>

This looks like sub-optimal handling of animationTransform in WebKit.

Searching the WebKit bug tracker I only found one very old bug report related to this, which make it sound like this problem has been there for at least 14 years now... Maybe someone should file a new bug about this.

There are 2 work arounds for this:

1. Replacing the animateTransform with CSS animations
2. Calling pauseAnimations / unpauseAnimations on the SVG as needed

[nussjustin-hmmh]

Okay, I just tried to replace the animateTransform with a CSS animation and as expected the style recalculations are gone and there is no unnecessary CPU usage when the SVG is hidden.

Code:

<div hidden>
    <svg viewBox="0 0 100 100" width="20" height="20">
        <circle cx="50" cy="50" fill="none" r="35" stroke="currentColor"
                stroke-dasharray="164.93361431346415 56.97787143782138" stroke-width="6">
        </circle>
    </svg>
</div>

<style>
    @keyframes spin {
        0% {
            transform: translate3d(0, 0, 0) rotate(0deg);
        }

        40% {
            transform: translate3d(0, 0, 0) rotate(90deg);
        }

        65% {
            transform: translate3d(0, 0, 0) rotate(180deg);
        }

        100% {
            transform: translate3d(0, 0, 0) rotate(360deg);
        }
    }

    svg {
        animation: spin 1s infinite linear;
        will-change: transform;
    }
</style>

@wannevancamp Can you try to confirm this?

[wannevancamp]

@nussjustin-hmmh, I can confirm that replacing animateTransform with a CSS animation resolves the style recalculation issue. Thanks for the research!

autocomplete/packages/autocomplete-js/src/elements/LoadingIcon.ts

Lines 27 to 34 in de8a195

	<animateTransform
	attributeName="transform"
	type="rotate"
	repeatCount="indefinite"
	dur="1s"
	values="0 50 50;90 50 50;180 50 50;360 50 50"
	keyTimes="0;0.40;0.65;1"
	/>

[Haroenv]

The tricky thing is that a style tag wouldn't be self contained like the svg form is. I can indeed reproduce that this is the source of the continuous recalculation, and it happens on InstantSearch as well. I think the most realistic way is probably to prevent rendering that svg if it's not meant to show.

A workaround for y'all is to pass a custom loading component of course.

I've opened a webkit bug about this: https://bugs.webkit.org/show_bug.cgi?id=298217