API Soft Navigations của Chrome 151 cuối cùng cũng cho phép các ứng dụng đơn trang (SPA) báo cáo Core Web Vitals cho mọi lần điều hướng trong ứng dụng, nhưng tập dữ liệu CrUX của Google vẫn chỉ ghi lại lần tải cứng (hard load) đầu tiên, khiến các nhà phát triển phải đối mặt với hai bức tranh hiệu suất khác nhau.

Tại sao các chỉ số SPA lại bị tụt hậu

Core Web Vitals—Largest Contentful Paint (LCP), Interaction-to-Next-Paint (INP) và Cumulative Layout Shift (CLS)—được định nghĩa dựa trên các điều hướng cứng (hard navigations). Một điều hướng cứng sẽ tải một tài liệu hoàn toàn mới và hủy bỏ trạng thái của trang trước đó.

Các SPA được xây dựng bằng React, Vue, Next.js hoặc các framework tương tự hiếm khi kích hoạt điều hướng cứng. Việc nhấp vào một liên kết sẽ cập nhật URL thông qua History API, tải dữ liệu ngầm và thay đổi nội dung mà không cần tải lại toàn bộ trang. Performance API hiện tại chỉ ghi lại lần tải trang đầu tiên, vì vậy LCP và INP không bao giờ thấy được độ trễ mà người dùng cảm nhận khi họ chuyển từ route này sang route khác.

Điểm mù đó làm sai lệch các bảng điều khiển (dashboards) lấy dữ liệu từ Performance Timeline hoặc Báo cáo Trải nghiệm Người dùng Chrome (CrUX) của Google. Chúng thường hiển thị chỉ số LCP tuyệt vời cho trang "vỏ" (shell) trong khi bỏ qua các lần tải chậm hơn ở sâu bên trong ứng dụng, tạo ra một cảm giác sai lầm về sức khỏe hiệu suất.

Chrome's Soft Navigations API

Chrome 151 đã giới thiệu Soft Navigations API, một tập hợp các quy tắc heuristic coi một số tương tác SPA là các lần điều hướng thực sự. API này theo dõi ba tín hiệu:

  • Một tương tác do người dùng khởi xướng (click, chạm, sự kiện bàn phím)
  • Thay đổi URL thông qua History API
  • Các sự kiện paint (vẽ) tiếp theo để hiển thị nội dung mới

Khi cả ba yếu tố này khớp nhau, Chrome sẽ ghi lại một soft navigation (điều hướng mềm) trong Performance Timeline, và các chỉ số Core Web Vitals sẽ được tính toán cho lần chuyển đổi đó giống như đối với một điều hướng cứng. Thư viện mã nguồn mở web-vitals đã thêm hỗ trợ vào ngày 21 tháng 7, vì vậy các nhà phát triển có thể bắt đầu lấy các con số này bằng chính API mà họ đang sử dụng.

Trong thực tế, giờ đây bạn sẽ thấy giá trị LCP cho mỗi lần thay đổi route, một chỉ số INP phản ánh độ trễ thực sự của lần nhập liệu cuối cùng từ người dùng, và một chỉ số CLS ghi lại các thay đổi bố cục sau một lần điều hướng mềm.

Sự phân tách dữ liệu: Chrome so với CrUX

CrUX (Chrome User Experience Report) của Google cung cấp dữ liệu cho PageSpeed Insights, Search Console và gián tiếp là các tín hiệu xếp hạng. CrUX vẫn chỉ tổng hợp dữ liệu điều hướng cứng.

Do đó, bạn sẽ có hai luồng dữ liệu nhất quán nhưng khác nhau:

  • Các công cụ nội bộ đọc từ Performance Timeline hiện hiển thị LCP, INP và CLS ở cấp độ route, mang lại cái nhìn thực tế về những gì người dùng trải nghiệm trong một SPA.
  • Các tập dữ liệu công khai của Google tiếp tục chỉ hiển thị các chỉ số cho lần tải trang đầu tiên, đây là những gì Search Console báo cáo và là những gì các thuật toán xếp hạng của Google tham chiếu.

Cả hai đều đúng; chúng chỉ đo lường các thời điểm khác nhau. Việc chỉ dựa vào Search Console có thể che giấu các lỗi suy giảm hiệu suất xảy ra sau lần tải đầu tiên, trong khi chỉ dựa vào các bảng điều khiển nội bộ sẽ không phản ánh được mức cơ sở (baseline) mà Google sử dụng cho SEO.

Những điều nhà phát triển cần lưu ý

  • Hỗ trợ trình duyệt – Soft Navigations API hiện chỉ có trên các trình duyệt dựa trên Chromium. Safari và Firefox hiện chưa có tính năng tương đương, vì vậy bạn phải duy trì logic dự phòng (fallback logic) cho một phần đối tượng người dùng của mình.
  • Giới hạn heuristic – API quyết định một lần điều hướng mềm dựa trên một tập hợp các dấu hiệu. Nếu ứng dụng của bạn cập nhật nội dung mà không thay đổi URL (ví dụ: các lớp phủ modal hoặc cuộn vô hạn), API có thể bỏ lỡ các lần chuyển đổi đó, để lại lỗ hổng trong dữ liệu.
  • Kiểm tra trước khi tin tưởng – Vì việc phát hiện dựa trên heuristic, hãy chạy một loạt các tương tác thực tế trên ứng dụng của bạn và so sánh các chỉ số được báo cáo với thời gian đo thủ công (ví dụ: sử dụng performance.mark). Chỉ sau khi xác nhận độ chính xác, bạn mới nên dựa vào các con số mới để đưa ra các quyết định tối ưu hóa.

Kết luận

Chrome 151 mang lại cho các nhà phát triển SPA khả năng mong đợi từ lâu là đo lường LCP, INP và CLS cho mỗi lần thay đổi route trong ứng dụng, nhưng dữ liệu xếp hạng của Google vẫn chỉ phản ánh lần tải cứng đầu tiên. Cho đến khi CrUX bắt kịp, các đội ngũ phải xoay xở với hai tập dữ liệu song song: một tập dữ liệu kể về trải nghiệm thực tế của người dùng, và một tập dữ liệu khác thúc đẩy thứ hạng tìm kiếm. Việc cân bằng cả hai — và chuẩn bị cho sự hỗ trợ trình duyệt rộng rãi hơn — sẽ là chìa khóa để duy trì các SPA ưu tiên hiệu suất trong một hệ sinh thái web đầy cạnh tranh.