Engineering 2 min read
Why this site has no animation library
The sites we admired most shared one problem — they were slow — and the cause was usually the same: handing scroll over to JavaScript.
While researching corporate sites, the flow we liked best belonged to the slowest-loading one. That was not a coincidence.
The problem is the scroll listener
Any JavaScript bound to scroll ties the page's most frequent event to the main thread. Code runs for as long as a finger is dragging, and every tap arriving in that window queues up behind it. This is exactly the pattern that ruins INP on mobile.
The browser already does this
All four effects we wanted exist in CSS: scroll-snap-type for section-by-section movement, animation-timeline: view() for content reveals, animation-timeline: scroll(root block) for the sticky nav and the reading bar, and @view-transition for page transitions. All four run on the compositor and never touch the main thread.
What we measured
The result is zero kilobytes of animation code. But the real gain is not size — it is that the page still answers a tap while the user is scrolling.
One more thing
Our first attempt felt wooden. There were two causes and both were lines we had added ourselves: scroll-snap-stop: always forbade a fast scroll from crossing more than one section, and scroll-behavior: smooth was fighting mandatory snap. Removing both worked better than anything we could have added.