Odpowiedzi na najczęstsze pytania dotyczące aplikacji jednostronicowych, Core Web Vitals i sposobu ich traktowania przez te wskaźniki
Opublikowano: 14 września 2021 r., ostatnia aktualizacja: 11 sierpnia 2026 r.
Od czasu wprowadzenia inicjatywy Web Vitals w maju 2020 r. zespół Chrome otrzymał wiele świetnych pytań i opinii na temat tego programu.
Najwięcej pytań dotyczyło tego, jak mierzyć Core Web Vitals w aplikacji jednostronicowej (SPA) oraz jak architektura SPA wpływa na wyniki Core Web Vitals. Jest to też prawdopodobnie najtrudniejsze pytanie.
Odpowiedź na te pytania jest trudna, ponieważ problem jest dość złożony. W tym poście postaramy się odpowiedzieć na najczęstsze pytania, podając jak najwięcej szczegółów i kontekstu.
Zanim jednak przejdziemy do szczegółów, warto zaznaczyć, że Google nie preferuje żadnej architektury ani technologii używanej do tworzenia witryny. Uważamy, że zarówno aplikacje jednostronicowe, jak i wielostronicowe mogą zapewniać użytkownikom wysoką jakość, a celem inicjatywy Web Vitals jest udostępnienie danych, które mierzą wrażenia niezależnie od technologii.
Najczęstsze pytania
Oto niektóre z najczęstszych pytań, które otrzymujemy na ten temat. Chętnie przyjmiemy opinie, które możemy dodać do tych najczęstszych pytań w naszej grupie opinii lub zgłaszając problem.
Czy Core Web Vitals obejmują przejścia między trasami w aplikacjach jednostronicowych?
Po wprowadzeniu każdy z podstawowych wskaźników internetowych był mierzony w odniesieniu do bieżącej nawigacji na stronie najwyższego poziomu. Jeśli strona dynamicznie wczytywała nowe treści i aktualizowała adres URL w pasku adresu, nie miało to wpływu na sposób pomiaru podstawowych wskaźników internetowych.
Wartości danych nie były resetowane, a adres URL powiązany z każdym pomiarem danych to adres URL, do którego użytkownik przeszedł, aby zainicjować wczytanie strony.
W Chrome 151 wprowadziliśmy nowe interfejsy API, które umożliwiają pomiar Core Web Vitals podczas przejść między trasami w aplikacjach jednostronicowych. W momencie pisania tego tekstu (sierpień 2026 r.) te interfejsy API dopiero zaczynają być używane w bibliotekach pomiarowych, takich jak web-vitals, rozwiązaniach RUM i narzędziach, takich jak Narzędzia deweloperskie w Chrome. Chrome nie opublikował jeszcze harmonogramu integracji tych interfejsów API z Raportem na temat użytkowania Chrome (CrUX). Ponadto inne silniki przeglądarek nie obsługują jeszcze tych nowych interfejsów API, dlatego Core Web Vitals można mierzyć tylko podczas pełnego wczytywania strony w tych przeglądarkach.
Dlaczego rozwiązanie tego problemu było trudne?
Obecnie nie ma standardowego sposobu tworzenia aplikacji jednostronicowej. Nawet w przypadku popularnych bibliotek SPA i routingu wrażenia użytkownika mogą się znacznie różnić w zależności od aplikacji:
- Niektóre aplikacje jednostronicowe aktualizują adres URL tylko wtedy, gdy wczytują nowe treści „pełnej strony”, a inne witryny aktualizują adres URL w przypadku niewielkich zmian treści lub nawet tylko zmian stanu interfejsu.
- Niektóre aplikacje jednostronicowe aktualizują adres URL za pomocą interfejsu History API, a inne używają zmian skrótu, aby obsługiwać starsze przeglądarki (a inne w ogóle nie aktualizują adresu URL).
- Niektóre aplikacje jednostronicowe wczytują treści, a następnie aktualizują adres URL, a inne aktualizują adres URL przed wczytaniem treści.
- Niektóre aplikacje jednostronicowe wczytują treści naraz, synchronicznie, w ramach jednego zadania JavaScript, a inne przechodzą do treści asynchronicznie, w ramach wielu zadań (bez wyraźnego zdarzenia zakończenia przejścia).
- Niektóre aplikacje jednostronicowe zawsze wczytują treści z sieci, a inne wstępnie wczytują wszystkie treści, aby zmiany tras wczytywały się natychmiast z pamięci.
Te różnice sprawiają, że zdefiniowanie i zidentyfikowanie, co stanowi zmianę trasy w aplikacji jednostronicowej, a nawet samą aplikację jednostronicową, jest bardzo trudne na dużą skalę.
W niektórych przypadkach zmiana trasy w aplikacji jednostronicowej jest logicznie identyczna z wczytaniem strony w aplikacji wielostronicowej. W takich przypadkach warto byłoby zastosować istniejące Core Web Vitals.
Jednak bez solidnych heurystyk, które pozwalają niezawodnie odróżnić „prawdziwe” zmiany tras od wszystkich innych zmian adresów URL, oraz bez wyraźnych sygnałów oznaczających początek i koniec takich przejść, raportowanie Core Web Vitals w tych przypadkach zniekształcałoby dane i sprawiało, że byłyby one mniej przydatne lub reprezentatywne dla rzeczywistych wrażeń użytkownika w witrynie.
Prace nad nawigacją miękką przyniosły rozwiązanie tego problemu dzięki 2 nowym interfejsom API dotyczącym wydajności:
PerformanceSoftNavigation, który mierzy, kiedy interakcja użytkownika prowadzi zarówno do wyrenderowania, jak i zmiany adresu URL. Połączenie tych 3 elementów zapewnia standardową definicję „nawigacji miękkiej” niezależnie od używanej platformy i niektórych wspomnianych wcześniej różnic. Umożliwia to podzielenie osi czasu wydajności na osobne „nawigacje”, co pozwala mierzyć CLS i INP dla każdej nawigacji.InteractionContentfulPaint, który mierzy „wyrenderowania treści” po interakcji, co pozwala mierzyć FCP i LCP w przypadku tych nawigacji miękkich.
Połączenie tych 2 interfejsów API umożliwia pomiar Core Web Vitals zarówno podczas pełnego wczytywania strony, jak i nawigacji miękkiej.
Czy zmiany tras w aplikacjach jednostronicowych są takie same jak pełne wczytywanie strony w przypadku Core Web Vitals?
Nie, nadal istnieje wiele różnic między tymi typami nawigacji, które mogą powodować różne podstawowe wskaźniki internetowe.
Nawigacja miękka zawiera treści na stronie i aktualizuje niektóre lub wszystkie te treści, aby wyświetlić nową „stronę”. Pod wieloma względami jest to podobne do różnicy między pełnym wczytaniem strony bez pamięci podręcznej a wczytaniem strony, gdy niektóre lub wszystkie zasoby strony są w pamięci podręcznej, ale w jeszcze bardziej ekstremalnym stanie, ponieważ niektóre treści mogą pozostać wyrenderowane.
Teoretycznie główną różnicą będzie potencjał nawigacji miękkiej do bycia znacznie szybszą. Istnieją jednak inne, bardziej subtelne różnice.
Nowe interfejsy API nawigacji miękkiej uwzględniają tylko nowe treści. Dlatego strona, która aktualizuje <h1> i treść tekstową, ale pozostawia ten sam baner powitalny między stronami, nie będzie traktować baneru powitalnego jako kandydata do LCP, jeśli nie zostanie on ponownie wyrenderowany. Spowoduje to różnice w tym, które elementy są używane do obliczania czasu LCP, w zależności od tego, czy ta sama strona jest wczytywana jako pełne wczytanie strony, czy jako nawigacja miękka z innej istniejącej strony.
Podobnie INP może być mniejszy w przypadku nawigacji miękkiej, ponieważ wiele kodu JavaScript potrzebnego do działania witryny będzie już wczytane. W ten sam sposób nawigacja miękka może mieć mniej (lub więcej!) CLS, jeśli ta sama treść powoduje CLS podczas pełnego wczytywania strony, ale nie musi być wczytywana ani ponownie renderowana podczas nawigacji miękkiej.
Istnieją też niewielkie różnice w tym, kiedy pomiary są wykonywane podczas pełnego wczytywania strony (mierzone po przetworzeniu interakcji nawigacji) a nawigacji miękkiej (mierzone od czasu rozpoczęcia interakcji).
Jak wspomnieliśmy wcześniej, wiele z tych różnic jest podobnych do różnic między stronami bez pamięci podręcznej a stronami z pamięcią podręczną, a koncepcja tego, co próbują mierzyć Core Web Vitals, nadal obowiązuje. Warto jednak zrozumieć te subtelności podczas analizowania problemów z podstawowymi wskaźnikami internetowymi.
Czy aplikacjom jednostronicowym trudniej jest osiągać dobre wyniki w Core Web Vitals niż aplikacjom wielostronicowym?
Architektura SPA nie ma żadnych wrodzonych cech, które uniemożliwiałyby wczytywanie strony w aplikacji jednostronicowej tak samo szybko jak podobnej strony w aplikacji wielostronicowej i uzyskiwanie tak samo dobrych wyników we wszystkich podstawowych wskaźnikach internetowych.
Jednak prawidłowo zoptymalizowane aplikacje wielostronicowe mają pewne zalety w zakresie spełniania progów podstawowych wskaźników internetowych, których nie mają aplikacje jednostronicowe. W dużej mierze zostało to złagodzone dzięki pracom nad nawigacją miękką, o których wspomnieliśmy wcześniej, ale może się tak zdarzyć, gdy te nowe interfejsy API nie są jeszcze używane. Dzieje się tak, ponieważ w architekturze MPA każda „strona” jest wczytywana jako pełna nawigacja (zamiast dynamicznego pobierania treści i wstawiania ich do istniejącej strony), co oznacza, że użytkownicy odwiedzający MPA częściej wczytują więcej niż 1 stronę z witryny. Z kolei oznacza to, że większy odsetek rozkładu wszystkich wczytań stron w MPA będzie obejmował niektóre lub wszystkie zasoby podrzędne w pamięci podręcznej.
Oczywiście, aby MPA osiągała lepsze wyniki w podstawowych wskaźnikach internetowych Core Web Vitals niż SPA, musi być spełnionych kilka warunków:
- MPA musi mieć zoptymalizowane buforowanie zasobów podrzędnych, aby zapewnić, że wczytywanie stron z tej samej domeny jest rzeczywiście szybsze niż wczytywanie stron z różnych domen w 75. percentylu.
- Użytkownicy odwiedzający MPA muszą odwiedzić wiele stron, aby witryna mogła korzystać z buforowania, co skutkuje szybszym wczytywaniem stron.
Ponieważ oceny Core Web Vitals uwzględniają 75. percentyl wizyt na stronie, większa liczba dobrze działających wizyt na stronie w zbiorze danych zwiększy prawdopodobieństwo, że wizyta w 75. percentylu rozkładu będzie mieścić się w zalecanych progach.
Pamiętaj, że podczas porównywania wyników podstawowych wskaźników internetowych ważne jest, aby wziąć pod uwagę sposób agregowania danych, czyli czy zbiór danych w rozkładzie obejmuje wszystkie strony z Twojej witryny lub domeny, czy tylko wczytywanie stron dla określonego adresu URL.
Podczas agregowania wyników wszystkich stron w domenie poszczególne szybkie strony mogą poprawić 75. percentyl dla całej domeny. Jednak podczas agregowania według poszczególnych stron wyniki jednej strony nie będą wpływać na wyniki następnej. Innymi słowy, podczas agregowania wyników MPA według strony szybkie wczytywanie z pamięci podręcznej na stronie płatności nie poprawi wyników powolnego wczytywania początkowego na stronie docelowej witryny.
Wynik witryny w przypadku różnych metod agregacji możesz sprawdzić za pomocą PageSpeed Insights lub interfejsu Raport na temat użytkowania Chrome API, który raportuje wyniki zarówno dla poszczególnych adresów URL, jak i dla całego origin.
Innym sposobem, w jaki architektura SPA może wpływać na wyniki Core Web Vitals, są dane, które uwzględniają cały okres istnienia strony. Ponieważ użytkownicy odwiedzający aplikacje jednostronicowe zwykle pozostają na tej samej „stronie” przez całą sesję, dane, które gromadzą się z upływem czasu, mogą być bardziej rygorystyczne w przypadku aplikacji jednostronicowych niż wielostronicowych.
Uważamy, że dzięki pracom nad nawigacją miękką aplikacje jednostronicowe nie powinny mieć żadnych wad w zakresie sposobu pomiaru Core Web Vitals. Pełna integracja tych interfejsów API ze wszystkimi narzędziami i rozwiązaniami do raportowania zajmie jednak trochę czasu.
Jeśli architektura SPA poprawia wrażenia użytkownika, czy ta poprawa nie powinna być odzwierciedlona w danych?
Tak, powinna. Określenie, o ile poprawiły się wrażenia, było trudne na dużą skalę ze względu na różne sposoby implementacji aplikacji jednostronicowych w internecie. Mamy już rozwiązanie problemu z pomiarami. Gdy te nowe interfejsy API będą używane, wszelkie ulepszenia wynikające z przejścia na aplikacje jednostronicowe powinny być odzwierciedlone w danych.
Prawda jest taka, że branża wydajności stron internetowych (w tym Google) historycznie nie poświęcała tyle czasu i wysiłku na opracowywanie danych zorientowanych na użytkownika dotyczących wydajności strony po wczytaniu, co na samo wczytywanie strony. Nie wynika to z tego, że wydajność po wczytaniu nie jest ważna, ale z tego, że wrażenia użytkownika i interakcje po wczytaniu są znacznie bardziej zróżnicowane i mniej dobrze zdefiniowane, co utrudnia projektowanie danych dla nich.
Jednak nawet teraz, gdy mamy więcej danych po wczytaniu do pomiaru wydajności aplikacji jednostronicowej, nie chcemy ignorować wrażeń podczas wczytywania tylko dlatego, że wrażenia po wczytaniu się poprawiły.
Jednym z celów inicjatywy Web Vitals jest promowanie i zachęcanie do dobrych wrażeń użytkownika w jak największej liczbie aspektów wczytywania i korzystania ze strony internetowej. Nie chcemy zachęcać do scenariuszy, w których złe wrażenia są uzasadnione, jeśli można uzyskać wystarczająco dużo dobrych wrażeń, aby je zrekompensować. Użytkownicy chcą, aby strony wczytywały się szybko i szybko przechodziły do nowych treści. Staraliśmy się zaprojektować dane, które faworyzują takie wrażenia.
Przełączyliśmy witrynę z MPA na SPA i nasze wyniki się pogorszyły. Czy to normalne?
To zależy. Po dużej migracji architektury wyniki mogą się zmienić z wielu powodów, ale spadek liczby wczytań z pamięci podręcznej może być częściowo odpowiedzialny za tę zmianę.
Szybkim sposobem na sprawdzenie tego jest przetestowanie za pomocą Lighthouse zarówno wersji MPA, jak i SPA jednej z Twoich stron docelowych. Jeśli wynik Lighthouse jest niższy w przypadku dowolnego z Core Web Vitals w wersji SPA, prawdopodobnie wrażenia podczas wczytywania pogorszyły się po aktualizacji.
Czy powinienem przełączyć witrynę z SPA na MPA, aby uzyskać lepsze wyniki w podstawowych wskaźnikach internetowych?
Raczej nie. Powinieneś przełączyć się z SPA na MPA tylko wtedy, gdy nie jesteś zadowolony z stosu SPA i masz powody, aby sądzić, że MPA zapewni lepsze wrażenia użytkownika.
Uważamy, że dzięki pracom nad nawigacją miękką rozwiązaliśmy problemy z pomiarami, więc przejście z tego powodu nie ma sensu.
Jeśli jednak masz powody, aby sądzić, że wydajność się poprawi, a nie tylko pomiary, może to być powód do przejścia z SPA na MPA (lub odwrotnie).
Jeśli wyniki Core Web Vitals są raportowane tylko w przypadku stron docelowych aplikacji SPA, jak mogę debugować problemy występujące na „stronach” po przejściu między trasami?
Narzędzia Google, które raportują dane z pól dotyczące podstawowych wskaźników internetowych (takie jak Search Console i PageSpeed Insights), pobierają dane z Raportu na temat użytkowania Chrome (CrUX). CrUX agreguje dane według originu lub adresu URL strony (czyli adresu URL strony w czasie wczytywania).
Pracujemy nad tym, aby CrUX mógł uwzględniać w swoich zagregowanych danych dane według trasy SPA. Jako właściciel witryny możesz jednak już teraz używać nowych interfejsów API do pomiaru Core Web Vitals według trasy SPA, aby sprawdzić, jak mogą się zmienić Twoje wyniki.
Więcej informacji i sprawdzonych metod na ten temat znajdziesz w artykule Pomiar nawigacji miękkiej.
Co robi Google, aby MPA nie miały nieuczciwej przewagi nad SPA?
Jak wspomnieliśmy wcześniej, uważamy, że dzięki pracom nad nawigacją miękką aplikacje jednostronicowe nie powinny mieć w tym względzie żadnych wad, chociaż pełna integracja ze wszystkimi narzędziami i rozwiązaniami do raportowania zajmie trochę czasu.
Oddzielna ocena wizyt na stronach z tej samej domeny i z różnych domen
Obecnie Core Web Vitals agregują wszystkie wizyty na stronie w jednym zbiorze. Nie rozróżniają one nowych i powracających wizyt, stron docelowych i stron płatności ani żadnego innego typu agregacji, w którym stan pamięci podręcznej może mieć wpływ na wydajność.
Jednym ze sposobów na znormalizowanie różnic między wydajnością SPA i MPA byłoby zastosowanie różnych wag do różnych typów wizyt, być może nawet z zupełnie innymi zaleceniami dotyczącymi progów.
Zdecydowanie chcemy nagradzać skuteczne implementacje pamięci podręcznej, ale nie chcemy, aby szybkie nawigacje w witrynie mogły maskować powolne wczytywanie stron docelowych. Nie chcemy też zachęcać witryn do dzielenia długich stron na zbiór krótszych tylko po to, aby poprawić wyniki danych.
Dzięki oddzielnej ocenie wizyt na stronach z tej samej domeny i z różnych domen możemy zapewnić, że oba typy wrażeń są ważne, bez dopuszczania do tego, aby względna popularność jednego typu w danej witrynie zniekształcała rozkład dowolnych danych.
Uwagi końcowe
Google jest głęboko zaangażowane w ulepszanie Web Vitals i zapewnianie, że mierzą one i zachęcają do wysokiej jakości wrażeń, które są ważne dla użytkowników. Przyznajemy jednak, że obecnie występują luki w pomiarach. Dane mogą teraz obejmować przejścia między trasami w aplikacjach jednostronicowych, co rozwiązuje jedną z głównych luk.
Uważamy też, że te nowe interfejsy API (zwłaszcza InteractionContentfulPaint) mają inne zastosowania i potencjalne korzyści poza pomiarem Core Web Vitals w przypadku nawigacji miękkiej. Bardzo się cieszymy, że możemy je dalej rozwijać, teraz gdy główny powód ich wprowadzenia został rozwiązany.
Mam nadzieję, że ten post pomógł rzucić nieco światła na ten złożony i subtelny temat. Jeśli masz opinie na temat obecnych lub przyszłych podstawowych wskaźników internetowych, wyślij e-maila na adres web-vitals-feedback@googlegroups.com.