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