"Илүү их CSS хүргэж хурдаа нэмсэн нь": GitHub платформоос CSS-in-JS-ийг бүрэн халж дууслаа

Вэб хөгжүүлэлтийн ертөнцөд олон жилийн турш нэгэн алтан дүрэм ноёрхож ирсэн: "Хэрэглэгчийн браузер луу аль болох бага CSS илгээ." Багцын хэмжээг хэдхэн килобайтаар ч болов хасах гэж бид багаж бүрийг ашиглаж, CSS-ийг хүртэл JavaScript дотор динамикаар үүсгэдэг CSS-in-JS сангуудыг өргөнөөр сонгосон билээ.

Гэвч дэлхийн сая сая хөгжүүлэгчдийн өдөр тутмын талбар болсон GitHub энэ дүрмийн эсрэг зоримог дүгнэлт хийж, инженерүүдийнхээ хамгийн сүүлийн тайланг танилцууллаа. Тэд github.com платформоос CSS-in-JS (ялангуяа styled-components, styled-system болон sx prop)-ийг 100% бүрэн халж, уламжлалт CSS Modules болон CSS хувьсагчид (CSS Variables) руу шилжиж дууссан байна.

Үр дүн нь? Хүргэж буй статик CSS-ийн хэмжээ бага зэрэг нэмэгдсэн ч хуудасны бодит ажиллагаа болон хурд урьд өмнөхөөсөө эрс сайжирчээ.

1. CSS-in-JS яагаад GitHub-ийн цар хүрээнд саад болсон бэ?

GitHub-ийн бүх интерфейс тэдний өөрсдийн хөгжүүлсэн Primer Design System дээр тулгуурладаг. Анхандаа React бүрэлдэхүүнүүдийг уян хатан, токентойгоо хялбар холбохын тулд styled-components болон sx prop-ийг өргөнөөр ашиглаж эхэлсэн байна. Жишээ нь:

<Box sx={{ padding: 2, bg: 'canvas.subtle', borderRadius: 2 }}>
  <span>Commit History</span>
</Box>

Энэ шийдэл нь TypeScript-ийн хувьд гайхалтай дэмжлэгтэй, стилийг компоненттой хамт байлгахад (colocation) маш тухтай байсан ч github.com-ийн нэг хуудсанд багтах компонентуудын тоо геометрийн прогрессоор нэмэгдэхэд дараах хүнд асуудлууд үүсгэв:

Client-side runtime ачаалал: Хэрэглэгчийн браузер дээр компонент бүр ачааллах тоолонд JavaScript ажиллаж, загварын тооцоолол хийн, DOM-ийн <style> таг руу динамикаар загвар шахаж (injection) байв. Энэ нь эхний хуудас ачааллалтыг (initial page load) ихээхэн саатуулжээ.
Server-Side Rendering (SSR)-ийн уналт: Сервер дээр HTML хуудас бэлтгэх үед тухайн хуудсанд байгаа бүх стилийг цуглуулж тооцоолох (style collection) шаардлага гарч, серверийн CPU болон санах ойд асар их ачаалал учруулав.
Хэт их санах ойн хэрэглээ: Ижил төстэй загварууд дахин дахин боловсруулагдаж, браузер болон серверийн аль алиных нь үйл ажиллагаанд "хүнд дарамт" болжээ.

2. 7,700 гаруй prop, 0 зогсолт: Шилжилтийг хэрхэн хийв?

Секундын ч зогсолтгүй ажиллах ёстой асар том бүтээгдэхүүний үндсэн загварын архитектурыг солино гэдэг задгай сансарт хөдөлгүүрээ солихтой адил эрсдэлтэй алхам байв. GitHub-ийн баг үүнийг дараах стратегийн дагуу хэрэгжүүлжээ:

Давхар багцын архитектур (Hybrid Packages): Primer баг компонентуудаа CSS Modules руу хөрвүүлэхдээ одоо байгаа хэрэглээг эвдэхгүйн тулд хоёр салангид бүтэц үүсгэсэн байна. Хуучин sx prop ашигладаг хэсгүүдэд зориулж @primer/styled-react багцыг үлдээж, шинээр шилжсэн цэвэр компонентуудыг үндсэн @primer/react сангаас шууд авдаг болгожээ.
Visual Regression тест ба Feature Flags: Шинэ CSS Modules-оор бичигдсэн загвар хуучин загвартай пиксел бүрээрээ яв цав нийцэж буйг автомат snapshot тестүүдээр шалгасан. Үүний дараа Feature Flag ашиглан эхлээд дотоод инженерүүд, дараа нь бүх GitHub-ийн ажилтнууд, хамгийн сүүлд нийт хэрэглэгчдэд шат дараатай нээсэн байна.
Автоматжуулалт ба Codemod: GitHub-ийн инженер Ян Сандерс хөгжүүлэгчдэд туслах VS Code өргөтгөл болон тусгай codemod скрипт бичиж өгсөн. 8 инженерийн ээлжит баг 6 сарын дотор код даяар тархсан 6,419 ширхэг sx бичиглэлийг автомат болон хагас автомат байдлаар CSS Modules руу амжилттай хөрвүүлжээ.

3. Үр дүн: "Илүү их CSS" хэрхэн хурд авчрав?

Энэхүү шилжилтийн дараа гарсан хэмжигдэхүүнүүд гайхалтай байв:

Сервер талын рендер хийх хугацаа (SSR) даруй 55%-иар буурсан. Зарим онцгой том, хүнд хуудсууд дээр SSR хугацаа 22% хүртэл шууд хэмнэгджээ.
Хуудас дээрх компонентуудын ажиллаж эхлэх (initialization) хугацаа 25%-иар хурдассан.
Тогтвортой байдал: Дэд бүтцийн санах ойн алдагдал, загвар давхардал үүсэх runtime зардлууд бүрэн арилсан байна.

Яагаад энэ нь "Илүү их CSS" гэсэн үг вэ?

CSS-in-JS нь зөвхөн хэрэглэгдэж буй багахан загварыг л динамикаар цуглуулж илгээдэг байсан бол CSS Modules-д шилжсэнээр бүх загвар статик .css файлууд болж нэгдсэн. Хэдийгээр эхний сүлжээний хүсэлтээр татагдах CSS файлын хэмжээ өмнөхөөсөө үл ялиг нэмэгдсэн ч:

Браузер өөрөө CSS-д зориулагдсан: Хөтчийн C++ дээр суурилсан layout engine нь статик CSS-ийг маш өндөр хурдаар уншиж, parse хийдэг. Үүнд ямар ч нэмэлт JS runtime хэрэггүй.
Кэшлэх боломж: Статик CSS файлууд CDN болон хэрэглэгчийн браузер дээр нэг л удаа кэшлэгдээд дахин дахин татагдах шаардлагагүй болно.
CPU-ийн хэмнэлт: Браузер хүнд хэмжээний JS скрипт уншиж, түүн дотроос CSS-ийг шүүж тунгаах үйл явц бүрмөсөн үгүй болжээ.

Дүгнэлт ба бидэнд өгөх сургамж

Frontend технологийн чиг хандлага олон жилийн турш "бүх зүйлийг JavaScript дотор хийх" туйлшрал руу явж ирсэн. Харин сүүлийн жилүүдэд CSS хувьсагчид (CSS Custom Properties), Container Queries, уугуул Nesting зэрэг шинэ стандартууд хөтчүүдэд бүрэн нэвтэрснээр бид эргээд веб стандартын хүчийг ойлгож эхэлж байна.

styled-components сан өөрөө албан ёсоор maintenance mode буюу зөвхөн засвар үйлчилгээний горимд шилжсэн нь ч санамсаргүй хэрэг биш юм. Хэрэв танай төслийн цар хүрээ томорч, React SSR эсвэл хуудасны гүйцэтгэл дээр гацалт мэдрэгдэж байвал GitHub-ийн энэхүү туршлага нь "Runtime CSS-in-JS-ээс татгалзаж, орчин үеийн CSS Modules болон CSS Variables руу шилжих" хамгийн том бодит баталгаа болж чадлаа.

Эх сурвалж: The GitHub Blog: Improving site performance by shipping more CSS