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

Barry Pollard

Michal Mocny

Xuất bản: Ngày 1 tháng 2 năm 2023, Lần cập nhật gần đây nhất: Ngày 30 tháng 3 năm 2026

Kể từ khi ra mắt, sáng kiến Core Web Vitals đã tìm cách đo lường trải nghiệm người dùng thực tế của một trang web, thay vì các chi tiết kỹ thuật đằng sau cách một trang web được tạo hoặc tải. Ba chỉ số Core Web Vitals được tạo ra dưới dạng chỉ số tập trung vào người dùng – một bước tiến so với các chỉ số kỹ thuật hiện có như DOMContentLoaded hoặc load. Các chỉ số này đo lường thời gian mà thường không liên quan đến cách người dùng cảm nhận về hiệu suất của trang. Do đó, công nghệ được dùng để tạo trang web sẽ không ảnh hưởng đến điểm số nếu trang web hoạt động hiệu quả.

Thực tế luôn phức tạp hơn lý tưởng, và kiến trúc ứng dụng trang đơn phổ biến chưa bao giờ được Core Web Vitals hỗ trợ đầy đủ. Thay vì tải các trang web riêng biệt khi người dùng di chuyển trên trang web, các ứng dụng web này sử dụng cái gọi là "thao tác điều hướng mềm", trong đó nội dung trang được thay đổi bằng JavaScript. Trong những ứng dụng này, ảo ảnh về 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 đó vào nhật ký của trình duyệt để cho phép các nút quay lại và chuyển tiếp 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 lại sử dụng theo một cách khác nhau. Vì điều 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 gặp khó khăn: đâu là ranh giới giữa một lượt tương tác trên trang hiện tại so với việc coi đây là một trang mới?

Nhóm Chrome đã cân nhắc thách thức này trong một thời gian và đang tìm cách chuẩn hoá định nghĩa về "thao tác điều hướng mềm" và cách đo lường Core Web Vitals cho thao tác này – theo cách tương tự như cách đo lường các trang web được triển khai trong cấu trúc nhiều trang (MPA) thông thường.

Chúng tôi đã cải thiện API này dựa trên ý kiến phản hồi của nhà phát triển trong bản dùng thử theo nguyên gốc gần đây nhất. Giờ đây, chúng tôi yêu cầu nhà phát triển dùng thử phiên bản mới nhất và đưa ra ý kiến phản hồi về phương pháp này trước khi ra mắt. Chúng tôi khá tự tin về vị trí của API trong các lần lặp lại này và đang hướng đến việc phát hành API vào cuối năm nay, tuỳ thuộc vào ý kiến phản hồi về bản dùng thử theo nguyên gốc mới nhất này.

Điều hướng mềm là gì?

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

• Lệnh điều hướng được bắt đầu bằng một hành động của người dùng.
• Thao tác điều hướng này dẫn đến việc người dùng thấy URL thay đổi.
• Tương tác này dẫn đến một lượt hiển thị có thể nhìn thấy.

Đối với một số trang web, các 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 không thực sự coi đó là một "hành động điều hướng") hoặc kết quả âm tính giả (người dùng coi đó là một "hành động điều hướng" mặc dù không đáp ứng các tiêu chí này). Chúng tôi rất mong nhận được ý kiến phản hồi tại kho lưu trữ quy cách điều hướng bằng phần mềm về các phương pháp phỏng đoán.

DevTools hỗ trợ tính năng Điều hướng mềm

Chúng tôi đã thêm tính năng hỗ trợ các thao tác điều hướng mềm vào Bảng điều khiển hiệu suất của Công cụ cho nhà phát triển ở chế độ xem dấu vết:

Bạn có thể thấy các điểm đánh dấu cho thao tác điều hướng mềm và LCP. Cả hai đều được đánh dấu bằng biểu tượng * để giúp phân biệt chúng với các mục nhập điều hướng cứng thông thường. Tính năng này được bật theo mặc định và tách biệt với các thay đổi về API hiệu suất mà chúng ta sẽ thảo luận tiếp theo. Đây là một cách nhanh chóng để kiểm tra xem thử nghiệm điều hướng mềm có hoạt động đúng cách cho trang web của bạn hay không.

Hiện tại, thông tin này chỉ cho biết điều hướng mềm và dấu thời gian LCP trong chế độ xem dấu vết. Các chỉ số khác (ví dụ: LCP) và chế độ hỗ trợ trong chế độ xem Số liệu trực tiếp sẽ được thêm vào sau.

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

Sau khi bạn bật các phương pháp phỏng đoán điều hướng mềm (xem thêm về vấn đề 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:

• Sự kiện soft-navigation PerformanceTiming sẽ được phát ra sau mỗi lần phát hiện thấy thao tác điều hướng mềm.
• Mục soft-navigation này sẽ bao gồm một navigationId, URL mới trong thuộc tính name, cũng như một interactionId của lượt tương tác bắt đầu.
• Một hoặc nhiều mục interaction-contentful-paint sẽ được phát ra sau các lượt tương tác gây ra một lượt hiển thị nội dung. Bạn có thể dùng API này để đo Nội dung lớn nhất hiển thị (LCP) cho các thao tác điều hướng mềm khi hoạt động tương tác phát ra một thao tác điều hướng mềm.
• Thuộc tính navigationId được thêm vào từng chỉ số thời gian hoạt động (first-paint, first-contentful-paint, largest-contentful-paint, interaction-contentful-paint, first-input-delay, event và layout-shift). Thuộc tính này tương ứng với mục nhập điều hướng mà sự kiện được phát ra. Xin lưu ý rằng khi các mục này trải dài trên các thao tác điều hướng mềm, chúng có thể chứa navigationId trước đó hoặc tiếp theo, tuỳ thuộc vào thời điểm mục được phát. Bạn có thể xem thêm thông tin về vấn đề này trong phần Báo cáo các chỉ số dựa trên URL thích hợp.
• soft-navigation sẽ bao gồm một mục largestInteractionContentfulPaint, trong đó có mục interaction-contentful-paint lớn nhất được phát ra trong quá trình điều hướng. Sau đó, bạn có thể dùng LCP này làm LCP ban đầu cho thao tác điều hướng đó và LCP đó có thể được cập nhật khi bạn quan sát thấy nhiều mục interaction-contentful-paint hơn cho hoạt động tương tác đó.
• Có thể một số mục interaction-contentful-paint đã xảy ra trước khi điều hướng mềm diễn ra (nếu quá trình cập nhật URL không diễn ra cho đến sau khi những lần hiển thị đó diễn ra). Trong những trường hợp này, mục nhập largestInteractionContentfulPaint lớn nhất sẽ giúp bạn không cần phải lưu vào bộ nhớ đệm và xem lại các mục nhập cũ. Xin lưu ý rằng largestInteractionContentfulPaint là bản sao chính xác của mục interaction-contentful-paint lớn nhất, vì vậy, mục đó sẽ sử dụng navigationId trước đó vì đó là thời điểm xảy ra hoạt động tạo điểm ảnh, nhưng các hoạt động tạo điểm ảnh này phải được đo lường dựa trên navigationId mới.
• Mục soft-navigation cũng sẽ bao gồm paintTime và presentationTime làm FCP cho hoạt động điều hướng đó.
• Xin lưu ý rằng các mục nhập interaction-contentful-paint cũng sẽ được phát sau các lượt tương tác khác, nhưng LCP cho một URL phải được giới hạn ở các mục nhập interaction-contentful-paint khớp với các thao tác điều hướng mềm interactionId để loại trừ các mục nhập này.

Những thay đổi này sẽ cho phép đo lường Core Web Vitals (và một số chỉ số chẩn đoán liên quan) theo từng lượt điều hướng trang, mặc dù có một số sắc thái cần được xem xét.

Việc bật tính năng điều hướng mềm trong Chrome có những điểm gì cần lưu ý?

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

• Việc theo dõi các mục soft-navigation cho phép "phân chia" các mục hiệu suất thành từng "thao tác điều hướng".
• Bạn có thể tuỳ ý phân chia các chỉ số CLS và INP thay vì đo lường trong suốt vòng đời của trang. Tuy nhiên, Soft Navigation API cung cấp một chỉ số tiêu chuẩn về thời điểm điều này xảy ra, bất kể công nghệ cơ bản được sử dụng.
• Mục largest-contentful-paint được hoàn tất trong một lượt tương tác (cần thiết để bắt đầu một thao tác điều hướng "mềm"), vì vậy, mục này chỉ có thể dùng để đo LCP điều hướng "cứng" ban đầu. Điều này có nghĩa là chỉ số này sẽ không thay đổi khi các thao tác điều hướng mềm được đo lường, do đó, bạn có thể đo LCP cho lần tải trang điều hướng cứng ban đầu như trước đây.
• Bạn có thể dùng mục interaction-contentful-paint mới được phát ra từ các hoạt động tương tác để đo LCP cho các thao tác điều hướng mềm. Tuy nhiên, có một số điểm cần lưu ý về cách sử dụng mục này mà chúng ta sẽ thảo luận trong bài viết này.
• Xin lưu ý rằng không phải người dùng nào cũng hỗ trợ API điều hướng mềm này, đặc biệt là đối với các phiên bản Chrome cũ và những người dùng trình duyệt khác. Xin lưu ý rằng một số người dùng có thể không báo cáo các chỉ số dựa trên thao tác điều hướng mềm, ngay cả khi họ báo cáo Core Web Vitals.
• Vì đây là một tính năng mới thử nghiệm và không được bật theo mặc định, nên các trang web cần kiểm thử tính năng này để xem có tác dụng phụ không mong muốn hay không.

Hãy kiểm tra với nhà cung cấp RUM của bạn để xem họ có hỗ trợ đo lường Core Web Vitals bằng thao tác điều hướng mềm hay không. Nhiều người đang lên kế hoạch kiểm thử tiêu chuẩn mới này và sẽ cân nhắc những yếu tố trước đây. Trong thời gian chờ đợi, một số nhà cung cấp cũng cho phép đo lường có giới hạn các chỉ số hiệu suất dựa trên phương pháp phỏng đoán của riêng họ.

Để biết thêm thông tin về cách đo lường các chỉ số cho thao tác điều hướng mềm, hãy xem phần Đo lường Core Web Vitals cho mỗi thao tác điều hướng mềm.

Làm cách nào để bật tính năng điều hướng mềm trong Chrome?

Theo mặc định, Chrome không bật tính năng điều hướng mềm, 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, bạn có thể bật tính năng này bằng cách bật cờ tại chrome://flags/#soft-navigation-heuristics. Ngoài ra, bạn có thể bật tính năng này bằng cách sử dụng đối số dòng lệnh --enable-features=SoftNavigationHeuristics khi chạy Chrome. Việc bật cờ chrome://flags/#enable-experimental-web-platform-features cũng sẽ bật các thao tác điều hướng mềm.

Đối với một trang web muốn bật tính năng này để tất cả khách truy cập đều thấy được tác động, sẽ có một bản dùng thử theo nguyên gốc chạy từ Chrome 147. Bạn có thể bật tính năng này bằng cách đăng ký dùng thử và thêm một phần tử meta có mã thông báo dùng thử theo nguyên gốc vào tiêu đề HTML hoặc HTTP. Hãy xem bài đăng Bắt đầu dùng thử nghiệm nguồn gốc để biết thêm thông tin.

Chủ sở hữu trang web có thể chọn đưa bản dùng thử theo nguyên gốc vào các trang của họ cho tất cả người dùng hoặc chỉ cho một nhóm nhỏ người dùng. Hãy lưu ý đến phần hệ quả trước đó về cách thay đổi này có thể ảnh hưởng đến cách báo cáo các chỉ số của bạn, đặc biệt là nếu bạn bật bản dùng thử theo nguyên gốc này cho một tỷ lệ lớn người dùng. Xin lưu ý rằng CrUX sẽ tiếp tục báo cáo các chỉ số theo cách hiện tại, bất kể chế độ cài đặt điều hướng mềm này. Do đó, CrUX không bị ảnh hưởng bởi những tác động này. Bạn cũng nên lưu ý rằng các thử nghiệm nguồn gốc cũng bị giới hạn ở mức tối đa 0,5% tổng số lượt tải trang trên Chrome (tính theo giá trị trung bình trong 14 ngày). Tuy nhiên, đây chỉ là vấn đề đối với những trang web có quy mô rất lớn.

Tính năng phát hiện hỗ trợ Soft Navigations API

Bạn có thể dùng mã sau để kiểm thử xem API có được hỗ trợ hay không:

if (PerformanceObserver.supportedEntryTypes.includes('soft-navigation')) {
  // Monitor Soft Navigations
}

Xin lưu ý rằng supportedEntryTypes sẽ bị cố định khi sử dụng lần đầu. Vì vậy, nếu tính năng hỗ trợ thao tác điều hướng linh hoạt được thêm một cách linh động bằng mã thông báo bản dùng thử theo nguyên gốc được chèn vào trang, thì mã thông báo này có thể trả về giá trị ban đầu, trước khi tính năng đó được kích hoạt.

Bạn có thể sử dụng phương án thay thế sau trong trường hợp này khi chế độ điều hướng mềm chưa được hỗ trợ theo mặc định và đang ở trạng thái chuyển đổi này:

if ('SoftNavigationEntry' in window) {
  // Monitor Soft Navigations
}

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

Sau khi bạn bật thử nghiệm điều hướng mềm, các chỉ số sẽ được báo cáo bằng API PerformanceObserver như các chỉ số khác. Tuy nhiên, bạn cần cân nhắc thêm một số yếu tố đối với các chỉ số này.

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

Bạn có thể dùng PerformanceObserver để theo dõi các thao tác điều hướng mềm. Sau đây là một đoạn mã ví dụ ghi 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 cách sử dụng lựa chọn buffered:

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

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

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

Khi thấy một thao tác điều hướng mềm, Core Web Vitals của trang trước đó sẽ được hoàn tất, sau đó được báo cáo cho URL trước đó và hoạt động giám sát mới sẽ bắt đầu cho URL mới.

Thuộc tính name của mục soft-navigation thích hợp sẽ chứa URL mới để báo cáo các chỉ số và navigationId sẽ là thông tin tham chiếu duy nhất cho hoạt động điều hướng này (vì cùng một URL có thể được truy cập nhiều lần trong suốt thời gian tồn tại của một ứng dụng trang đơn). 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;

Báo cáo đúng URL cho interaction-contentful-paint

Bạn cần cân nhắc thêm để tính LCP từ các mục interaction-contentful-paint, vì không phải tất cả các mục interaction-contentful-paint đều được liên kết bằng navigationId và được báo cáo là LCP cho URL đó:

• Vấn đề đầu tiên là các mục interaction-contentful-paint có thể được phát ra trước khi thao tác điều hướng mềm xảy ra nếu một thao tác hiển thị xảy ra trước khi URL được cập nhật. Trong những trường hợp này, navigationId sẽ dành cho URL cũ. Nếu URL được cập nhật trước, thì quá trình hiển thị sẽ hoàn tất thao tác điều hướng mềm và trong trường hợp đó, mục soft-navigation sẽ được phát trước và interaction-contentful-paint sẽ có URL mới.
• Vấn đề thứ hai là interaction-contentful-paint, các mục nhập sẽ tiếp tục được phát ra cho các lượt tương tác mới hơn, vì phạm vi của chỉ số hiệu suất này không chỉ giới hạn ở LCP cho các thao tác điều hướng mềm. Chúng ta chỉ muốn xem xét các lần hiển thị cho lượt tải điều hướng mềm cho LCP chứ không phải các lần hiển thị cho các lượt tương tác tiếp theo.

Do đó, bạn nên sử dụng interactionId thay vì navigationId để liên kết các mục interaction-contentful-paint với soft-navigation-entries nhằm lấy đúng URL. Thao tác này sẽ xử lý mọi mục có navigationId cũ cũng như lọc bỏ mọi mục interaction-contentful-paint không được xem xét cho LCP.

Ngoài ra, bạn cũng nên cân nhắc xử lý mục largestInteractionContentfulPaint của các mục soft-navigation, để dễ dàng xử lý các mục interaction-contentful-paint xảy ra trước khi soft-navigation entries được phát.

Nhận startTime về các thao tác điều hướng mềm

Tất cả các thời gian hiệu suất (kể cả thời gian cho các thao tác điều hướng mềm) và các mục dùng để tính toán chỉ số Core Web Vitals đều được báo cáo dưới dạng thời gian kể từ thời gian điều hướng trang "cứng" ban đầu. Do đó, bạn nên trừ thời gian bắt đầu điều hướng mềm khỏi thời gian chỉ số tải điều hướng mềm (ví dụ: LCP) để báo cáo các chỉ số này so với thời gian điều hướng mềm.

Bạn có thể lấy thời gian bắt đầu chỉ đường theo cách tương tự bằng cách liên kết với mục soft-navigation thích hợp và sử dụng startTime của mục đó.

startTime là thời gian của lượt tương tác ban đầu (ví dụ: lượt nhấp vào nút) đã bắt đầu thao tác điều hướng mềm. Điều này có phần khác với "thao tác điều hướng cứng", trong đó "thời gian bắt đầu" là khi trang mới được "xác nhận" với trình duyệt và sau khi một số mã trình xử lý sự kiện được chạy. Thời gian bắt đầu điều hướng mềm cũng bao gồm mã trình xử lý sự kiện đó vì chúng tôi đo lường từ thời gian bắt đầu tương tác.

Đo lường Core Web Vitals cho mỗi thao tác điều hướng mềm

Để đo lường Core Web Vitals, hãy theo dõi các mục soft-navigation, đặt lại các chỉ số khi nhận được những mục này. FCP có thể được phát dựa trên presentationTime và LCP có thể được khởi chạy thành largestInteractionContentfulPaint. INP, CLS phải được khởi tạo thành 0 như khi tải trang.

Sau đó, bạn có thể đo lường và theo dõi LCP, INP và CLS như bình thường (ngoại trừ việc sử dụng interaction-contentful-paint cho LCP cung cấp các kết quả trùng khớp interactionId). Bạn có thể dùng interactionId và navigationId để đặt tên cho các mục trong một URL như đã thảo luận trước đó.

Thời gian vẫn sẽ được trả về tương ứng với thời gian bắt đầu điều hướng "cứng" ban đầu. Ví dụ: để tính LCP cho một thao tác điều hướng mềm, bạn sẽ cần lấy thời gian interaction-contentful-paint và trừ đi 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.

Theo truyền thống, một số chỉ số được đo lường trong suốt thời gian tồn tại của trang: ví dụ: LCP có thể thay đổi cho đến khi xảy ra một lượt tương tác. CLS và INP có thể được cập nhật cho đến khi người dùng rời khỏi trang, bất kể có tương tác nào hay không. Do đó, các chỉ số của thao tác điều hướng trước đó phải được hoàn tất khi mỗi thao tác điều hướng mềm mới xảy ra. Điều này có nghĩa là các chỉ số điều hướng "cứng" ban đầu có thể được hoàn tất sớm hơn bình thường khi đo lường Core Web Vitals bằng các thao tác điều hướng mềm.

Tương tự, khi bắt đầu đo lường các chỉ số cho chế độ điều hướng mềm mới của những chỉ số tồn tại lâu này, các chỉ số sẽ cần được "đặt lại" hoặc "khởi động lại" và được coi là chỉ số mới, không có bộ nhớ về các giá trị đã được đặt cho "các trang" trước đó. Tức là thông tin về nội dung hiển thị "lớn nhất", lượt tương tác đến nội dung hiển thị tiếp theo hoặc sự thay đổi bố cục sẽ được đặt lại để cho phép đo lường lại từ đầu.

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

LCP cho thao tác điều hướng mềm (được tính từ interaction-contentful-paint) sẽ chỉ đo lường các lần hiển thị mới và chỉ những lần hiển thị liên kết đến hoạt động tương tác gây ra thao tác điều hướng. Điều này có thể dẫn đến LCP khác, chẳng hạn như từ một lần tải nguội của thao tác điều hướng mềm đó sang một lần tải mềm.

Ví dụ: hãy lấy một trang có chứa một ảnh biểu ngữ lớn là phần tử LCP, nhưng văn bản bên dưới sẽ 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ờ hình ảnh biểu ngữ làm phần tử LCP và dựa vào đó để tính thời gian 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 hiển thị sau thao tác điều hướng mềm và sẽ là phần tử LCP mới. Tuy nhiên, nếu trang đượ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ẽ là một lần hiển thị mới và do đó sẽ đủ điều kiện được coi là phần tử LCP.

Tương tự, một ảnh động có thể liên tục cập nhật một phần của trang mà không liên quan đến bất kỳ thao tác điều hướng mềm nào xảy ra. Mọi hoạt động kết xuất mới do ảnh động nền đó sẽ không được xem xét cho LCP đối với chế độ điều hướng mềm mới. Tuy nhiên, các phần tử này có thể được xem xét cho LCP nếu trang được tải lại từ URL này.

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

Cách đo lường TTFB?

Thời gian cho byte đầu tiên (TTFB) đối với một lần tải trang thông thường là thời gian mà các 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 khó hơn. Chúng ta có nên đo lường yêu cầu đầu tiên được thực hiện 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 nào khác thì sao? Điều gì sẽ xảy ra nếu yêu cầu đó được thực hiện trước bằng một lệnh tìm nạp trước? Điều gì sẽ xảy ra nếu yêu cầu không liên quan đến thao tác điều hướng linh hoạt theo quan điểm của người dùng (ví dụ: đó là yêu cầu phân tích)?

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 cho các thao tác 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 linh hoạt và là phương thức mà chúng tôi đề xuất cho chỉ số này tại thời điểm này.

Bạn có nên đo lường Core Web Vitals bằng cả hai phương pháp không?

Trong quá trình thử nghiệm này, bạn nên tiếp tục đo lường Core Web Vitals theo cách hiện tại, dựa trên các thao tác điều hướng trang "cứng" vì việc triển khai mới có thể gặp vấn đề hoặc thay đổi trước khi được phát hành chính thức. Điều này cũng sẽ khớp với những gì CrUX đo lường hiện tại (sẽ nói thêm về vấn đề này sau).

Bạn nên đo lường các thao tác điều hướng mềm ngoài những thao tác này để biết cách đo lường các thao tác đó trong tương lai, đồng thời có cơ hội gửi ý kiến phản hồi cho nhóm Chrome về cách triển khai này hoạt động trên thực tế. Điều này sẽ giúp bạn và nhóm Chrome định hình API trong tương lai.

Đối với LCP, điều đó có nghĩa là chỉ xem xét các mục largest-contentful-paint cho cách hiện tại và cả các mục largest-contentful-paint và interaction-contentful-paint cho cách mới.

Đối với CLS và INP, điều này có nghĩa là đo lường các chỉ số này trong toàn bộ vòng đời của trang như cách hiện tại, đồng thời phân chia riêng dòng thời gian theo các thao tác điều hướng mềm để đo lường các giá trị CLS và INP riêng biệt cho chỉ số mới.

Dùng thư viện web-vitals để đo lường Core Web Vitals cho các thao tác điều hướng mềm

Cách dễ nhất để tính đến mọi sắc thái là sử dụng thư viện JavaScript web-vitals có hỗ trợ thử nghiệm cho các thao tác điều hướng mềm trong một soft-navs branch riêng biệt (cũng có trên npm và unpkg). Bạn có thể đo lường 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';

function doTraditionalProcessing(callback) {
  ...
}

function doSoftNavProcessing(callback) {
  ...
}

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});

Thư viện web-vitals cũng đảm bảo bạn báo cáo các chỉ số được báo cáo dựa trên URL chính xác như đã lưu ý trước đó, vì các chỉ số này bao gồm cả navigationId và navigationURL trong các mục được cung cấp cho lệnh gọi lại.

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

Những thay đổi này có trở thành một phần của các chỉ số Core Web Vitals không?

Chúng tôi muốn đánh giá các phương pháp phỏng đoán và xem liệu chúng 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 Core Web Vitals hay không. Mục tiêu cuối cùng là cung cấp một phương tiện để đo lường hiệu suất tốt hơn dưới dạng trải nghiệm của người dùng thực tế. Vì vậy, mục tiêu là đưa những chỉ số này vào các phép đo Core Web Vitals mà tất cả các công cụ đều hiển thị nếu thử nghiệm này thành công.

Chúng tôi trân trọng ý kiến phản hồi của nhà phát triển web 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 này phản ánh chính xác hơn trải nghiệm hay không. Kho lưu trữ GitHub về thao tác điều hướng mềm là nơi phù hợp nhất để bạn gửi ý kiến phản hồi đó, mặc dù các lỗi riêng lẻ liên quan đến việc Chrome triển khai thao tác đó nên được báo cáo trong trình theo dõi lỗi của Chrome.

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

Cách chính xác mà 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) vẫn chưa được xác định. Không nhất thiết là các thao tác này sẽ được xử lý giống như các thao tác điều hướng "cứng" hiện tại.

Trong một số trang web, thao tác điều hướng mềm gần như giống hệt với thao tác tải toàn bộ trang đối với người dùng và việc sử dụng công nghệ Ứng dụng trang đơn chỉ là một chi tiết triển khai. Trong những trường hợp khác, chúng có thể 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 những thao tác điều hướng mềm này trong CrUX (Báo cáo trải nghiệm người dùng trên Chrome), hoặc có thể tính trọng số cho những thao tác này khi tính toán Core Web Vitals 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 chế độ điều hướng mềm tải 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 kỹ thuật và kinh nghiệm, điều này sẽ giúp chúng tôi đánh giá mức độ thành công của thử nghiệm này. Vì vậy, chúng tôi chưa đưa ra quyết định nào về những vấn đề này.

Phản hồi

Chúng tôi đang tích cực tìm kiếm ý kiến phản hồi về thử nghiệm này tại những nơi sau:

• Bạn nên nêu ý kiến phản hồi về API dưới dạng vấn đề trên GitHub.
• Các lỗi về việc triển khai Chromium phải được báo cáo trên trình theo dõi vấn đề của Chrome, nếu đây chưa phải là một trong những vấn đề đã biết.
• Bạn có thể chia sẻ ý kiến phản hồi chung về Core Web Vitals tại web-vitals-feedback@googlegroups.com.

Nếu bạn không chắc chắn, đừng lo lắng quá nhiều. Chúng tôi muốn nhận được ý kiến phản hồi ở cả hai nơi và sẽ sẵn sàng phân loại vấn đề ở cả hai nơi cũng như chuyển hướng vấn đề đến đúng nơi.

Nhật ký thay đổi

Vì API này đang trong giai đoạn thử nghiệm, nên có một số thay đổi đang diễn ra đố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ề phương pháp suy đoán điều hướng mềm để biết thêm thông tin chi tiết.

Kết luận

Thử nghiệm điều hướng mềm là một phương pháp thú vị về cách sáng kiến Core Web Vitals có thể phát triển để đo lường một mẫu hình phổ biến trên web hiện đại mà các chỉ số của chúng tôi còn thiếu. Mặc dù thử nghiệm này vẫn đang ở giai đoạn đầu và còn nhiều việc phải làm, nhưng việc cung cấp tiến trình đã đạt được cho cộng đồng web rộng lớn hơn để thử nghiệm là một bước quan trọng. Thu thập ý kiến phản hồi từ thử nghiệm này là một phần quan trọng khác 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 việc phát triển này hãy tận dụng cơ hội này để giúp định hình API, nhằm đảm bảo API này thể hiện được những gì chúng tôi hy vọng có thể đo lường được.

Lời cảm ơn

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

Đây là công việc tiếp nối công việc mà Yoav Weiss bắt đầu khi còn làm việc tại Google. Chúng tôi cảm ơn Yoav vì những nỗ lực của anh ấy đối với API này.