Watching a stopwatch during a cold page load teaches a lesson no framework brochure ever admits aloud, the number that truly matters is how fast something meaningful reaches the waiting screen, not how clever the runtime proves to be once it wakes. Nearly every interface loses that quiet race for one plain reason, a heavy bundle ships first and only then does the browser begin assembling the page from nothing, so a waiting visitor keeps staring at an empty frame while a background script slowly rebuilds what a server could have delivered already finished, already shaped, and ready to read from the opening moment. Flipping that order changes everything, living markup arrives first while a small script attaches behavior a moment later on. ## Rethinking the Load Order Painted straight from the raw server output, a page now waits on nothing at all before it turns useful to the person reading it. Content already sitting there, plainly readable and neatly shaped for the eye, means the script showing up afterward has only one job left to handle, making everything respond to a tap instead of drawing the entire interface from a blank canvas, which is exactly why perceived speed stops depending at all on how large the runtime behind it happens to grow over time. Measured honestly, performance stops tracking the bundle size and starts tracking the moment server output lands in view, so treating the ready event as the finish line becomes the mistake, the true finish line is the first frame carrying meaning. ## Markup Carries the Contract Behavior never needs a listener bolted onto every single element scattered across a page, it needs a plain declaration living in the markup that names which region owns which logic and which event maps to which handler, so one dispatcher sitting quietly at the root can catch anything bubbling upward and route it toward the exact place that was meant to answer it. Standing in for thousands of them, a single listener stays light on memory while keeping the entire intent readable from markup. Because a stable naming hook lets a script still find elements after a minifier scrambles every friendly name into noise, intent written into the markup survives the build step far better than any intent buried deep inside a script that nobody reads. ![Signals from many elements converging into one central dispatcher that routes each to its handler](/articles/the-architecture-of-blazing-fast-web-ui/image-1.webp) ## Capture Every Early Tap Tapping during the first second of a load should never quietly vanish because the real handler has not yet arrived, so a tiny inline stub captures those early events into a small queue and carefully remembers which element the finger just touched. Holding that moment safely, the stub waits until heavier machinery catches up and finally stands ready to honor what happened. When the true dispatcher finally boots, it drains the entire waiting queue and replays each captured event as though it had only just occurred, then retires the stub and quietly steps aside, which is the small trick making a page feel alive while most of its own code is still crossing the open network, turning responsiveness into a promise kept a moment later on. Credit for this pattern belongs to Google, whose JsAction library pioneered the exact flow shown here, capture early events into a queue, register a dispatcher later, then drain the queue and replay each one. The demo below is a small original reimplementation of that idea, kept tiny so the moving parts stay legible rather than hidden inside a production library. Markup carries the contract here, so a button declares its intent inside a `data-intent` attribute rather than wiring a function directly, and the value reads plainly as an event mapped to a named handler, while a nearby status line and three small counters keep exposing exactly what the dispatcher happens to be doing at each and every moment on the screen itself. ```html handler: not-ready

captured: 0 | executed: 0 | queued: 0

``` Turning that attribute into a handler name is the first job. Since one element can declare several events at once, the parser splits each piece at the colon into event and handler, returning the handler only when its event matches the current one. ```javascript // Return the handlerId declared for eventType, or null when none matches function parseAction(attribute, eventType) { for (const segment of (attribute || '').split(';')) { const trimmed = segment.trim() const colonIndex = trimmed.indexOf(':') if (colonIndex < 0) { continue } if (trimmed.slice(0, colonIndex).trim() === eventType) { return trimmed.slice(colonIndex + 1).trim() } } return null } ``` Capturing comes next, the half that runs before any handler exists. A click starts at the element the finger just touched and walks up through its parents until a declared intent appears, then the dispatcher runs it now or parks it on the queue. ```javascript // Read the declarative intent from markup, no handler required yet capture(eventType, target) { let node = target while (node && node.getAttribute) { const handlerId = parseAction(node.getAttribute('data-intent'), eventType) if (handlerId) { const intent = { eventType, handlerId } if (this.ready && this.handlers.has(handlerId)) { this.run(intent) } else { this.queue.push(intent) } return } node = node.parentElement } } ``` One listener at the document root feeds every click into that method. Clicks bubble upward from the touched element to the root, so a single handler stands in for thousands of them, staying light on memory while the whole page routes through it. ```javascript // A single root listener captures clicks anywhere on the page document.addEventListener('click', (event) => { Dispatcher.capture('click', event.target) }) ``` Registering is the execute half, firing the moment the late chunk lands. Storing the function under its name flips the dispatcher to ready and drains the queue, replaying each parked click in arrival order and re-parking any still without a match. ```javascript // Register a handler, then replay everything captured before it existed register(handlerId, handlerFn) { this.handlers.set(handlerId, handlerFn) this.ready = true this.drain() } drain() { const pending = this.queue this.queue = [] for (const intent of pending) { if (this.handlers.has(intent.handlerId)) { this.run(intent) } else { this.queue.push(intent) } } } ``` Behind that button the pretend chunk hands its `Cart.add` function to the dispatcher, the way a split would once it downloads. ```javascript // Simulate the late chunk that finally defines Cart.add document.getElementById('ship').addEventListener('click', () => { Dispatcher.register('Cart.add', () => console.log('item added')) }) ``` Spamming the button while the status still reads not-ready shows the whole contract playing out at once. Each early event lands safely on the waiting queue instead of vanishing, then the instant the handler finally registers, every parked click drains and replays in its original order, so nothing a visitor did during that first uncertain second is ever quietly lost. Same promise JsAction keeps running behind Google at massive scale, honored here by a small handful of plain lines any reader can copy, open directly inside a browser, and watch it faithfully replay a click that happened before its own code arrived. ## Payload Follows the Page Punishing every single visitor for the many features that most of them will never touch, a giant bundle taxes those who came. Smarter routing lets the server work out exactly which pieces a given page truly needs and then send only those few across the wire, while everything else keeps waiting behind a lazy map keyed by feature and gets fetched on its own first real use. Keeping the arrangement honest, a dependency graph separates hard requirements that must resolve before a region runs from softer ones staying dormant until something asks, and loading itself arrives in careful tiers, a critical layer first with calmer layers trailing after, so the payload mirrors the page in front of the visitor instead of the entire heavy application. ## Paint Once per Frame Rendering the exact instant that data changes is a quiet way to invite ugly stutter onto the screen, so every single update belongs inside a queue that flushes once per frame through a double buffer, letting many small changes collapse together into a single smooth visual step instead of a dense crowd of tiny writes elbowing one another in the middle of a lone repaint. Leaning on a tiered scheduler that prefers a modern priority hint and steps down when it goes missing, heavier work follows the same restraint, and a long task politely yields control back to the browser partway so the main thread never freezes. Never luck at all, smoothness is only the discipline of batching work and giving the browser room to breathe between the parts. ![Many small changes queued through a double buffer and flushed as one update per frame](/articles/the-architecture-of-blazing-fast-web-ui/image-2.webp) ## Restraint Beats Raw Power Running through every choice here is a steady refusal to reach for heavy tools before a page truly needs them, a simple screen stays quick on plain updates while only a demanding one earns the real cost of workers, compression, or offline storage. Ending fast means feeling less like a framework flexing its own muscles and more like a page that was simply ready all along.