Odpowiedzi na najczęstsze pytania dotyczące aplikacji SPA, podstawowych wskaźników internetowych i planów Google dotyczących rozwiązania obecnych ograniczeń pomiarów.
Od czasu wprowadzenia w maju 2020 r. inicjatywy Web Vitals zespół Chrome otrzymał wiele ciekawych pytań i opinii na temat tego programu.
Najwięcej pytań, na które trudno jest nam odpowiadać, dotyczy pomiaru podstawowych wskaźników internetowych w aplikacji jednostronicowej (SPA) oraz wpływu architektury SPA na wyniki podstawowych wskaźników internetowych.
Trudno jest odpowiedzieć na te pytania, ponieważ problem jest dość złożony. W tym poście postaramy się jednak odpowiedzieć na najczęstsze z nich, podając jak najwięcej szczegółów i kontekstu.
Zanim przejdziemy do szczegółów, warto zaznaczyć, że Google nie ma żadnych preferencji dotyczących architektury ani technologii wykorzystywanych do tworzenia witryn. Uważamy, że zarówno aplikacje SPA, jak i aplikacje wielostronicowe (MPA) mogą zapewniać użytkownikom wysoką jakość wrażeń. Naszym celem w ramach inicjatywy Podstawowe wskaźniki internetowe jest udostępnianie danych, które mierzą jakość wrażeń niezależnie od technologii. Obecnie nie jest to możliwe w każdym przypadku (z powodu ograniczeń platformy internetowej), ale aktywnie pracujemy nad wyeliminowaniem tych braków.
Najczęstsze pytania
Czy wskaźniki podstawowe wskaźniki internetowe obejmują przejścia na strony SPA?
Nie. Każdy z podstawowych wskaźników internetowych jest mierzony w zależności od bieżącej nawigacji na najwyższym poziomie strony. Jeśli strona wczytuje dynamicznie nową zawartość i aktualizuje adres URL strony w pasku adresu, nie ma to wpływu na sposób pomiaru danych podstawowych wskaźników internetowych. Wartości danych nie są resetowane, a adres URL powiązany z każdym pomiarem to adres URL, do którego użytkownik przeszedł, co zapoczątkowało wczytanie strony.
Czy podstawowe wskaźniki internetowe mogą traktować zmiany ścieżki SPA tak samo jak tradycyjne wczytywanie stron?
Niestety nie. Przynajmniej nie na razie.
Obecnie nie ma standardowego sposobu tworzenia aplikacji SPA. Nawet w przypadku popularnych bibliotek SPA i bibliotek routingu wrażenia użytkownika mogą się znacznie różnić w zależności od aplikacji:
- Niektóre SPA aktualizują adres URL tylko podczas wczytywania nowych „pełnych stron”, podczas gdy inne witryny aktualizują adres URL przy niewielkich zmianach treści lub nawet tylko przy zmianach stanu interfejsu.
- Niektóre aplikacje na jednym ekranie aktualizują adres URL za pomocą interfejsu History API, inne używają zmian w haszu w celu obsługi starszych przeglądarek (a jeszcze inne wcale nie aktualizują adresu URL).
- Niektóre SPA wczytują treści, a potem aktualizują adres URL, podczas gdy inne aktualizują adres URL przed wczytaniem treści.
- Niektóre SPA wczytują treści jednocześnie, synchronicznie, w ramach pojedynczego zadania JavaScript, podczas gdy inne przekazują treści asynchronicznie w ramach wielu zadań (bez wyraźnego zdarzenia zakończenia przejścia).
- Niektóre SPA zawsze wczytują treści z sieci, a inne wstępnie wczytują wszystkie treści, aby zmiany trasy były natychmiast wczytywane z pamięci.
Z powodu tych różnic bardzo trudno jest w dużej skali zdefiniować i określić, co stanowi zmianę ścieżki SPA lub nawet całą aplikację SPA.
W niektórych przypadkach zmiana trasy SPA jest logicznie identyczna z wczytywaniem strony MPA. W takich przypadkach przydałoby się zastosowanie dotychczasowych danych podstawowych wskaźników internetowych.
Jednak bez solidnej heurystyki, która pozwalałaby niezawodnie odróżnić „prawdziwe” zmiany trasy od wszystkich innych zmian adresu URL, a także bez wyraźnych sygnałów wskazujących początek i koniec takich przejść, raportowanie danych podstawowych wskaźników internetowych w tych przypadkach powodowałoby zaciemnianie danych, co czyniłoby je mniej przydatnymi i mniej reprezentatywnymi dla rzeczywistego doświadczenia użytkownika w witrynie.
Czy w przypadku aplikacji SPA trudniej jest uzyskać dobre wyniki w podstawowych wskaźnikach internetowych niż w przypadku aplikacji MPA?
Architektura SPA nie zawiera niczego, co uniemożliwiałoby stronie w SPA wczytywanie się tak samo szybko i osiąganie tak samo dobrych wyników we wszystkich podstawowych wskaźnikach internetowych jak w przypadku podobnej strony w MPA.
Jednak odpowiednio zoptymalizowane witryny MPA mają pewne zalety w spełnianiu progów podstawowych wskaźników internetowych, których nie mają obecnie witryny SPA. Dzieje się tak, ponieważ w ramach architektury MPA każda „strona” jest wczytywana jako pełna strona (zamiast dynamicznego pobierania treści i wstawiania ich na istniejącą stronę), co oznacza, że użytkownicy, którzy odwiedzają MPA, prawdopodobnie wczytają więcej niż jedną stronę z witryny. Z kolei oznacza to, że większy odsetek dystrybucji wszystkich wczytanych stron MPA będzie obejmował niektóre lub wszystkie zasoby podrzędne w pamięci podręcznej.
Aby strona MPA miała lepsze wyniki w podstawowych wskaźnikach internetowych niż strona SPA, musi być spełnionych kilka warunków:
- MPA musi mieć zoptymalizowane buforowanie zasobów podrzędnych, aby zapewnić szybsze wczytywanie stron w ramach tej samej domeny niż w ramach innych domen w 75. procencie przypadków.
- Użytkownicy, którzy odwiedzają strony MPA, muszą odwiedzić kilka stron, aby witryna mogła korzystać z zalet pamięci podręcznej, które powodują szybsze wczytywanie stron.
Oceny podstawowych wskaźników internetowych biorą pod uwagę 75. percentyl wizyt na stronie, więc im więcej dobrze działających wizyt na stronie w danym zbiorze danych, tym większe prawdopodobieństwo, że wizyta na 75. percentylu rozkładu będzie mieścić się w zalecanych progach.
Podczas porównywania wyników podstawowych wskaźników internetowych należy wziąć pod uwagę sposób agregowania danych, czyli czy zbiór danych w rozkładzie obejmuje wszystkie strony w Twojej witrynie lub pochodzeniu, czy tylko wczytywanie stron w przypadku konkretnego adresu URL strony.
Podczas agregowania wyników wszystkich stron w źródle poszczególne szybkie strony mogą poprawić 75. percentyl źródła jako całości. Jednak podczas agregowania wyników według poszczególnych stron wyniki jednej strony nie będą miały wpływu na wyniki następnej. Innymi słowy, podczas agregowania wyników MPA według stron szybkie wczytywanie z pamięci podręcznej na stronie płatności nie poprawi wyników wolnego początkowego wczytywania na stronie docelowej.
Oceny witryny dla różnych metod agregacji możesz sprawdzić za pomocą PageSpeed Insights lub interfejsu API raportu na temat użytkowania Chrome, który zawiera oceny zarówno pojedynczych adresów URL stron, jak i całego źródła.
Architektura SPA może też wpływać na wyniki podstawowych wskaźników internetowych w przypadku danych, które uwzględniają cały czas życia strony. Użytkownicy odwiedzający strony AMP zwykle pozostają na tej samej „stronie” przez całą sesję, dlatego dane gromadzone z czasem mogą być w przypadku stron AMP mniej korzystne niż w przypadku stron MPA.
W kwietniu 2021 r. ogłosiliśmy zmiany w metryce CLS, które częściowo rozwiązują ten problem. Wcześniej wskaźnik CLS kumulował się przez cały okres istnienia strony, a teraz kumuluje się tylko w określonym przedziale czasu, czyli w najgorszym skoku przesunięcia układu na danej stronie.
Jednak nawet przy nowej definicji CLS aplikacje SPA są nadal w niekorzystnej sytuacji, ponieważ wartość CLS nie jest „resetowana” po przejściu do innej ścieżki, tak jak ma to miejsce w przypadku pełnego wczytania strony w aplikacji MPA. Może to też wprowadzać użytkowników w błąd, ponieważ zmiany układu, które występują po przejściu na inną trasę, będą przypisywane do adresu URL strony w momencie jej załadowania, a nie do adresu URL w pasku adresu w momencie zmiany (więcej informacji znajdziesz poniżej).
Jeśli architektury SPA poprawiają wrażenia użytkowników, czy nie powinno to być widoczne w danych?
Tak. Jak już wspomnieliśmy, trudno jest określić, o ile poprawiło się działanie aplikacji, ponieważ istnieją różne sposoby implementacji SPA w internecie.
Prawda jest taka, że branża zajmująca się wydajnością stron internetowych (w tym Google) nie poświęcała do tej pory tyle czasu i wysiłku na opracowanie danych ukierunkowanych na użytkownika dotyczących wydajności strony po jej załadowaniu, co na samo wczytywanie strony. Nie dlatego, że wydajność po załadowaniu nie jest ważne, ale dlatego, że po załadowaniu interfejs użytkownika i interakcje są znacznie bardziej zróżnicowane i mniej zdefiniowane, co utrudnia projektowanie wskaźników.
Nawet jeśli uda nam się dobrze zdefiniować dane pobierane po załadowaniu, aby mierzyć wydajność SPA, nie chcemy ignorować procesu wczytywania tylko dlatego, że pobieranie po wczytaniu przebiega lepiej.
Jednym z celów inicjatywy Wskaźniki internetowe jest promowanie i zachęcanie do zapewnienia użytkownikom jak najlepszych wrażeń 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 je zrównoważyć pozytywnymi wrażeniami. Użytkownicy chcą, aby strony wczytywały się szybko i aby szybko przechodzić do nowych treści. Staraliśmy się zaprojektować wskaźniki, które sprzyjają takim działaniom.
Chociaż wersja MPA strony może mieć lepsze wyniki w podstawowych wskaźnikach internetowych w 75. percentylu niż wersja SPA tej samej strony, ta druga powinna się jednak starać osiągnąć próg „dobry”. Jeśli wersja SPA nie spełnia progu „dobrego” w przypadku większości użytkowników, początkowe wczytywanie prawdopodobnie nie będzie odbierane jako dobre, nawet jeśli późniejsza nawigacja po stronie będzie znakomita.
W przyszłości planujemy opracować wskaźniki, które zachęcają do korzystania z aplikacji SPA wysokiej jakości w sposób niewymagający kompromisów w zakresie początkowego wczytywania. Wprowadziliśmy już nowy rodzaj danych o nazwanej interakcja do kolejnego wyrenderowania (INP), który mierzy opóźnienie interakcji w całym cyklu życia strony. Aktywnie pracujemy też nad innymi danymi pobierania, w tym nad danymi, które mierzą przejścia na ścieżce SPA (patrz poniżej).
Przełączyliśmy naszą witrynę z MPA na SPA i nasze wyniki się pogorszyły. Czy to normalne?
To zależy. Wyniki mogą się zmienić po dużej migracji architektury z różnych powodów, ale częściowo może to być spowodowane spadkiem liczby wczytań ciepłej pamięci podręcznej.
Szybkim sposobem sprawdzenia jest przetestowanie wersji MPA i SPA jednej z Twoich stron docelowych za pomocą Lighthouse. Jeśli wynik Lighthouse jest niższy w przypadku dowolnego z podstawowych wskaźników internetowych w wersji SPA, prawdopodobnie po aktualizacji wczytywanie się strony jest gorsze.
Czy aby uzyskać wyższą ocenę w podstawowych wskaźnikach internetowych, powinienem zmienić swoją witrynę z aplikacji SPA na MPA?
Raczej nie. Dopiero wtedy, gdy nie jesteś zadowolony(-a) ze swojego pakietu SPA i masz powody, by sądzić, że MPA zapewni lepsze wrażenia użytkownika, powinieneś(-a) przejść z SPA na MPA.
Z czasem, gdy podstawowe wskaźniki internetowe będą się poprawiać i zawierać coraz więcej elementów przeglądania, zespoły, które mają dobrze skonstruowane aplikacje SPA zapewniające świetne wrażenia użytkownika, powinny zauważyć, że ich wyniki w przypadku podstawowych wskaźników internetowych będą to odzwierciedlać.
Jeśli wyniki podstawowych wskaźników internetowych są raportowane tylko w przypadku stron docelowych aplikacji SPA, jak mogę debugować problemy występujące na „stronach” po przejściu na inną ścieżkę?
Narzędzia Google, które podają dane z pól dotyczące wskaźnika Core Web Vitals (np. Search Console i PageSpeed Insights), pobierają je z raportu na temat użytkowania Chrome (CrUX). Raport CrUX agreguje dane według źródła lub adresu URL strony (czyli adresu URL strony w momencie jej wczytania).
Ze wszystkich wymienionych powyżej powodów CrUX nie może agregować danych według ścieżki SPA. Jako właściciel witryny znasz jednak swoją architekturę i możesz samodzielnie mierzyć ten czas. Wiele narzędzi analitycznych umożliwia też sygnalizowanie zmian w trasie SPA i odpowiednie aktualizowanie danych pomiarowych.
Podczas pomiaru danych wskaźników internetowych za pomocą narzędzia analitycznego pamiętaj, aby mierzyć zarówno bieżący adres URL trasy, jak i adres URL oryginalnej strony. Dzięki temu możesz debugować poszczególne problemy występujące w trakcie cyklu życia strony, a także agregować dane według oryginalnego adresu URL strony, aby dopasować sposób pomiaru i raportowania danych przez narzędzia Google.
Więcej informacji i sprawdzonych metod znajdziesz w artykule Debugowanie skuteczności w warunkach rzeczywistych.
Co Google robi, aby MPA nie miały nieuczciwej przewagi nad SPA?
Jak już wspomnieliśmy, odpowiednio zoptymalizowane MPA może w niektórych przypadkach generować lepsze wyniki Core Web Vitals w 75. percentylu, ponieważ prawdopodobnie będzie mieć większy odsetek wizyt na stronach z poziomem pamięci podręcznej. Z drugiej strony, żadne z podstawowych wskaźników internetowych nie rejestruje obecnie rzeczywistych ulepszeń wrażeń użytkownika w prawidłowo zoptymalizowanych aplikacjach SPA.
Zdajemy sobie sprawę, że powoduje to zachęty, które nie są w pełni zgodne z celami inicjatywy Web Vitals. Aktywnie szukamy sposobów na rozwiązanie tego problemu. Obecnie rozważamy 2 potencjalne rozwiązania: jedno krótkoterminowe i jedno długoterminowe:
- Oceniaj osobno wizyty na stronach z różnych domen i z tej samej domeny.
- opracować nowe interfejsy API, które umożliwią lepsze pomiary SPA;
osobno oceniać wizyty na stronach z różnych i tych samych źródeł;
Obecnie podstawowe wskaźniki internetowe agregują wszystkie wizyty na stronie w jednym zbiorze. Nie rozróżniają one nowych i powracających wizyt ani stron docelowych od 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 normalizacji różnic między skutecznością SPA a MPA jest zastosowanie różnych wag dla różnych typów wizyt, nawet z całkowicie innymi rekomendacjami progowymi.
Zdecydowanie chcemy nagradzać skuteczne implementacje pamięci podręcznej, ale nie chcemy, aby szybka nawigacja w witrynie mogła maskować powolne wczytywanie stron docelowych. Nie chcemy też zachęcać właścicieli witryn do dzielenia długich stron na kilka krótszych tylko po to, aby poprawić wyniki wskaźników.
Dzięki temu, że osobno oceniamy wizyty na stronach z różnych i tych samych źródeł, możemy zadbać o to, aby oba typy doświadczeń były ważne, a relatywna popularność jednego z nich w danej witrynie nie wpływała na rozkład danej metryki.
Projektowanie nowych interfejsów API, które umożliwiają lepsze pomiary SPA
Innym rozwiązaniem, nad którym obecnie pracujemy (równolegle z powyższym), jest nowy interfejs App History API, który pomoże ujednolicić obecne wzorce SPA i ułatwi pomiar oraz zrozumienie korzystania z SPA na dużą skalę.
Interfejs App History API wprowadza nowe zdarzenie navigate, które ma 2 kluczowe funkcje związane z mierzeniem aplikacji na jednym ekranie:
- Flaga
userInitiated, która będzie miała wartość true tylko wtedy, gdy nawigacja została zainicjowana przez kliknięcie linku, przesłanie formularza lub interfejs Wstecz lub Wprzód przeglądarki. - metoda
transitionWhile(), która przyjmuje obietnicę umożliwiającą deweloperowi sygnalizowanie, że rozpoczęte przez niego czynności związane z wykonywaniem nawigacji zostały zakończone.
Flagi userInitiated można używać do określania semantycznego punktu początkowego przejścia na ścieżkę SPA, co wskazuje na wyraźny zamiar użytkownika. Rozwiązanie transitionWhile()
obiecuje, że przeglądarka może powiązać renderowanie z konkretnym przejściem na trasie, dzięki czemu może określić największe wyrenderowanie treści powiązane z tym przejściem.
Bazując na idei przedstawionej w poprzedniej sekcji, można nawet zagregować czas przejścia na trasę SPA w tym samym zbiorze, co wczytywanie stron w tej samej domenie w przypadku MPA. To ekscytująca perspektywa, ponieważ pozwoliłaby witrynom przechodzącym z MPA na SPA na porównanie skuteczności przed i po migracji.
Oczywiście zanim będziemy mogli dokładnie określić, czy możemy to zrobić, będziemy musieli przeprowadzić więcej badań. Jeśli masz propozycje lub opinie na temat tych propozycji, wyślij je na adres web-vitals-feedback@googlegroups.com.
Uwagi końcowe
Dokładamy wszelkich starań, aby ulepszać wskaźniki internetowe i zapewniać wysoką jakość wrażeń użytkowników, która jest dla nich ważna. Zdajemy sobie jednak sprawę, że obecnie występują luki w pomiarach. Obecnie metryki nie obejmują wszystkich aspektów związanych z doświadczeniami użytkowników, ale aktywnie nad tym pracujemy.
Pomimo obecnych ograniczeń uważamy, że obszary objęte przez istniejące dane są kluczowe dla prawidłowego działania i sukcesu internetu. Jeśli witryny (niezależnie od architektury) nie spełniają zalecanych wartości progowych, uważamy, że jest miejsce na poprawę.
Mam nadzieję, że ten post pomoże Ci lepiej zrozumieć tę złożoną i delikatną kwestię. Jeśli chcesz podzielić się opinią na temat obecnych lub przyszłych danych Web Vitals, wyślij e-maila na adres web-vitals-feedback@googlegroups.com.