რატომ არის 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-ის მოდელი ასეთია: სერვერი სინქრონიზაციის სამიზნეა და არა სიმართლის წყარო, ბაზა ბრაუზერშია, ცვლილებები ფონურად თანხვდება, პირველი ჩატვირთვა კი ნაკლებ კოდს მეტ ნაწილად აგზავნის. რთული ნაწილი, ავტორის თქმით, იმპლემენტაცია არაა, არამედ წლების განმავლობაში ხელობისადმი ერთგულება, როცა კოდის ბაზა იზრდება და ახალ შეზღუდვებს აწყდება.