Rediscovering Peak Performance: How 'Old Ways' Lead to 100 Lighthouse Scores

This article explores how leveraging mainframe-era techniques and native browser APIs can significantly outperform modern frameworks, achieving exceptional web performance metrics. The core argument centers on the idea that many contemporary layers of abstraction solve problems they themselves created.

Unpacking the Performance Numbers

Before diving into the methodology, consider the tangible results achieved by multicardz.com, a drag-and-drop spatial query interface:

Frontend Performance (multicardz.com)

• JavaScript Bundle Size: 32KB (approximately 15% of a minified React application)
• Total Payload: <100KB (including HTML, CSS, fonts, and all assets)
• Total Blocking Time (TBT): 0ms
• Cumulative Layout Shift (CLS): 0
• First Contentful Paint (FCP): 0.3s
• Lighthouse Score: 100

Backend Performance

• Server Processing: 32ms to select any result from a dataset of 1 million cards.
• Round Trip Time: 160ms (network latency accounts for the remainder).
• Query Time Consistency: Result set size does not impact query duration.

These metrics demonstrate that it is possible to build a complex, interactive web application without compromising speed or user experience, by embracing established, often overlooked, architectural principles.

The Application: multicardz

Multicardz is designed as a spatial data organization tool, enabling users to categorize and filter information by dragging tags into distinct zones. For example, dropping a tag to the left groups rows, dropping to the top splits columns, and dropping to the center applies a filter. This intuitive interface allows users to precisely slice a million cards with just a few drag operations.

This application was developed to address a personal need for multidimensional matrices that standard tools like Trello or Notion could not provide, particularly for managing complex many-to-many relationships across features, code, releases, and dependencies in various roles (Product Manager, Software Architect, CTO). The development process reinforced the conviction that traditional performance techniques can indeed surpass the latest trends.

The Backend: A 1972 Revelation

The backend architecture draws inspiration from IBM's Model 204 database, developed in 1972, which famously stored query results as bitmaps. The fundamental insight was to defer database access until absolutely necessary, keeping intermediate results as bitmaps and performing set operations (intersection, union) in memory. Only the final, refined result set would trigger a record fetch from the database.

This principle is effectively implemented today using modern compressed bitmap libraries like RoaringBitmaps. Each tag is associated with a bitmap of card IDs. When users interact by dragging tags:

• Bitmap operations (AND/OR/NOT) execute entirely in memory.
• No database hits occur during the manipulation phase.
• Actual card data is only retrieved for the final, desired result set.

This approach results in a query complexity of O(M), where M is the size of the result set, rather than O(N), where N is the total number of cards. Consequently, querying 10 cards from a million takes the same 32ms as querying 10 cards from a thousand. This "50-year-old technique" was largely obscured by the rise of Object-Relational Mappers (ORMs) and the pervasive mindset of "just query the database."

The Frontend: DATAOS – DOM As The Authority On State

Inspired by HATEOAS (Hypermedia As The Engine Of Application State), the frontend employs DATAOS: DOM As The Authority On State. The core principle is straightforward: the Document Object Model (DOM) inherently represents the UI's state. Instead of maintaining a separate state object that requires constant (and often error-prone) synchronization with the DOM, DATAOS advocates for reading state directly from and writing state directly to the DOM. This completely eliminates the synchronization problem.

For example, when a user drags a tag in multicardz, the process avoids:

• Updating a separate state object.
• Triggering a re-render cycle.
• Diffing a virtual DOM.
• Patching the real DOM.

Instead, the element is simply moved within the DOM:

zone.querySelector('.tags-wrapper').appendChild(tagElement);

To determine a tag's location or identify tags within a filter zone, one queries the DOM directly. The visual representation is the data structure. This methodology eradicates an entire class of bugs related to state synchronization and eliminates the performance overhead associated with reconciliation algorithms.

Frontend Optimization Strategies

Achieving a lean 32KB JavaScript bundle involves several key strategies:

• Native Browser APIs: Utilizing the browser's built-in drag-and-drop API, which is optimized in C++, provides superior performance compared to reimplementing such complex logic in JavaScript. These APIs handle hit testing, event propagation, and cursor changes at native speeds.
• Direct DOM Manipulation: Bypassing virtual DOM diffing algorithms and directly manipulating the DOM removes a significant layer of abstraction and its associated performance cost.
• Minimal Framework Overhead: Eliminating reliance on heavy frameworks allows for complete control over performance characteristics, in stark contrast to frameworks like React, which have a minimum bundle size of approximately 215KB—much of which is dedicated to reconciliation.
• CSS for Visuals: Leveraging CSS for animations and complex visual effects reduces the need for JavaScript, as browsers are inherently optimized for rendering CSS.

Specific Techniques Employed

• Font Subsetting: To combat the nearly 500ms First Contentful Paint (FCP) delay caused by Google Fonts for the "multicardz" workmark, only the necessary 9 characters were subsetted and vendored locally. This reduced the font file size from over 100KB to just 2KB.

  pyftsubset font.woff2 --text="multicardz" --output-file=subset.woff2
  

• Script Deferral: Using the defer attribute on script tags ensures that JavaScript execution aligns perfectly with DOM rendering completion, optimizing perceived load times.

  <script defer src="/static/js/drag-drop.min.js"></script>
  

When DATAOS Applies

The DATAOS approach is highly effective when the DOM serves as the primary representation of user state, which encompasses a wide range of common web applications: data displays, forms, dashboards, editors, and spatial interfaces.

However, DATAOS is less suitable when the DOM acts merely as a render target for an external state:

• Games: Where state primarily involves physics, positions, and velocities, and the DOM is only used to draw pixels.
• Video Applications: Where state pertains to playback, buffering, and streams, and the DOM displays frames.
• Canvas Applications: Such as drawing tools or image editors, where the DOM shows results but doesn't manage the underlying state.

In essence, if users interact with and manipulate elements that directly reside in the DOM, then the DOM can effectively serve as your state manager. If the DOM is merely a viewport into an independently managed state, then DATAOS is not the ideal fit.

The Core Thesis

The most effective frontend technologies (native DOM APIs, CSS3) are approximately 15 years old, while the most effective backend techniques (bitmap indexes) are around 50 years old. Many of the layers introduced since then—such as virtual DOMs, ORMs, and sophisticated state management libraries—often exist to mitigate complexities and problems that these very layers inadvertently created. We developed frameworks to manage the complexity arising from treating application state as distinct from what the user interacts with on screen. This cycle often leads to further frameworks designed to manage the complexity of previous frameworks.

The proposition is to simplify:

• Read state directly from the DOM.
• Maintain result sets as bitmaps in memory.
• Access the database only when absolutely necessary.

By embracing these "old ways," it's possible to achieve exceptional performance metrics: 100 Lighthouse score, 0ms Total Blocking Time, and 32ms query times.