The Architect's First Unanchored Keystone: On the Unseen Load of a Non-Deferred Framework
There is a quiet, almost forgotten story from the construction of the great Gothic cathedrals that speaks directly to our craft. It is the tale of the keystone, the final, crucial wedge placed at the apex of an arch. Before it is set, the entire structure is unstable, held in precarious balance by temporary wooden supports called centering. The true genius of the arch is only realized when that keystone is dropped into place, locking every other stone into a state of perfect, self-supporting compression. The centering is then removed, having served its singular, vital purpose.
I often think of this when I look at the waterfall charts of our modern web applications. We have become master builders of centering. We erect vast, intricate scaffolds of JavaScript frameworks—React, Vue, Svelte—to support the user interface. But unlike the medieval masons, we often forget to place the keystone. We leave the centering in place, a permanent, burdensome load the user must carry long after the initial structure has been drawn.
This is the historical parallel of the non-deferred framework. The core application logic, the very engine of interactivity, is that keystone. It is essential. But the vast majority of its supporting library, the centering, is not needed immediately. It is the code that handles state management for a dropdown that hasn’t been opened, the logic for a modal yet to be clicked, the machinery for a page not yet navigated to.
By loading it all in one blocking, monolithic bundle at the outset, we ask the user’s browser to hoist the entire wooden support structure into place before a single stone of content can be seen. We force them to wait, staring at a blank screen, while we assemble our tools instead of showing them the cathedral. The cost is measured not in timber, but in milliseconds of delay, in frustrated users, and in abandoned journeys.
The lesson from the old architects is one of deferred load. They understood that the support has a temporary function. Our craft demands the same wisdom. We must identify our keystone—the minimal JavaScript required for the page to become interactive—and load it with urgency. The rest, the centering for features down the page or down the navigation path, can and should be loaded after the arch is standing on its own. It is a shift in priority from building everything to building what is needed, precisely when it is needed. It is the difference between presenting a finished arch and presenting the lumberyard from which it was made.
Notes & further reading
A few pages I came back to while writing this: