CSS: Runtime Atomic CSS Và Compiler-Based CSS

Trong kỷ nguyên đầu của kiến trúc Web, CSS (Cascading Style Sheets) thuần túy đóng vai trò là một lớp khai báo tĩnh (declarative layer) nhằm định dạng hiển thị: xử lý các thuộc tính trực quan cơ bản như màu sắc, kiểu chữ (typography), khoảng cách (spacing) và sơ đồ bố cục (layout). Ở giai đoạn này, mô hình tương tác của trang web mang tính chất tĩnh, vòng đời của một tài liệu HTML ngắn và cấu trúc cây tài liệu (DOM Tree) có độ sâu hạn chế.

Tuy nhiên, sự dịch chuyển của công nghệ Frontend hiện đại — với sự trỗi dậy của các ứng dụng dạng Single Page Application (SPA), Server-Driven UI, Real-time Dashboard, Collaborative Editor (như Figma, Canva), và các nền tảng SaaS Enterprise — đã biến đổi hoàn toàn bản chất của các giao diện này. Cấu trúc Client-side hiện nay có quy mô và độ phức tạp tương đương, thậm chí vượt trội so với các ứng dụng Desktop truyền thống.

Một hệ thống Frontend cấp Enterprise phải đối mặt với những thách thức vận hành ở quy mô lớn:

Độ Phức Tạp Của DOM (DOM Scale & Density): Hàng chục nghìn đến hàng trăm nghìn DOM node tồn tại đồng thời trong bộ nhớ, liên tục thay đổi trạng thái dựa trên luồng dữ liệu thời gian thực (real-time data streaming).
Mô Hình Rendering Phức Tạp: Sự đan xen giữa các cơ chế Streaming Server-Side Rendering (Streaming SSR), Partial Hydration, Selective Hydration, Virtualization (ảo hóa danh sách) và Incremental Rendering (rendering tăng tiến).
Quản Trị Hệ Thống Thiết Kế (Design System): Yêu cầu phân rã và phân phối hàng nghìn mã thông báo thiết kế (design tokens) có khả năng thay đổi động theo ngữ cảnh người dùng (dynamic themes) hoặc phân quyền hệ thống ngay tại runtime.

Khi quy mô hệ thống tăng lên theo cấp số nhân, điểm nghẽn hiệu năng (performance bottleneck) của ứng dụng Frontend không còn đơn thuần nằm ở tốc độ thực thi JavaScript (JavaScript Execution Time) hay độ trễ mạng (Network Latency). Trọng tâm chuyển dịch một cách rõ rệt sang Browser Rendering Pipeline (Tuyến trình thực thi hiển thị của trình duyệt).

Thực tế kỹ thuật cho thấy, nhiều hệ thống dù sở hữu mã nguồn JavaScript được tối ưu hóa thuật toán nghiêm ngặt, cấu trúc bundle được phân tách chặt chẽ (code-splitting), vẫn phải chịu hệ quả từ các hiện tượng tiêu cực về mặt đồ họa:

Frame Drop (Sụt giảm khung hình): Tốc độ phản hồi đồ họa không đạt mức 60 FPS (hoặc 120 FPS trên màn hình tần số quét cao), gây ra hiện tượng giật lag trực quan.
Jank Scrolling & Input Latency: Sự chậm trễ giữa hành vi cuộn chuột hoặc tương tác của người dùng và phản hồi hiển thị của màn hình.
Layout Thrashing (Đánh tráo bố cục liên tục): Hệ quả của việc đọc và ghi đè các thuộc tính hình học (geometric properties) của DOM một cách tuần tự nhưng không đồng bộ, ép buộc trình duyệt phải tính toán lại bố cục (forced synchronous layout) liên tục.
Paint Storm & Main-thread Congestion: Sự tắc nghẽn luồng xử lý chính do khối lượng tính toán và vẽ lại (rasterization) quá lớn, phân mảnh tài nguyên CPU.

Nguyên nhân cốt lõi của những vấn đề này bắt nguồn từ việc Browser Engine phải liên tục thực thi các tác vụ tính toán nặng: đối sánh bộ chọn (selector matching), phân định thứ tự ưu tiên (cascade resolution), tính toán lại phân cấp thuộc tính (style recalculation), và tái cấu trúc các lớp đồ họa (compositing layers) cho mỗi chu kỳ cập nhật giao diện (UI update).

Trước bối cảnh đó, các kỹ sư hệ thống Frontend đã định hình lại tư duy phát triển CSS, chuyển từ việc tối ưu hóa cú pháp viết (Developer Experience - DX) sang việc thiết kế cấu trúc vận hành (Execution Model) và tương tác trực tiếp với lõi trình duyệt (Browser Engine Interaction). Hai trường phái kiến trúc lớn đã xuất hiện và đối đầu trực tiếp:

Runtime Atomic CSS Architecture (Kiến trúc CSS nguyên tử vận hành tại Runtime)
Compiler-based CSS Architecture (Kiến trúc CSS dựa trên trình biên dịch tĩnh)

Sự phân hóa này không đơn thuần là câu hỏi về việc lựa chọn thư viện, mà là sự đánh đổi chiến lược sâu sắc về: mô hình thực thi, chiến lược kết xuất, tính toàn vẹn của quá trình thủy hóa (hydration stability), hiệu năng bộ nhớ cache, và mức độ chiếm dụng luồng xử lý chính (main-thread pressure). Bài viết này sẽ phân tích chuyên sâu hai kiến trúc trên dưới lăng kính của Browser Engine Internals và Systems Engineering.

Table of Contents

1. Đi Sâu Vào Browser Rendering Pipeline Và Vai Trò Của CSS

Để làm rõ tầm ảnh hưởng của các kiến trúc CSS đối với hiệu năng, chúng ta cần phân tích sâu cơ chế vận hành bên trong của Browser Rendering Pipeline, đặc biệt là cách thức các bộ tử (Engine) như Blink (Chromium), WebKit (Safari), và Gecko (Firefox) xử lý các chỉ thị phong cách.

+-----------+     +-----------+
|   HTML    |     |    CSS    |
+-----------+     +-----------+
      |                 |
      v                 v
+-----------+     +-----------+
|    DOM    |     |   CSSOM   |
+-----------+     +-----------+
      \                 /
       \               /
        v             v
     +-------------------+
     |    Render Tree    |
     +-------------------+
              |
              v
     +-------------------+
     |   Layout Phase    |
     +-------------------+
              |
              v
     +-------------------+
     |    Paint Phase    |
     +-------------------+
              |
              v
     +-------------------+
     |  Composite Phase  |
     +-------------------+

1.1. Giai Đoạn Khởi Tạo: DOM, CSSOM Và Render Tree

Khi một trang web được tải hoặc cập nhật, Browser Engine tiếp nhận hai nguồn dữ liệu độc lập: luồng mã mã hóa HTML và các biểu mẫu CSS (stylesheets).

DOM (Document Object Model) Tree: Trình duyệt phân tách (parse) HTML để thiết lập một cấu trúc cây phân cấp đại diện cho các phần tử luận lý của tài liệu.
CSSOM (CSS Object Model) Tree: Song song với đó, trình duyệt phân tách các quy tắc CSS (rules) để xây dựng một bản đồ hướng đối tượng của các phong cách. CSSOM mang cấu trúc cây vì nó phản ánh tính chất kế thừa của các thuộc tính (ví dụ: một thuộc tính đặt tại body sẽ tác động xuống các nhánh con trừ khi bị ghi đè).

Điểm giao thoa đầu tiên và cũng là nơi phát sinh chi phí tính toán nặng nề là quá trình thiết lập Render Tree (Cây kết xuất). Trình duyệt duyệt qua từng node trong cây DOM, tìm kiếm và đối sánh tất cả các quy tắc CSS có khả năng áp dụng cho node đó từ cây CSSOM.

Hiệu năng của giai đoạn này phụ thuộc tuyến tính và phi tuyến vào các yếu tố:

Số lượng và độ phức tạp của Selector: Bộ chọn càng phức tạp, chu kỳ duyệt cây tìm kiếm càng kéo dài.
Đồ thị tính đặc hiệu (Specificity Graph): Trình duyệt phải liên tục giải quyết xung đột thuộc tính dựa trên trọng số của selector (Inline > ID > Class > Element).
Độ sâu kế thừa (Inheritance Depth): Các thuộc tính có tính chất kế thừa tự động (như color, font-family) buộc trình duyệt phải thực hiện các phép tra cứu ngược (ancestor lookup) lên các tầng cha nếu node hiện tại không khai báo cụ thể.

1.2. Giai Đoạn Tính Toán Lại Phong Cách (Style Recalculation)

Khi một ứng dụng thay đổi trạng thái giao diện (ví dụ: thêm một class, thay đổi một thuộc tính thông qua JavaScript), trình duyệt không chỉ đơn thuần thay đổi thuộc tính đó của phần tử đơn lẻ. Nó bắt buộc phải kích hoạt tiến trình Style Recalculation.

Trong tiến trình này, Browser Engine phải xác định lại:

Những bộ chọn (selectors) nào bị ảnh hưởng bởi sự thay đổi trạng thái.
Những quy tắc (rules) nào cần phải được tính toán lại trị số.
Phạm vi vô hiệu hóa (invalidation scope) lan rộng đến đâu trong cây tài liệu.

Hãy xem xét một bộ chọn phức tạp theo mô hình truyền thống:

CSS

.dashboard .sidebar ul li a.active { color: #007acc; }

Khi thực hiện đối sánh selector (selector matching), các Browser Engine hiện đại đọc bộ chọn từ phải sang trái (Right-to-Left). Đối với ví dụ trên, trình duyệt sẽ tìm kiếm tất cả các thẻ a có class .active trên toàn bộ DOM. Sau đó, với mỗi thẻ tìm thấy, nó sẽ duyệt ngược lên tổ tiên để kiểm tra xem thẻ đó có nằm trong thẻ li, thuộc ul, bên trong .sidebar, và cuối cùng là thuộc cấu trúc .dashboard hay không.

Trong một ứng dụng có mật độ DOM dày đặc, quy trình duyệt cây ngược này tiêu tốn một lượng chu kỳ CPU khổng lồ, tạo ra hiện tượng nghẽn luồng xử lý (CPU-bound main-thread blocking).

1.3. Giai Đoạn Bố Cục (Layout/Reflow)

Sau khi thiết lập xong Render Tree với đầy đủ thông số phong cách cho từng phần tử, trình duyệt chuyển sang giai đoạn Layout (hoặc Reflow). Mục tiêu của giai đoạn này là tính toán chính xác tọa độ hình học, kích thước không gian (geometry) của từng node trên màn hình phẳng: width, height, margin, padding, border, và vị trí tương đối/tuyệt đối.

CSS đóng vai trò quyết định trong việc thiết lập cấu trúc phụ thuộc của Layout (Layout Dependency Graph). Một thay đổi nhỏ về mặt kích thước của một phần tử ở tầng trên cùng (ví dụ: thay đổi width của một thanh sidebar) có thể kích hoạt một chuỗi phản ứng dây chuyền, buộc trình duyệt phải vô hiệu hóa hình học (layout invalidation) và tính toán lại toàn bộ cây con (subtree layout), thậm chí là toàn bộ tài liệu. Đây là nguồn gốc của hiện tượng Layout Thrashing, xảy ra khi mã nguồn JavaScript thực hiện xen kẽ các thao tác đọc ghi thuộc tính hình học (như offsetHeight tiếp theo là style.height = ...) trong cùng một frame đồ họa.

1.4. Giai Đoạn Vẽ Và Tổng Hợp Layer (Paint Và Compositing)

Khi các thông số hình học đã được xác lập, trình duyệt tiến hành Paint Phase. Đây là quá trình chuyển đổi các lệnh hình học thành các mảng pixel thực tế trong bộ nhớ — một tiến trình được gọi là Rasterization (Số hóa pixel). Tác vụ này bao gồm việc vẽ chữ, đổ màu nền, dựng viền, xử lý đổ bóng (box-shadow), và áp dụng các bộ lọc hình ảnh (filters).

Cuối cùng là giai đoạn Compositing (Tổng hợp lớp). Để tối ưu hóa hiệu năng, các trình duyệt chia giao diện thành nhiều lớp đồ họa độc lập (Compositing Layers) được quản lý trực tiếp bởi GPU. Thay vì vẽ lại toàn bộ màn hình khi có thay đổi, trình duyệt chỉ vẽ lại lớp bị biến đổi và gửi chỉ thị cho GPU thực hiện các phép biến đổi hình học (như transform hay opacity) để gộp các lớp lại thành khung hình cuối cùng.

Nếu kiến trúc CSS không kiểm soát chặt chẽ các thuộc tính kích hoạt tái vẽ, nó sẽ vô tình tạo ra các Paint Storms (Cơn bão tái vẽ) trên diện rộng, ép buộc trình duyệt liên tục hủy bỏ và thiết lập lại bộ nhớ đệm đồ họa của GPU (GPU cache invalidation), tiêu hao nghiêm trọng tài nguyên phần cứng.

2. Kiến Trúc CSS Truyền Thống (Traditional CSS) Và Những Giới Hạn Tới Hạn

Để thấy rõ giá trị giải pháp của Runtime Atomic và Compiler-based CSS, cần phải mổ xẻ những lỗ hổng mang tính hệ thống của các mô hình CSS truyền thống, bao gồm CSS thuần, Sass/Less, và mô hình BEM (Block Element Modifier).

2.1. Sự Bùng Nổ Của Thác Phân Cấp Toàn Cục (Global Cascade Explosion)

Mô hình thiết kế nguyên thủy của CSS dựa trên giả định về một không gian tên toàn cục duy nhất (Global Namespace). Tính chất “thác đổ” (Cascade) cho phép các quy tắc viết sau có quyền ghi đè các quy tắc viết trước nếu có cùng mức độ đặc hiệu (specificity).

Tuy nhiên, trong các hệ thống phần mềm lớn được phát triển bởi hàng trăm kỹ sư theo mô hình micro-frontend hoặc component-based, tính toàn cục này biến thành một thảm họa kiểm soát. Hãy xem xét tình huống sau:

CSS

/* Khai báo trong Shared Design System Component */
.card {
    padding: 16px;
    border-radius: 8px;
}

/* Khai báo trong một Feature Module được tải muộn (Lazy-loaded) */
.dashboard .card {
    padding: 24px;
}

Sự xuất hiện của mã nguồn ở Feature Module phá vỡ tính nhất quán của cấu trúc .card ở các phân vùng khác. Khi hệ thống mở rộng, biểu đồ đặc hiệu (Specificity Graph) trở nên hỗn loạn với các đỉnh nhọn bất thường, dẫn đến việc lạm dụng từ khóa !important như một giải pháp tình thế để ép buộc hiển thị. Hậu quả là Browser Engine phải thực hiện nhiều phép so sánh toán học phức tạp hơn để phân định xem thuộc tính nào thực sự chiến thắng trong chuỗi Cascade.

2.2. Sự Trùng Lặp Thuộc Tính (CSS Duplication) Và Sự Phình To Của Bundle

Trong mô hình CSS truyền thống theo thành phần (Component-based CSS như CSS Modules), mỗi thành phần giao diện sở hữu một tệp phong cách riêng biệt nhằm đảm bảo tính đóng gói (encapsulation). Điều này dẫn đến sự lặp lại hàng nghìn lần của các cặp thuộc tính-giá trị (property-value pairs) phổ biến trên toàn hệ thống.

CSS

/* Button.module.css */
.button {
    display: flex;
    align-items: center;
    justify-content: center;
    padding: 12px 24px;
}

/* Alert.module.css */
.alert {
    display: flex;
    align-items: center;
    padding: 12px 24px;
}

Mặc dù các công cụ đóng gói (bundlers như Webpack, Vite) có thể nén văn bản rất tốt qua Gzip hoặc Brotli nhờ vào tính lặp lại của chuỗi ký tự, nhưng điều đó chỉ giải quyết bài toán dung lượng mạng (network payload). Khi tệp tin CSS được tải xuống và giải nén trong trình duyệt, toàn bộ khối lượng mã trùng lặp này sẽ chuyển hóa thành một cấu trúc CSSOM khổng lồ. Trình duyệt bắt buộc phải cấp phát bộ nhớ RAM lớn để lưu trữ và duyệt qua hàng triệu luật khai báo trùng lặp này, gia tăng đáng kể chi phí phân tích ban đầu (parse cost) và chi phí chỉ mục hóa quy tắc (rule indexing cost).

2.3. Vấn Đề Mã Chết Tích Tụ (Dead CSS)

Khi một hệ thống Frontend vận hành qua nhiều năm, các thành phần giao diện liên tục bị chỉnh sửa hoặc loại bỏ. Tuy nhiên, việc loại bỏ các đoạn mã CSS tương ứng luôn tiềm ẩn rủi ro cao do tính toàn cục của bộ chọn. Các kỹ sư thường chọn giải pháp an toàn là giữ lại mã CSS cũ vì không thể chắc chắn liệu có một DOM node nào đó ở một góc khuất của ứng dụng đang phụ thuộc vào bộ chọn đó hay không.

Hệ quả là ứng dụng tích tụ một khối lượng lớn “Mã CSS chết” (Dead CSS). Dù không trực tiếp hiển thị trên UI hiện hành, Browser Engine vẫn bắt buộc phải tải, phân tách thành CSSOM, đưa vào danh mục bản đồ bộ chọn (selector map) và thực hiện đối sánh thử nghiệm với mọi DOM node trong mỗi chu kỳ kết xuất.

2.4. Phạm Vi Vô Hiệu Hóa Diện Rộng (Large Invalidation Scope)

Bởi vì các bộ chọn truyền thống liên kết chặt chẽ với cấu trúc phân cấp của DOM (thông qua các quan hệ tổ tiên, con, anh em), ranh giới thay đổi phong cách mang tính chất bất định. Một chỉnh sửa thuộc tính hoặc việc kích hoạt một class ở tầng root node có thể dẫn đến việc trình duyệt phải hủy bỏ toàn bộ kết quả tính toán phong cách trước đó của hàng vạn node con (deep style invalidation layout invalidation paint invalidation). Điều này triệt tiêu hoàn toàn khả năng tối ưu hóa cục bộ (local optimization) vốn là thế mạnh của các Browser Engine hiện đại.

3. Kiến Trúc Runtime Atomic CSS: Cơ Chế Vận Hành, Ưu Điểm Và Lỗ Hổng Hiệu Năng

Kiến trúc Runtime Atomic CSS (đại diện tiêu biểu bởi các thư viện như Emotion, Styled-components ở các phiên bản runtime, hay Styletron) xuất hiện như một lời giải trực diện cho bài toán đóng gói và động hóa phong cách trong kỷ nguyên Component-driven UI.

3.1. Bản Chất Của Atomic CSS

Tư duy cốt lõi của Atomic CSS (hay Functional CSS) là triệt tiêu hoàn toàn các bộ chọn phức tạp và cấu trúc cascade. Kiến trúc này chuẩn hóa CSS về dạng các hạt nguyên tử:

$$\text{1 Class Name} \equiv \text{1 CSS Property-Value Declaration}$$

Ví dụ, thay vì định nghĩa một class phức hợp, hệ thống phân rã thành:

CSS

.d-flex { display: flex; }
2.p-4 { padding: 1rem; }
.text-red { color: #ff0000; }

3.2. Cơ Chế Vận Hành Tại Runtime (Runtime Stylesheet Injection Lifecycle)

Trong kiến trúc Runtime Atomic CSS, quá trình khởi tạo và phân phối phong cách không diễn ra ở giai đoạn xây dựng (build-time), mà được thực thi hoàn toàn trong quá trình ứng dụng chạy trên trình duyệt (runtime).

[UI Component Render] 
        │
        ▼
[Extract Style Object] ──> [Hash Checksum Generation]
                                 │
                                 ├──> Nếu có trong Cache ──> [Return Class Names]
                                 │
                                 └──> Nếu KHÔNG có trong Cache
                                             │
                                             ▼
                                     [Generate CSS Rule]
                                             │
                                             ▼
                                     [CSSOM Mutation] (insertRule)
                                             │
                                             ▼
                                     [Update Browser Selector Map]

Quy trình kỹ thuật diễn ra như sau:

Trích xuất phong cách (Style Extraction): Khi một component được thực thi hàm render (ví dụ: React phát hiện component cần hiển thị), mã nguồn JavaScript thu thập đối tượng cấu hình phong cách (style object).
Tính toán Hash (Deterministic Hashing): Hệ thống thực hiện băm (hash) nội dung của từng cặp thuộc tính-giá trị thành một chuỗi định danh duy nhất (ví dụ: padding: 16px biến thành class .atm_pd_16px).
Tra cứu Bộ nhớ đệm (Cache Lookup): Một registry nội bộ bằng JavaScript (thường là một Map hoặc Set) được tra cứu. Nếu chuỗi hash này đã tồn tại, engine bỏ qua bước sinh mã và trả về tên class trực tiếp.
Bơm Phong Cách Động (Dynamic Stylesheet Injection): Nếu chuỗi hash chưa tồn tại trong bộ nhớ đệm, runtime engine sẽ kiến tạo một chuỗi văn bản CSS hoàn chỉnh và thực hiện can thiệp trực tiếp vào CSSOM thông qua phương thức gốc của trình duyệt: CSSStyleSheet.prototype.insertRule().
Gán Nhãn Giao Diện (DOM Attachment): Tên class nguyên tử vừa được xử lý sẽ được gán vào mảng thuộc tính className của phần tử DOM tương ứng.

3.3. Lợi Thế Hệ Thống Của Runtime Atomic CSS

Tối Ưu Hóa Trùng Lặp Cực Hạn (Maximum Deduplication): Bằng việc quy đổi về dạng nguyên tử, nếu thuộc tính display: flex hay padding: 16px được sử dụng ở 10.000 vị trí khác nhau trong ứng dụng, tệp CSSOM chỉ tồn tại duy nhất một định nghĩa quy tắc cho mỗi thuộc tính đó. Kích thước tổng thể của stylesheet đạt trạng thái bão hòa (tăng trưởng theo đường tiệm cận ngang) bất chấp quy mô của mã nguồn ứng dụng tiếp tục phình to.
Khả Năng Tái Sử Dụng Hoàn Hảo (High Reusability & Cache Locality): Trình duyệt ghi nhận một danh mục các class rất mỏng và tập trung. Do các class này liên tục được tái sử dụng qua các DOM node khác nhau, bộ nhớ đệm tính toán phong cách (Computed Style Cache) của trình duyệt hoạt động với hiệu suất tối đa.
Sinh Mã Theo Nhu Cầu (Just-In-Time Generation): Chỉ có những đoạn mã CSS thực sự cần thiết cho màn hình hiện tại của người dùng mới được khởi tạo và bơm vào trình duyệt. Các đoạn mã dành cho các tính năng ẩn, các tuyến đường chưa được kích hoạt (lazy-loaded routes) hoàn toàn không chiếm dụng bộ nhớ của hệ thống cho đến khi chúng thực sự xuất hiện.

3.4. Điểm Yếu Về Hiệu Năng (The Performance Pitfalls)

Mặc dù giải quyết triệt để bài toán về dung lượng bundle và tính đóng gói, Runtime Atomic CSS lại đặt ra những gánh nặng nghiêm trọng lên năng lực xử lý tại client.

Chi Phí Can Thiệp CSSOM (CSSOM Mutation Cost)

Mỗi lệnh insertRule() là một thao tác can thiệp trực tiếp (mutation) vào cấu trúc dữ liệu cốt lõi của trình duyệt. Trình duyệt vốn được tối ưu hóa cực mạnh cho việc tiếp nhận các stylesheet tĩnh toàn cục một lần duy nhất tại giai đoạn khởi tạo tài liệu. Việc liên tục chèn thêm quy tắc mới một cách không đồng bộ buộc Browser Engine phải:

Hủy bỏ cấu trúc bộ chọn đã được lập chỉ mục trước đó (invalidate selector map).
Xây dựng lại đồ thị phụ thuộc các quy tắc nhằm phục vụ cho tiến trình Cascade.
Kích hoạt lại tiến trình tính toán lại phong cách (Style Recalculation) trên diện rộng để kiểm tra xem quy tắc mới chèn vào có làm thay đổi trạng thái của các phần tử hiện hữu hay không.

Áp Lực Lên Luồng Xử Lý Chính (Main-Thread Pressure & CPU Contention)

Trong các giai đoạn tương tác cao độ của người dùng (ví dụ: chuyển đổi trang phức tạp, thao tác kéo thả, hiển thị đồ thị real-time), JavaScript engine phải xử lý đồng thời logic nghiệp vụ, tính toán DOM ảo (Virtual DOM reconciliation), và quản lý trạng thái. Nếu cộng thêm tác vụ tính toán chuỗi hash, kiểm tra registry, và biên dịch chuỗi CSS cho Runtime CSS, luồng chính (Main Thread) của trình duyệt sẽ rơi vào trạng thái quá tải nghiêm trọng.

Hệ quả trực tiếp là Input Latency (Độ trễ phản hồi tương tác) tăng cao và xảy ra hiện tượng Frame Drop do thời gian xử lý của một khung hình vượt quá ngưỡng 16.67ms.

Sự Phân Mảnh Bộ Nhớ (Memory Fragmentation)

Mô hình runtime liên tục khởi tạo các đối tượng JavaScript ngắn hạn (ephemeral objects) nhằm phục vụ cho quá trình phân tách phong cách và tạo chuỗi văn bản. Điều này tạo ra áp lực nặng nề lên bộ thu gom rác Garbage Collector (GC) của JavaScript Engine (V8). Việc GC phải kích hoạt liên tục để dọn dẹp các mảnh bộ nhớ này sẽ gây ra những khoảng dừng ngắn (micro-pauses) trong quá trình hiển thị ứng dụng, trực tiếp làm suy giảm trải nghiệm mượt mà của người dùng.

4. Kiến Trúc Compiler-Based CSS: Sự Trỗi Dậy Của Zero-Runtime Styling

Nhận diện được các giới hạn vật lý của mô hình Runtime, cộng đồng kỹ sư Frontend đã tạo ra một bước chuyển dịch mang tính bước ngoặt: di dời toàn bộ khối lượng tính toán phức tạp từ trình duyệt của người dùng về giai đoạn biên dịch hệ thống (Build-time). Đây là triết lý vận hành của Compiler-based CSS Architecture (tiêu biểu bởi StyleX của Meta, Vanilla Extract, Panda CSS, hay Linaria).

4.1. Triết Lý Zero-Runtime

Mục tiêu tối thượng của Compiler-based CSS là: Đạt được trải nghiệm phát triển hướng đối tượng, dynamic bằng JavaScript nhưng đầu ra cuối cùng phân phối đến trình duyệt phải là những tệp tin CSS tĩnh nguyên bản và cấu trúc HTML thuần túy. Trình duyệt không phải chạy bất kỳ dòng mã JavaScript nào để phục vụ riêng cho việc sinh phong cách.

4.2. Cơ Chế Biên Dịch Tĩnh (Static Analysis & Code Transformation Pipeline)

Để hiện thực hóa mô hình này, các thư viện Compiler-based sử dụng các hệ thống phân tích mã nguồn nâng cao thông qua Babel, SWC, hoặc các plugin chuyên biệt của trình đóng gói.

[Mã nguồn JSX/TSX] 
        │
        ▼
[Phân Tích Cú Pháp - AST Parsing]
        │
        ▼
[Phân Tích Tĩnh - Static Extraction] ──> Tách thuộc tính CSS tĩnh ra khỏi JS File
        │
        ▼
[Tối Ưu Hóa & Sinh Mã Nguyên Tử] ───> Tạo tệp CSS Tĩnh (.css) tại Build-time
        │
        ▼
[Biến Đổi Mã JS gốc] ───────────────> Thay thế Object Style bằng chuỗi Class Tĩnh

Tiến trình kỹ thuật được thực hiện thông qua các bước:

Phân tích cây cú pháp trừu tượng (AST Parsing): Trình biên dịch đọc mã nguồn (ví dụ: các tệp .tsx hoặc .jsx) và chuyển đổi thành cấu trúc dữ liệu cây AST (Abstract Syntax Tree).
Trích xuất phong cách tĩnh (Static Extraction): Trình biên dịch thực hiện phân tích luồng dữ liệu tĩnh để xác định các khối khai báo phong cách. Đối với các giá trị phụ thuộc vào biến số, compiler sẽ cố gắng thực hiện cơ chế đánh giá tĩnh (static evaluation) hoặc chuyển đổi chúng thành các biến CSS bản xứ (CSS Variables/Custom Properties).
Sinh mã nguyên tử tại Build-time (Build-time Atomic Generation): Tương tự như cơ chế của Atomic CSS, trình biên dịch thực hiện phân rã các thuộc tính thành các class nguyên tử và gom toàn bộ chúng vào một hoặc nhiều tệp .css tĩnh độc lập. Các luật trùng lặp được loại bỏ triệt để ngay tại bước này.
Biến đổi mã nguồn (Code Transformation): Tệp JavaScript gốc được compiler chỉnh sửa: toàn bộ các hàm khai báo phong cách phức tạp bị xóa bỏ, các tham chiếu đối tượng được thay thế bằng các chuỗi ký tự chứa tên class tĩnh thuần túy.

Ví dụ, đoạn mã nguồn ban đầu được kỹ sư viết:

TypeScript

// Trước khi biên dịch
import { stylex } from '@stylexjs/stylex';

const styles = stylex.create({
  base: {
    display: 'flex',
    padding: 16,
    color: 'blue',
  },
});

function Component() {
  return <div {...stylex.props(styles.base)}>Hello</div>;
}

Sau khi qua pipeline của compiler, mã nguồn JavaScript xuất xưởng chỉ còn:

JavaScript

// Sau khi biên dịch (JS output)
function Component() {
  return <div className="x1lliihq x1n2onr6 x1md962g">Hello</div>;
}

Và một tệp CSS tĩnh được tạo ra song song:

CSS

/* Tệp CSS output tách biệt */
.x1lliihq { display: flex; }
.x1n2onr6 { padding: 16px; }
.x1md962g { color: blue; }

4.3. Ưu Điểm Tuyệt Đối Về Mặt Vận Hành Hệ Thống

Giải Phóng Tuyến Trình Hiển Thị (Optimized Critical Rendering Path): Trình duyệt nhận được HTML và tệp CSS tĩnh thông qua thẻ <link>. Trình duyệt có thể song song tải xuống, phân tách CSSOM và dựng Render Tree ngay lập tức mà không cần phải chờ đợi toàn bộ khối lượng mã JavaScript được tải về, giải nén và thực thi. Giai đoạn sinh phong cách hoàn toàn bị xóa bỏ khỏi trục thời gian hiển thị tại client.
Hỗ Trợ Hoàn Hảo Cho Cơ Chế Tối Ưu Trình Duyệt (Browser-Native Optimizations): Vì stylesheet là tĩnh và được định hình trước khi tài liệu hiển thị, Browser Engine có thể kích hoạt toàn bộ các cơ chế tối ưu hóa cấp thấp của phần cứng: lập chỉ mục bộ chọn trước (pre-indexing), tối ưu hóa tải trước tài nguyên (preload tokenization), và thiết lập bộ nhớ đệm computed style một cách bền vững mà không lo ngại bị phá vỡ bởi các lệnh mutate từ JavaScript.
An Toàn Tuyệt Đối Trước Tiến Trình Thu Gom Rác: Việc loại bỏ hoàn toàn các logic băm, sinh chuỗi và quản lý registry tại runtime giúp giải phóng JavaScript heap memory, triệt tiêu nguy cơ nghẽn main-thread do hiện tượng Garbage Collection diễn ra liên tục.

5. Trận Chiến Tại Lõi Trình Duyệt: Phân Tích Đối Sánh Chuyên Sâu (Deep Architectural Comparison)

Để đưa ra quyết định kiến trúc chính xác cho một hệ thống Frontend quy mô lớn, chúng ta cần so sánh định lượng và định tính hành vi của hai giải pháp này khi chúng tương tác với các cơ chế cao cấp bên trong Browser Engine.

5.1. Tương Tác Với Cơ Chế Thực Thi Đồng Thời (Concurrent Rendering)

Trong các thư viện UI hiện đại như React 18+, cơ chế Concurrent Rendering cho phép quá trình render có thể bị gián đoạn (interrupted), tạm dừng, hoặc chạy song song nhiều luồng ảo tùy thuộc vào mức độ ưu tiên của tác vụ (Task Priority).

Đối với Runtime Atomic CSS: Đây là một bài toán phối hợp cực kỳ phức tạp. Nếu một tiến trình render đang diễn ra giữa chừng và bị tạm dừng để nhường quyền cho một tương tác có mức độ ưu tiên cao hơn, Runtime CSS Engine có thể đã kịp chèn một số quy tắc mới vào CSSOM. Sự không đồng bộ này dễ dẫn đến hiện tượng Tearing (Sự bất nhất về mặt đồ họa), khi mà thứ tự các class trong CSSOM bị đảo lộn so với trật tự render thực tế, gây sai lệch nghiêm trọng về mặt hiển thị do tính chất phụ thuộc vị trí của các quy tắc CSS.
Đối với Compiler-based CSS: Do toàn bộ các quy tắc phong cách đã được định hình tĩnh và tồn tại sẵn trong bộ nhớ của trình duyệt độc lập với vòng đời kết xuất của JavaScript component, tiến trình Concurrent Rendering có thể tự do ngắt dòng, tiếp tục (resume), hoặc hủy bỏ các lượt render mà không gây ra bất kỳ tác động tiêu cực nào tới trạng thái hoặc tính toàn vẹn của giao diện.

5.2. Ổn Định Hóa Tiến Trình Thủy Hóa (Hydration Stability Trong Streaming SSR)

Kiến trúc ứng dụng hiện đại dựa trên mô hình Streaming SSR kết hợp Incremental Hydration. Server sẽ truyền tải liên tục các đoạn mã HTML (stream) xuống client, và client sẽ tiến hành “thủy hóa” (hydration – gắn kết logic JavaScript vào HTML tĩnh) một cách chọn lọc trên từng phân vùng giao diện.

Mô hình Stream HTML:
[Server Stream] ──> [HTML Chunk 1] ──> [HTML Chunk 2] ──> [HTML Chunk 3]
                          │                  │                  │
                          ▼                  ▼                  ▼
[Client Hydration]  [Hydrate Core]     [Hydrate Component]  [Hydrate Lazy Elements]

Hành vi của Runtime Atomic CSS: Sự phụ thuộc vào thời điểm thực thi của JavaScript tạo ra một “Race Condition” (Điều kiện cạnh tranh) nguy hiểm. Nếu một component ở Chunk 2 cần một class nguyên tử chưa từng được nạp ở Chunk 1, Runtime CSS Engine sẽ ép chèn quy tắc đó vào giữa stylesheet. Hành vi này có thể làm thay đổi độ đặc hiệu hoặc thứ tự ưu tiên của các class hiện tại, dẫn đến hiện tượng Hydration Mismatch (Bất đồng nhất giữa cấu trúc Server dựng và Client nhận), gây ra lỗi giao diện hiển thị nhấp nháy trực quan (Flash of Unstyled Content - FOUC).
Hành vi của Compiler-based CSS: Do tính chất tách biệt hoàn toàn, toàn bộ bản đồ phong cách đã được nạp trọn vẹn từ đầu (hoặc được phân tách chính xác theo các tệp CSS tương ứng với các phân đoạn code-splitting). Quá trình thủy hóa diễn ra một cách deterministic (định tính, có thể dự đoán trước), đảm bảo cấu trúc DOM và CSSOM luôn khớp nhau tuyệt đối tại mọi thời điểm tiếp nhận luồng dữ liệu stream.

5.3. Đồ Thị Tính Toán Lại Phong Cách (Style Recalculation Graph Cost)

Khi đánh giá chi phí vận hành CPU cho tác vụ tính toán lại phong cách, chúng ta có thể mô hình hóa thông qua công thức ước lượng chi phí tổng quát của Browser Engine cho mỗi chu kỳ cập nhật:

$$\text{Total Cost} = \mathcal{O}\left( N_{\text{DOM}} \times M_{\text{Selectors}} \times D_{\text{Depth}} \right)$$

Trong đó:

$N_{\text{DOM}}$: Số lượng node trong cây DOM cần kiểm tra.
$M_{\text{Selectors}}$: Số lượng quy tắc bộ chọn hiện có trong hệ thống.
$D_{\text{Depth}}$: Độ sâu trung bình của quá trình duyệt cây ngược để giải quyết mối quan hệ tổ tiên.

So sánh cấu trúc đồ thị giữa các kiến trúc:

Thuộc tính phân tích	Traditional CSS Architecture	Runtime Atomic CSS Architecture	Compiler-based CSS Architecture
Cấu trúc Selector	Phức hợp, lồng nhau đa tầng (`.a .b .c .d`)	Đơn cấp, đơn hạt (`.atm_x`)	Đơn cấp, đơn hạt (`.x1a2b3`)
Độ sâu duyệt cây ($D_{\text{Depth}}$)	Lớn (Trình duyệt phải duyệt ngược nhiều tầng DOM)	Bằng 1 (Trình duyệt chỉ kiểm tra trực tiếp trên node hiện hành)	Bằng 1 (Trình duyệt chỉ kiểm tra trực tiếp trên node hiện hành)
Số lượng bộ chọn ($M_{\text{Selectors}}$)	Trung bình đến Lớn (Chứa nhiều mã chết theo thời gian)	Nhỏ đến Trung bình (Biến thiên động theo thời gian chạy)	Nhỏ và Tĩnh (Tối ưu hóa triệt để từ bước đóng gói)
Tần suất biến động CSSOM	Không (Ổn định tĩnh)	Rất cao (Liên tục gọi `insertRule`)	Không (Ổn định tĩnh tuyệt đối)

Từ bảng so sánh trên, chúng ta nhận thấy cả hai kiến trúc Atomic (Runtime và Compiler) đều tối ưu hóa xuất sắc hai tham số $M_{\text{Selectors}}$ và $D_{\text{Depth}}$ bằng cách triệt tiêu cấu trúc lồng nhau. Tuy nhiên, Runtime Atomic CSS tự tạo ra điểm nghẽn cho mình bằng việc liên tục làm biến động đồ thị (dynamic CSSOM mutation), buộc trình duyệt phải chạy lại thuật toán kiểm tra từ đầu, trong khi Compiler-based CSS duy trì một đồ thị tĩnh hoàn toàn, cho phép trình duyệt tận dụng tối đa các kết quả tính toán đã được lưu trong bộ nhớ đệm (cache hits).

5.4. Bài Toán Điều Phối Tài Nguyên CPU (CPU Scheduling)

Trong các trình duyệt hiện đại, luồng chính (Main Thread) vận hành dựa trên một cơ chế điều phối sự kiện (Event Loop) vô cùng bận rộn. Luồng này phải phân chia thời gian cho rất nhiều tác vụ khác nhau:

+-----------------------------------------------------------------------+
|                       MAIN THREAD EVENT LOOP                          |
+-----------------------------------------------------------------------+
|  JS Execution  |  Style Recalc  |  Layout  |  Paint  |  Input Event   |
+-----------------------------------------------------------------------+

Khi Runtime Atomic CSS thực thi, nó chèn thêm một khối lượng công việc đáng kể (JS Execution cho việc sinh style + CSSOM Mutation Processing) vào ngay trước giai đoạn Style Recalc. Điều này làm kéo dài thời gian chiếm dụng của một chu kỳ tuần hoàn Event Loop.

Ngược lại, Compiler-based CSS dịch chuyển toàn bộ phần việc JS Execution liên quan đến style ra khỏi sơ đồ này. Main Thread giải phóng được băng thông xử lý, chỉ tập trung thực thi logic nghiệp vụ thuần túy của ứng dụng và thực hiện hiển thị các phong cách tĩnh vốn đã được tối ưu hóa ở mức mã máy bởi Browser Engine.

5.5. Quản Lý Trạng Thái Động (Dynamic Styling & Design Token Resolution)

Mặc dù Compiler-based CSS chiếm ưu thế lớn về hiệu năng kết xuất, Runtime Atomic CSS lại sở hữu một vũ khí tối thượng: Khả năng xử lý các kịch bản phong cách động ở mức độ phức tạp cực cao.

Tính linh hoạt của Runtime: Do phong cách được tính toán bằng JavaScript ngay khi chạy, ứng dụng có thể dễ dàng tiếp nhận các tùy biến từ người dùng cuối (ví dụ: một ứng dụng CMS cho phép người dùng tự kéo thanh trượt để đổi màu, đổi khoảng cách, căn chỉnh lề với hàng triệu sắc độ khác nhau). Runtime engine sẽ tiếp nhận giá trị động đó, tính toán băm và tạo ra rule tương ứng ngay lập tức.
Sự giới hạn của Compiler-based: Vì compiler yêu cầu phân tích mã nguồn tĩnh tại build-time, nó không thể biết trước các giá trị ngẫu nhiên do người dùng nhập vào tại runtime. Để giải quyết bài toán này, các hệ thống Compiler-based hiện đại buộc phải sử dụng giải pháp lai: xuất bản các cấu trúc class tĩnh cho các khung thuộc tính cố định, kết hợp gán các giá trị biến động vào các Biến CSS tĩnh (CSS Custom Properties) trên thuộc tính style dạng inline của DOM node:

TypeScript

// Giải pháp xử lý giá trị động của Compiler-based CSS
const styles = stylex.create({
  dynamicBox: (customColor) => ({
    color: customColor, // Bản chất compiler sẽ chuyển dịch thành một CSS Variable
  }),
});

6. Xu Hướng Chuyển Dịch Kiến Trúc Và Khuyến Nghị Thực Tiễn (Systems Engineering Guidance)

Ngành công nghiệp Frontend đang bước vào một làn sóng chuyển dịch kiến trúc sâu sắc tuân theo tuyên ngôn:

“Compile more, Run less” (Biên dịch nhiều hơn, Thực thi ít hơn).

Tư duy này không chỉ thống trị lớp phong cách (CSS) mà còn là kim chỉ nam cho sự phát triển của các cấu trúc UI tầng sâu như React Server Components (RSC), các compiler tối ưu hóa giao diện như React Compiler (React Forget), và các framework như Qwik với cơ chế Resumability. Mục tiêu cốt lõi là giải phóng client khỏi các gánh nặng tính toán cấu trúc hạ tầng, trả lại trình duyệt vai trò nguyên bản: một bộ máy hiển thị hiệu năng cao và phản hồi tương tác mượt mà.

6.1. Bảng Đối Sánh Tổng Quan (Comprehensive Framework Matrix)

Dưới đây là bảng tổng hợp tiêu chí kỹ thuật toàn diện phục vụ cho việc thẩm định kiến trúc hệ thống:

Tiêu Chí Thẩm Định	Runtime Atomic CSS Architecture	Compiler-based CSS Architecture
Thời điểm sinh mã	Runtime (Tại trình duyệt của Client)	Build-time (Tại máy chủ Build/CI-CD)
Biến động CSSOM	Có (Kích hoạt liên tục qua `insertRule`)	Gần như bằng 0 (Stylesheet tĩnh cố định)
Chi phí luồng chính (Main-thread Overhead)	Trung bình đến Cao (Xử lý Hash, String, Registry)	Rất thấp (Zero runtime JavaScript execution)
Tính an toàn của Hydration	Rủi ro cao (Dễ gây Mismatch trong Streaming SSR)	Tuyệt đối (Deterministic, an toàn với Stream)
Khả năng tương thích với Concurrent Mode	Phức tạp (Nguy cơ gây lỗi hiển thị Tearing)	Hoàn hảo (Không phụ thuộc vào vòng đời render)
Hiệu năng tối ưu hóa của Trình Duyệt	Bị hạn chế do cấu trúc stylesheet liên tục thay đổi	Tối đa (Kích hoạt bộ lọc tĩnh cấp thấp của Engine)
Áp lực lên bộ nhớ (GC Pressure)	Cao (Tạo nhiều đối tượng chuỗi ngắn hạn)	Thấp (Không phát sinh đối tượng rác tại runtime)
Khả năng xử lý Dynamic Styling ngẫu nhiên	Cực mạnh (Xử lý trực tiếp mọi cấu hình đối tượng)	Có giới hạn (Phải thông qua cầu nối CSS Variables)
Dung lượng tệp JS xuất xưởng	Lớn hơn (Bao gồm mã nguồn của thư viện runtime)	Nhỏ hơn (Chỉ còn các chuỗi ký tự đặt tên class)

6.2. Khuyến Nghị Lựa Chọn Kiến Trúc (Architectural Blueprint)

Việc quyết định đầu tư vào kiến trúc nào không nên dựa trên sự phổ biến nhất thời của công nghệ, mà phải dựa trên việc phân tích bản chất của sản phẩm phần mềm cần xây dựng:

Trường hợp ưu tiên lựa chọn Compiler-based CSS Architecture:

Hệ thống Enterprise SaaS Quy Mô Lớn: Các ứng dụng có số lượng màn hình lên tới hàng trăm, mật độ linh kiện dày đặc, nơi mà sự tích tụ mã CSS và chi phí Style Recalculation có thể làm tê liệt trình duyệt.
Nền Tảng E-commerce & Web Công Cộng Hiệu Năng Cao: Những hệ thống đặt nặng các chỉ số Core Web Vitals như First Contentful Paint (FCP) và Interaction to Next Paint (INP). Việc giảm thiểu thời gian nghẽn luồng chính và tối ưu hóa Critical Rendering Path là yếu tố quyết định đến tỷ lệ chuyển đổi của người dùng.
Ứng Dụng Ứng Dụng Mô Hình Kiến Trúc Hiện Đại: Hệ thống sử dụng React Server Components, Next.js App Router, hoặc các kiến trúc yêu cầu Streaming SSR và Partial Hydration nghiêm ngặt.

Trường hợp chấp nhận/ưu tiên lựa chọn Runtime Atomic CSS Architecture:

Ứng Dụng Có Tính Chất Tùy Biến Đồ Họa Cực Hạn (Highly Dynamic/User-Generated Interfaces): Các công cụ thiết kế, các dashboard có tính năng cho phép người dùng cấu hình sâu sắc từng thuộc tính giao diện trực quan theo thời gian thực mà hệ thống không thể dự đoán trước danh mục thuộc tính tại thời điểm build.
Hệ Hệ Thống Legacy Hoặc Dự Án Có Tốc Độ Phát Triển Nhanh (Rapid Prototyping): Nơi mà đội ngũ kỹ sư cần sự linh hoạt tối đa của JavaScript để can thiệp cấu trúc phong cách một cách nhanh chóng, và quy mô DOM chưa đạt tới ngưỡng giới hạn gây ra các vấn đề về mặt hiệu năng hiển thị.

. Kết Luận (Conclusion)

Sự tiến hóa của các kiến trúc CSS trong thế giới Frontend hiện đại đã vượt qua ranh giới của những tranh luận thuần túy về mặt cú pháp (syntax) hay trải nghiệm lập trình viên (DX). Giờ đây, việc thiết kế một kiến trúc CSS cho hệ thống quy mô lớn đã trở thành một bài toán Kỹ thuật hệ thống kết xuất (Rendering Systems Engineering) thực thụ.

Sự khác biệt cốt lõi giữa Runtime Atomic CSS và Compiler-based CSS nằm ở chiến lược phân bổ tài nguyên tính toán và mô hình hợp tác với Browser Engine Internals. Runtime Atomic CSS mang đến sự linh hoạt tuyệt đối, khả năng sinh mã thích ứng cao độ ngay tại thời điểm sử dụng, nhưng đánh đổi bằng chi phí CPU tại client, sự bất ổn định trong tiến trình thủy hóa đa nền tảng và áp lực liên tục lên cấu trúc CSSOM.

Ngược lại, Compiler-based CSS đại diện cho tư duy kỹ thuật hiện đại: chuyển dịch sự phức tạp về phía hạ tầng biên dịch, trả lại sự nguyên bản và tối giản cho trình duyệt. Bằng cách triệt tiêu runtime overhead và cung cấp những cấu trúc stylesheet tĩnh, có thể dự đoán trước, kiến trúc này cho phép Browser Engine kích hoạt các cơ chế tối ưu hóa phần cứng sâu nhất, mang lại hiệu năng đồ họa tối ưu và sự ổn định dài hạn cho hệ thống phần mềm.

Trong bối cảnh các ứng dụng Web ngày càng tiến gần đến giới hạn phức tạp của các hệ điều hành giao diện thế hệ mới, việc thấu hiểu cách thức CSS tương tác với Browser Rendering Pipeline không còn là kiến thức bổ trợ, mà là năng lực cốt lõi giúp các kỹ sư Frontend kiến tạo nên những hệ thống có hiệu năng vượt trội, bền vững và sẵn sàng thích ứng với những thay đổi công nghệ trong tương lai.