Linearの高速性、ブラウザDBと同期エンジンが鍵

プロジェクト管理ツール「Linear」のUIが、従来のCRUDアプリと比べて格段に速いことは、同ツールを使ったことのある開発者なら誰しもが実感しているだろう。一つのIssueを更新するのに数ミリ秒で完了するのに対し、従来型のアプリでは300ミリ秒程度かかるのが一般的だ。この差はどこから生まれるのか。Linearの内部実装を詳しく解説した記事が公開され、話題を呼んでいる。

この解説を書いたのはDennis Brotzky氏。同氏はLinearの社員ではなく、コードベースを直接見たこともないと断りつつ、公開情報や実際の使用体験に基づいてパフォーマンスの秘密を分析している。結論から言えば、特効薬のような単一のテクニックがあるわけではなく、適切な基盤の上に無数の小さな判断が積み重なった結果だという。

ブラウザをデータベースとして使う

Linearの最も重要な設計判断は、UIが読み取るデータベースをブラウザ内、具体的にはIndexedDBに置いている点だ。従来のWebアプリは、ユーザーの操作ごとにHTTPリクエストをサーバーに送り、サーバーがデータベースに問い合わせた結果を待ってUIを更新する。この間、スピナーやスケルトン表示、フリーズしたUIが数百ミリ秒続く。

Linearはこの関係を逆転させている。変更はまずローカルに適用され、その後非同期でサーバーにプッシュされる。サーバーはWebSocket経由で差分を他のクライアントにブロードキャストする。

Brotzky氏は「高速なWebアプリを構築する上で最大の障壁はネットワーク」だと指摘する。クライアントとサーバーの間のデータ転送には常に数百ミリ秒がかかる。そのため最善のアプローチはネットワークリクエストそのものを排除することであり、Linearはまさにそれを実現している。

コード例を見ると違いは明確だ。従来型のアプリでは、Issueを更新するたびにfetchでPATCHリクエストを送り、レスポンスを待ってからUIを更新する。一方Linearでは、issue.title = "Faster app launch"; issue.save(); の2行で完了する。1行目でメモリ上のデータストア（Linearの場合はMobX observable）を即座に更新し、2行目で同期エンジンにトランザクションをキューイングする。UIはバックグラウンドでの同期を待たずに即座に再描画される。

ファーストロードを一瞬にする仕組み

初回読み込みの速さもLinearの特徴だ。単なるスプラッシュ画面を表示するのではなく、ユーザーがすぐに操作できる状態にするための工夫が随所に施されている。

具体的な手法として、必要なデータを事前にキャッシュしておく仕組みが挙げられる。ユーザーがアプリケーションを開くと、前回のセッションで保持していたIndexedDBのデータが即座に利用可能になる。このデータがあれば、サーバーからのレスポンスを待つことなく前回の作業状態を復元できる。その後バックグラウンドでサーバーとデータの差分を同期し、最新の状態に更新する。

このアプローチは、いわゆる「オフラインファースト」の設計思想に近い。ただしLinearは完全なオフライン対応を謳っているわけではなく、あくまでネットワークを意識させない体験を提供することに主眼を置いている。

同期エンジンの設計

Linearの中核をなす同期エンジンは、複数のクライアント間でデータの一貫性を保つための仕組みだ。ローカルで行われた変更は、バッチ処理されて定期的にサーバーにフラッシュされる。サーバー側では競合の解決やバリデーションを行い、他のクライアントに変更を伝搬する。

この設計の利点は、ユーザーが編集操作を行うたびにサーバーとの通信が発生しないことだ。タイピングの最中やドラッグ&ドロップの操作中に頻繁にネットワークリクエストが発生すると、UIの応答性が著しく低下する。Linearは変更をキューに溜め込み、適切なタイミングでバッチ送信することでこの問題を回避している。

Brotzky氏は「優れたWebアプリを構築する秘訣は、すべてのネットワークリクエストをユーザーから隠すことだ」と繰り返し述べている。ローディング状態をいかに減らすかが、パフォーマンスに対するユーザーの知覚を大きく左右する。

スピードを最適化した設計判断

Linearのパフォーマンスは、アーキテクチャレベルの判断だけでなく、細部にわたる最適化の積み重ねでも成り立っている。例えば、コンポーネントのレンダリング最適化では、変更があった部分だけを再描画する仕組みが徹底されている。MobXのobservableを活用したリアクティブなデータフローにより、不要な再レンダリングを最小限に抑えている。

また、アニメーションの扱いにも特徴がある。単なる視覚的な装飾ではなく、ユーザーの操作とフィードバックの間のタイムラグを心理的に短く感じさせる効果を狙っている。適切なタイミングで適切なアニメーションを適用することで、操作に対する反応が実際の処理時間よりも速く感じられるよう設計されている。

編集部の見解

短期的影響: Linearの設計アプローチは、プロジェクト管理ツールに限らず、あらゆるCRUDアプリケーションに応用可能な知見を提供している。特に、SaaS製品のUI/UX品質が差別化要因となる市場では、今後半年以内に同様のアプローチを採用する競合製品が増えると見られる。IndexedDBとバックグラウンド同期を組み合わせたアーキテクチャは、ReactやVueなどのモダンなフロントエンドフレームワークとの親和性が高く、導入のハードルは比較的低い。

長期的視点: 1〜3年のスパンで見ると、「ブラウザをプライマリデータベースとする」設計思想は、Webアプリケーションのアーキテクチャに根本的な変革をもたらす可能性がある。従来のクライアント・サーバーモデルでは、ネットワークが常にボトルネックだった。これが解消されれば、Webアプリの応答性はネイティブアプリに肉薄し、さらにはオフライン環境での動作も標準化するだろう。ただし、データの一貫性や競合解決の複雑さは依然として課題であり、大規模なコラボレーションアプリケーションへの適用には注意が必要だ。

編集部からの問い: 今回の解説で興味深いのは、Linearが競合解決をどの程度厳密に行っているかが外部からは完全には見えない点だ。ローカルファーストのアーキテクチャでは、複数ユーザーが同時に同じデータを編集した際の競合が避けられない。Linearはこの問題をどのように処理しているのか。また、IndexedDBの容量制限やブラウザによる実装の差異は、実運用でどの程度の制約となるのか。これらの疑問が明らかになれば、より多くのプロダクトが同様のアーキテクチャを採用する判断材料になるだろう。

参考

• How’s Linear so fast? A technical breakdown - performance.dev — 2026-05-03公開