What was going on
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.
What fixed it
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