Odpowiedzi na najczęstsze pytania dotyczące SPA, podstawowych wskaźników internetowych i planu Google rozwiązania dotychczasowych ograniczeń pomiarów.
Odkąd po raz pierwszy wprowadziliśmy inicjatywę Wskaźniki internetowe w maju 2020 r., zespół Chrome otrzymał wiele ciekawych pytań i opinii na temat programu.
Tematem, na który padło najwięcej pytań, ale też prawdopodobnie najtrudniejsze, jest mierzenie podstawowych wskaźników internetowych w aplikacji jednostronicowej (SPA) i wpływ architektur 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ę odpowiedzieć na najczęstsze pytania, dodając jak najwięcej szczegółów i kontekstu.
Zanim przejdziemy do szczegółów, chcemy zaznaczyć, że Google nie ma żadnych preferencji co do architektury i technologii wykorzystywanej do tworzenia witryn. Uważamy, że zarówno aplikacje jednostronicowe, jak i aplikacje wielostronicowe mogą zapewniać użytkownikom wysoką jakość obsługi, a naszym celem w ramach inicjatywy Web Vitals jest dostarczanie danych służących do pomiaru wrażeń użytkowników niezależnie od technologii. Obecnie nie zawsze jest to możliwe (ze względu na ograniczenia na platformie internetowej), ale aktywnie pracujemy nad ich wyeliminowaniem.
Najczęstsze pytania
Czy podstawowe wskaźniki internetowe obejmują przejścia na SPA?
Nie. Wszystkie podstawowe wskaźniki internetowe są mierzone w odniesieniu do bieżącej nawigacji na stronie najwyższego poziomu. Jeśli strona dynamicznie wczytuje nowe treści i aktualizuje jej adres URL w pasku adresu, nie będzie to miało wpływu na pomiar podstawowych wskaźników internetowych. Wartości danych nie są resetowane, a adres URL powiązany z poszczególnymi pomiarami danych to adres URL, na który przeszedł użytkownik, który zainicjował wczytanie strony.
Czy podstawowe wskaźniki internetowe mogą traktować zmiany tras SPA tak samo jak tradycyjne wczytywanie stron?
Niestety nie. Tak czy inaczej, jeszcze nie.
Obecnie nie ma ustandaryzowanego sposobu tworzenia SPA. Nawet wśród popularnych bibliotek i bibliotek SPA i routingów obsługa użytkowników może się znacznie różnić w zależności od aplikacji:
- Niektóre aplikacje „SPA” aktualizują adres URL tylko podczas wczytywania nowej treści „pełnej strony”, natomiast inne witryny aktualizują adres URL na potrzeby niewielkich zmian w treści lub nawet tylko zmian stanu interfejsu użytkownika.
- Niektóre aplikacje SPA aktualizują adres URL za pomocą interfejsu History API, a inne – zmiany skrótu, aby umożliwić obsługę starszych przeglądarek (a inne w ogóle nie aktualizują adresu URL).
- Niektóre aplikacje „SPA” wczytują treść, a potem aktualizują adres URL, a inne przed załadowaniem treści.
- Niektóre aplikacje SPA wczytują całą treść jednocześnie, synchronicznie w ramach pojedynczego zadania JavaScriptu, natomiast inne przekazują treści asynchronicznie między wieloma zadaniami (bez wyraźnego zdarzenia końcowego przejścia).
- Niektóre aplikacje SPA zawsze wczytują treści z sieci, podczas gdy inne wstępnie wczytują wszystkie treści z góry, dzięki czemu zmiany trasy są wczytywane natychmiast z pamięci.
Te różnice sprawiają, że definiowanie i identyfikowanie tego, co stanowi zmianę trasy SPA, a nawet samej SPA, jest bardzo trudne na dużą skalę.
W niektórych przypadkach zmiana trasy SPA jest logicznie identyczna jak w przypadku wczytywania strony MPA. W takich przypadkach warto zastosować obecne wskaźniki podstawowych wskaźników internetowych.
Jednak bez solidnej heurystyki pozwalającej na wiarygodne zidentyfikowanie „rzeczywistych” zmian w trasach w przypadku wszystkich innych zmian w adresach URL oraz wyraźnych sygnałów wskazujących początek i koniec takich przejść – raportowanie podstawowych wskaźników internetowych w takich przypadkach sprawiłoby, że dane zabłybyły i zmniejszyłyby ich użyteczność oraz reprezentatywność dla rzeczywistych użytkowników witryny.
Czy aplikacje SPA mają trudniejsze do osiągnięcia podstawowe wskaźniki internetowe niż MPA?
Architektura SPA nie zawiera nic, co uniemożliwiałoby takim samym szybkie wczytywanie strony w komponencie SPA (i poprawę wyników w zakresie wszystkich podstawowych wskaźników internetowych) co podobna strona w MPA.
Właściwie zoptymalizowane MPA mają jednak pewne zalety w zakresie osiągania progów podstawowych aplikacji internetowych. Wynika to z tego, że dzięki architekturze MPA każda „strona” jest wczytywana jako nawigacja zajmująca całą stronę (a nie dynamiczne pobieranie treści i umieszczanie jej na istniejącej stronie), co oznacza, że użytkownicy odwiedzający platformę MPA z większym prawdopodobieństwem wczytają więcej niż jedną stronę z witryny, co z kolei oznacza, że większy odsetek rozkładu wszystkich wczytań strony w przypadku MPA będzie obejmował część lub wszystkie zasoby podrzędne.
Aby jednak MPA osiągało lepsze wyniki w zakresie podstawowych wskaźników internetowych niż SPA, trzeba pamiętać o kilku kwestiach:
- MPA musi mieć zoptymalizowane buforowanie zasobów podrzędnych, aby zapewnić szybsze wczytywanie stron z tej samej domeny w przypadku 75. percentyla.
- Użytkownicy korzystający z MPA muszą odwiedzić wiele stron, aby witryna mogła korzystać z pamięci podręcznej, co przyspiesza ładowanie stron.
W ramach ocen podstawowych wskaźników internetowych uwzględniasz 75 percentyl wizyt na stronie, dlatego większa liczba skutecznych wizyt na stronie w zbiorze danych zwiększy prawdopodobieństwo, że te wizyty w 75 centylu rozkładu mieszczą się w zalecanych progach.
Pamiętaj, że przy porównywaniu wyników podstawowych wskaźników internetowych należy wziąć pod uwagę sposób agregacji danych, czyli to, czy zbiór danych w rozkładzie uwzględnia wszystkie strony z Twojej witryny lub źródła, czy tylko wczytania stron w przypadku określonego adresu URL strony.
Gdy agregujesz wyniki wszystkich stron w witrynie, poszczególne szybkie strony mogą poprawić 75 centyl dla całego źródła. W przypadku agregowania danych według poszczególnych stron wyniki jednej strony nie wpływają jednak na wyniki następnej. Oznacza to, że podczas agregowania wyników MPA według strony szybkie wczytywanie z pamięci podręcznej widoczne na stronie płatności nie poprawia wyników powolnych wczytywania początkowych występujących na stronie docelowej witryny.
Wynik witryny możesz sprawdzić pod kątem różnych metod agregacji, korzystając z narzędzia PageSpeed Insights lub interfejsu Chrome User Experience Report API, które przekazuje wyniki zarówno w przypadku poszczególnych adresów URL stron, jak i całego źródła.
Innym sposobem na wyniki podstawowych wskaźników internetowych jest architektura SPA, która uwzględnia dane, które uwzględniają całą długość życia strony. Ponieważ użytkownicy odwiedzający aplikacje SPA zwykle pozostają na tej samej „stronie” przez całą sesję, dane zbierane z upływem czasu mogą być ostrzejsze w przypadku aplikacji SPA niż MPA.
W kwietniu 2021 r. ogłosiliśmy zmiany wskaźnika CLS, które częściowo rozwiązały ten problem. Wcześniej CLS gromadził się w całym okresie życia strony, podczas gdy obecnie – tylko w określonym przedziale czasu – zasadniczo jest to najgorsza seria przesunięć układu na danej stronie.
Jednak nawet w przypadku nowej definicji CLS aplikacje do zarządzania urządzeniami mobilnymi mają w dalszym ciągu niekorzystną wartość, ponieważ wartość CLS nie jest „resetowana” po zmianie trasy, tak jak w przypadku pełnego wczytania strony w MPA. Może to też być mylące, ponieważ przesunięcia układu, które następuje po przeniesieniu trasy, są przypisywane do adresu URL strony w momencie jej wczytywania, a nie do adresu URL na pasku adresu w momencie przesunięcia (więcej informacji poniżej).
Jeśli architektury SPA poprawiają wygodę użytkowników, czy ta poprawa powinna być widoczna w danych?
Tak, powinien. Jak już wspomnieliśmy, trudno jest ocenić, jak bardzo poprawiła się jakość obsługi, z uwagi na różne sposoby wdrażania aplikacji SPA w internecie.
Prawda jest taka, że branża wydajności w internecie (w tym Google) do tej pory nie inwestował niemal tyle czasu i wysiłku w opracowywanie danych skoncentrowanych na użytkownikach dotyczących wydajności działania strony po wczytaniu niż samej strony w przypadku jej wczytywania. Nie wynika to z wydajności po wczytaniu nie jest ważne, lecz dlatego, że wrażenia użytkowników i interakcje po jej wczytaniu są znacznie bardziej zróżnicowane i mniej dokładnie zdefiniowane, co utrudnia projektowanie wskaźników.
Jednak nawet gdy mamy dokładnie zdefiniowane wskaźniki post-load do zmierzenia wydajności SPA, nie chcemy ignorować wygody użytkowników tylko dlatego, że poprawia się interfejs po wczytaniu.
Jednym z celów inicjatywy dotyczącej wskaźników internetowych jest promowanie i zachęcanie użytkowników do dbania o wygodę użytkowników w jak największej liczbie aspektów wczytywania i używania strony internetowej. Nie chcemy zachęcać do sytuacji, w których złe wrażenia są uzasadnione, jeśli możesz zapewnić sobie wystarczająco dużo dobrych wrażeń, aby je zrekompensować. Użytkownicy chcą, aby strony szybko się ładowały oraz szybko przechodzić do nowych treści, dlatego próbowaliśmy zaprojektować dane, które korzystnie wpływają na takie treści.
Choć to prawda, że wersja MPA witryny może mieć lepsze wyniki w zakresie podstawowych wskaźników internetowych na 75 centylu niż wersja SPA tej samej witryny, wersja SPA nadal powinna dążyć do osiągnięcia progu „dobrego”. Jeśli w przypadku większości użytkowników wersja aplikacji na Androida nie spełnia wymagań „dobrej”, oznacza to, że pierwsze wczytywanie strony prawdopodobnie nie będzie postrzegane jako dobre – nawet jeśli późniejsza nawigacja na stronie będzie znakomita.
W przyszłości planujemy opracowanie wskaźników, które będą zapewniać użytkownikom wygodę po wczytaniu. Uważamy, że jest to najlepsza metoda promowania wysokiej jakości aplikacji SA bez negatywnego wpływu na początkowe wczytywanie. Wprowadziliśmy już nowy rodzaj danych o nazwie Interakcja do następnego wyrenderowania (INP), który mierzy czas oczekiwania na interakcję w całym cyklu życia strony. Pracujemy też nad innymi wskaźnikami po wczytaniu, w tym wskaźnikami mierzącymi przejścia na trasach SPA (patrz poniżej).
Przekształciliśmy witrynę z MPA w SPA i nasze wyniki pogorszyły się. Czy to normalne?
To zależy. Istnieje wiele powodów, dla których wyniki mogą się zmienić po poważnej migracji architektury, ale część z nich może być związana ze spadkiem liczby wczytań pamięci podręcznej częściowo z pamięci.
Szybkim sposobem jest przetestowanie jednej ze stron docelowych w wersji MPA i SPA w Lighthouse. Jeśli wartość dowolnego z podstawowych wskaźników internetowych w przypadku wersji SPA w Lighthouse jest niższa, może to pogorszyć się po aktualizacji strona ładowania danych.
Czy muszę przejść ze strony SPA na MPA, aby uzyskać wyższą pozycję w podstawowych wskaźnikach internetowych?
Raczej nie. Wybierz platformę SPA na MPA tylko wtedy, gdy nie jesteś zadowolony ze stosu SPA i masz powody sądzić, że standard MPA zapewni użytkownikom lepsze wrażenia.
W miarę upływu czasu, w miarę jak Podstawowe wskaźniki internetowe obejmą coraz większą część pełnego interfejsu użytkownika, zespoły ze świetnymi aplikacjami SPA, które zapewniają wygodę korzystania z aplikacji, powinny to zaobserwować.
Jeśli wyniki w zakresie podstawowych wskaźników internetowych są raportowane tylko w przypadku stron docelowych SPA, jak mogę debugować problemy, które pojawiają się na „stronach” po przeniesieniu trasy?
Narzędzia Google, które raportują dane w ramach podstawowych wskaźników internetowych (np. Search Console i PageSpeed Insights), pobierają dane z Raportu na temat użytkowania Chrome (CrUX). Raport ten agreguje dane według źródła lub adresu URL strony (czyli adresu URL strony w momencie wczytywania).
Z powodów wymienionych powyżej CrUX nie może agregować danych według trasy SPF. Jednak jako właściciel witryny, który zna Twoją architekturę, możesz samodzielnie go zmierzyć. Wiele narzędzi analitycznych umożliwia zasygnalizowanie zmiany trasy SPA i odpowiednie aktualizowanie danych pomiarowych.
Mierząc wskaźniki internetowe za pomocą narzędzia do analizy, pamiętaj, aby mierzyć zarówno bieżący adres URL trasy, jak i pierwotny adres URL strony. Dzięki temu możesz debugować poszczególne problemy występujące w całym cyklu życia strony i agregować dane według adresu URL strony oryginalnej. Dzięki temu możesz dopasowywać dane do pomiaru i raportowania tych danych przez narzędzia Google.
Więcej informacji i sprawdzone metody znajdziesz w sekcji Debugowanie wydajności w tym polu.
Co robi Google, aby zapobiec uzyskaniu nieuczciwej przewagi w porównaniu z SPA?
Jak wspomnieliśmy wcześniej, odpowiednio zoptymalizowana reklama MPA może w niektórych przypadkach uzyskiwać lepsze wyniki w zakresie wskaźników internetowych na 75. centylu, ponieważ prawdopodobnie będzie miała wyższy odsetek wizyt stron w pamięci podręcznej. I na odwrót: żadne z podstawowych wskaźników internetowych nie uwzględniają obecnie żadnych ulepszeń dotyczących wygody użytkowników dzięki odpowiednio zoptymalizowanych aplikacji SPA.
W Google wiemy, że tworzymy zachęty, które nie są w pełni zgodne z celami inicjatywy dotyczącej wskaźników internetowych, i aktywnie szukamy sposobów na rozwiązanie tego problemu. Obecnie analizujemy 2 potencjalne rozwiązania: jedno krótkoterminowe, a drugie długoterminowe:
- Oddzielnie oceniaj wizyty na stronach z różnych domen i tej samej domeny.
- Opracowywanie nowych interfejsów API, które umożliwiają lepsze pomiary SPA.
Oddzielna ocena wizyt na stronach z różnych domen i tej samej domeny
Obecnie podstawowe wskaźniki internetowe gromadzą wszystkie wizyty na stronie w jednym segmencie – nie rozróżniają wizyt nowych i powracających 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 znormalizowania różnic między skutecznością SPA i MPA jest zastosowanie różnych wag do różnych typów wizyt, nawet w przypadku zupełnie innych rekomendacji dotyczących progu.
Zdecydowanie chcemy nagradzać skuteczne rozwiązania z pamięci podręcznej, nie chcemy jednak, aby szybka nawigacja w witrynie mogła ukrywać się po wolnym ładowaniu stron docelowych. Nie chcemy też zachęcać witryn do dzielenia długich stron na kilka krótszych stron tylko w celu poprawy wyników pomiarów.
Oddzielnie oceniając wizyty na stronach z innych i tej samej domeny, możemy zadbać o to, aby oba rodzaje treści były ważne, a względna popularność jednego typu w danej witrynie nie zaburzała rozkładu konkretnych danych.
Opracowywanie nowych interfejsów API, które umożliwiają lepsze pomiary SPA
Kolejnym rozwiązaniem, nad którym aktywnie pracujemy (równolegle do powyższych), jest nowy interfejs App History API. Pomoże on ustandaryzować obecne wzorce aplikacji SPA oraz ułatwi pomiar i interpretację korzystania z usług SPA na dużą skalę.
Interfejs App History API wprowadza nowe zdarzenie navigate mające 2 główne funkcje związane z pomiarami SPA:
- Flaga
userInitiated, która ma wartość Prawda tylko wtedy, gdy nawigacja została zainicjowana przez kliknięcie linku, przesłanie formularza lub za pomocą interfejsu przeglądarki wstecz lub dalej. - Metoda
transitionWhile(), która zawiera obietnicę umożliwiającą deweloperowi zasygnalizowanie, że praca związana z nawigacją została zainicjowana.
Flaga userInitiated może służyć do określania semantycznego punktu początkowego przejścia trasy SPA, co wskazuje na wyraźną intencję użytkownika. Rozwiązanie na podstawie obietnicy transitionWhile() może pomóc przeglądarce skorelować renderowanie z konkretnym przejściem trasy, dzięki czemu będzie w stanie określić największe wyrenderowanie treści związane z tym przejściem.
Na podstawie koncepcji przedstawionej w poprzedniej sekcji może istnieć nawet możliwość zgromadzenia czasu przejścia trasy SPA do tego samego zasobnika, co w MPA wczytanych stron z tego samego źródła. To ekscytujące, ponieważ pozwoliłoby witrynie migracji z MPA do SPA porównać skuteczność przed i po.
Oczywiście, zanim będziemy w stanie stwierdzić, czy jesteśmy w stanie dokonać dokładnej oceny, potrzeba jeszcze więcej badań. Jeśli masz sugestie lub opinie na temat tych ofert, wyślij e-maila na adres web-vitals-feedback@googlegroups.com.
Uwagi końcowe
Google dokłada wszelkich starań, aby poprawiać wskaźniki internetowe oraz dbać o to, aby mierzyły i zachęcały użytkowników do tworzenia treści wysokiej jakości, które są ważne dla użytkowników. Zdajemy sobie jednak sprawę, że obecnie istnieją luki w pomiarach. Obecnie dane te nie obejmują wszystkich aspektów związanych z wrażeniami użytkowników, ale pracujemy nad usunięciem tych luk.
Pomimo obecnych ograniczeń uważamy, że obszary, w których zbierane są dotychczasowe dane, mają kluczowe znaczenie dla sprawnego działania i sukcesu internetu. Jeśli witryny (niezależnie od architektury) nie spełniają zalecanych progów, uważamy, że możemy wprowadzić ulepszenia.
Mam nadzieję, że ten post pomógł rzucić nieco światła na ten skomplikowany i złożony z nich temat. Jak zawsze, jeśli chcesz podzielić się opinią na temat bieżących lub przyszłych wskaźników internetowych, wyślij e-maila na adres web-vitals-feedback@googlegroups.com.