API Soft Navigations w Chrome 151 w końcu pozwala aplikacjom typu single-page (SPA) raportować Core Web Vitals dla każdej nawigacji wewnątrz aplikacji, ale zbiór danych CrUX od Google wciąż rejestruje tylko pierwsze, pełne przeładowanie (hard load), co pozostawia programistów z dwoma rozbieżnymi obrazami wydajności.

Dlaczego metryki SPA pozostawały w tyle

Core Web Vitals — Largest Contentful Paint (LCP), Interaction-to-Next-Paint (INP) oraz Cumulative Layout Shift (CLS) — zostały zdefiniowane w oparciu o twarde nawigacje (hard navigations). Twarda nawigacja pobiera zupełnie nowy dokument i odrzuca stan poprzedniej strony.

Aplikacje SPA budowane w React, Vue, Next.js lub podobnych frameworkach rzadko wywołują twarde nawigacje. Kliknięcie linku aktualizuje adres URL za pomocą History API, pobiera dane w tle i podmienia treść bez pełnego przeładowania strony. Istniejące Performance API rejestruje jedynie początkowe ładowanie strony, przez co LCP i INP nie uwzględniają opóźnień, które użytkownicy odczuwają podczas przechodzenia między kolejnymi trasami (routes).

Ta luka powoduje błędy w pulpitach nawigacyjnych (dashboards), które pobierają dane z Performance Timeline lub raportu Google Chrome User Experience Report (CrUX). Często pokazują one doskonały wynik LCP dla strony typu „shell”, ignorując jednocześnie wolniejsze ładowania głębiej w aplikacji, co daje fałszywe poczucie dobrej wydajności.

API Soft Navigations w Chrome

Chrome 151 wprowadził Soft Navigations API — zestaw heurystyk, które traktują określone interakcje w SPA jak rzeczywiste nawigacje. API monitoruje trzy sygnały:

  • Interakcja zainicjowana przez użytkownika (kliknięcie, dotknięcie, zdarzenie klawiatury)
  • Zmiana adresu URL za pomocą History API
  • Następujące po tym zdarzenia renderowania (paint events), które wyświetlają nową treść

Gdy wszystkie trzy warunki zostaną spełnione, Chrome rejestruje miękką nawigację (soft navigation) w Performance Timeline, a wskaźniki Core Web Vitals są obliczane dla tego przejścia dokładnie tak samo, jak w przypadku twardej nawigacji. Biblioteka open-source web-vitals dodała wsparcie dla tej funkcji 21 lipca, dzięki czemu programiści mogą zacząć pobierać te dane za pomocą tego samego API, którego już używają.

W praktyce można teraz zobaczyć wartość LCP dla każdej zmiany trasy, INP odzwierciedlający rzeczywiste opóźnienie ostatniej interakcji użytkownika oraz CLS rejestrujący przesunięcia układu po miękkiej nawigacji.

Rozbieżność danych: Chrome vs. CrUX

Usługa CrUX (Chrome User Experience Report) od Google zasila PageSpeed Insights, Search Console i pośrednio sygnały rankingowe. CrUX wciąż agreguje dane wyłącznie z twardych nawigacji.

W rezultacie otrzymujemy dwa spójne, ale różne strumienie danych:

  • Narzędzia wewnętrzne, które odczytują Performance Timeline, pokazują teraz LCP, INP i CLS na poziomie poszczególnych tras, dając realistyczny obraz tego, czego doświadczają użytkownicy w aplikacji SPA.
  • Publiczne zbiory danych Google nadal pokazują metryki tylko dla pierwszego ładowania strony, co jest raportowane w Search Console i na czym opierają się algorytmy rankingowe Google.

Oba źródła są poprawne; mierzą po prostu inne momenty. Poleganie wyłącznie na Search Console może maskować regresje wydajności występujące po początkowym załadowaniu strony, podczas gdy same wewnętrzne pulpity nawigacyjne nie odzwierciedlą punktu odniesienia (baseline), którego Google używa do SEO.

Na co muszą zwrócić uwagę programiści

  • Wsparcie przeglądarek – Obecnie Soft Navigations API występuje tylko w przeglądarkach opartych na Chromium. Safari i Firefox nie posiadają odpowiednika, więc należy zachować logikę zapasową (fallback) dla części użytkowników.
  • Ograniczenia heurystyczne – API decyduje o miękkiej nawigacji na podstawie zestawu wskazówek. Jeśli aplikacja aktualizuje treść bez zmiany adresu URL (np. nakładki modalne lub nieskończone przewijanie), API może pominąć te przejścia, co spowoduje luki w danych.
  • Weryfikacja przed zaufaniem – Ponieważ wykrywanie opiera się na heurystyce, należy przeprowadzić zestaw interakcji w rzeczywistych warunkach i porównać raportowane metryki z ręcznym pomiarem czasu (np. za pomocą performance.mark). Dopiero po potwierdzeniu dokładności należy opierać decyzje optymalizacyjne na nowych liczbach.

Podsumowanie

Chrome 151 daje programistom aplikacji SPA długo wyczekiwaną możliwość mierzenia LCP, INP i CLS dla każdej zmiany trasy wewnątrz aplikacji, ale dane rankingowe Google wciąż odzwierciedlają tylko pierwsze, twarde przeładowanie. Dopóki CrUX nie nadrobi zaległości, zespoły będą musiały zarządzać dwoma równoległymi zestawami danych: jednym, który pokazuje prawdziwe doświadczenia użytkowników, i drugim, który wpływa na rankingi w wyszukiwarce. Balansowanie między nimi – oraz przygotowanie się na szersze wsparcie przeglądarek – będzie kluczowe dla utrzymania wydajności aplikacji SPA w konkurencyjnym ekosystemie internetowym.