Tất cả những điều bạn cần biết về Core Web Vitals: Các vấn đề phổ biến nhất và cách khắc phục

Với giai đoạn cuối cùng của đợt triển khai diễn ra vào tháng 8 năm 2021, bản cập nhật Core Web Vitals đã chính thức được áp dụng. Điều này có nghĩa là giờ đây chúng ta có thể chuyển từ các đánh giá sơ bộ sang xác định một số xu hướng phổ biến.

Nghiên cứu chuyên sâu về Core Web Vitals của chúng tôi bao gồm các nội dung sau:

• Dựa trên dữ liệu lịch sử, chúng tôi đánh giá mức độ sẵn sàng của các website trên mobile và desktop trước bản cập nhật, cũng như những giá trị tốt hơn của các chỉ số Core Web Vitals (Largest Contentful Paint, Total Blocking Time* và Cumulative Layout Shift).

• Chúng tôi cũng xác định được những yếu tố quan trọng nhất ảnh hưởng đến hiệu suất của các trang xét theo ba chỉ số này.

• Sử dụng dữ liệu từ công cụ Site Audit, chúng tôi đã xem xét các giá trị trung bình của LCP, TBT và CLS, đồng thời xác định những vấn đề thường gặp nhất ở từng chỉ số.

Với những thông tin này, bạn sẽ có thêm cơ sở để tối ưu hóa các trang nhằm đáp ứng tối đa các tiêu chí CWV, từ đó mang lại trải nghiệm thân thiện nhất cho người dùng và cải thiện thứ hạng.

*Lưu ý: trong Site Audit, chúng tôi sử dụng chỉ số Total Blocking Time (TBT) thay cho First Input Delay (FID), vì chỉ số sau cần có dữ liệu từ người dùng thực. Google cũng cho biết hai chỉ số này có mối tương quan với nhau và đều có thể được dùng để đánh giá các vấn đề về tính tương tác.

Phương pháp nghiên cứu

Nghiên cứu của chúng tôi gồm một số phần:

1. Đánh giá những thay đổi về mức độ đáp ứng tiêu chí CWV trước và sau bản cập nhật.
2. Tìm hiểu các yếu tố ảnh hưởng đến việc một website có đạt ngưỡng của từng chỉ số hay không.
3. Kiểm tra CWV toàn diện các website được phân tích để tìm hiểu những vấn đề thường gặp nhất và ít gặp nhất ở từng chỉ số.

Phần đầu tiên của nghiên cứu dựa trên phân tích 1,7 triệu URL trên desktop và 324 nghìn URL trên mobile. Chúng tôi so sánh các giá trị LCP, TBT và CLS trước bản cập nhật vào tháng 6 năm 2021 với số liệu tháng 9 năm 2021, thời điểm bản cập nhật hoàn tất.

Để thực hiện so sánh, chúng tôi kiểm tra số trang thuộc từng nhóm trong ba mức — “good,” “poor,” “to improve” — đối với mỗi chỉ số trước và sau bản cập nhật.

Chúng tôi cũng đề cập đến điểm số “Any TBT” và “Any CLS”. Những điểm số này chỉ phản ánh giá trị trung bình của các chỉ số trên tất cả URL, không xét đến hiệu suất TBT hoặc CLS của chúng.

Để xác định các yếu tố ảnh hưởng đến từng chỉ số và tìm hiểu lỗi nào xuất hiện thường xuyên hơn, chúng tôi sử dụng dữ liệu kiểm tra tháng 9/2021 của Site Audit trên 4M URL desktop và 1.7M URL mobile. Nhìn chung, công cụ đã kiểm tra các trang này qua 23 bước đánh giá riêng cho CWV.** Nhờ đó, chúng tôi xác định được những bước kiểm tra khó và dễ vượt qua nhất.

Toàn bộ nghiên cứu này dựa trên dữ liệu phòng thí nghiệm.

**Lưu ý: Bạn có thể xem danh sách tất cả các bước kiểm tra, định nghĩa của chúng và phân tích đầy đủ kết quả kiểm tra trên mobile và desktop ở cuối bài viết.

Kết quả nghiên cứu Core Web Vitals trên mobile và desktop

Có bao nhiêu URL cải thiện điểm LCP, TBT và CLS

Các biểu đồ bên dưới cho thấy số trang trên mobile và desktop thực sự đạt ngưỡng tốt đối với ba chỉ số CWV (tổng hợp và riêng lẻ) tính đến tháng 6/2021 so với tháng 9/2021.

Trước bản cập nhật, chỉ 34.5% trang desktop đáp ứng được ngưỡng yêu cầu của cả ba chỉ số. Sau bản cập nhật, số URL desktop đạt điểm “good” ở cả LCP, TBT và CLS tăng 7 điểm phần trăm.

Các URL mobile cho thấy bức tranh kém khả quan hơn: chưa đến 4% trang mobile đạt ngưỡng “good” ở cả ba chỉ số. Vào tháng 6/2021, con số này cao gần gấp ba lần, cho thấy các trang mobile ít sẵn sàng cho bản cập nhật hơn so với các trang desktop tương ứng.

Đánh giá những thay đổi tích cực của các chỉ số CWV trước và sau bản cập nhật

Tuy nhiên, các chỉ số CWV có nhiều mức hơn chỉ điểm “good”. LCP, TBT và CLS có thể thuộc một trong ba nhóm: “Good,” “To improve,” và “Poor”.

Để phân tích những thay đổi sau bản cập nhật chi tiết hơn, chúng tôi kiểm tra tất cả cải thiện ở cả ba chỉ số, xem có bao nhiêu URL đạt được kết quả tốt hơn khi điểm LCP, TBT và CLS chuyển từ nhóm này sang nhóm khác.

Xét những thay đổi tích cực về điểm số trước và sau bản cập nhật, chúng tôi nhận thấy các xu hướng sau:

URL mobile

URL desktop

• Chúng tôi ghi nhận tỷ lệ trang cải thiện tất cả các điểm số ở mọi chỉ số rất thấp — tối đa 0,1%. Tuy nhiên, một phần ba tổng số trang đã cải thiện điểm số ở ít nhất một chỉ số. Điều này đúng với cả URL trên mobile lẫn desktop.

• Trên mobile, thay đổi phổ biến nhất ở cả ba chỉ số là chuyển từ mức “poor” sang “to improve”. URL trên desktop cho thấy xu hướng tích cực hơn: phần lớn điểm số LCP, TBT và CLS chuyển từ mức “to improve” sang “good”.

• Trên mobile, việc chuyển thẳng từ “poor” sang “good” dường như gần như bất khả thi, chỉ có một ngoại lệ. CLS có vẻ là ngưỡng dễ vượt qua nhất để chuyển thẳng từ “poor” sang “good”, và nhiều trang đã cải thiện đáng kể điểm CLS.

Chúng tôi thu thập những thông tin này sau khi Google hạ ngưỡng CLS, vì vậy việc ngưỡng này có vẻ dễ đạt hơn có lẽ liên quan đến thay đổi đó.

• Các trang mobile có ít thay đổi tích cực nhất về LCP, trong khi với URL trên desktop, TBT dường như là thách thức lớn nhất, với tỷ lệ thay đổi tích cực thấp nhất — 6,7%.

Các yếu tố ảnh hưởng đến điểm số LCP, TBT và CLS

Phân tích kỹ hơn các yếu tố của từng chỉ số, chúng tôi đã xác định được những yếu tố ảnh hưởng đến các điểm số này.

Nguyên nhân khiến điểm LCP kém

LCP đo thời gian tải của phần tử lớn nhất trên trang — hình ảnh hoặc khối văn bản — trong khung nhìn của người dùng, nên những gì nằm ngoài màn hình sẽ không được tính.

Vì vậy, chúng tôi xem xét sự hiện diện hoặc vắng mặt của các phần tử sau trên những trang được phân tích:

• thẻ <img> là hình ảnh, ảnh xem trước video, hình nền, v.v.;
• thẻ <div> / <section> đại diện cho mọi phần tử (vùng chứa) trên trang;
• thẻ <p> là một đoạn văn bản;
• thẻ <span> thường chỉ một dạng phần tử văn bản nào đó; và
• thẻ <h1> / <h2> / <h3> dùng để biểu thị các tiêu đề và tiêu đề phụ khác nhau trên trang.

Phân tích của chúng tôi cho thấy thẻ <img> và <div> là những phần tử phổ biến nhất gây ra tình trạng LCP chậm.

Tuy nhiên, nếu xem xét kỹ hơn, chúng ta sẽ thấy có thêm khác biệt giữa các phần tử thẻ trên mobile và desktop ảnh hưởng đến điểm số LCP.

• Thẻ <img> và <div> chủ yếu là vấn đề đối với URL mobile có LCP ở mức “poor”. Các trang mobile có LCP ở mức “good” và “to improve” thường bị ảnh hưởng nhiều nhất bởi thẻ <p> và <img>.
• H1 bắt đầu trở thành vấn đề trên mobile, có lẽ vì h1 là một trong những phần tử lớn nhất trong khung nhìn khi màn hình nhỏ hơn.

Điều này có nghĩa là phần tử được xem là lớn nhất trên mobile có thể khác với phần tử lớn nhất trên desktop.

Bạn có thể dùng công cụ Site Audit để xác định chính xác phần tử nào trên trang được xem là phần tử có nội dung lớn nhất trong khung nhìn ở trường hợp cụ thể của mình.

Những yếu tố ảnh hưởng đến điểm TBT

Vì TBT đo lường tốc độ người dùng có thể bắt đầu tương tác với các phần tử trên trang, chúng tôi đã phải xem xét các tác vụ dài.

Vì long tasks là một phần của JavaScript code khiến UI bị treo, để đạt điểm TBT “good”, bạn cần giữ tổng TBT dưới 300 ms.

Dù bạn có thể có bao nhiêu long tasks tùy ý (miễn là không vượt ngưỡng 300 ms), vẫn đáng chú ý khi các trang trên cả mobile lẫn desktop đạt điểm TBT “good” đều có số lượng long tasks thấp nhất:

Trung bình, một trang desktop có điểm TBT “poor” có số long tasks nhiều gấp 6 lần so với các trang thuộc nhóm “good”. Trên mobile, chênh lệch này khiêm tốn hơn — gấp ba lần.

Những yếu tố ảnh hưởng đến điểm CLS

Chỉ số CLS đo lường độ ổn định về mặt hiển thị của trang và phụ thuộc nhiều vào layout shifts xuất hiện mỗi khi vị trí của một phần tử đang hiển thị thay đổi giữa hai khung hình được kết xuất liên tiếp.

Tương tự TBT, layout shifts phụ thuộc vào mức độ dịch chuyển chứ không phải số lần dịch chuyển. Và nếu TBT chưa cho thấy điều này một cách trực tiếp, thì phân tích CLS của chúng tôi đã làm rõ:

Chúng tôi không thấy sự khác biệt lớn về số lượng layout shifts giữa các trang có điểm CLS khác nhau. Điều này có nghĩa là bạn vẫn có thể có khá nhiều lần dịch chuyển, miễn là chúng nằm trong ngưỡng cho phép.

Các vấn đề Core Web Vitals phổ biến nhất và cách khắc phục

Dù đã xác định được những yếu tố hàng đầu ảnh hưởng đến điểm CWV của các trang, điều đó không có nghĩa đây là những vấn đề cấp bách nhất đối với chủ sở hữu website.

Đây là lúc báo cáo Core Web Vitals của Site Audit phát huy tác dụng, giúp xác định những bước kiểm tra khó vượt qua nhất.

Công cụ Site Audit kiểm tra mỗi trang qua 23 bước khác nhau, áp dụng logic của Pagespeed Insights và xem xét:

• Nếu điểm kiểm tra vượt mốc 90, trang sẽ nằm trong vùng xanh và chúng tôi xem bước kiểm tra này là đạt;
• Điểm từ 50 đến 89 đưa trang vào vùng vàng; và
• Nếu giá trị dưới 49, trang sẽ chuyển sang vùng đỏ ở bước kiểm tra tương ứng.

Nhìn tổng thể, chúng ta có thể thấy các trang mobile gặp nhiều vấn đề về CWV hơn đáng kể. Các URL desktop có vẻ vượt qua các bước kiểm tra CWV khá tốt, với phần lớn — 68% — kết quả nằm trong vùng xanh.

Khác với desktop, nơi phần lớn các lượt kiểm tra đều đạt, trên mobile chỉ có 34% lượt kiểm tra hiển thị màu xanh. Đáng lo ngại là 65% tổng số lần audit có kết quả màu vàng hoặc đỏ, nghĩa là các trang mobile không đáp ứng yêu cầu CWV ở những lượt kiểm tra này.

Hãy xem xét kỹ hơn tất cả các lượt kiểm tra và tìm ra ba lượt dễ đạt nhất cũng như ba lượt khó đạt nhất trên cả trang mobile lẫn desktop.

Các mục đứng đầu gần như giống nhau, dù là URL desktop hay mobile:

• Các phần tử hình ảnh không có chiều rộng và chiều cao được xác định rõ ràng dường như là vấn đề lớn nhất đối với cả trang mobile lẫn desktop.
• Các module trùng lặp trong gói JavaScript, nhiều lần chuyển hướng trang và việc sử dụng định dạng video cho nội dung động hiệu quả thường vượt qua các lượt kiểm tra mà không gặp nhiều vấn đề, thậm chí không gặp vấn đề nào.
• Tuy nhiên, khi nói đến việc loại bỏ các tài nguyên chặn hiển thị, sự khác biệt rất rõ rệt: URL desktop gần như vượt qua lượt kiểm tra này, trong khi URL mobile chỉ vừa chạm đến vùng màu vàng.

Site Audit không chỉ phát hiện vấn đề trên tất cả các chỉ số mà còn phân loại chúng thành các vấn đề liên quan đến LCP, CLS và TBT.

Hãy xem kỹ phần phân tích từng chỉ số về những vấn đề phổ biến nhất trên các trang cụ thể của bạn, vì Site Audit mô tả vấn đề theo cách đồng thời đưa ra giải pháp.

Tổng kết

Khi Core Web Vitals Update đã có hiệu lực, bạn cần cải thiện điểm số ở cả ba chỉ số — CLS, LCP và TBT — để cho Google thấy rằng các trang của bạn mang lại trải nghiệm thân thiện tối ưu cho người dùng và xứng đáng có được thứ hạng đó.

Chúng tôi hy vọng nghiên cứu bao quát nhiều khía cạnh và hé lộ những thông tin quan trọng này sẽ cung cấp hướng dẫn rõ ràng, giúp bạn tiếp tục nỗ lực tối ưu hóa.

Dù khuyến khích bạn xem lại tất cả những phát hiện, có một vài điều bạn nên ghi nhớ từ nghiên cứu này:

1. Web vẫn chưa sẵn sàng hoàn toàn cho CWV.

Chỉ một phần ba số URL desktop và 3% số URL mobile đạt ngưỡng ở cả ba chỉ số CWV.

Kể từ bản cập nhật, chúng tôi chỉ ghi nhận mức cải thiện trên diện rộng ở khoảng 1% số trang. Chưa đến 40% có điểm số tốt hơn ở ít nhất một chỉ số.

Điều này có nghĩa là bạn có nhiều cơ hội cải thiện. Nếu được thực hiện đúng cách và sớm, nỗ lực tối ưu hóa trang có thể tạo lợi thế cạnh tranh cho các trang của bạn.

2. Đặc biệt chú ý đến các trang mobile.

Phần lớn lượt kiểm tra trên desktop có kết quả màu xanh (tức là đạt), trong khi trên mobile, chúng tôi chủ yếu thấy màu vàng và đỏ. Điều này có nghĩa là vượt qua các lượt audit trên desktop dễ hơn mobile; trung bình, trang mobile gặp nhiều vấn đề hơn trang desktop.

Nhiều khả năng nguyên nhân là do ngưỡng dành cho mobile và dữ liệu lab được mô phỏng trên thiết bị 3G.

3. Cải thiện điểm LCP (trên mobile) và TBT (trên desktop).

Vì CLS là chỉ số ít gây “vấn đề” nhất, bạn cần cải thiện điểm LCP và TBT:

• Các cải thiện về CLS có nhiều khả năng giúp bạn nhanh chóng chuyển từ mức điểm “poor” sang “good”.
• Kiểm tra các thẻ <img>, <div>, <p> và <h1> để đảm bảo chúng không làm giảm điểm LCP của bạn. Dùng công cụ Site Audit để xác định chính xác các phần tử trên trang gây chậm.
• Giữ tổng thời gian chặn ở mức không quá 300 ms để đảm bảo điểm TBT “good”. Một lần nữa, công cụ Site Audit sẽ giúp bạn xác định những tác vụ dài ảnh hưởng nhiều nhất đến điểm TBT tổng thể.

• Theo dõi mức độ dịch chuyển bố cục và loại bỏ những dịch chuyển chiếm quá nhiều ngưỡng CLS. Site Audit thể hiện mức đóng góp CLS của từng lần dịch chuyển bố cục lớn nhất.

4. 
   Chú ý đến chiều cao và chiều rộng của các phần tử hình ảnh cũng như những vấn đề CWV phổ biến khác.
   Hãy xem lại những mục kiểm tra khó vượt qua nhất. Phần lớn vấn đề — trên cả URL mobile lẫn desktop — đều liên quan đến kích thước hình ảnh. Vì đây là mục kiểm tra liên quan đến CLS và có thể khắc phục khá nhanh, bạn có thể xem đây là một thành quả nhanh chóng để cải thiện điểm CLS.

5. Hãy đặt kỳ vọng hợp lý.

Với desktop, thay đổi phổ biến nhất là chuyển từ mức “to improve” sang “good”. Tuy nhiên, phần lớn URL mobile chỉ chuyển từ mức “poor” sang “to improve”, ngoại trừ CLS. Vì vậy, đừng kỳ vọng nhanh chóng chuyển tất cả điểm “poor” thành “good” ở mọi chỉ số CWV, đồng thời hãy theo dõi mọi thay đổi về ngưỡng.

Bonus: Danh sách đầy đủ các vấn đề CWV phổ biến nhất trên URL mobile và desktop

Nếu muốn khám phá danh sách đầy đủ các mục kiểm tra của Site Audit và xem điểm trung bình của các trang mobile và desktop, hãy rê chuột đến bảng bên dưới để có cái nhìn tổng quan.

Điểm kiểm tra trung bình

Để tiện cho bạn, chúng tôi bổ sung ghi chú của Google cho từng mục kiểm tra:

1. Giảm thời gian thực thi JavaScript: Khi JavaScript mất nhiều thời gian để thực thi, hiệu suất trang sẽ chậm lại theo nhiều cách, chẳng hạn như tăng chi phí mạng, chi phí phân tích cú pháp và biên dịch, chi phí thực thi hoặc chi phí bộ nhớ;
2. Tránh DOM có kích thước quá lớn: Cây DOM lớn có thể làm chậm hiệu suất trang theo nhiều cách, chẳng hạn như ảnh hưởng đến hiệu quả mạng và hiệu suất tải, hiệu suất khi chạy cũng như hiệu suất bộ nhớ;
3. Xóa các module trùng lặp trong JavaScript bundles: JavaScript bundles trên phần lớn trang web thường được tạo bằng cách nhập code từ các thư viện, dependency và package phổ biến. Điều này thường khiến trang của bạn có các module trùng lặp từ nhiều nguồn;
4. Dùng định dạng video cho nội dung động: GIF lớn không phải là định dạng hiệu quả để phân phối nội dung động, vì vậy tốt hơn hết bạn nên dùng định dạng video
5. Đảm bảo văn bản vẫn hiển thị trong khi webfont tải: Font thường là các tệp lớn và mất một lúc mới tải xong. Một số trình duyệt ẩn văn bản cho đến khi font tải xong, khiến văn bản tạm thời không hiển thị;
6. Tránh cung cấp JavaScript cũ cho các trình duyệt hiện đại: Tránh cung cấp code JavaScript cũ (tức tiêu chuẩn ES5) cho các trình duyệt hiện đại để người dùng không phải tải xuống những tệp JavaScript lớn không cần thiết;
7. Giảm thiểu tác vụ trên main thread: Tiến trình renderer của trình duyệt chuyển code của bạn thành trang web để người dùng có thể tương tác. Theo mặc định, main thread của tiến trình renderer thường xử lý phần lớn code: phân tích cú pháp HTML và xây dựng DOM, phân tích cú pháp CSS và áp dụng các kiểu được chỉ định, đồng thời phân tích cú pháp, đánh giá và thực thi JavaScript;
8. Tránh chuyển hướng trang nhiều lần: Redirect làm chậm tốc độ tải trang;
9. Loại bỏ các tài nguyên chặn render: Phần Opportunities trong báo cáo Lighthouse liệt kê tất cả URL đang chặn lần hiển thị đầu tiên của trang. Mục tiêu là giảm ảnh hưởng của những URL chặn render này bằng cách nhúng trực tiếp các tài nguyên thiết yếu, trì hoãn tài nguyên không thiết yếu và xóa mọi thứ không được sử dụng;
10. Giảm thời gian phản hồi của máy chủ: Phần Opportunities trong báo cáo Lighthouse cho biết Time to First Byte, tức khoảng thời gian trình duyệt của người dùng cần để nhận byte đầu tiên của nội dung trang;
11. Lazy load tài nguyên bên thứ ba bằng facade: Tài nguyên bên thứ ba thường được dùng để hiển thị quảng cáo hoặc video và tích hợp với mạng xã hội. Cách làm mặc định là tải tài nguyên bên thứ ba ngay khi trang tải, nhưng việc này có thể khiến trang tải chậm không cần thiết. Nếu nội dung bên thứ ba không thiết yếu, bạn có thể giảm ảnh hưởng đến hiệu suất bằng cách lazy load nội dung đó;
12. Giảm ảnh hưởng của code bên thứ ba: Để thêm mạng quảng cáo, nút mạng xã hội, thử nghiệm A/B hoặc dịch vụ phân tích vào trang, bạn thường cần thêm tập lệnh của bên thứ ba vào HTML. Những tập lệnh này có thể ảnh hưởng đáng kể đến hiệu suất tải trang;
13. Tránh tải lượng dữ liệu mạng quá lớn: Tải lượng dữ liệu mạng lớn có mối tương quan chặt chẽ với thời gian tải lâu. Chúng cũng khiến người dùng tốn tiền; chẳng hạn, người dùng có thể phải trả thêm phí cho dữ liệu di động. Vì vậy, giảm tổng dung lượng các yêu cầu mạng của trang sẽ cải thiện trải nghiệm của người dùng trên website và giúp họ tiết kiệm chi phí;
14. Rút gọn CSS: Mục Opportunities trong báo cáo Lighthouse liệt kê tất cả các tệp CSS chưa được rút gọn, cùng với mức dung lượng có thể tiết kiệm tính bằng kibibyte (KiB) khi rút gọn các tệp này;
15. Rút gọn JavaScript: Rút gọn các tệp JavaScript có thể giảm kích thước payload và thời gian phân tích cú pháp tập lệnh;
16. Hình ảnh chưa được khai báo kích thước: Hình ảnh trông vẫn ổn, nhưng đang tiêu tốn dữ liệu của người dùng và làm giảm hiệu suất trang;
17. Xóa các quy tắc CSS không sử dụng: Mục Opportunities trong báo cáo Lighthouse liệt kê tất cả stylesheet có CSS không được sử dụng, với mức tiết kiệm tiềm năng từ 2 KiB trở lên. Hãy xóa CSS không dùng để giảm số byte không cần thiết phát sinh từ hoạt động mạng;
18. Xóa JavaScript không sử dụng: JavaScript không sử dụng có thể làm chậm tốc độ tải trang;
19. Thiết lập kết nối trước đến các nguồn cần thiết.: Mục Opportunities trong báo cáo Lighthouse liệt kê tất cả yêu cầu quan trọng chưa ưu tiên các yêu cầu tải bằng <link rel=preconnect>;
20. Bật tính năng nén văn bản: Các tài nguyên dạng văn bản nên được phân phối dưới dạng nén để giảm tổng số byte truyền qua mạng.