Đo lường thao tác điều hướng mềm

Barry Pollard

Michal Mocny

Ngày xuất bản: Ngày 1 tháng 2 năm 2023, Ngày cập nhật gần đây nhất: Ngày 24 tháng 6 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 về 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 đo lường thời gian thường không liên quan đến cách người dùng cảm nhận 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 các chỉ số 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 đã thực hiện một số điểm cải tiến đối với đề xuất này dựa trên ý kiến phản hồi của nhà phát triển và đang hướng đến việc phát hành 2 API hiệu suất mới để giúp giải quyết vấn đề này từ Chrome 151.

Thao tác đ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 được 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, định nghĩa này có thể dẫn đến kết quả dương tính giả (người dùng thực sự không 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.

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 DevTools ở 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 tính năng phát hiện thao tác đ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à tính năng 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 tính năng điều hướng mềm (xem thêm về tính năng 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 khởi tạo.
• Một hoặc nhiều mục interaction-contentful-paint sẽ được phát ra sau các hoạt động tương tác gây ra một lần hiển thị nội dung. Thao tác này sẽ chứa một mục largestContentfulPaint có thể dùng để đo Nội dung lớn nhất hiển thị (LCP) cho các thao tác điều hướng mềm.
• Thuộc tính navigationId được thêm vào từng thời gian hiệu suất (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 hàm getLargestInteractionContentfulPaint() để truy xuất mục nhập interaction-contentful-paint lớn nhất cho thao tác điều hướng đó. Sau đó, bạn có thể dùng LCP này làm LCP ban đầu cho hoạt động đ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 đó. Xin lưu ý rằng thuộc tính này sẽ thay thế thuộc tính largestInteractionContentfulPaint có trong các thử nghiệm nguồn gốc trước đây.
• Có thể một số mục interaction-contentful-paint đã xảy ra trước khi thao tác đ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ị đó). Trong những trường hợp này, hàm getLargestInteractionContentfulPaint() không cần phải lưu vào bộ nhớ đệm và xem lại các mục cũ sau khi quá trình điều hướng mềm hoàn tất. Xin lưu ý rằng mục do getLargestInteractionContentfulPaint() trả về là bản sao chính xác của mục interaction-contentful-paint lớn nhất tại thời điểm mục đó được phát, vì vậy, mục đó có thể đã sử dụng navigationId trước đó vì đó là thời điểm xảy ra hoạt động hiển thị, nhưng những hoạt động hiển thị 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 interaction-contentful-paint cũng sẽ được phát sau các hoạt động tương tác khác, nhưng LCP cho một URL phải được giới hạn ở các mục 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 này và cũng chỉ giới hạn ở các thuộc tính largestContentfulPaint trong đó.

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ố điểm khác biệt 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 nào 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ỳ ý chia nhỏ các chỉ số CLS và INP thay vì đo lường trong suốt vòng đời của trang. Tuy nhiên, tính năng Điều hướng mềm 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, vì vậy, 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ể sử 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 bằng cách xem xét thuộc tính largestContentfulPaint trong mục đó. Tuy nhiên, có một số điều cần cân nhắc 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ợ tính năng điều hướng mềm này, đặc biệt là đối với những người dùng 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 các chỉ số Core Web Vitals.

Hãy kiểm tra với nhà cung cấp RUM của bạn để biết họ có hỗ trợ đo lường Core Web Vitals theo điều hướng mềm hay không. Nhiều người đang lên kế hoạch thử nghiệm 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, tính năng thao tác chuyển hướng linh hoạt sẽ được bật trong Chrome 151, nhưng bạn có thể bật tính năng này một cách rõ ràng để kiểm thử trước đó.

Đố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.

Một số chủ sở hữu trang web cũng đã bật tính năng này trên các trang web trước khi phát hành thông qua quy trình bản dùng thử theo nguyên gốc. Xin lưu ý rằng hình dạng API đã thay đổi trong quá trình phát triển tính năng và tính năng được phát hành cuối cùng khác với các bản dùng thử ban đầu trước đó như được nêu chi tiết trong Nhật ký thay đổi về tính năng điều hướng mềm

Tính năng phát hiện hỗ trợ API Điều hướng mềm

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ị đóng băng khi sử dụng lần đầu. Vì vậy, nếu tính năng điều hướng mềm được thêm một cách linh động bằng mã thông báo dùng thử nguồ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 tính năng phát hiện thao tác điều hướng mềm, các chỉ số sẽ 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 đó phải đượ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 phải được 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 nên đặt giá trị này làm từng mục nhập soft-navigation và dùng để báo cáo các chỉ số cho đến khi nhận được mục nhập soft-navigation tiếp theo.

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 ánh xạ 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 hoạt động 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ý hàm getLargestInteractionContentfulPaint() 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 ánh xạ đến 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 mục getLargestInteractionContentfulPaint(). 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 để đặ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 liên quan đến 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 vòng đờ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 lần điều hướng?

LCP cho các 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 quan đến lượt 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 hình ả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 trang được tải – 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 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 này không?

Mặc dù các API mới này chỉ giới hạn ở các trình duyệt dựa trên Chromium, nhưng các trang web có thể muốn đo lường cả hai bằng cách phân chia theo thao tác điều hướng mềm và bằng cách tiếp tục phân chia theo thao tác điều hướng cứng. Điều này sẽ cho phép so sánh trên nhiều trình duyệt và theo xu hướng trước đây.

Đố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.

Sau đó, các chỉ số này cần được báo cáo và lưu trữ hai lần để phân tích.

Sử 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?

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 các chỉ số này vào phép đo Các chỉ số quan trọng về trang web do tất cả các công cụ cung cấp sau khi API được ra mắt.

Chúng tôi trân trọng ý kiến phản hồi của nhà phát triển web về API này và liệu bạn có cảm thấy API 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 linh hoạt 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 điều hướng linh hoạt 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 sau khi tính năng này ra mắt vẫn chưa được xác định. Chúng tôi sẽ thông báo về những thay đổi đối với CrUX khi có thêm thông tin để chia sẻ tại đây.

Phản hồi

Chúng tôi đang tích cực thu thập ý kiến phản hồi về API 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.
• Nếu đây chưa phải là một trong những vấn đề đã biết, thì bạn nên báo cáo lỗi về việc triển khai Chromium trên trình theo dõi vấn đề của Chrome.
• 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 vấn đề đến đúng vị trí.

Nhật ký thay đổi

Trong quá trình phát triển API này, đã 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ề thao tác điều hướng mềm để biết thêm thông tin chi tiết.

Kết luận

Tính năng Điều hướng mềm là một phương pháp thú vị về cách sáng kiến Chỉ số quan trọng chính của trang web 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. Chúng tôi đã thu thập được nhiều ý kiến phản hồi từ cộng đồng web nói chung và chúng tôi 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 các API nhằm đảm bảo API này đại diện cho 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

Công việc này là sự tiếp nối công việc do 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.