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