Tìm hiểu cách phân bổ dữ liệu hiệu suất bằng thông tin gỡ lỗi giúp xác định và khắc phục các vấn đề của người dùng thực bằng Analytics
Google cung cấp 2 danh mục công cụ để đo lường và gỡ lỗi hiệu suất:
- Các công cụ của Lab: Các công cụ như Lighthouse, nơi trang của bạn được tải trong môi trường mô phỏng có thể bắt chước nhiều điều kiện khác nhau (ví dụ: máy tính bảng và một thiết bị di động cấp thấp).
- Công cụ thực địa: Các công cụ như Trải nghiệm người dùng trên Chrome Báo vi phạm (CrUX), dựa trên dữ liệu người dùng thực được tổng hợp từ Chrome. (Lưu ý rằng dữ liệu trường được báo cáo bằng các công cụ như PageSpeed Thông tin chi tiết và Tìm kiếm Bảng điều khiển được lấy nguồn từ dữ liệu CrUX.)
Mặc dù công cụ thực địa cung cấp dữ liệu chính xác hơn — dữ liệu thực sự đại diện cho những gì trải nghiệm thực tế của người dùng – các công cụ trong phòng thí nghiệm thường tốt hơn trong việc giúp bạn xác định và khắc phục vấn đề.
Dữ liệu CrUX phản ánh chính xác hơn hiệu suất thực tế của trang, nhưng khi biết rằng điểm CrUX của bạn có thể không giúp bạn tìm ra cách cải thiện hiệu suất.
Mặt khác, Lighthouse sẽ xác định các vấn đề và đảm bảo các đề xuất về cách cải thiện. Tuy nhiên, Lighthouse sẽ chỉ đưa ra đề xuất cho các vấn đề về hiệu suất phát hiện vào thời gian tải trang. Không phát hiện thấy vấn đề mà chỉ xuất hiện khi người dùng tương tác, chẳng hạn như cuộn hoặc nhấp vào trên trang.
Điều này đặt ra một câu hỏi quan trọng: làm cách nào để thu thập thông tin gỡ lỗi cho Các chỉ số quan trọng về trang web hay các chỉ số khác về hiệu suất từ người dùng thực tế trong trường hợp này?
Bài đăng này sẽ giải thích chi tiết những API mà bạn có thể sử dụng để thu thập thêm thông tin gỡ lỗi cho từng chỉ số Core Web Vitals hiện tại và bạn có ý tưởng về cách thu thập dữ liệu này trong công cụ phân tích hiện tại của mình.
Các API để phân bổ và gỡ lỗi
Điểm số tổng hợp về mức thay đổi bố cục (CLS)
Trong số tất cả các chỉ số Core Web Vitals, có lẽ CLS là chỉ số mà thu thập thông tin gỡ lỗi trong trường này là quan trọng nhất. CLS được đo lường trong toàn bộ thời gian hoạt động của trang, để cách người dùng tương tác với trang—cách họ cuộn bao xa, nội dung họ nhấp vào, v.v.—có thể có về việc có thay đổi bố cục hay không và phần tử nào đang thay đổi.
Hãy xem xét báo cáo sau đây của PageSpeed Insights:
Giá trị được báo cáo cho CLS (chỉ số CLS) do phòng thí nghiệm (Lighthouse) báo cáo so với CLS (Mức thay đổi bố cục tích luỹ) của trường (dữ liệu CrUX) khá khác nhau và điều này rất hợp lý nếu bạn xem xét trang có thể có nhiều nội dung tương tác không được dùng khi kiểm thử trong Lighthouse.
Nhưng ngay cả khi bạn hiểu rằng tương tác của người dùng ảnh hưởng đến dữ liệu thực địa, bạn vẫn cần biết những yếu tố nào trên trang đang chuyển đổi để dẫn đến điểm số là 0,28 tại phân vị thứ 75. LayoutShiftAttribution giao diện giúp điều đó trở nên khả thi.
Xem thông tin phân bổ thay đổi bố cục
LayoutShiftAttribution
giao diện hiển thị trên mỗi mục layout-shift Tính không ổn định của bố cục
API phát ra.
Để được giải thích chi tiết về cả hai giao diện này, hãy xem phần Bố cục gỡ lỗi ca làm việc. Nhằm mục đích bài đăng này, điều quan trọng bạn cần biết là với tư cách là một nhà phát triển, bạn có thể để quan sát mọi thay đổi bố cục diễn ra trên trang cũng như những phần tử đang thay đổi.
Dưới đây là một số mã mẫu ghi lại mỗi lần thay đổi bố cục cũng như các phần tử đã thay đổi:
new PerformanceObserver((list) => {
for (const {value, startTime, sources} of list.getEntries()) {
// Log the shift amount and other entry info.
console.log('Layout shift:', {value, startTime});
if (sources) {
for (const {node, curRect, prevRect} of sources) {
// Log the elements that shifted.
console.log(' Shift source:', node, {curRect, prevRect});
}
}
}
}).observe({type: 'layout-shift', buffered: true});
Việc đo lường và gửi dữ liệu đến công cụ phân tích của bạn cho mọi lần thay đổi bố cục xảy ra; tuy nhiên, bằng cách theo dõi tất cả các ca chuyển, bạn có thể theo dõi những chuyển biến tồi tệ nhất và chỉ báo cáo thông tin về những chuyển biến đó.
Mục tiêu không phải là xác định và khắc phục mọi lần thay đổi bố cục xảy ra cho mọi người dùng; mục tiêu là xác định những thay đổi có ảnh hưởng đến và do đó đóng góp nhiều nhất vào CLS (Mức thay đổi bố cục tích luỹ) của trang ở bách phân vị thứ 75.
Ngoài ra, bạn không cần phải tính toán phần tử nguồn lớn nhất mỗi khi có ca, bạn chỉ cần làm như vậy khi đã sẵn sàng gửi giá trị CLS đến công cụ phân tích.
Mã sau đây liệt kê danh sách layout-shift mục nhập đã đóng góp
cho CLS (Mức thay đổi bố cục tích luỹ) và trả về phần tử nguồn lớn nhất từ mức thay đổi lớn nhất:
function getCLSDebugTarget(entries) {
const largestEntry = entries.reduce((a, b) => {
return a && a.value > b.value ? a : b;
});
if (largestEntry && largestEntry.sources && largestEntry.sources.length) {
const largestSource = largestEntry.sources.reduce((a, b) => {
return a.node && a.previousRect.width * a.previousRect.height >
b.previousRect.width * b.previousRect.height ? a : b;
});
if (largestSource) {
return largestSource.node;
}
}
}
Khi bạn đã xác định được yếu tố lớn nhất đóng góp vào sự thay đổi lớn nhất, bạn có thể báo cáo cho công cụ phân tích của mình.
Yếu tố đóng góp nhiều nhất vào CLS (Mức thay đổi bố cục tích luỹ) đối với một trang nhất định có thể sẽ thay đổi từ người dùng với người dùng, nhưng nếu bạn tổng hợp các thành phần đó giữa tất cả người dùng, bạn sẽ có thể tạo danh sách các yếu tố thay đổi ảnh hưởng đến số lượng người dùng nhiều nhất.
Sau khi bạn xác định và khắc phục được nguyên nhân gốc khiến những thay đổi đó xảy ra thì mã phân tích của bạn sẽ bắt đầu báo cáo những thay đổi nhỏ cho là "tệ nhất" cho các trang của mình. Cuối cùng, tất cả các thay đổi được báo cáo sẽ đủ nhỏ để các trang của bạn có chất lượng tốt trong phạm vi "tốt" ngưỡng của 0,1!
Một số siêu dữ liệu khác có thể hữu ích khi thu thập cùng với sự thay đổi lớn nhất phần tử nguồn là:
- Thời điểm có sự chuyển dịch lớn nhất
- Đường dẫn URL tại thời điểm xảy ra sự thay đổi lớn nhất (đối với những trang web động cập nhật URL, chẳng hạn như Ứng dụng trang đơn).
Thời gian hiển thị nội dung lớn nhất (LCP)
Để gỡ lỗi LCP trong trường này, thông tin chính bạn cần là là phần tử lớn nhất (phần tử ứng viên LCP) cho cụ thể đó tải trang.
Xin lưu ý rằng điều hoàn toàn có thể xảy ra, trên thực tế, điều khá phổ biến là LCP phần tử đề xuất sẽ khác nhau giữa các người dùng, thậm chí cho cùng một phần tử .
Điều này có thể xảy ra vì một vài lý do:
- Thiết bị của người dùng có độ phân giải màn hình khác nhau, dẫn đến các điểm khác nhau bố cục trang và do đó các phần tử khác nhau hiển thị trong khung nhìn.
- Không phải lúc nào người dùng cũng tải trang mà người dùng cuộn lên đầu trang. Thông thường, các đường liên kết sẽ chứa giá trị nhận dạng mảnh hoặc thậm chí mảnh văn bản, tức là có thể để tải và hiển thị trang tại bất kỳ vị trí cuộn nào trên trang.
- Nội dung có thể được cá nhân hoá cho người dùng hiện tại, do đó, phần tử ứng viên LCP có thể khác nhau rất nhiều giữa người dùng.
Điều này có nghĩa là bạn không thể đưa ra giả định về phần tử hoặc tập hợp phần tử nào sẽ là phần tử ứng viên LCP phổ biến nhất cho một trang cụ thể. Bạn phải đo lường dựa trên hành vi thực tế của người dùng.
Xác định phần tử ứng viên LCP
Để xác định phần tử ứng viên LCP trong JavaScript, bạn có thể sử dụng thuộc tính Lớn nhất Contentful Paint API chính API mà bạn dùng để xác định giá trị thời gian LCP.
Khi quan sát các mục nhập largest-contentful-paint, bạn có thể xác định
phần tử ứng viên LCP hiện tại bằng cách xem thuộc tính element của mục nhập gần đây nhất:
new PerformanceObserver((list) => {
const entries = list.getEntries();
const lastEntry = entries[entries.length - 1];
console.log('LCP element:', lastEntry.element);
}).observe({type: 'largest-contentful-paint', buffered: true});
Sau khi biết phần tử ứng viên LCP, bạn có thể gửi phần tử đó đến công cụ phân tích của mình cùng với giá trị chỉ số. Giống như CLS, chỉ số này sẽ giúp bạn xác định các yếu tố quan trọng nhất để tối ưu hoá trước tiên.
Ngoài phần tử ứng viên LCP, việc đo lường thời gian của phần phụ LCP, có thể hữu ích để xác định các bước tối ưu hoá cụ thể phù hợp với trang web của bạn.
Lượt tương tác đến nội dung hiển thị tiếp theo (INP)
Các bit thông tin quan trọng nhất cần thu thập tại trường INP là:
- Phần tử nào được tương tác
- Tại sao loại tương tác này
- Thời điểm hoạt động tương tác đó diễn ra
Nguyên nhân chính gây ra tình trạng tương tác chậm là luồng chính bị chặn, có thể thường xảy ra trong khi JavaScript đang tải. Xác định xem các tương tác chậm nhất xảy ra trong khi tải trang rất hữu ích trong việc xác định những gì cần được thực hiện để khắc phục sự cố.
Chỉ số INP xem xét độ trễ đầy đủ của một bao gồm cả thời gian cần để chạy bất kỳ trình nghe sự kiện đã đăng ký nào dưới dạng cũng như thời gian cần thiết để hiển thị khung tiếp theo sau tất cả các trình nghe sự kiện đã chạy. Điều này có nghĩa là đối với INP, việc biết được các thành phần có xu hướng dẫn đến tương tác chậm và các loại tương tác đó.
Mã sau đây ghi lại yếu tố mục tiêu và thời gian của mục nhập INP.
function logINPDebugInfo(inpEntry) {
console.log('INP target element:', inpEntry.target);
console.log('INP interaction type:', inpEntry.name);
console.log('INP time:', inpEntry.startTime);
}
Xin lưu ý rằng mã này không cho biết cách xác định mục nhập event nào là INP
vì logic đó liên quan nhiều hơn. Tuy nhiên, phần sau đây giải thích
Cách lấy thông tin này bằng cách sử dụng
Thư viện JavaScript web-vitals.
Sử dụng với thư viện JavaScript quan trọng
Các phần trước cung cấp một số đề xuất chung và ví dụ về mã để nắm bắt thông tin gỡ lỗi để đưa vào dữ liệu bạn gửi đến công cụ phân tích của mình.
Kể từ phiên bản 3, web-vitals Thư viện JavaScript bao gồm một thuộc tính xây dựng hiển thị tất cả những thông tin này và một vài thông tin bổ sung .
Ví dụ về mã sau đây cho thấy cách bạn có thể đặt thêm một sự kiện thông số (hoặc tuỳ chỉnh ) chứa chuỗi gỡ lỗi hữu ích giúp xác định nguyên nhân gốc của hiệu suất vấn đề.
import {onCLS, onINP, onLCP} from 'web-vitals/attribution';
function sendToGoogleAnalytics({name, value, id, attribution}) {
const eventParams = {
metric_value: value,
metric_id: id,
}
switch (name) {
case 'CLS':
eventParams.debug_target = attribution.largestShiftTarget;
break;
case 'LCP':
eventParams.debug_target = attribution.element;
break;
case 'INP':
eventParams.debug_target = attribution.interactionTarget;
break;
}
// Assumes the global `gtag()` function exists, see:
// https://developers.google.com/analytics/devguides/collection/ga4
gtag('event', name, eventParams);
}
onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);
Mã này dành riêng cho Google Analytics, nhưng ý tưởng chung nên dịch đối với các công cụ phân tích khác.
Mã này cũng chỉ cho biết cách báo cáo một tín hiệu gỡ lỗi duy nhất, nhưng hữu ích để có thể thu thập và báo cáo về nhiều tín hiệu khác nhau mỗi chỉ số.
Ví dụ: để gỡ lỗi INP, bạn có thể muốn thu thập phần tử đang được tương tác với, loại tương tác, thời gian, loadState, tương tác giai đoạn và nhiều chế độ khác (chẳng hạn như dữ liệu Khung ảnh động dài).
Bản dựng phân bổ web-vitals cung cấp thêm thông tin phân bổ,
như trong ví dụ sau đây về INP:
import {onCLS, onINP, onLCP} from 'web-vitals/attribution';
function sendToGoogleAnalytics({name, value, id, attribution}) {
const eventParams = {
metric_value: value,
metric_id: id,
}
switch (name) {
case 'INP':
eventParams.debug_target = attribution.interactionTarget;
eventParams.debug_type = attribution.interactionType;
eventParams.debug_time = attribution.interactionTime;
eventParams.debug_load_state = attribution.loadState;
eventParams.debug_interaction_delay = Math.round(attribution.inputDelay);
eventParams.debug_processing_duration = Math.round(attribution.processingDuration);
eventParams.debug_presentation_delay = Math.round(attribution.presentationDelay);
break;
// Additional metric logic...
}
// Assumes the global `gtag()` function exists, see:
// https://developers.google.com/analytics/devguides/collection/ga4
gtag('event', name, eventParams);
}
onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);
Tham khảo phân bổ web-vitals tài liệu dành cho danh sách đầy đủ các tín hiệu gỡ lỗi được hiển thị.
Báo cáo và trực quan hoá dữ liệu
Khi bạn đã bắt đầu thu thập thông tin gỡ lỗi cùng với các giá trị chỉ số, bước tiếp theo là tổng hợp dữ liệu từ tất cả người dùng để bắt đầu tìm kiếm mẫu và xu hướng.
Như đã đề cập trước đó, bạn không nhất thiết phải giải quyết mọi vấn đề người dùng gặp phải, bạn muốn giải quyết (đặc biệt là lúc đầu) các vấn đề đang ảnh hưởng đến số lượng người dùng lớn nhất. Đây cũng sẽ là vấn đề có tác động tiêu cực nhất đến điểm số Core Web Vitals.
Đối với GA4, hãy xem bài viết chuyên biệt về cách truy vấn và trình bày trực quan dữ liệu bằng BigQuery.
Tóm tắt
Hy vọng bài đăng này đã giúp nêu ra các cách cụ thể mà bạn có thể sử dụng
các API hiệu suất hiện có và thư viện web-vitals để lấy thông tin gỡ lỗi
để giúp chẩn đoán hiệu suất dựa trên những người dùng thực tế truy cập trong trường. Trong khi
tập trung vào Chỉ số quan trọng chính của trang web, các khái niệm này cũng áp dụng cho gỡ lỗi
mọi chỉ số hiệu suất có thể đo lường trong JavaScript.
Nếu bạn chỉ mới bắt đầu đo lường hiệu suất và đã Người dùng Google Analytics, công cụ Báo cáo Các chỉ số quan trọng về trang web có thể là nơi phù hợp để bắt đầu vì công cụ này đã hỗ trợ báo cáo thông tin gỡ lỗi cho Web chính Chỉ số Android vitals.
Nếu bạn là một nhà cung cấp phân tích và bạn đang tìm cách cải thiện sản phẩm và cung cấp thêm thông tin gỡ lỗi cho người dùng, hãy cân nhắc một số các kỹ thuật được mô tả ở đây, nhưng đừng giới hạn bản thân chỉ ở những ý tưởng được trình bày vào đây. Bài đăng này nhằm mục đích áp dụng chung cho tất cả các công cụ phân tích; tuy nhiên, công cụ phân tích cá nhân có thể (và nên) ghi lại và báo cáo thông tin gỡ lỗi khác.
Cuối cùng, nếu bạn cảm thấy khả năng gỡ lỗi của các chỉ số này bị thiếu hụt do các tính năng hoặc thông tin bị thiếu trong API sẽ gửi phản hồi của bạn đến web-vitals-feedback@googlegroups.com.