Linear’s speed: How a local-first architecture and aggressive code splitting eliminate network latency

A technical analysis published on performance.dev has dissected the architectural foundations of Linear, attributing the platform’s perceived speed to a local-first sync model, the use of MobX observables, and a keyboard-first design philosophy. The breakdown, authored by an independent developer, details how the system treats the browser as the primary database using IndexedDB, applying mutations locally before asynchronously syncing with the server. This approach effectively eliminates the network latency that typically plagues traditional CRUD applications.

The core of Linear’s performance lies in its inversion of the standard request-response loop. Rather than waiting for a server to query a database and return data, Linear updates an in-memory datastore immediately. Co-founder Tuomas Heikkinen noted in a 2024 conference talk that the sync engine was the first component he coded, underscoring the company’s early commitment to this architecture. By assuming a "happy path" for authentication and data mutations, the application renders the user interface instantly, verifying session tokens and syncing data in the background.

To achieve instant first loads, Linear has rewritten its build pipeline four times, migrating from Parcel to Rollup, then Vite, and finally Rolldown. These iterations were driven by the goal of reducing JavaScript and CSS payloads, resulting in a 59% drop in time-to-first-paint for the active-issues view on Safari. Although the application ships approximately 21 MB of minified JavaScript, this is aggressively code-split into hundreds of route-level chunks fetched on demand. A service worker precaches around 1,200 hashed assets, allowing the full application to be stored in cache within seconds of the user hitting the login screen.

The sync engine utilises "data-level code splitting," lazy-hydrating heavy tables such as Issue and Comment on demand. This ensures that startup speed tracks the workspace structure rather than its size, allowing a 10,000-issue workspace to boot as quickly as a smaller one. When data changes, MobX observables ensure that only the specific components reading the affected fields re-render, rather than redrawing entire lists. This granular re-rendering capability allows the application to remain smooth even when multiple users are editing content simultaneously.

Beyond engineering, Linear’s speed is reinforced by a keyboard-first design and strict animation constraints. The command palette searches the local MobX object pool rather than the server, ensuring instant response times for navigation and issue creation. Animations are strictly limited to composited properties such as transform and opacity, with durations kept below 100ms to avoid layout thrashing. The combination of these technical and design decisions creates a user experience that feels native and instantaneous, despite the complexity of the underlying data synchronization.