Critical Rendering Path là gì?

Khi nói đến tối ưu hiệu suất frontend, rất nhiều người bắt đầu bằng việc nén ảnh, lazy-load hay giảm JavaScript. Những kỹ thuật đó đều đúng, nhưng nếu không hiểu trình duyệt thực sự render trang web như thế nào, chúng ta rất dễ tối ưu sai chỗ.

Trong bài viết này, chúng ta sẽ cùng tìm hiểu Critical Rendering Path (CRP) – quá trình mà trình duyệt sử dụng để biến HTML, CSS và JavaScript thành những pixel mà người dùng nhìn thấy trên màn hình. Đây chính là nền tảng cốt lõi để hiểu và cải thiện các chỉ số như LCP, CLS, FID/INP.

Critical Rendering Path là gì?

Critical Rendering Path (CRP) là chuỗi các bước mà trình duyệt phải thực hiện kể từ khi nhận được dữ liệu từ server cho đến khi trang web được hiển thị.

Một cách đơn giản, CRP trả lời cho câu hỏi:

“Điều gì đang xảy ra bên trong trình duyệt từ lúc tải trang cho đến khi người dùng thấy nội dung?”

CRP bao gồm 5 bước chính:

1. Phân tích DOM và CSSOM

• Tạo Render Tree

• DOM chứa toàn bộ nội dung của trang và CSSOM chứa toàn bộ kiểu dáng của trang.
• Làm thế nào để chúng ta lấy nội dung và kiểu dáng rồi chuyển chúng thành các pixel trên màn hình?
• Chúng ta cần kết hợp DOM và CSSOM thành cây hiển thị (render tree).
• Lưu ý:
  • Cây hiển thị chỉ thu thập nội dung hiển thị được.
  • Các bước liên quan đến việc xây dựng cây hiển thị sẽ được chúng ta hiểu rõ hơn thông qua một ví dụ.
  • Để tạo cây hiển thị, trước tiên chúng ta truy cập vào nút gốc của nội dung hiển thị.
  • Trong hình ảnh trên, nội dung hiển thị đầu tiên là nút `body`. Có một quy tắc khớp với thẻ `body` trong CSSOM.
  • Vì vậy, chúng ta sao chép nút `body` vào cây hiển thị cùng với các thuộc tính CSS.
  • Tương tự, tất cả các nút hiển thị từ DOM đều được sao chép vào cây hiển thị cùng với kiểu dáng của chúng nếu có trong CSSOM.
• Layout (Reflow)

• • Quá trình bố cục tính toán kích thước của một phần tử và căn chỉnh dựa trên không gian có sẵn.
  • Kết quả của quá trình bố cục là một “mô hình hộp”, mô tả chính xác vị trí và kích thước của từng phần tử trong khung nhìn: tất cả các phép đo tương đối được chuyển đổi thành pixel tuyệt đối trên màn hình.
  • Cuối cùng, khi chúng ta biết các nút nào hiển thị, cũng như kiểu dáng và hình học đã được tính toán của chúng, chúng ta có thể chuyển thông tin này đến giai đoạn cuối cùng, giai đoạn chuyển đổi từng nút trong cây kết xuất thành pixel thực tế trên màn hình.
  • Bước này thường được gọi là “vẽ” hoặc “raster hóa”.

• Paint
  • Khi quá trình bố cục hoàn tất, trình duyệt sẽ phát ra các sự kiện “Paint Setup” và “Paint”, chuyển đổi cây hiển thị thành các pixel trên màn hình.
• Composite

Chỉ cần một bước bị chậm, trải nghiệm người dùng sẽ bị ảnh hưởng ngay lập tức.

1. Từ HTML và CSS đến DOM và CSSOM

Khi trình duyệt nhận được HTML từ server, việc đầu tiên nó làm là phân tích HTML và xây dựng DOM (Document Object Model).

DOM là một cấu trúc cây biểu diễn toàn bộ nội dung của trang web. Mỗi thẻ HTML trở thành một node trong cây này.

Song song với đó, trình duyệt cũng tải và phân tích các file CSS để tạo ra CSSOM (CSS Object Model) – một cây cấu trúc mô tả tất cả các quy tắc style.

Điểm quan trọng ở đây là:

• DOM và CSSOM hoàn toàn độc lập
• DOM quyết định có gì trên trang
• CSSOM quyết định nó trông như thế nào

Trình duyệt không thể render bất cứ thứ gì nếu thiếu một trong hai.

2. Render Tree – chỉ giữ lại những gì thực sự hiển thị

Sau khi có DOM và CSSOM, trình duyệt kết hợp chúng để tạo ra Render Tree.

Render Tree chỉ chứa:

• Các phần tử sẽ xuất hiện trên màn hình
• Thông tin về style cần thiết để hiển thị

Những thứ không xuất hiện trong Render Tree:

• Các phần tử có display: none
• Thẻ <script>, <meta>
• Các node bị ẩn hoàn toàn bằng CSS

Render Tree là nền tảng cho toàn bộ quá trình layout và paint phía sau.

3. Layout (Reflow) – tính toán kích thước và vị trí

Khi đã có Render Tree, trình duyệt cần xác định:

• Mỗi phần tử nằm ở đâu
• Rộng bao nhiêu, cao bao nhiêu
• Quan hệ không gian giữa các phần tử
• Bước này được gọi là layout, hay còn gọi là reflow.

Đây là một trong những bước tốn tài nguyên nhất. Bất kỳ thay đổi nào ảnh hưởng đến bố cục như:

• Thay đổi chiều rộng hoặc chiều cao
• Thêm hoặc xóa phần tử
• Thay đổi font-size đều có thể kích hoạt reflow lại toàn bộ hoặc một phần trang.

4. Paint – vẽ từng pixel lên màn hình

Sau khi layout hoàn tất, trình duyệt bắt đầu bước paint – nơi các pixel thực sự được vẽ lên màn hình.

Paint bao gồm:

• Vẽ text
• Màu nền
• Hình ảnh
• Border, shadow, gradient…

Paint thường được thực hiện trên nhiều layer khác nhau. Các thuộc tính như box-shadow, filter hay gradient có thể làm bước này trở nên chậm hơn đáng kể.

5. Composite – ghép các layer lại với nhau

Ở bước cuối cùng, trình duyệt kết hợp các layer đã được paint để tạo ra hình ảnh cuối cùng.

Đây là lý do vì sao các thuộc tính như transform và opacity rất được ưa chuộng khi làm animation. Chúng chỉ ảnh hưởng đến composite, không gây reflow hay repaint, giúp animation mượt mà hơn rất nhiều.

JavaScript ảnh hưởng đến quá trình render như thế nào?

JavaScript có thể gây ảnh hưởng lớn đến Critical Rendering Path:

• Mặc định, JavaScript là parser-blocking: trình duyệt phải tải và thực thi xong JS trước khi tiếp tục parse HTML
• JavaScript có thể thay đổi DOM và CSSOM, dẫn đến reflow và repaint
• JavaScript nặng có thể chiếm main thread, làm chậm phản hồi tương tác

Đây là lý do vì sao các trang có quá nhiều JavaScript thường:

• Load chậm
• Click không ăn
• Scroll bị giật

Giải pháp phổ biến bao gồm:

• Dùng defer hoặc async
• Chia nhỏ bundle (code-splitting)
• Đẩy tác vụ nặng sang Web Worker

Critical Rendering Path và Core Web Vitals

Hiểu CRP giúp chúng ta hiểu rõ hơn các chỉ số Core Web Vitals của Google.

Largest Contentful Paint (LCP)

LCP đo thời điểm mà phần tử nội dung lớn nhất trong viewport được hiển thị.

• Ngưỡng tốt: dưới 2.5 giây

LCP thường bị ảnh hưởng bởi:

• Hình ảnh hero lớn
• CSS hoặc JavaScript chặn render
• Server phản hồi chậm

First Input Delay (FID) & Interaction to Next Paint (INP)

FID và INP đo độ trễ tương tác của người dùng.

• FID tốt: dưới 100ms
• INP tốt: dưới 200ms

Nguyên nhân phổ biến nhất là JavaScript chạy quá lâu trên main thread.

Cumulative Layout Shift (CLS)

CLS đo mức độ “nhảy layout” – các phần tử bị dịch chuyển ngoài ý muốn.

• Ngưỡng tốt: dưới 0.1

Nguyên nhân thường gặp:

• Ảnh không có kích thước cố định
• Font load muộn
• Nội dung được chèn động

Công cụ giúp phân tích quá trình render

Để tối ưu hiệu quả, chúng ta cần đo lường:

• Chrome DevTools – Performance: xem timeline render, long tasks, reflow
• Lighthouse: đánh giá Core Web Vitals và gợi ý cải thiện
• PageSpeed Insights: kết hợp dữ liệu lab và dữ liệu người dùng thật
• WebPageTest: phân tích chi tiết theo nhiều điều kiện mạng

Kết luận

Tối ưu hiệu suất frontend không chỉ là làm cho trang web “nhẹ hơn”, mà là hiểu cách trình duyệt suy nghĩ và làm việc.

Khi nắm rõ Critical Rendering Path, bạn sẽ:

• Biết chính xác thứ gì đang làm trang web chậm
• Tối ưu đúng bước trong pipeline render
• Cải thiện Core Web Vitals một cách bền vững

Hiệu suất không phải là mẹo vặt – đó là hiểu bản chất.

Bài viết có tham khảo thêm: https://codegyaan.medium.com/builddemystifying-critical-rendering-path-7c09bf6e8731