The Watchmaker's First Un-counterweighted Escapement: On the Wobbling Pendulum of a Perfectly Optimized Page Without a `will-change`

In the 18th century, a watchmaker’s craft was measured by the silent, rhythmic dance of gears and the steady swing of a pendulum. The escapement, that critical mechanism which transfers energy and maintains the beat, required not just precision but anticipation. A master would painstakingly add tiny counterweights, not for the present state of the movement, but for the subtle shifts in balance that would occur once the watch was worn, turned, and moved through the world. This foresight, this preparation for future state, is the direct ancestor of a most peculiar and often misunderstood CSS property: `will-change`.

We, as builders of the web, are modern horologists. We polish our JavaScript until it gleams, we compress our images to a minimum, and we trim our CSS of every superfluous declaration. The page is a masterpiece of efficiency. Yet, when a user clicks a button to slide in a navigation drawer, the animation stutters. The pendulum wobbles. The finely tuned machine judders because the browser was caught unaware, forced to calculate styles and layouts in the frantic few milliseconds before the paint. We built for the steady state, but not for the transition.

The Cost of a Surprise

This is where the watchmaker’s foresight finds its digital expression. The `will-change` property is not a performance enhancer in the way `transform` or `opacity` are; it is a declaration of intent. It is the craftsman quietly adding a counterweight to the escapement arm before it is ever mounted. By hinting to the browser that a particular element is about to change in a specific way—its contents, its scroll position, its transform—we grant the rendering engine a precious head start. It can allocate a compositor layer, prepare the GPU, and isolate the element, all before the main thread is tasked with the change.

But like any powerful tool, it demands respect and restraint. The old watchmaker would not counterweight every gear; to do so would add unnecessary mass and friction, ruining the very precision he sought to achieve. Similarly, declaring `will-change` on half your DOM is a recipe for bloated memory consumption and, ironically, worse performance. It is a tool for specific, anticipated interactions, not a blanket tonic for jank. It is the final, considered adjustment for a known future event, not a speculative gamble on every possible one.

Our pursuit of a stable, instantaneous web can sometimes feel like a quest for a perpetual motion machine—an elegant, impossible dream. Yet, the lesson from the watchmaker’s bench is not about achieving perfection, but about mastering anticipation. It is the understanding that true smoothness isn't just found in the efficiency of the movement itself, but in the thoughtful preparation for its inevitable change. We must build not just for the page as it is, but for the page as it is about to become.

Notes & further reading

A few pages I came back to while writing this: