Thử nghiệm việc đo lường thao tác điều hướng mềm

Barry Pollard
Yoav Weiss
Yoav Weiss
X GitHub

Kể từ khi ra mắt, sáng kiến Chỉ số quan trọng chính của trang web đã tìm cách đo lường trải nghiệm thực tế của người dùng trên một trang web, thay vì các chi tiết kỹ thuật liên quan đến cách một trang web được tạo hoặc tải. Ba chỉ số Chỉ số quan trọng chính của trang web được tạo dưới dạng chỉ số lấy người dùng làm trung tâm. Đây là một bước phát triển so với các chỉ số kỹ thuật hiện có (như DOMContentLoaded hoặc load) nhằm đo lường những khoảng thời gian thường không liên quan đến cảm nhận của người dùng về hiệu suất của trang. Do đó, công nghệ dùng để xây dựng trang web sẽ không ảnh hưởng đến việc chấm điểm đối với việc cung cấp trang web đó.

Thực tế luôn phức tạp hơn một chút so với lý tưởng và kiến trúc Ứng dụng trang đơn phổ biến chưa bao giờ được các chỉ số Core Web Vitals hỗ trợ đầy đủ. Thay vì tải các trang web riêng biệt, riêng biệt khi người dùng điều hướng về trang web, những ứng dụng web này sử dụng cái gọi là "điều hướng mềm", trong đó nội dung trang được thay đổi bằng JavaScript. Trong các ứng dụng này, ảo tưởng về một cấu trúc trang web thông thường được duy trì bằng cách thay đổi URL và đẩy các URL trước đó trong lịch sử của trình duyệt để cho phép các nút quay lại và tiến lên hoạt động như người dùng mong đợi.

Nhiều khung JavaScript sử dụng mô hình này, nhưng mỗi khung theo một cách khác nhau. Vì trang này nằm ngoài phạm vi mà trình duyệt thường hiểu là "trang", nên việc đo lường điều này luôn khó khăn: ranh giới sẽ được vẽ giữa một lượt tương tác trên trang hiện tại ở đâu, so với việc coi đây là trang mới?

Nhóm Chrome hiện đã cân nhắc thách thức này và đang tìm cách chuẩn hoá định nghĩa về khái niệm "thao tác mềm" cũng như cách đo lường Chỉ số quan trọng chính của trang web về vấn đề này. Cách đo lường cũng tương tự như cách đo lường các trang web được triển khai trong kiến trúc nhiều trang (MPA) thông thường. Tuy vẫn còn ở những giai đoạn đầu, nhưng giờ đây, nhóm của chúng tôi đã sẵn sàng cung cấp những tính năng đã được triển khai rộng rãi hơn cho các trang web để thử nghiệm. Điều này sẽ cho phép các trang web đưa ra ý kiến phản hồi về phương pháp này cho đến thời điểm hiện tại.

Chỉ dẫn mềm là gì?

Chúng tôi đã đưa ra định nghĩa sau đây về thao tác mềm:

  • Di chuyển được bắt đầu bằng một thao tác của người dùng.
  • Thao tác điều hướng dẫn đến thay đổi về URL hiển thị cho người dùng và thay đổi lịch sử.
  • Điều hướng dẫn đến thay đổi DOM.

Đối với một số trang web, những phương pháp phỏng đoán này có thể dẫn đến kết quả dương tính giả (người dùng sẽ không thực sự xem đó là một "thao tác" đã xảy ra) hoặc âm tính giả (trong đó người dùng cho rằng một "thao tác" đã xảy ra mặc dù họ không đáp ứng các tiêu chí này). Chúng tôi hoan nghênh ý kiến phản hồi tại kho lưu trữ thông số kỹ thuật điều hướng mềm về các phương pháp phỏng đoán.

Chrome triển khai thao tác điều hướng mềm như thế nào?

Sau khi bật phương pháp phỏng đoán điều hướng mềm (tìm hiểu thêm về nội dung này trong phần tiếp theo), Chrome sẽ thay đổi cách báo cáo một số chỉ số hiệu suất:

Những thay đổi này sẽ cho phép đo lường Chỉ số quan trọng chính của trang web (và một số chỉ số chẩn đoán liên quan) trên mỗi thao tác điều hướng trang, mặc dù có một số điểm khác biệt nhỏ cần được xem xét.

Tác động của việc bật thao tác tạm thời trong Chrome là gì?

Sau đây là một số thay đổi mà chủ sở hữu trang web cần xem xét sau khi bật tính năng này:

  • Các sự kiện FP, FCP và LCP bổ sung có thể được phát lại cho quá trình điều hướng mềm. Báo cáo trải nghiệm người dùng trên Chrome (CrUX) sẽ bỏ qua các giá trị bổ sung này, nhưng điều này có thể ảnh hưởng đến mọi hoạt động theo dõi dữ liệu đo lường người dùng thực (RUM) trên trang web của bạn. Hãy liên hệ với nhà cung cấp dịch vụ RUM để xem bạn có lo ngại gì không. Điều này có ảnh hưởng đến kết quả đo lường của bạn hay không. Hãy xem phần về cách đo lường Chỉ số quan trọng chính của trang web trong quá trình điều hướng mềm.
  • Bạn có thể cần xem xét thuộc tính navigationID mới (và không bắt buộc) trên các mục nhập hiệu suất trong mã xử lý ứng dụng bằng cách sử dụng các mục nhập này.
  • Chỉ các trình duyệt dựa trên Chromium mới hỗ trợ chế độ mới này. Mặc dù nhiều chỉ số mới chỉ có trong trình duyệt dựa trên Chromium, nhưng một số chỉ số (FCP, LCP) có trong các trình duyệt khác và không phải ai cũng có thể đã nâng cấp lên phiên bản trình duyệt dựa trên Chromium mới nhất. Vì vậy, hãy lưu ý rằng một số người dùng có thể không báo cáo các chỉ số điều hướng mềm.
  • Vì đây là tính năng thử nghiệm mới và không được bật theo mặc định, nên các trang web nên thử nghiệm tính năng này để đảm bảo không có bất kỳ tác dụng phụ ngoài ý muốn nào khác.

Để biết thêm thông tin về cách đo lường chỉ số cho quá trình điều hướng mềm, vui lòng tham khảo bài viết Đo lường Chỉ số quan trọng chính của trang web cho mỗi phần điều hướng mềm.

Làm thế nào để bật thao tác tạm thời trong Chrome?

Thao tác mềm không được bật theo mặc định trong Chrome, nhưng bạn có thể thử nghiệm bằng cách bật tính năng này một cách rõ ràng.

Đối với nhà phát triển, họ có thể bật tính năng này bằng cách bật cờ các tính năng của Nền tảng web thử nghiệm tại chrome://flags/#enable-experimental-web-platform-features hoặc sử dụng đối số dòng lệnh --enable-experimental-web-platform-features khi chạy Chrome.

Làm cách nào để đo lường hoạt động điều hướng mềm?

Sau khi bật thử nghiệm thao tác mềm, các chỉ số sẽ được báo cáo bằng API PerformanceObserver như thường lệ. Tuy nhiên, có một số cân nhắc bổ sung cần được xem xét cho các chỉ số này.

Báo cáo các thao tác điều hướng mềm

Bạn có thể sử dụng PerformanceObserver để quan sát các thao tác điều hướng mềm. Sau đây là một đoạn mã mẫu sẽ ghi lại các mục điều hướng mềm vào bảng điều khiển – bao gồm cả các thao tác điều hướng mềm trước đó trên trang này bằng tuỳ chọn buffered:

const observer = new PerformanceObserver(console.log);
observer.observe({ type: "soft-navigation", buffered: true });

Bạn có thể sử dụng thao tác này để hoàn tất các chỉ số toàn thời gian của trang cho điều hướng trước.

Báo cáo các chỉ số dựa trên URL thích hợp

Vì các thao tác điều hướng tạm thời chỉ xuất hiện sau khi chúng diễn ra, nên một số chỉ số cần được tổng kết trong sự kiện này rồi được báo cáo cho URL trước đó, vì URL hiện tại giờ đây sẽ phản ánh URL được cập nhật cho trang mới.

Bạn có thể dùng thuộc tính navigationId của PerformanceEntry thích hợp để liên kết sự kiện với đúng URL. Bạn có thể tra cứu thông tin này bằng API PerformanceEntry:

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const pageUrl = navEntry?.name;

pageUrl này nên được sử dụng để báo cáo các chỉ số theo đúng URL, thay vì URL hiện tại mà các chỉ số có thể đã sử dụng trước đây.

Tải startTime của thao tác điều hướng mềm

Có thể lấy thời gian bắt đầu điều hướng theo cách tương tự:

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const startTime = navEntry?.startTime;

startTime là thời gian diễn ra lượt tương tác ban đầu (ví dụ: nhấp vào nút) để bắt đầu quá trình điều hướng mềm.

Tất cả thời gian hiệu suất, bao gồm cả thời gian cho điều hướng tạm thời, được báo cáo là thời gian từ "cứng" ban đầu thời gian điều hướng trang. Do đó, thời gian bắt đầu điều hướng mềm là cần thiết để cơ sở thời gian chỉ số tải điều hướng mềm (ví dụ: LCP), so với thời gian điều hướng mềm này.

Đo lường Chỉ số quan trọng chính của trang web trong quá trình điều hướng mềm

Để đưa các mục nhập chỉ số điều hướng mềm, bạn cần đưa includeSoftNavigationObservations: true vào lệnh gọi observe của trình quan sát hiệu suất.

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout Shift time:', entry);
  }
}).observe({type: 'layout-shift', buffered: true, includeSoftNavigationObservations: true});

Ngoài việc bật tính năng điều hướng mềm trong Chrome, bạn cần phải gắn cờ includeSoftNavigationObservations cho phương thức observe. Việc chọn sử dụng rõ ràng ở cấp trình quan sát hiệu suất là để đảm bảo những trình quan sát hiệu suất hiện có không bị bất ngờ bởi các mục bổ sung này, vì cần xem xét một số yếu tố khác cần cân nhắc khi đo lường Chỉ số quan trọng chính của trang web cho quá trình điều hướng mềm.

Thời gian sẽ vẫn được trả về theo giá trị "cứng" ban đầu thời gian bắt đầu điều hướng. Ví dụ: để tính LCP cho một thao tác điều hướng mềm, bạn cần lấy thời gian LCP và trừ thời gian bắt đầu thao tác điều hướng mềm thích hợp như đã nêu chi tiết trước đó để có được thời gian tương ứng với thao tác điều hướng mềm. Ví dụ: đối với LCP:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const softNavEntry =
      performance.getEntriesByType('soft-navigation').filter(
        (navEntry) => navEntry.navigationId === entry.navigationId
      )[0];
    const hardNavEntry = performance.getEntriesByType('navigation')[0];
    const navEntry = softNavEntry || hardNavEntry;
    const startTime = navEntry?.startTime;
    console.log('LCP time:', entry.startTime - startTime);
  }
}).observe({type: 'largest-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

Trước đây, người dùng thường đo lường một vài chỉ số trong suốt thời gian hoạt động của trang: chẳng hạn như LCP có thể thay đổi cho đến khi có một lượt tương tác xảy ra. Bạn có thể cập nhật CLS (Mức thay đổi bố cục tích luỹ) và INP (Lượt tương tác đến nội dung hiển thị tiếp theo) cho đến khi người dùng rời khỏi trang. Do đó, mỗi thao tác "navigation" (bao gồm điều hướng ban đầu) có thể cần phải hoàn tất các chỉ số của trang trước đó khi mỗi lần điều hướng mềm mới diễn ra. Điều này có nghĩa là giá trị "cứng" ban đầu chỉ số điều hướng có thể được hoàn tất sớm hơn như bình thường.

Tương tự, khi bắt đầu đo lường các chỉ số cho quá trình điều hướng tạm thời mới của các chỉ số dài hạn này, bạn cần phải "đặt lại" các chỉ số hoặc "khởi chạy lại" và được coi là các chỉ số mới, không có bộ nhớ về các giá trị đã được đặt cho các "trang" trước đó.

Bạn nên xử lý nội dung không thay đổi giữa các lần điều hướng như thế nào?

FP, FCP và LCP cho các thao tác điều hướng mềm sẽ chỉ đo lường các nội dung hiển thị mới. Điều này có thể dẫn đến LCP khác, ví dụ: từ tải nguội của điều hướng mềm đó sang tải mềm.

Ví dụ: lấy một trang có chứa hình ảnh biểu ngữ lớn là phần tử LCP, nhưng văn bản bên dưới trang đó thay đổi theo mỗi thao tác điều hướng mềm. Lần tải trang ban đầu sẽ gắn cờ ảnh biểu ngữ là phần tử LCP và căn thời gian cho LCP. Đối với các thao tác điều hướng mềm tiếp theo, văn bản bên dưới sẽ là phần tử lớn nhất được vẽ sau thanh điều hướng mềm và sẽ là phần tử LCP mới. Tuy nhiên, nếu một trang mới được tải bằng một đường liên kết sâu vào URL điều hướng mềm, thì hình ảnh biểu ngữ sẽ được hiển thị mới và do đó sẽ đủ điều kiện để được coi là phần tử LCP.

Như ví dụ này cho thấy, phần tử LCP của phần điều hướng mềm có thể được báo cáo theo cách khác nhau tuỳ thuộc vào cách tải trang – tương tự như cách tải một trang có đường liên kết neo ở phía dưới trang có thể dẫn đến phần tử LCP khác.

Làm cách nào để đo lường TTFB?

Thời gian đến byte đầu tiên (TTFB) cho một lượt tải trang thông thường biểu thị thời gian mà byte đầu tiên của yêu cầu ban đầu được trả về.

Đối với thao tác điều hướng mềm, đây là một câu hỏi phức tạp hơn. Chúng tôi có nên đo lường yêu cầu đầu tiên được đưa ra cho trang mới không? Nếu tất cả nội dung đã có trong ứng dụng và không có yêu cầu bổ sung thì sao? Nếu yêu cầu đó được thực hiện trước bằng phương thức tìm nạp trước thì sao? Nếu một yêu cầu không liên quan đến việc điều hướng mềm từ góc độ người dùng (ví dụ: đó là một yêu cầu phân tích) thì sao?

Một phương pháp đơn giản hơn là báo cáo TTFB bằng 0 cho các thao tác điều hướng mềm – theo cách tương tự như chúng tôi đề xuất để khôi phục bộ nhớ đệm cho thao tác tiến/lùi. Đây là phương thức mà thư viện web-vitals sử dụng cho các thao tác điều hướng mềm.

Trong tương lai, chúng tôi có thể hỗ trợ những cách chính xác hơn để biết yêu cầu nào là "yêu cầu chỉ đường" của quá trình điều hướng mềm và sẽ có thể có được các phép đo TTFB chính xác hơn. Tuy nhiên, đó chưa phải là một phần của thử nghiệm hiện tại.

Làm thế nào để đo lường cả cũ và mới?

Trong quá trình thử nghiệm này, bạn nên tiếp tục đo lường Các chỉ số quan trọng chính của trang web theo cách hiện tại, dựa trên giá trị "cứng" các thao tác điều hướng trang để khớp với dữ liệu mà CrUX sẽ đo lường và báo cáo dưới dạng tập dữ liệu chính thức trong sáng kiến Chỉ số quan trọng chính của trang web.

Ngoài các chỉ số này, bạn nên đo lường các thao tác điều hướng mềm để biết cách đo lường những chỉ số này trong tương lai, cũng như để bạn có cơ hội đưa ra ý kiến phản hồi cho nhóm Chrome về cách triển khai trong thực tế. Việc này sẽ giúp bạn và nhóm Chrome định hình API trong tương lai.

Để đo lường cả hai, bạn cần lưu ý các sự kiện mới có thể được phát hành khi ở chế độ điều hướng mềm (ví dụ: nhiều sự kiện FCP và LCP bổ sung), đồng thời xử lý các sự kiện này một cách phù hợp bằng cách hoàn tất các chỉ số này vào thời điểm thích hợp, đồng thời bỏ qua các sự kiện trong tương lai chỉ áp dụng cho các thao tác điều hướng mềm.

Sử dụng thư viện web-vitals để đo lường Các chỉ số quan trọng về trang web cho quá trình điều hướng mềm

Cách dễ nhất để xem xét mọi điểm khác biệt là sử dụng thư viện JavaScript web-vitals. Thư viện này có hỗ trợ thử nghiệm cho quá trình điều hướng mềm trong một soft-navs branch riêng biệt (cũng có sẵn trên npm và unpkg). Bạn có thể đo lường thời gian này theo cách sau (thay thế doTraditionalProcessing và doSoftNavProcessing nếu thích hợp):

import {
  onTTFB,
  onFCP,
  onLCP,
  onCLS,
  onINP,
} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';

onTTFB(doTraditionalProcessing);
onFCP(doTraditionalProcessing);
onLCP(doTraditionalProcessing);
onCLS(doTraditionalProcessing);
onINP(doTraditionalProcessing);

onTTFB(doSoftNavProcessing, {reportSoftNavs: true});
onFCP(doSoftNavProcessing, {reportSoftNavs: true});
onLCP(doSoftNavProcessing, {reportSoftNavs: true});
onCLS(doSoftNavProcessing, {reportSoftNavs: true});
onINP(doSoftNavProcessing, {reportSoftNavs: true});

Đảm bảo các chỉ số được báo cáo dựa trên URL chính xác như đã nêu trước đây.

Thư viện web-vitals báo cáo các chỉ số sau cho các thao tác điều hướng mềm:

Chỉ số Thông tin chi tiết
TTFB Đã báo cáo là 0
FCP (hiển thị nội dung đầu tiên) Chỉ có FCP đầu tiên của trang được báo cáo.
LCP (Thời gian hiển thị nội dung lớn nhất) Thời gian hiển thị nội dung lớn nhất tiếp theo, so với thời gian bắt đầu điều hướng mềm. Các thành phần hiển thị hiện có từ thành phần điều hướng trước đó sẽ không được xem xét. Do đó, LCP sẽ >= 0. Như thường lệ, thông tin này sẽ được báo cáo khi có sự tương tác hoặc khi trang chạy ở chế độ nền, vì chỉ khi đó LCP mới có thể được hoàn tất.
CLS (Điểm số tổng hợp về mức thay đổi bố cục) Khoảng thời gian chuyển đổi lớn nhất giữa các lần di chuyển. Như thường lệ, khi trang chạy ở chế độ nền vì chỉ khi đó mới có thể hoàn tất CLS (Mức thay đổi bố cục tích luỹ). Giá trị bằng 0 được báo cáo nếu không có sự thay đổi.
INP INP giữa các lần điều hướng. Như thường lệ, thông tin này sẽ được báo cáo khi có lượt tương tác hoặc khi trang chạy ở chế độ nền vì chỉ khi đó INP mới có thể được hoàn tất. Giá trị 0 sẽ không được báo cáo nếu không có lượt tương tác.

Những thay đổi này có được đưa vào các chỉ số đo lường Core Web Vitals không?

Thử nghiệm điều hướng mềm này chính xác là một thử nghiệm. Chúng tôi muốn đánh giá các phương pháp phỏng đoán và xem liệu các phương pháp đó có phản ánh chính xác hơn trải nghiệm người dùng hay không trước khi đưa ra quyết định về việc có tích hợp phương pháp này vào sáng kiến Chỉ số quan trọng chính của trang web hay không. Chúng tôi rất vui mừng về khả năng của thử nghiệm này, nhưng không thể đảm bảo về việc liệu hay khi nào thử nghiệm này sẽ thay thế các phép đo hiện tại.

Chúng tôi coi trọng tinh thần trách nhiệm của nhà phát triển web phản hồi về thử nghiệm, các phương pháp phỏng đoán được sử dụng và liệu bạn có cảm thấy thử nghiệm đó phản ánh chính xác hơn trải nghiệm hay không. Kho lưu trữ điều hướng mềm trên GitHub là nơi tốt nhất để cung cấp ý kiến phản hồi đó, mặc dù bạn nên gửi từng lỗi riêng lẻ trong quá trình triển khai Chrome qua công cụ theo dõi lỗi của Chrome.

Thao tác điều hướng mềm sẽ được báo cáo như thế nào trong CrUX?

Cách chính xác các thao tác điều hướng mềm sẽ được báo cáo trong CrUX, nếu thử nghiệm này thành công, thì vẫn đang được xác định. Không nhất thiết là một giá trị nhất định sẽ được đối xử giống như "cứng" hiện tại điều hướng được xử lý.

Trên một số trang web, thao tác điều hướng mềm gần giống với tải toàn bộ trang khi người dùng có quan ngại và việc sử dụng công nghệ Ứng dụng trang đơn chỉ là một chi tiết triển khai. Nói cách khác, các video này có thể gần giống với việc tải một phần nội dung bổ sung.

Do đó, chúng tôi có thể quyết định báo cáo riêng các thao tác điều hướng mềm này trong CrUX, hoặc có thể dựa vào trọng số khi tính toán Các chỉ số quan trọng chính của trang web cho một trang hoặc nhóm trang nhất định. Chúng tôi cũng có thể loại trừ hoàn toàn việc điều hướng mềm một phần khi phương pháp phỏng đoán phát triển.

Nhóm đang tập trung vào việc triển khai phương pháp phỏng đoán và kỹ thuật để đánh giá mức độ thành công của thử nghiệm này. Do đó, chúng tôi chưa đưa ra quyết định nào về các khía cạnh này.

Phản hồi

Chúng tôi đang tích cực thu thập ý kiến phản hồi về thử nghiệm này tại các địa điểm sau:

Nhật ký thay đổi

Vì API này đang trong quá trình thử nghiệm nên sẽ có một số thay đổi đối với API này nhiều hơn so với các API ổn định. Bạn có thể xem Nhật ký thay đổi về hệ thống điều hướng mềm để biết thêm chi tiết.

Kết luận

Thử nghiệm điều hướng mềm là một cách tiếp cận thú vị đối với cách phát triển sáng kiến Chỉ số quan trọng chính của trang web nhằm đo lường một mẫu hình phổ biến trên web hiện đại bị thiếu trong các chỉ số của chúng tôi. Mặc dù thử nghiệm này vẫn chỉ mới bắt đầu và vẫn còn nhiều việc phải làm, cho đến nay, việc cung cấp tiến trình thử nghiệm cho toàn thể cộng đồng web là một bước quan trọng. Thu thập ý kiến phản hồi từ thử nghiệm này cũng là một phần quan trọng của thử nghiệm, vì vậy, chúng tôi đặc biệt khuyến khích những người quan tâm đến quá trình phát triển này tận dụng cơ hội này để giúp định hình API nhằm đảm bảo API đại diện cho những gì chúng tôi hy vọng có thể đo lường được bằng cách này.

Xác nhận

Hình thu nhỏ của Jordan Madrid trên Unsplash