Tìm hiểu lý do tại sao các công cụ theo dõi chỉ số Core Web Vitals có thể báo cáo những con số khác nhau và cách diễn giải những điểm khác biệt đó.
Google cung cấp một số công cụ để giúp chủ sở hữu trang web giám sát điểm số Core Web Vitals của họ. Các công cụ này thuộc hai danh mục chính:
- Công cụ báo cáo dữ liệu phòng thí nghiệm – dữ liệu được thu thập trong môi trường có kiểm soát cài đặt thiết bị và mạng đã xác định trước.
- Công cụ báo cáo dữ liệu thực địa – dữ liệu được thu thập từ những người dùng thực đang truy cập trang web của bạn.
Vấn đề là đôi khi dữ liệu do các công cụ trong phòng thí nghiệm báo cáo có thể hơi khác với dữ liệu do công cụ tại hiện trường báo cáo! Dữ liệu phòng thí nghiệm của bạn có thể cho biết rằng trang web của bạn hoạt động hiệu quả, nhưng dữ liệu thực tế cho thấy trang web này cần cải tiến. Ngoài ra, dữ liệu trường của bạn có thể cho biết tất cả các trang đều tốt, nhưng dữ liệu phòng thí nghiệm của bạn có thể báo cáo điểm rất thấp.
Ví dụ thực tế sau đây về một báo cáo PageSpeed Insights của web.dev cho thấy rằng trong một số trường hợp, dữ liệu phòng thí nghiệm và dữ liệu thực địa có thể khác nhau trên tất cả Các chỉ số Chỉ số quan trọng của trang web:
Sự khác biệt giữa các công cụ là một nguyên nhân dễ gây nhầm lẫn đối với nhà phát triển. Bài đăng này giải thích các nguyên nhân chính có thể dẫn đến sự khác biệt này tồn tại (cùng với các ví dụ cụ thể bao gồm từng chỉ số Core Web Vitals) và bạn cần làm gì khi thấy sự khác biệt trên trang của mình.
Dữ liệu phòng thí nghiệm so với dữ liệu thực địa
Để hiểu lý do khiến các công cụ trong phòng thí nghiệm và tại hiện trường có thể báo cáo các giá trị khác nhau – ngay cả đối với cùng một trang web—bạn cần hiểu sự khác biệt giữa phòng thí nghiệm và trường .
Dữ liệu của phòng thí nghiệm
Dữ liệu phòng thí nghiệm được xác định bằng cách tải một trang web trong môi trường được kiểm soát bằng nhóm điều kiện mạng và thiết bị được xác định trước. Những điều kiện này được gọi là phòng thí nghiệm, đôi khi còn được gọi là môi trường tổng hợp.
Các công cụ của Chrome báo cáo dữ liệu của phòng thí nghiệm thường đang chạy Lighthouse.
Mục đích của xét nghiệm trong phòng thí nghiệm là kiểm soát càng nhiều yếu tố càng tốt, do đó kết quả nhất quán (nhiều nhất có thể) và có thể tái tạo từ khi chạy đến khi chạy.
Dữ liệu trường
Dữ liệu trường được xác định bằng cách theo dõi tất cả người dùng truy cập vào một trang và đo lường một tập hợp các chỉ số hiệu suất nhất định cho từng người dùng đó cá nhân của bạn. Bởi vì dữ liệu trường dựa trên số lượt truy cập của người dùng thực, nên dữ liệu này phản ánh thiết bị thực tế, điều kiện mạng và vị trí địa lý của người dùng.
Dữ liệu trường còn thường được gọi là Giám sát người dùng thực (RUM); hai điều kiện có thể thay thế cho nhau.
Những công cụ của Chrome báo cáo dữ liệu thực tế tại chỗ thường lấy dữ liệu đó từ Chrome Báo cáo trải nghiệm người dùng (CrUX). Chủ sở hữu trang web cũng nên thu thập dữ liệu thực địa" (và được khuyến nghị) vì công cụ này có thể mang lại thông tin chi tiết hữu ích hơn so với việc chỉ sử dụng CrUX.
Điều quan trọng nhất cần hiểu về dữ liệu trường là không chỉ là một số, đó là sự phân phối của các số. Điều đó có nghĩa là đối với một số người truy cập trang web của bạn, trang web có thể tải rất nhanh, trong khi đối với những người dùng khác, trang web có thể tải rất chậm. Dữ liệu thực địa của trang web là tập hợp hoàn chỉnh gồm tất cả dữ liệu về hiệu suất thu thập được từ người dùng của bạn.
Ví dụ: báo cáo CrUX cho thấy sự phân phối các chỉ số hiệu suất thực tế Người dùng Chrome trong khoảng thời gian 28 ngày. Nếu nhìn vào hầu hết các báo cáo CrUX, bạn có thể thấy rằng một số người dùng truy cập vào trang web có thể có trải nghiệm rất tốt trong khi những người khác có thể có trải nghiệm rất kém.
Nếu một công cụ báo cáo một số duy nhất cho một chỉ số nhất định, công cụ đó thường đại diện cho một điểm cụ thể trong phân phối. Công cụ báo cáo Web cốt lõi Điểm số tại hiện trường của Vitals làm như vậy bằng cách sử dụng phân vị.
Khi xem LCP từ dữ liệu trường trong ảnh chụp màn hình ở trên, bạn có thể thấy nơi phân phối:
- 88% số lượt truy cập có LCP là 2,5 giây trở xuống (tốt).
- 8% lượt truy cập nhận thấy LCP trong khoảng từ 2,5 đến 4 giây (cần cải thiện).
- 4% số lượt truy cập nhận thấy LCP lớn hơn 4 giây (kém).
Ở phân vị thứ 75, LCP là 1,8 giây:
Dữ liệu thử nghiệm trên cùng một trang cho thấy giá trị LCP là 3 giây. Trong khi giá trị này lớn hơn 1,8 giây hiển thị trong dữ liệu trường, thì đó vẫn là LCP hợp lệ giá trị cho trang này—đó là một trong nhiều giá trị tạo nên phân phối đầy đủ trải nghiệm tải.
Tại sao dữ liệu thực tế và dữ liệu phòng thí nghiệm khác nhau
Như phần trên giải thích, dữ liệu phòng thí nghiệm và dữ liệu thực địa đo lường những thứ khác nhau.
Dữ liệu trường bao gồm nhiều điều kiện về mạng và thiết bị cũng như vô số loại hành vi của người dùng. Ngoài ra, điều này còn bao gồm mọi yếu tố khác ảnh hưởng đến trải nghiệm người dùng, chẳng hạn như các biện pháp tối ưu hoá trình duyệt như bộ nhớ đệm cho thao tác tiến/lùi (bfcache) hoặc các tính năng tối ưu hoá nền tảng như Bộ nhớ đệm AMP.
Ngược lại, dữ liệu của phòng thí nghiệm chủ động giới hạn số lượng biến có liên quan. Đáp xét nghiệm trong phòng thí nghiệm bao gồm:
- Một thiết bị...
- kết nối với một mạng...
- chạy từ một vị trí địa lý duy nhất.
Các chi tiết cụ thể của bất kỳ xét nghiệm cụ thể nào trong phòng thí nghiệm có thể phản ánh chính xác hoặc không phản ánh chính xác Phân vị thứ 75 của dữ liệu trường cho một trang hoặc trang web nhất định.
Môi trường được kiểm soát của phòng thí nghiệm này rất hữu ích khi gỡ lỗi sự cố hoặc kiểm thử trước khi triển khai phát hành công khai, nhưng khi bạn kiểm soát các yếu tố này bạn rõ ràng không thể hiện phương sai mà bạn thấy trong thế giới thực trên tất cả các loại mạng, khả năng của thiết bị hoặc vị trí địa lý. Bạn cũng thường không nắm bắt được tác động về hiệu suất từ hành vi của người dùng thực, chẳng hạn như cuộn, chọn văn bản hoặc nhấn vào các phần tử trên trang.
Ngoài sự không liên kết có thể xảy ra giữa điều kiện phòng thí nghiệm và điều kiện của hầu hết người dùng trong thế giới thực, cũng có một số khác biệt nhỏ hơn điều quan trọng cần hiểu để hiểu rõ nhất về phòng thí nghiệm của bạn và dữ liệu thực địa, cũng như mọi điểm khác biệt bạn có thể tìm thấy.
Một số phần tiếp theo sẽ đi sâu vào chi tiết, nêu bật những lý do phổ biến nhất dẫn đến vấn đề này có thể là sự khác biệt giữa dữ liệu phòng thí nghiệm và dữ liệu thực địa đối với từng trang Web chính Các chỉ số quan trọng:
- Nội dung lớn nhất hiển thị (LCP)
- Lượt tương tác với nội dung hiển thị tiếp theo (INP)
- Điểm số tổng hợp về mức thay đổi bố cục (CLS)
LCP (Thời gian hiển thị nội dung lớn nhất)
Các phần tử LCP khác nhau
Phần tử LCP được xác định trong một thử nghiệm trong phòng thí nghiệm có thể không giống với LCP mà người dùng nhìn thấy khi truy cập trang của bạn.
Nếu bạn chạy báo cáo Lighthouse cho một trang nhất định, trang đó sẽ trả về cùng một giá trị phần tử LCP. Nhưng nếu bạn xem dữ liệu trường cho cùng một trang, bạn thường sẽ thấy nhiều phần tử LCP khác nhau, tuỳ thuộc vào số trường hợp cụ thể cho mỗi lượt truy cập trang.
Ví dụ: tất cả các yếu tố sau đây đều có thể đóng góp vào một LCP khác phần tử được xác định cho cùng một trang:
- Kích thước màn hình thiết bị khác nhau dẫn đến các thành phần khác nhau hiển thị trong khung nhìn.
- Nếu người dùng đã đăng nhập hoặc nếu nội dung được cá nhân hoá xuất hiện trong thì phần tử LCP có thể rất khác nhau giữa người dùng.
- Tương tự như điểm trước, nếu thử nghiệm A/B đang chạy trên trang thì khiến các phần tử hiển thị rất khác nhau.
- Bộ phông chữ đã cài đặt trên hệ thống của người dùng có thể ảnh hưởng đến kích thước văn bản trên trang (và do đó yếu tố nào là phần tử LCP).
- Các thử nghiệm trong phòng thí nghiệm thường được chạy trên "cơ sở" của trang URL—không có bất kỳ tham số truy vấn nào hoặc mảnh băm được thêm vào. Nhưng trong thế giới thực, người dùng thường chia sẻ URL có chứa mã nhận dạng mảnh hoặc mảnh văn bản, do đó, phần tử LCP có thể thực sự ở giữa hoặc cuối trang (thay vì "phía trên gập").
Vì LCP trong trường này được tính là phân vị thứ 75 của tất cả lượt truy cập của người dùng vào một trang nếu phần lớn những người dùng đó có phần tử LCP đã tải rất nhanh (ví dụ: một đoạn văn bản được kết xuất bằng phông chữ hệ thống), sau đó ngay cả khi một số người dùng đó có LCP lớn hình ảnh tải chậm thì có thể không ảnh hưởng đến điểm số của trang nếu điểm số đó xảy ra dưới 25% khách truy cập.
Hoặc, điều ngược lại có thể đúng. Thử nghiệm trong phòng thí nghiệm có thể xác định một khối dưới dạng phần tử LCP vì phần tử này mô phỏng một chiếc điện thoại Moto G4 có khung nhìn tương đối nhỏ và hình ảnh chính của trang ban đầu được hiển thị ngoài màn hình. Mặc dù vậy, dữ liệu thực địa của bạn có thể bao gồm phần lớn người dùng Pixel XL có màn hình lớn hơn, nên đối với chúng, hình ảnh chính tải chậm là phần tử LCP của chúng.
Ảnh hưởng của trạng thái bộ nhớ đệm đến LCP
Các thử nghiệm trong phòng thí nghiệm thường tải một trang bằng bộ nhớ đệm nguội, nhưng khi người dùng thực truy cập trang đó, họ có thể đã lưu một số tài nguyên của trang đó trong bộ nhớ đệm.
Vào lần đầu tiên người dùng tải một trang, trang đó có thể tải chậm, nhưng nếu trang đó đã được định cấu hình đúng cách bộ nhớ đệm, vào lần tiếp theo người dùng trả lại trang có thể tải ngay lập tức.
Mặc dù một số công cụ trong phòng thí nghiệm hỗ trợ nhiều lần chạy trên cùng một trang (để mô phỏng trải nghiệm của khách truy cập cũ), thì công cụ trong phòng thí nghiệm không thể biết được tỷ lệ phần trăm số lượt truy cập trong thế giới thực của người dùng mới so với người dùng cũ.
Trang web có cấu hình bộ nhớ đệm được tối ưu hoá tốt và có nhiều khách truy cập quay lại có thể phát hiện ra rằng LCP trong thế giới thực của họ nhanh hơn nhiều so với dữ liệu trong phòng thí nghiệm.
Tối ưu hoá AMP hoặc Signed Exchange
Trang web được tạo bằng AMP hoặc sử dụng cơ chế Trao đổi có chữ ký (SXG) có thể được các công cụ tổng hợp nội dung như Google tải trước Tìm kiếm. Điều này có thể giúp cải thiện đáng kể hiệu suất tải cho người dùng truy cập vào các trang của bạn từ các nền tảng đó.
Ngoài khả năng tải trước trên nhiều nguồn gốc, bản thân các trang web cũng có thể tải trước nội dung cho các trang tiếp theo trên trang web của họ, Điều này cũng có thể cải thiện LCP cho các trang đó.
Các công cụ trong phòng thí nghiệm không mô phỏng lợi ích thu được từ những phương pháp tối ưu hoá này, và ngay cả khi có nghĩa là họ không thể biết được tỷ lệ phần trăm lưu lượng truy cập của bạn đến từ nền tảng như Google Tìm kiếm so với các nguồn khác.
Ảnh hưởng của bfcache đối với LCP
Khi các trang được khôi phục từ bfcache, trải nghiệm tải sẽ gần tức thì và những trải nghiệm này có trong trường của bạn .
Các thử nghiệm trong phòng thí nghiệm không xem xét đến bfcache, vì vậy, nếu các trang của bạn phù hợp với bộ nhớ đệm, thì khả năng giúp điểm số LCP nhanh hơn được báo cáo trong trường.
Ảnh hưởng của sự tương tác của người dùng đến LCP
LCP xác định thời gian kết xuất của hình ảnh hoặc khối văn bản lớn nhất trong khung nhìn, nhưng phần tử lớn nhất đó có thể thay đổi khi trang được tải hoặc nếu mới nội dung được thêm tự động vào khung nhìn.
Trong phòng thí nghiệm, trình duyệt sẽ đợi cho đến khi trang được tải đầy đủ trước khi xác định phần tử LCP là gì. Nhưng trong trường, trình duyệt sẽ dừng theo dõi các phần tử lớn hơn sau khi người dùng cuộn hoặc tương tác với trang.
Điều này là hợp lý (và cần thiết) vì người dùng thường chờ đợi tương tác với một trang cho đến khi trang đó "xuất hiện" chính xác là nội dung mà LCP để phát hiện. Việc cân nhắc các thành phần được thêm vào cũng sẽ không hợp lý khung nhìn sau khi người dùng tương tác vì các phần tử đó có thể chỉ được tải vì một việc gì đó mà người dùng đã làm.
Tuy nhiên, ngụ ý của việc này là dữ liệu trường cho một trang có thể báo cáo nhanh hơn LCP, tuỳ thuộc vào hành vi của người dùng trên trang đó.
INP
INP đòi hỏi tương tác người dùng thực
Chỉ số INP đo lường mức độ phản hồi của một trang đối với tương tác của người dùng, khi người dùng thực sự chọn tương tác với ứng dụng.
Phần thứ hai của câu đó rất quan trọng vì các xét nghiệm trong phòng thí nghiệm, thậm chí là những thử nghiệm để hỗ trợ hành vi của người dùng theo tập lệnh, không thể dự đoán chính xác thời điểm người dùng sẽ chọn tương tác với một trang và do đó không thể đo lường FID chính xác.
TBT không xem xét hành vi của người dùng
Chỉ số trong phòng thí nghiệm Tổng thời gian chặn (TBT) nhằm giúp chẩn đoán các vấn đề liên quan đến INP vì chỉ số này định lượng mức độ mà luồng chính bị chặn trong quá trình tải trang.
Ý tưởng là các trang có nhiều JavaScript đồng bộ hoặc các trang thao tác kết xuất có nhiều khả năng có luồng chính bị chặn khi người dùng tương tác lần đầu tiên. Tuy nhiên, nếu người dùng đợi để tương tác với trang cho đến JavaScript hoàn tất việc thực thi, INP có thể rất thấp.
Thời điểm người dùng chọn tương tác với một trang phụ thuộc phần lớn vào việc liệu người dùng có lựa chọn thì dữ liệu đó có vẻ tương tác và không thể đo lường bằng TBT.
TBT không tính đến độ trễ nhấn
Nếu một trang web không được tối ưu hoá để xem trên thiết bị di động, thì trình duyệt sẽ thêm 300 mili giây trễ sau mỗi lần nhấn trước khi chạy trình xử lý sự kiện. Họ làm điều này vì cần xác định xem người dùng có đang cố nhấn đúp để thu phóng trước khi họ có thể kích hoạt hay không sự kiện nhấp chuột hoặc nhấp chuột.
Độ trễ này được tính vào INP của một trang do đóng góp vào thông tin đầu vào thực tế mà người dùng gặp phải. Nhưng vì sự chậm trễ này về mặt kỹ thuật không phải là Task, chứ không ảnh hưởng đến TBT của trang. Điều này có nghĩa là trang có thể có INP thấp mặc dù có điểm TBT rất cao.
Ảnh hưởng của trạng thái bộ nhớ đệm và bfcache trên INP
Tương tự như cách lưu vào bộ nhớ đệm đúng cách có thể cải thiện LCP, cải thiện INP.
Trong thế giới thực, một người dùng có thể có JavaScript cho trang web đã có trong nên việc xử lý dữ liệu đó có thể tốn ít công sức và giảm được độ trễ.
Điều này cũng đúng đối với các trang được khôi phục từ bfcache. Trong những trường hợp đó, JavaScript được khôi phục từ bộ nhớ, nên có thể có ít hoặc không xử lý thời gian nào.
CLS (Điểm số tổng hợp về mức thay đổi bố cục)
Ảnh hưởng của hành động tương tác của người dùng đến CLS (Mức thay đổi bố cục tích luỹ)
CLS được đo lường trong phòng thí nghiệm chỉ xem xét các thay đổi về bố cục ở trên trong màn hình đầu tiên và trong khi tải, nhưng đây chỉ là một phần nhỏ của CLS đo lường.
Trong trường này, CLS sẽ xem xét tất cả bố cục không mong muốn những thay đổi diễn ra trong suốt vòng đời của trang, bao gồm cả nội dung thay đổi khi người dùng cuộn hoặc khi người dùng phản hồi các yêu cầu mạng chậm sau khi người dùng tương tác.
Ví dụ: trường hợp các trang tải từng phần hình ảnh hoặc iframe không có và có thể khiến bố cục thay đổi khi người dùng cuộn đến các phần đó của trang. Tuy nhiên, những thay đổi đó có thể điều này chỉ xảy ra nếu người dùng cuộn xuống (thường sẽ không bị phát hiện khi thử nghiệm trong phòng thí nghiệm).
Nội dung được cá nhân hóa
Nội dung được cá nhân hoá (bao gồm cả quảng cáo được nhắm mục tiêu và thử nghiệm A/B) ảnh hưởng đến các thành phần được tải trên một trang. Thứ nguyên này cũng ảnh hưởng đến cách quảng cáo được tải vì được cá nhân hóa nội dung thường được tải sau và chèn vào nội dung chính của trang, khiến thay đổi bố cục.
Trong phòng thí nghiệm, một trang thường được tải mà không có nội dung được cá nhân hoá, hoặc với nội dung dành cho "người dùng thử nghiệm" chung chung, có thể hoặc không thể kích hoạt các thay đổi mà người dùng thực sự đang nhìn thấy.
Vì dữ liệu thực địa bao gồm trải nghiệm của tất cả người dùng, nên số lượng (và bằng cấp) số lần thay đổi bố cục trên một trang nhất định bất kỳ phụ thuộc rất lớn vào nội dung đã được tải.
Ảnh hưởng của trạng thái bộ nhớ đệm và bfcache đối với CLS
Hai trong số những nguyên nhân phổ biến nhất khiến bố cục thay đổi trong khi tải là hình ảnh và iframe không có kích thước (như đã đề cập ở trên) và web tải chậm phông chữ và cả hai vấn đề này có nhiều khả năng ảnh hưởng đến trải nghiệm lần đầu tiên người dùng truy cập vào trang web, khi bộ nhớ đệm của họ được trống.
Nếu tài nguyên của một trang được lưu vào bộ nhớ đệm hoặc nếu trang đó được khôi phục từ bfcache, trình duyệt thường có thể hiển thị hình ảnh và phông chữ ngay lập tức mà không cần chờ họ tải xuống. Điều này có thể khiến giá trị CLS (Mức thay đổi bố cục tích luỹ) thấp hơn trong trường so với báo cáo của công cụ trong phòng thí nghiệm.
Việc cần làm khi kết quả khác nhau
Theo quy tắc chung, nếu bạn có cả dữ liệu thực địa và dữ liệu phòng thí nghiệm cho một trang nhất định, là dữ liệu trường mà bạn nên sử dụng để ưu tiên nỗ lực của mình. Vì dữ liệu trường thể hiện những gì người dùng thực tế đang trải nghiệm, đó là cách chính xác nhất để thực sự hiểu người dùng của bạn đang gặp khó khăn gì và cần phải đã được cải thiện.
Mặt khác, nếu dữ liệu trong trường của bạn cho thấy điểm số tốt, nhưng dữ liệu phòng thí nghiệm của bạn cho thấy vẫn còn khả năng cải thiện, điều đáng giá biết có thể thực hiện thêm những biện pháp tối ưu hoá nào.
Ngoài ra, mặc dù dữ liệu thực địa thu thập được trải nghiệm người dùng thực tế, nhưng dữ liệu thực tế chỉ thu thập đối với những người dùng có thể tải thành công trang web của bạn. Dữ liệu phòng thí nghiệm đôi khi giúp xác định các cơ hội mở rộng phạm vi tiếp cận trang web của bạn và làm cho dễ tiếp cận hơn đối với người dùng có mạng chậm hơn hoặc thiết bị cấp thấp hơn.
Nhìn chung, cả dữ liệu phòng thí nghiệm và dữ liệu thực địa đều là phần quan trọng của đo lường hiệu suất. Cả hai đều có những thế mạnh và hạn chế riêng, và nếu nếu bạn chỉ đang sử dụng một tài sản, bạn có thể đang bỏ lỡ cơ hội cải thiện cho người dùng.