[PageSpeed] Các khái niệm nâng cao để đo tốc độ trang

Để hiểu những yếu tố ảnh hưởng đến tốc độ trang web, trước tiên chúng ta cần hiểu cách thức trình duyệt hiển thị một trang web. Nếu bạn chưa quen với tốc độ trang web và các khái niệm công nghệ web như DOM, CSSOM, cây hiển thị (rendering tree), chi phí reflow và các loại DOM, có thể bạn nên bắt đầu bằng việc đọc bài viết được liên kết ở trên.

Khi các trang web và trình duyệt web trở nên phức tạp hơn, tốc độ trang web không chỉ đơn thuần là về độ lớn của một trang web hay tốc độ phản hồi của máy chủ. Trong bài viết này, chúng ta sẽ xem xét một số tiêu chí mới và đang nổi lên để đánh giá tốc độ trang web và những năm tiếp theo: số lượng và kích thước của các tài nguyên được yêu cầu, đường dẫn hiển thị quan trọng (critical rendering path), chỉ số LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift – độ dịch chuyển bố cục), và tổng thời gian chặn (total blocking time).

Bài viết này là bài thứ hai trong loạt bốn bài về tốc độ trang web. Bạn có thể tìm thấy bài viết đầu tiên tại đây: Trình duyệt tạo trang web như thế nào?

Quản lý thứ tự, kích thước và số lượng các yêu cầu tài nguyên

Mỗi bước trong quá trình render đều tốn thời gian. Để xác định phần nào website của bạn chậm và cách tăng tốc, cần xem xét cách trình duyệt xử lý các tài nguyên trong lúc render trang.

Điều này có nghĩa thứ tự, số lượng và kích thước của các yêu cầu đóng vai trò cực kì quan trọng trong đánh giá tốc độ trang hiện nay.

Đóng góp quan trọng nhất của việc tối ưu hóa thứ tự tài nguyên và gợi ý tải tài nguyên là giảm TTI (Time to Interactive – Thời gian cho đến khi tương tác được) thông qua Largest Contentful Paint (LCP – Vẽ nội dung lớn nhất). Với việc tối ưu hóa thứ tự tài nguyên, bạn có thể tải lên các tệp có cùng số lượng và kích thước trong thời gian ngắn hơn, cung cấp chúng nhanh hơn cho người dùng lẫn công cụ tìm kiếm.

Critical Rendering Path (Đường dẫn hiển thị quan trọng) là gì?

Critical Rendering Path bao gồm tất cả các tài nguyên sẽ tạo nên phần trang web phía trên màn hình ban đầu (above the fold).

Trang web của bạn có thể chậm hơn trang đối thủ cạnh tranh do tổng kích thước tải trang. Tuy nhiên, mẹo ở đây là: ngay cả khi các bộ phận khác không cho phép bạn thay đổi kích thước tải trang, bạn vẫn có thể cung cấp nội dung của mình nhanh hơn đối thủ bằng cách tối ưu hóa Critical Rendering Path.

Giải thích thêm:

• Above the fold: Phần của trang web mà người dùng nhìn thấy ngay mà không cần cuộn xuống.
• TTI (Time to Interactive): Thời gian tính từ lúc người dùng truy cập trang đến lúc trang có thể phản hồi với các tương tác (nhấp chuột, cuộn trang, v.v).

Cách tối ưu hóa Critical Rendering Path

Đây là một trình mô phỏng tương quan giữa tốc độ trang web và tỷ lệ chuyển đổi, được tạo ra bởi Sergey Chernyshev. Bạn có thể tìm thấy câu trả lời cho câu hỏi điều gì sẽ xảy ra nếu trang web của tôi tải nhanh hơn 0,5 giây cho người dùng và trình bày điều này cho nhóm phát triển để nhấn mạnh rằng mỗi mili giây cũng có thể cải thiện tỷ lệ chuyển đổi.

Để tối ưu hóa đường dẫn hiển thị quan trọng (critical rendering path), bạn cần xác định những tài nguyên nào cần thiết cho việc hiển thị phần phía trên đầu trang web (above the fold). Sau đó, bạn cần đặt ra một số câu hỏi sau:

• Tài nguyên nào ngăn cản trình duyệt tải xuống các nguồn quan trọng?
• Có thể giảm kích thước và số lượng các nguồn quan trọng được hay không?
• Có thể nội tuyến (inline) các nguồn quan trọng không?
• Có thể hợp nhất các nguồn trong đường dẫn hiển thị quan trọng để hạn chế quá trình tra cứu DNS không?
• Chúng ta sẽ xem xét một ví dụ. Chúng tôi cũng sẽ đưa ra một số khuyến nghị để tăng tốc xử lý CSS, JS và HTML.

Đây là một ví dụ về phần quan trọng (critical part) từ một trang web của Amazon. Với DevTools, bạn có thể thấy phần tử <div> quan trọng nhất trong phần quan trọng của trang cùng với các mã CSS cần thiết. Bằng cách này, bạn có thể tạo một khối mã CSS nội tuyến (inline) trước khi các tài nguyên chặn kết xuất (render blocking resources) làm ảnh hưởng đến trình duyệt. Bạn cũng có thể thấy các chồng mã không sử dụng ở phía dưới. Amazon luôn sử dụng các mẫu tài nguyên CSS/JS giống nhau cho các danh mục khác nhau, ngay cả khi chúng không được tối ưu hóa.

Ngoài tốc độ, còn có một vấn đề khác ở đây. Với các kích thước màn hình điện thoại di động khác nhau, phần quan trọng của trang web thay đổi tùy theo từng model. Một số màn hình không hiển thị giá, một số không hiển thị thông tin kho hàng. Đây là một lỗi thiết kế quan trọng, và nó cũng khiến việc tối ưu hóa đường dẫn kết xuất quan trọng (critical rendering path) trở nên khó khăn hơn. Nó cũng chia nhỏ giá trị PageRank nếu có liên kết trong khu vực này và làm giảm khả năng chuyển đổi.

Bạn có thể sử dụng Puppeteer (Công cụ thu thập thông tin của Googlebot) để kiểm tra loại sự cố này và tự động chụp ảnh màn hình cho từng kiểu điện thoại thông minh/máy tính bảng và kiểm tra thiết kế của phần quan trọng của trang web. Jean-Francois Lagarde có một thư viện Puppeteer hữu ích cho tác vụ này mà bạn có thể muốn thử.

Ảnh chụp màn hình nhanh về tính năng cấu hình thiết bị trong công cụ chụp ảnh tự động Puppeteer cho từng kích thước khung nhìn của thiết bị.

Largest Contentful Paint (LCP) là gì?

Largest Contentful Paint (LCP) là phần nội dung lớn nhất trên một trang web xét về dung lượng (byte) và kích thước. Trong mỗi trang web, có rất nhiều thẻ “div” khác nhau và tất cả chúng đều chứa các thành phần trang khác nhau. Các thành phần này có những giá trị tải trang khác nhau.

Theo Google, Largest Contentful Paint bị ảnh hưởng nhiều nhất bởi thành phần quan trọng nhất của trang. Để bạn hiểu thêm về tầm quan trọng của LCP, Google đã quyết định thêm chỉ số mới này vào báo cáo Lighthouse trong tương lai.

Điều này cũng đồng nghĩa với việc chúng ta sẽ nghe nhiều hơn về LCP, vì nó sẽ được sử dụng cùng với Real User Metrics (RUM) và sẽ là một chỉ số quan trọng, đặc biệt khi liên quan đến đường dẫn kết xuất quan trọng (critical rendering path).

Đây là một ví dụ về Largest Contentful Paint (LCP) từ Lendio. Như bạn có thể thấy, DevTools hiển thị LCP trên một trang cùng với dữ liệu về loại, kích thước và thời gian tải của nó. Nội dung LCP của bạn nên luôn bao gồm mục đích và giá trị của trang, cùng với chức năng hoặc lời kêu gọi hành động (CTA) quan trọng nhất – và đặc biệt, nội dung này cũng nên được tải đầu tiên!

Trong ví dụ này, LCP chỉ là văn bản. Sẽ tốt hơn nếu kết hợp LCP với một công cụ có tính năng nào đó, thay vì chỉ dùng hình ảnh/văn bản đơn thuần.

LCP chỉ xem xét một số loại tài nguyên nhất định. Lý do chính là để giữ cho việc đo lường LCP đơn giản lúc ban đầu. Dưới đây là một “Script Instance” được đóng dấu để tạo danh sách mục nhập LCP. Việc nghiên cứu những đoạn mã này sẽ cho bạn biết Google Developers đang chú ý đến những gì và cách thức họ đánh giá khi tải một trang web.

[Exposed=Window]
interface LargestContentfulPaint : PerformanceEntry {
readonly attribute DOMHighResTimeStamp renderTime;
readonly attribute DOMHighResTimeStamp loadTime;
readonly attribute unsigned long size;
readonly attribute DOMString id;
readonly attribute DOMString url;
readonly attribute Element? element;
[Default] object toJSON();
};

Những gì bạn thấy trong danh sách này là các thang đo cần thiết để so sánh các mục ứng cử viên nằm trong danh sách LCP. Dưới đây, tôi sẽ chỉ cho bạn một phương pháp để chọn các ứng cử viên LCP (“văn bản lớn” và “hình ảnh lớn”).

Hiểu các nguyên tắc và quy trình để xác định LCP

Các nguyên tắc để xác định LCP cực kỳ quan trọng:

• Trong khi trang tải, LCP có thể thay đổi sau vài giây. Đôi khi, ngay cả khi một thành phần trang đã có vai trò là LCP đủ lâu, thì một thành phần lớn hơn được tải sau đó cũng không thay đổi trạng thái trước đó.
• Đôi khi, một phần tử nằm ở phần trên của trang (phần quan trọng của trang web) được chọn làm LCP thay vì một phần tử lớn hơn ở phần dưới (phần không quan trọng của trang web).
• Một phần tử <div> lớn hơn không thể được chọn làm LCP nếu các thành phần bên trong nó bị chia nhỏ trên màn hình. Thay vào đó, một phần tử <div> dạng khối sẽ được chọn làm LCP. Dưới đây bạn sẽ thấy một ví dụ minh họa điều này.

Trong ví dụ này, chúng ta thấy rằng thành phần lớn nhất là thẻ <div> chứa bốn hình ảnh khác nhau. Tuy nhiên, không có hình ảnh riêng lẻ nào lớn hơn Logo Oncrawl và phần văn bản đi kèm bên trong cùng một thẻ <div>. Vì cả hai đều nằm trong phần quan trọng nhất của trang web, yếu tố thứ hai sẽ là LCP (Largest Contentful Paint).

Khi tính toán thời gian LCP và xác định góc nhìn của các nhà phát triển Google, bạn cũng nên chú trọng đến thiết kế “ghép khối”. Nếu một thẻ <div> không có cảm giác/giao diện thiết kế thống nhất, có thể nó sẽ không được chọn làm LCP.

Ngay cả khi được chọn, Google Chrome vẫn có thể cho rằng đây không phải là một LCP lành mạnh, đặc biệt xét đến các mã mới sẽ được thêm vào LCP API trong tương lai. Vì những lý do gắn với UX (trải nghiệm người dùng) và hiểu biết rõ hơn về tốc độ trang, Google sẽ tiếp tục cải thiện nhận thức của chính mình bằng các phương pháp này.

Layout Shifting và Cumulative Layout Shifting là gì?

Layout shifting (xê dịch bố cục) đề cập đến việc các phần tử trang thay đổi vị trí trong quá trình tải xuống bởi trình duyệt, dẫn đến trải nghiệm khó chịu cho người dùng.

Trong khi một trang web đang được tải xuống, từng phần của trang sẽ lần lượt hiển thị theo thứ tự nhất định. Điều này là bình thường. Nhưng nếu các phần này thay đổi vị trí ban đầu do tác động của thành phần tải sau đó, sẽ xảy ra layout shifting.

Cumulative Layout Shifting (CLS) – Xê dịch bố cục tích lũy – là tổng của tất cả các sự kiện layout shifting (xê dịch bố cục).

Báo cáo Chrome User Experience (Trải nghiệm người dùng Chrome) cũng có phần đánh giá về điểm số CLS. Nhưng điều này không chỉ liên quan đến UX. Layout shifting có thể gây hại cho người dùng mắc bệnh động kinh nhạy cảm với ánh sáng. Với tư cách là một “công ty sức khỏe”, Google cũng coi trọng sức khỏe người dùng; họ cố gắng giảm thiểu “căng thẳng trên web” ở bất cứ đâu có thể.

“Tôi tin rằng Google đã là một công ty về sức khỏe. Điều đó đã nằm trong DNA của công ty ngay từ đầu.” David Feinberg – Giám đốc Google Health

Đây là một ví dụ đơn giản và rõ ràng về xáo trộn bố cục từ một trong những trang web mà chúng ta đã xem trước đó trong loạt bài này. Đây là một trang web tin tức chính từ Thổ Nhĩ Kỳ và đây là trang chủ của họ.

Bạn có thể đọc thêm về Xáo trộn bố cục, Nhấp nháy, Thay đổi màu sắc vốn dĩ nguy hiểm cho sức khỏe, trên trang dành cho nhà phát triển của Moz.

Cách tìm Cumulative Layout Shift (tổng điểm xáo trộn bố cục) trên trang web của bạn

Để xem các phần bố cục bị xáo trộn của trang web, bạn có thể sử dụng Google Chrome DevTools hoặc sử dụng Layout Instability API để mở rộng quy mô xử lý cho tất cả các trang web của mình.

Cumulative Layout Shift, hay tổng tất cả các sự kiện xáo trộn bố cục, là một tiêu chí quan trọng của cả tốc độ trang và trải nghiệm người dùng (UX) trong năm 2020 và về sau nữa. Nếu phần trên cùng (above-the-fold) của trang web bị dịch chuyển trong khi tải, bạn cũng cần tối ưu hóa phần đó khi muốn tối ưu hóa tốc độ.

Bên dưới, bạn sẽ tìm thấy Công thức tính điểm Xáo trộn bố cục, cùng một ví dụ Code sử dụng Layout Instability API để cung cấp cho bạn cái nhìn tổng quan về đóng góp của CLS và phương pháp tính toán Điểm xáo trộn bố cục của bạn.

Công thức tính điểm Xáo trộn bố cục như sau:

Điểm xáo trộn bố cục = tỷ lệ ảnh hưởng * tỷ lệ khoảng cách

Điểm xáo trộn bố cục được tính với hai thuật ngữ mới hữu ích: Tỷ lệ ảnh hưởng và Tỷ lệ khoảng cách:

• Tỷ lệ ảnh hưởng là tỷ lệ phần trăm màn hình bị ảnh hưởng bởi sự thay đổi. Bạn biết rằng CLS của bạn sẽ cao nếu phần tử trang, chiếm 50% khung nhìn trên thiết bị di động, gây ra xáo trộn bố cục, bởi vì việc di chuyển phần tử đó ít nhất sẽ tác động đến hơn 50% màn hình.
• Tỷ lệ khoảng cách được đo bằng khoảng cách mà phần tử dịch chuyển ra khỏi điểm gốc của nó theo hướng mà nó dịch chuyển. Nếu khoảng cách giữa vị trí đầu tiên và cuối cùng quá lớn, Tỷ lệ khoảng cách cũng sẽ rất lớn.

Điều này sẽ giúp bạn dễ dàng ước tính Điểm số CLS của mình và đưa ra góp ý cho nhóm CNTT và UX của bạn.

Phía trên, bạn có thể thấy một đoạn mã CLS API và phía dưới, là một GIF minh họa cách tính toán Cumulative Layout Shifting (CLS)

Trên cùng trang tin tức Thổ Nhĩ Kỳ mà chúng ta đã xem xét, điểm CLS của chúng ta là 0,47.

Xét rằng nó được tính toán trong khoảng từ 0 đến 1, đây là một điểm số khá tệ.

Bạn có thể tính điểm CLS của mình bằng Hệ thống Số liệu Tùy chỉnh Nâng cao của Webpagetest.org. Bạn nên sử dụng mã của API CLS cho đến phần “Gửi thông tin.” Sau đó, bạn cần thay đổi URL của mình từ root/results/ thành root/custom_metrics.php?test={Số kết quả tương ứng}.”

Giải thích thêm:

• CLS (Cumulative Layout Shift): Một chỉ số quan trọng dùng để đo lường độ ổn định về mặt trực quan của trang web. Điểm CLS thấp cho thấy trải nghiệm người dùng tốt hơn vì nội dung trên trang ít bị xáo trộn trong quá trình tải.
• Webpagetest.org: Một công cụ miễn phí để kiểm tra hiệu suất trang web, bao gồm tính toán điểm CLS

Total Blocking Time (TBT) là gì?

Bạn có thể tải xuống phần phía trên màn hình hiển thị ban đầu (above the fold) của trang web mình một cách nhanh chóng, không gây thay đổi bố cục trang. Nhưng nếu trang không phản hồi với thao tác người dùng, thuật toán của Google sẽ cho rằng bạn đang gặp một vấn đề khác về trải nghiệm người dùng (UX) và tốc độ trang. Total Blocking Time chính là khoảng thời gian bị mất ở giai đoạn này.

Giống như Cumulative Layout Shifting (CLS – Dịch chuyển Bố cục Tích lũy) và Largest Contentful Paint (LCP – Vẽ nội dung lớn nhất), Total Blocking Time (TBT) là một tiêu chí mới về tốc độ trang và UX đã được áp dụng từ năm 2020.

Các sự kiện tải trang được tính vào Total Blocking Time (TBT) là bất kỳ sự kiện nào diễn ra giữa First Paint (FP – Vẽ ban đầu) và Time to Interactive (TTI – Thời gian tương tác) có thời lượng chặn luồng chính của trình duyệt (hay thiết bị) quá 50 mili giây và ngăn cản người dùng thực hiện thao tác.

Cách tính toán và tối ưu TBT

Bạn có thể tính toán Total Blocking Time (TBT) của mình với Long Tasks API.

Để tối ưu điểm TBT, bạn cũng cần tập trung vào thứ tự và các ưu tiên khi tải tài nguyên, thêm vào đó là số lượng và kích thước các yêu cầu.

Đoạn này được lấy từ cùng một trang web như trước đó. Như bạn có thể nhận thấy, luồng chính (main thread) hoàn toàn bận rộn trong hơn 5 giây liên tục. Chỉ số LCP (Largest Contentful Paint) của họ vẫn đang được tải sau gần 2,5 giây… Điều quan trọng cần lưu ý ở đây là tác vụ (request) dài nhất của họ kéo dài hơn 350 MS. Điều này có nghĩa là nó được coi là đang chặn luồng chính trong hơn 300 MS.

Ngoài ra, tất cả thời gian bị chặn đều được tính là một phần của Tổng thời gian chặn (Total Blocking Time – TBT). Điều này không chỉ bao gồm các yếu tố ở phần hiển thị đầu tiên (above-the-fold), mà còn áp dụng cho tất cả các thành phần của trang web. Nó tạo ra một lịch sử trình duyệt có hại cho trang web của bạn.

Nếu TBT của bạn lớn hơn 300 mili giây, điều này có thể sẽ ảnh hưởng đáng kể đến tỷ lệ giữ chân người dùng và tỷ lệ chuyển đổi của bạn.

Bạn có thể thấy một ví dụ tính toán cho TBT đối với luồng chính (main thread) ở trên. Trong ví dụ này, có bốn yêu cầu. Google Chrome có thể tạo 6 yêu cầu từ cùng một máy chủ tại một thời điểm. Chỉ 50 MS đầu tiên sẽ diễn ra suôn sẻ; sau đó, nhiều tác vụ sẽ bắt đầu được thực hiện cùng một lúc, tùy thuộc vào khả năng của CPU / Mạng. Hãy nhớ rằng, con người có thể nhìn thấy một khung hình sau mỗi 16 MS. Google quan tâm đến từng mili giây đối với người dùng.

Trong ví dụ này, Tổng Thời gian Chặn (Total Blocking Time) là 1 giây 100 MS.

Các bước tiếp theo trong việc tối ưu hóa tốc độ trang

Trong loạt bài này cho đến nay, chúng ta đã xem xét cách các trình duyệt tạo ra các trang web, điều này đã cho phép chúng ta thấy trong bài viết này cách các chỉ số mới liên quan đến cách các trang tải trong trình duyệt có thể ảnh hưởng đến tốc độ trang. Chúng ta đã xem xét một số chỉ số mới hàng đầu cũng như cách đo lường và tối ưu hóa chúng.

Trong bài viết tiếp theo thuộc loạt bài này về tốc độ trang trên các trang web hiện nay, chúng ta sẽ đề cập đến một chủ đề đã trở thành một chủ đề chính trong SEO và phát triển web: tối ưu hóa các tài nguyên JavaScript để cải thiện tốc độ trang và quá trình hiển thị trang.