Ինչու է 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՝ բաժանված հարյուրավոր route-մասերի, որոնք բեռնվում են ըստ պահանջի։ Ներմուծումների «ջրվեժից» խուսափելու համար HTML-ը հայտարարում է modulepreload ակնարկներ, այնպես որ բրաուզերը բոլոր հարցումները զուգահեռ է ուղարկում JavaScript-ի կատարումից առաջ։

Անիմացիա և վերջին մանրամասներ

Անիմացիան վերջին շերտն է։ Linear-ի ոճաթերթում տևողությունները կարճ են՝ 0,1 վրկ արագ անցումների համար, 0,25 վրկ սովորական, 0,35 վրկ դանդաղ, իսկ ընդգծման մարումը՝ 0,15 վրկ, ինչը նկատելիորեն քիչ է Material-ի 200 մվ-ից կամ iOS-ի մոտ 350 մվ-ից։ Մուտքն ու ելքը ասիմետրիկ են․ ընդգծումները և popover-ները հայտնվում են ակնթարթորեն և մարում 150 մվ-ում։ Շարժումը սովորաբար ցույց է տալիս սկզբնաղբյուրը․ կարգավիճակի popover-ը բացվում է կարգավիճակի պիտակից։

Արծաթե փամփուշտ չկա

Վերլուծության եզրակացությունն այն է, որ ոչ մի առանձին որոշում հավելվածը արագ չի դարձնում։ Linear-ի մոդելը հետևյալն է․ սերվերը սինխրոնիզացիայի թիրախ է, ոչ թե ճշմարտության աղբյուր, տվյալների բազան ապրում է բրաուզերում, փոփոխությունները համաձայնեցվում են ֆոնում, իսկ առաջին բեռնումը ավելի քիչ կոդ է ուղարկում ավելի շատ մասերով։ Դժվարը, ըստ հեղինակի, ոչ թե իրականացումն է, այլ տարիների նվիրումը արհեստին, երբ կոդային բազան աճում է և բախվում նոր սահմանափակումների։