Назад
Чому Linear такий швидкий: технічний розбір
SiTech AI Team3 хв читання

Чому Linear такий швидкий: технічний розбір

Технічний розбір пояснює, як Linear тримає оновлення інтерфейсу в межах мілісекунд: база даних живе в браузері, зміни застосовуються локально, а код ділиться на сотні частин.

Оновлення задачі в Linear займає кілька мілісекунд, тоді як традиційний CRUD-застосунок витрачає на ту саму дію близько 300 мс. Технічний розбір, опублікований на performance.dev, пояснює прийоми, що стоять за цим відчуттям, і наголошує: секретної «срібної кулі» немає. Автор зазначає, що ніколи не працював у Linear і не бачив їхнього коду.

База даних у браузері

Більшість вебзастосунків працюють в одному циклі: клік, HTTP-запит, запит до бази на сервері й кілька сотень мілісекунд за спінером. Linear це перевертає: база, з якої читає інтерфейс, живе в браузері, в IndexedDB — зміни застосовуються локально, а потім асинхронно надсилаються на сервер, який розсилає дельти іншим клієнтам через WebSocket.

На практиці зміна — це два рядки: issue.title = "Faster app launch" оновлює сховище в пам'яті (спостережувані об'єкти MobX), а issue.save() ставить у чергу транзакцію, яку рушій синхронізації групує та надсилає. Інтерфейс перемальовується синхронно з локального стану, тож чекати нема чого. Співзасновник Linear Туомас на конференції 2024 року сказав, що «перші рядки коду», які він написав, були саме рушієм синхронізації. Більшості команд власний рушій не потрібен: TanStack Query або SWR з оптимістичними оновленнями дають досить близький результат.

Перше завантаження без очікування

Швидкість починається ще на етапі збірки. Linear переписувала свій конвеєр чотири рази — Parcel, Rollup, Vite, Rolldown — щоразу, щоб надсилати менше JavaScript і CSS. За даними компанії: на 50% менше коду, на 30% менший після стиснення, завантаження з холодним кешем на 10–30% швидше, час до першого відображення списку активних задач у Safari впав на 59%, а споживання пам'яті — на 70–80%. Більшість цього дали відмова від застарілих браузерів, краще видалення мертвого коду та агресивне розділення коду.

Попри це Linear усе ще надсилає близько 21 МБ мініфікованого JavaScript — розбитого на сотні частин на рівні маршрутів, які завантажуються на вимогу. Щоб уникнути «водоспаду» імпортів, його HTML оголошує підказки modulepreload, тож браузер надсилає всі запити паралельно ще до виконання JavaScript.

Анімація та останні деталі

Анімація — останній шар. У таблиці стилів Linear тривалості короткі: 0,1 с для швидких переходів, 0,25 с звичайних, 0,35 с повільних, а згасання підсвічування — 0,15 с, що помітно менше за 200 мс у Material чи приблизно 350 мс пружини в iOS. Вхід і вихід асиметричні: підсвічування, поповери та панель агента з'являються миттєво й згасають за 150 мс. Рух зазвичай вказує на походження — наприклад, поповер статусу розгортається з відповідної позначки.

Срібної кулі немає

Висновок розбору: жодне окреме рішення не робить застосунок швидким. Модель Linear така: сервер — це ціль синхронізації, а не джерело істини, база живе в браузері, зміни узгоджуються у фоні, а перше завантаження надсилає менше коду більшою кількістю частин. Складною, за словами автора, є не реалізація, а відданість ремеслу протягом років, коли кодова база зростає й натрапляє на нові обмеження.

SSiTech

SiTech — веброзробка з підтримкою AI

Створюємо швидкі та сучасні сайти й інтегруємо AI у бізнес-процеси. Маєте проєкт чи запитання? Із задоволенням допоможемо.