Đ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 nhất: Ngày 20 tháng 9 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 tạo hoặc tải trang web. Ba chỉ số Core Web Vitals được tạo ra dưới dạng chỉ số lấy người dùng làm trung tâm – 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 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 điểm số, miễn là trang web hoạt động tốt.

Thực tế luôn phức tạp hơn một chút so với lý thuyết, 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à "đ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ề 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 những gì trình duyệt thường hiểu là một "trang", nên việc đo lường điều này luôn gặp khó khăn: ranh giới giữa một lượt tương tác trên trang hiện tại và việc coi đây là một trang mới là gì?

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ề "điều hướng mềm" cũng như cách đo lường Core Web Vitals cho việc này – 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 cho đề xuất dựa trên ý kiến phản hồi của nhà phát triển và đã ra mắt hai API hiệu suất mới để giúp giải quyết vấn đề này từ Chrome 151. Ngoài ra, chúng tôi đã cung cấp các chỉ số về thao tác điều hướng mềm trong Báo cáo trải nghiệm người dùng trên Chrome (CrUX) dưới dạng chỉ số thử nghiệm.

Thế nào là điều hướng mềm?

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

• Thao tác điều hướng do người dùng thực hiện.
• Thao tác điều hướng dẫn đến thay đổi URL mà người dùng có thể thấy.
• Lượt tương tác dẫn đến một nội dung 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 không thực sự coi là đã xảy ra "hoạt động điều hướng") hoặc âm tính giả (người dùng coi là đã xảy ra "hoạt độ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ữ thông số kỹ thuật điều hướng mềm.

Hỗ trợ của Công cụ cho nhà phát triển cho thao tác điều hướng mềm

Chúng tôi đã thêm tính năng hỗ trợ cho thao tác điều hướng mềm vào bảng Hiệu suất của DevTools trong chế độ xem Chỉ số theo thời gian thực, cũng như trong chế độ xem dấu vết có hỗ trợ Thông tin chi tiết và điểm đánh dấu:

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

Sau khi bật tính năng điều hướng mềm (xem thêm thông tin 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 khi phát hiện thấy mỗi lần điều hướng mềm.
• Mục nhập soft-navigation này sẽ bao gồm navigationId, URL mới trong thuộc tính name, cũng như interactionId của hoạt động tương tác bắt đầu.
• Một hoặc nhiều mục nhập interaction-contentful-paint sẽ được phát ra sau các lượt tương tác gây ra nội dung hiển thị. Mục này sẽ chứa một mục largestContentfulPaint có thể dùng để đo lường 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 mỗi 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 đ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 nhập được phát ra. Bạn có thể tìm hiểu thêm về vấn đề này trong phần Báo cáo chỉ số cho 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 thành phần điều hướng đó. Sau đó, bạn có thể dùng giá trị này làm LCP ban đầu cho hoạt động điều hướng đó và có thể cập nhật LCP đó khi quan sát thấy nhiều mục nhập interaction-contentful-paint hơn cho hoạt động tương tác đó. Lưu ý rằng thuộc tính này thay thế thuộc tính largestInteractionContentfulPaint có trong các bản dùng thử theo nguyên gốc trước đây.
• Có thể một số mục nhập interaction-contentful-paint đã xảy ra trước khi quá trình điều hướng mềm diễn ra (nếu quá trình cập nhật URL không xảy ra cho đến sau những lần vẽ đó). Trong những trường hợp này, hàm getLargestInteractionContentfulPaint() giúp tránh phải lưu vào vùng đệ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 nhập do getLargestInteractionContentfulPaint() trả về là bản sao chính xác của mục nhập interaction-contentful-paint lớn nhất tại thời điểm mục nhập đó được phát ra, vì vậy, mục nhập đó có thể đã sử dụng navigationId trước đó vì đó là thời điểm xảy ra quá trình hiển thị, nhưng các quá trình hiển thị này phải được đo lường theo navigationId mới.
• Mục nhập soft-navigation cũng sẽ bao gồm paintTime và presentationTime dưới dạng FCP cho thao tác điều hướng đó.
• Xin lưu ý rằng các mục nhập interaction-contentful-paint cũng sẽ được phát ra 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 và cũng chỉ cho 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) cho mỗi lần đ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ó ý nghĩa gì?

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 nhập soft-navigation cho phép "cắt" các mục nhập hiệu suất thành từng "thao tác điều hướng".
• Bạn đã có thể phân chia các chỉ số CLS và INP theo ý muốn, thay vì đo lường trong suốt thời gian của toàn bộ vòng đời trang, nhưng tính năng Điều hướng mềm cung cấp một thước đo chuẩn hoá về thời điểm xảy ra việc này, bất kể công nghệ cơ bản được sử dụng.
• Mục nhập largest-contentful-paint được hoàn tất dựa trên 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 nhập này chỉ có thể được dùng để đo lường LCP cho thao tác đ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 đo lường thao tác điều hướng mềm, vì vậy, LCP cho lượt tải trang điều hướng cứng ban đầu có thể được đo lường như trước đây.
• Bạn có thể sử dụng mục nhập interaction-contentful-paint mới được phát ra từ các lượt tương tác để đo lường LCP cho các thao tác điều hướng mềm bằng cách xem thuộc tính largestContentfulPaint trong đó, nhưng có một số điểm cần lưu ý về cách sử dụng mục nhập 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à những người dùng trình duyệt khác hoặc phiên bản Chrome trước 151. 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 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 thử nghiệm tiêu chuẩn mới này và sẽ cân nhắc những điểm nêu trên. Trong thời gian chờ đợi, một số nhà cung cấp cũng cho phép đo lường hạn chế 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?

Tính năng điều hướng mềm được bật theo mặc định từ Chrome 151.

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

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

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

Hoặc:

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

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

Nếu được hỗ trợ, bạn có thể báo cáo các chỉ số này bằng API PerformanceObserver như các chỉ số khác. Tuy nhiên, bạn cần lưu ý thêm một số điều đố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ể sử dụng PerformanceObserver để quan sát các thao tác điều hướng mềm. Sau đây là đoạn mã ví dụ 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 cách sử dụng tuỳ chọn buffered:

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

Bạn có thể dùng sự kiện này để hoàn tất các chỉ số về toàn bộ vòng đời của trang cho hoạt động điều hướng trước đó.

Báo cáo các chỉ số cho URL thích hợp

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

Thuộc tính name của mục nhập soft-navigation thích hợp sẽ chứa URL mới để báo cáo các chỉ số báo cáo và navigationId sẽ là tệp đối chiếu duy nhất cho thao tác đ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 hoạt động của một ứng dụng trang đơn).

Bạn nên đặt giá trị này cho mỗi 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 khi 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 phải đượ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 nhập 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 lượt hiển thị xảy ra trước khi cập nhật URL. 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ì lượt hiển thị sẽ hoàn tất quá trình điều hướng mềm và trong trường hợp đó, mục nhập soft-navigation sẽ được phát ra 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 mở rộng ra ngoài LCP cho các thao tác điều hướng mềm. Chúng tôi 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 nhập interaction-contentful-paint với soft-navigation-entries nhằm lấy được URL chính xác. Thao tác này sẽ xử lý mọi mục nhập có navigationId cũ cũng như lọc ra mọi mục nhập interaction-contentful-paint không nên được xem xét cho LCP.

Ngoài ra, trước tiên, bạn nên xử lý hàm getLargestInteractionContentfulPaint() của các mục nhập soft-navigation để xử lý các mục nhập interaction-contentful-paint xảy ra trước khi soft-navigation entries được phát ra.

Nắm bắt startTime của thao tác điều hướng mềm

Tất cả thời gian hiệu suất, bao gồm cả thời gian điều hướng mềm và các mục dùng để tính toán các 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 đó, thời gian bắt đầu điều hướng mềm phải được trừ 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 tương ứng với thời gian điều hướng mềm này.

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

startTime là thời điểm 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 "điều hướng cứng", trong đó "thời gian bắt đầu" là thời điểm trang mới được "cam kết" 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 Các chỉ số quan trọng về trang web cho mỗi lần điều hướng mềm

Để đo lường Core Web Vitals, hãy theo dõi các mục nhập soft-navigation, đặt lại các chỉ số khi nhận được các mục nhập này. FCP có thể được phát ra dựa trên presentationTime và LCP có thể được khởi chạy cho mục nhập 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 các chỉ số LCP, INP và CLS như bình thường (ngoại trừ việc sử dụng interaction-contentful-paint cho LCP, miễn là interactionId khớp). Bạn có thể sử dụng interactionId để đặt tên cho các mục nhập vào 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 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ư đã trình bày chi tiết trước đó để có được thời gian tương ứng với thao tác điều hướng mềm.

Một số chỉ số thường được đo lường trong suốt thời gian hoạt động của trang: ví dụ: LCP có thể thay đổi cho đến khi có 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ó lượt 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 diễn 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 tính năng điều hướng mềm.

Tương tự, khi bắt đầu đo lường các chỉ số cho thao tác điều hướng mềm mới của các chỉ số tồn tại lâu dài 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 "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 mức thay đổi bố cục sẽ được đặt lại để cho phép đo lường lại từ đầu.

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

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ượt hiển thị mới và chỉ những lượt hiển thị liên quan đế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 nhau giữa lượt tải nguội của thao tác điều hướng mềm đó và lượt tải mềm.

Ví dụ: hãy xem xét một trang có hình ảnh biểu ngữ lớn là phần tử LCP, nhưng văn bản bên dưới hình ảnh đó thay đổi theo mỗi lần điều hướng mềm. Lần tải trang đầu tiên sẽ gắn cờ hình ảnh biểu ngữ là phần tử LCP và dựa vào thời gian LCP trên đó. Đố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 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ượt 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, 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 lượt vẽ mới do ảnh động nền đó sẽ không được xem xét cho LCP cho thao tác đ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ư các 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 nhau tuỳ thuộc vào cách tải trang – giống như cách tải một trang có đường dẫn liên kết neo ở phía dướ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.

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

Thời gian cho byte đầu tiên (TTFB) cho một lượt tải trang thông thường thể hiện 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 tính năng tìm nạp trước? Điều gì sẽ xảy ra nếu một yêu cầu không liên quan đến thao tác điều hướng mềm 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, tương tự như cách chúng tôi đề xuất cho việ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 mềm và là phương thức chúng tôi đề xuất cho chỉ số này tại thời điểm hiện tại.

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

Mặc dù các API mới này chỉ dành cho 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à tiếp tục phân chia theo thao tác điều hướng cứng. Điều này cho phép so sánh giữa các trình duyệt và xu hướng trước đây.

Đối với LCP, điều này có nghĩa là chỉ xem xét các mục nhập largest-contentful-paint cho cách hiện tại và cả mục nhập 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 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 thao tác điều hướng mềm mới.

Sau đó, các chỉ số sẽ cần được báo hiệu 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 thao tác điều hướng mềm

Cách dễ nhất để tính đến tất cả các sắc thái là sử dụng thư viện JavaScript web-vitals có hỗ trợ thao tác điều hướng mềm kể từ phiên bản 6.0.0. Bạn có thể đo lường điều 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';

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 theo đúng URL 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 đây cho thao tác điều hướng mềm:

Những thay đổi này có trở thành một phần trong các phép đo lường 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 theo 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 kết quả đo lường Các chỉ số quan trọng về trang web do tất cả công cụ hiển thị sau khi API được ra mắt.

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

Chúng tôi đã ra mắt các phiên bản thử nghiệm của chỉ số Core Web Vitals trong CrUX. Các chỉ số này kết thúc CLS và INP "điều hướng cứng" sau lần điều hướng mềm đầu tiên, đồng thời bao gồm các chỉ số LCP, CLS và INP bổ sung cho mỗi lần điều hướng mềm. Chúng tôi dự định sẽ chuyển các chỉ số thử nghiệm này thành chỉ số ổn định vào tháng 5 năm 2027. Để biết thêm thông tin, hãy xem bài đăng trên blog Chỉ số điều hướng mềm thử nghiệm hiện có trong CrUX.

Làm cách nào để xử lý thao tác điều hướng mềm trong các trình duyệt khác?

Rất khó để phát hiện các thao tác điều hướng mềm theo phương thức lập trình trong các trình duyệt không hỗ trợ API này. Đó chính là lý do chúng tôi phát triển API này.

Bạn có thể sử dụng Navigation API để theo dõi các thay đổi về URL, nhờ đó có thể phân chia INP theo URL (và CLS tương tự, mặc dù hiện tại chỉ có Chromium nên sẽ không được đo lường). Tuy nhiên, điều này không giải quyết được các chỉ số hiển thị (FCP và LCP) vốn chỉ có thể ước chừng.

Đồng thời, chúng tôi tin rằng thông tin chi tiết mà API này cung cấp là quá giá trị để bỏ qua, cả trong việc đo lường thời gian điều hướng mềm và phân bổ các chỉ số cho đúng hoạt động điều hướng. Bạn nên sử dụng API mới này mặc dù hiện tại chưa có tính năng hỗ trợ trên nhiều trình duyệt. Tương tự như khi Core Web Vitals ra mắt, các vấn đề được xác định và giải pháp hiệu suất có thể sẽ ảnh hưởng đến tất cả trình duyệt, ngay cả khi hiện tại khả năng hiển thị chỉ giới hạn ở các trình duyệt dựa trên Chromium.

Chúng tôi sẽ tiếp tục thực hiện quy trình chuẩn hoá và hợp tác với các nhà cung cấp trình duyệt khác để cho thấy tầm quan trọng của API 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ề API này tại những nơi sau:

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

Nếu bạn không chắc chắn, đừng lo lắng quá. Chúng tôi muốn nhận được ý kiến phản hồi ở cả hai nơi và 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

Khi API này được phát triển, một số thay đổi đã xảy ra, nhiều hơn so với các API ổn định. Bạn có thể xem Nhật ký thay đổi về điều hướng mềm để biết thêm thông tin chi tiết.

Kết luận

Tính năng Thao tác mềm là một phương pháp thú vị cho thấy 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 phổ biến trên web hiện đại mà các chỉ số của chúng tôi chưa có. Chúng tôi đã thu thập được nhiều ý kiến phản hồi từ cộng đồng web rộng lớn hơn và chúng tôi rất phấn khởi trước tiềm năng của API này.

Xác nhậ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ủa công việc do Yoav Weiss bắt đầu khi anh ấy 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.