Categories Tối ưu CSS

Bạn có nên sử dụng critical CSS

Tóm tắt: Bài viết này sẽ cho bạn biết critical CSS là gì? Cách nó hoạt động và khi nào bạn nên sử dụng nó? Và thậm chí…khi nào bạn không nên sử dụng critical CSS?

Đây là một hướng dẫn khác về hiệu suất của WordPress không-hề-chém-gió (cut-the-crap) tôi muốn dành cho bạn…

Để tôi kể chuyện, hồi trước tôi nhận được một câu hỏi ngây thơ từ khách hàng từng mua hosting của mình:

Này, tôi muốn hỏi bạn nhanh một câu: Bạn đã bao giờ xử lý critical CSS chưa? Tôi đang cố gắng thử nghiệm nó nhưng thường thì các plugin hứa hẹn lại chẳng làm tốt cho lắm. Website đã có tốc độ rất nhanh rồi (crazy fast) nhưng nếu nó có thể nhanh hơn nữa thì tại sao lại không thử cơ chứ?

Tôi đã rất thiếu kiên nhẫn, tôi trả lời ngay lập tức…”Cái này không dành cho bạn đâu. Đây là một chiến thuật cũ, giờ được áp dụng trở lại phổ biến ở những người xây dựng các website cồng kềnh. Bạn không có vấn đề như vậy

Và một thời gian ngắn sau khi mối quan hệ bị phá vỡ, tôi cảm thấy cần phải chia sẻ điều gì đó trên blog của mình…


Cách “Critical CSS” làm việc?

Critical CSS là đoạn mã CSS mà trang web của bạn tải lúc ban đầu để sử dụng chỉ cho nội dung ATF (Above The Fold / Nội dung thuộc màn hình đầu tiên) của trang web, thay vì tải toàn bộ CSS (entire CSS) cho toàn trang. Ý tưởng là bằng cách chỉ tải “critical CSS” này, trang của bạn sẽ được hiển thị nhanh hơn cho người dùng, trong khi phần còn lại của trang (nội dung từ màn hình thứ hai trở đi) vốn mất nhiều thời gian hơn để tải về và phân tích sẽ được trì hoãn (defer) mà không bị để ý.

Chiến thuật này đặc biệt hữu ích khi bạn có rất nhiều CSS (giả sử là bất cứ dung lượng CSS nào trên 60KB) cái cần nửa giây hoặc thậm chí lâu hơn để xử lý. Chúng ta cần nhớ lại cách video trên internet từng hoạt động như thế nào? Bạn không thể xem được video cho đến khi toàn bộ video được tải xuống! Nhưng giờ đây với định dạng dữ liệu streaming/phát trực tuyến, bạn có thể bắt đầu xem ngay khi video tải được vài giây. Critical CSS làm việc tương tự, trang có thể hiển thị một khi CSS ban đầu (initial CSS) được xử lý.


Cẩn thận với “critical CSS”

Giống như mọi thứ khác, có hàng tá cảnh báo với chiến thuật này. Tôi sẽ liệt kê những cái đáng chú ý:

  • Ai là người xác định cái nào là “critical CSS”? – người coder? Hoặc một công cụ xuất mã tự động? Tôi thích xử lý code tay (hand-coders) hơn vì sẽ biết chính xác thành phần nào thực sự nằm trên màn hình đầu tiên trong khi các đoạn mã tự động chỉ dự đoán dựa trên các thuật toán định trước. Liệu pop-up GDPR (Quy định chung về bảo vệ dữ liệu) phiền nhiễu có được bao gồm vào hay không? Liệu các icon mua hàng có được bao gồm hay không? Bạn hiểu ý tôi chứ…có quá nhiều thứ phải quyết định, đắn đo. Trong trường hợp xấu nhất, các đoạn mã critical CSS được tạo ra không đúng cách và phá vỡ style/chức năng trang của bạn.
  • Critical CSS có thể làm ảnh hưởng xấu đến thời gian tải trang cho những lần ghé thăm sau nếu bạn có cache phía trình duyệt. Hãy nghĩ về điều này…với cache phía trình duyệt được bật, các thành phần tĩnh như ảnh và CSS/JS được cache trong trình duyệt người dùng và được tải cục bộ từ thiết bị của họ (cái có thời gian tải nhanh nhất). Bằng cách nội tuyến critical CSS vào trong tài liệu HTML, bạn sẽ cần nhiều thời gian hơn để tải trang cho mỗi yêu cầu. Trong trường hợp sử dụng cache phía trình duyệt, tôi nghĩ citical CSS chỉ có ích cho lần ghé thăm đầu tiên mà thôi.
  • Tổng lượng CSS của bạn rất nhỏ, do vậy việc phân chia nó thành nhiều phần hơn làm chậm trang của bạn (bằng cách bổ sung thêm các yêu cầu HTTP) trong khi không tạo ra được thời gian xuất trang nhanh hơn mà người dùng có thể cảm nhận được.
  • Bạn có rất nhiều critical CSS làm gia tăng thêm phức tạp trong khi không đem lại bất kỳ cải thiện tốc độ đáng chú ý nào.

CSS nên chặn hiển thị!

Tôi phát chán cách những người mới cố gắng triển khai các kỹ thuật tối ưu hóa CSS (như việc gộp CSS hoặc critical CSS)!

Hãy nói thẳng điều này > CSS về bản chất được giả định dùng để “chặn hiển thị”.

Nó phải như vậy để bạn không gặp phải các vấn đề FOUT/FOUC/FOIT (Flash Of Unstyled Tex hoặc Flash Of Unstyle Content/hiệu ứng nháy văn bản khi nội dung của bạn tải trước style và văn bản bị giật/nháy khi chuyển từ trạng thái font thông thường sang font được chỉ định trong CSS).

Vấn đề duy nhất bây giờ là làm giảm ảnh hưởng của chặn hiển thị càng nhiều càng tốt. Tôi thậm chí ghét mô tả theo cách như vậy. Nếu tôi có thể tự quyết, tôi sẽ gọi hiện tượng này đơn giản là do “Xử lý CSS”.

Trước đây, CSS không hề cồng kềnh. Chỉ cần vài kilobytes là đủ để bạn tạo style cho toàn bộ website. Điều này dễ dàng đạt được bởi vì trang của bạn được thiết kế toàn bộ trong một lần, bởi một người và với toàn bộ hình dung trong đầu. Ngày nay, các website được xây dựng theo phong cách modul quá mức. Giao diện được thiết kế hoặc lựa chọn trong năm 2016, tùy chỉnh thêm vào năm 2017. Có thể có 15 – 30 plugin, mỗi cái được thiết kế bởi lập trình viên khác nhau, và do vậy cũng bao gồm các đoạn mã CSS riêng biệt của từng người.

Hãy đoán xem khi tất cả các đoạn mã CSS này được trộn lẫn với nhau? Sẽ có nhiều đoạn CSS chồng chéo bởi các nhà phát triển khác nhau chêm những đoạn mã CSS của riêng họ. Lấy ví dụ, theme của bạn đã có style cho nút bấm (button) rồi nhưng nó sẽ được ghi đè (over-ridden) bởi style nút bấm được tạo bởi công cụ xây dựng trang (page builder) và rồi một lần nữa nó được ghi đè bởi style của pop up đăng ký nhận thư. Nếu bạn viết mã từ ban đầu, tất cả điều này có thể chỉ là 3 dòng đơn giản…thay vì 9 dòng, mà 6 trong số chúng ghi đè lên cái khác (dung lượng CSS cồng kềnh, đồng thời việc phân tích cũng mất thời gian hơn).

Hãy tiếp tục nào!…

Cho dù bạn có lượng CSS lớn như thế nào (một lần nữa, tôi định nghĩa “quá nhiều CSS” là có lượng CSS từ 60KB trở lên), lý tưởng là giảm thời gian xử lý của nó (hoặc trong thuật ngữ của pagespeed là thời gian “chặn hiển thị”).


Các phương thức để giảm CSS không cần thiết

  1. Nếu CSS của bạn đã được tối thiểu hóa sẵn rồi (dưới 60kb, tốt nhất là dưới 30kb), thế thì bạn không cần phải làm bất kỳ điều gì cả, vì nó không làm chặn hiển thị.
  2. Nếu CSS của bạn có kích cỡ lớn, hãy cố gắng loại bỏ càng nhiều plugin không cần thiết càng tốt.
  3. Nếu bạn phải giữ lại tất cả CSS này, vậy thì hãy viết lại theme của bạn từ ban đầu hoặc cấu trúc lại mã (về cơ bản viết lại code của bạn sạch hơn và ngắn gọn hơn). Vâng, tôi hoàn toàn ý thức được chuyện hầu hết những ai không phải là coder không thể tự làm được điều này.
  4. Lựa chọn thực tế nhất cho những người mới/không phải coder – chia file CSS của bạn thành những file nhỏ hơn vì thế trang của bạn có thể tải nhanh hơn thay vì phải đợi cho việc tải toàn bộ CSS. Điều này xảy ra một cách tự nhiên ngoại trừ khi mọi người làm những việc ngớ ngẩn như KẾT HỢP CSS (đúng vậy, đây là một chiến thuật phiền nhiễu khác được sử dụng để đánh lừa các công cụ pagespeed). Tôi chỉ có thể nói rằng cách tốt nhất để giảm các yêu cầu HTTP là THỰC SỰ LOẠI BỎ CÁC YÊU CẦU ĐÓ (thay vì thực hiện kết hợp chúng lại với nhau). Cách kết hợp/gộp mã tương đương với 5 khách hàng tại siêu thị kết hợp đơn hàng của họ thành một đơn hàng khổng lồ và tất nhiên vẫn tốn nhiều thời gian để giải quyết.
  5. Hoặc triển khai chiến thuật “critical CSS”. Nó có thể hữu dụng nếu bạn có quá nhiều CSS. Nhưng một lần nữa thì điều tốt hơn là bạn loại bỏ tất cả những đoạn mã không cần thiết.

Lý lẽ cho việc sử dụng (và chống lại việc sử dụng) critical CSS?

Ủng hộ việc sử dụng critical CSS:

  • Khi bạn có rất nhiều CSS phần lớn trong số chúng không cần thiết trong màn hình đầu tiên.

Chống lại việc sử dụng citical CSS:

  • Khi bạn đã bật cache phía trình duyệt (browser cache). Cache phía trình duyệt đã lưu sẵn các tài nguyên tĩnh (như CSS, JS và ảnh) vào trình duyệt của người sử dụng, vì thế nó không cần tải lại lần nữa. Nếu bạn sử dụng critical CSS và nó được nội tuyến (inline) vào tài liệu HTML, người dùng sẽ phải tải lại các đoạn mã critical CSS này khi thực hiện bất cứ yêu cầu tải trang nào. Vì thế, về cơ bản…critical CSS chỉ giúp bạn cho lần ghé thăm đầu tiên (nhưng sẽ làm chậm lại ở những lần ghé thăm tiếp theo của cùng user đó).
  • Khi bạn không có nhiều CSS.
  • Khi bạn không có nhiều nội dung. Có điểm giới hạn bất lợi đạt đến khi bạn chia nhỏ các yêu cầu hơn nữa trong khi bạn không có nhiều nội dung HTML hoặc các yêu cầu tải. Giả sử bạn chỉ có 12 yêu cầu và 1KB nội dung HTML, sẽ không có ý nghĩa khi tạo thêm một yêu cầu HTTP và làm tổn hại thời gian tải trang tổng thể.
  • Khi mà hầu hết CSS của bạn vốn đã được dùng để render nội dung thuộc màn hình đầu tiên rồi. Nếu bạn có file critical CSS là 45KB trên tổng số 50KB CSS của toàn trang, thế thì tại sao bạn phải chia nó thành 2 liên kết?
  • Khi bạn có rất nhiều trang và nó không đáng để máy chủ phải tiến hành xử lý nhằm tạo ra critical CSS cho tất cả chúng
  • Khi bạn không biết cách tạo ra critical CSS thích hợp cho trang của bạn.
  • Khi nó tạo ra các vấn đề về render.

Các câu hỏi thường gặp (về Critical CSS)

Điều gì xảy ra nếu tôi có công cụ pagebuilder? Liệu tôi có thể bật nó (critical CSS) lên sau đó?

  • Việc có công cụ xây dựng trang (pagebuilder) không nhất thiết biến bạn thành ứng cử viên hoàn hảo cho critical CSS. Điều quan trọng nhất là bạn tải hàng tấn CSS phần lớn trong số chúng không cần thiết để render trang. Nhưng ở đây có khó khăn để áp dụng. Phần lớn pagebuilder sử dụng tất cả CSS khổng lồ mà họ tải. Hoặc ở một góc độ khác bạn có một công cụ pagebuilder nhưng không thực sự sử dụng tất cả các tùy chọn điên rồ và không tải nhiều CSS. Trong cả hai kịch bản đó, critical CSS vẫn không được khuyến khích sử dụng.

Tôi có thể thử nó không? Tôi tuyệt vọng trong các thiết lập ngẫu nhiên và hy vọng tăng tốc website của mình.

  • Vâng, bạn có thể làm bất cứ điều gì bạn muốn. Không cần sự cho phép của tôi đâu. Bạn có thể tìm đọc và thấy tất cả những xác nhận mà bạn muốn trên hàng trăm website khác.

Nhưng Google nói rằng tôi có “CSS chặn hiển thị”…

  • CSS một cách tự nhiên được giả định là để chặn hiển thị (để tránh các vấn đề như FOUT/FOUC mà tôi đã đề cập ở phần trên). Tôi nghĩ điều Google muốn nói là CSS của bạn mất quá nhiều thời gian để tải.
  • Bạn không thể ngăn CSS của bên thứ ba chặn hiển thị. Chúng không tải từ máy chủ của bạn. Bạn không thể làm được gì với nó ngoại trừ việc tránh hoặc trì hoãn (defer) các yêu cầu như vậy.

(Dịch từ bài viết: Should you use Critical CSS?, tác giả: Johnny Nguyen, website: WPJohnny)


Lời bàn của người dịch

Johnny Nguyen giúp chúng ta nhận biết các nhược điểm quan trọng của critical CSS, nhưng tôi cho rằng quan điểm của anh ấy có phần cực đoan, vì thực tế phần lớn người quản trị web phải đi mua giao diện và sử dụng hàng tá plugin, ngay cả khi cẩn thận chọn lựa, CSS của những website như vậy vẫn lên đến hàng 100 KB, lúc này rõ ràng critical CSS đóng vai trò giải cứu quan trọng. Điều Johnny Nguyen nói chỉ đúng khi mà tất cả những người sở hữu website cũng đồng thời là người (hoặc đủ tiền thuê) lập trình viên chuyên nghiệp có hiểu biết về tối ưu hóa hiệu suất.

Tôi có một số phản biện:

  • Trừ các website quá phức tạp tôi chưa thử bao giờ, còn với các blog như trang này, tôi thấy các công cụ trích xuất tự động critical CSS vẫn cho ra các mã đủ chính xác để website hoạt động bình thường.
  • Với vấn đề cache, hầu hết người ta chỉ trích xuất một lượng nhỏ critical CSS thôi (nó chỉ dành cho màn hình đầu tiên) để inline, còn phần lớn dung lượng còn lại được cho vào file ngoài, và cái này vẫn được cache bình thường.
Back to Top