Odpowiedzi na najczęstsze pytania dotyczące aplikacji SPA, podstawowych wskaźników internetowych i planu Google dotyczącego przeciwdziałania aktualnym ograniczeniom dotyczącym pomiarów.
Od czasu wprowadzenia w maju 2020 r. inicjatywy Wskaźniki internetowe zespołu Chrome otrzymał wiele ciekawych pytań i opinii na temat programu.
Być może temat, o który padało najwięcej pytań, Chyba najtrudniejsze pytanie brzmi: jak mierzyć podstawowe wskaźniki internetowe aplikacja jednostronicowa (SPA) oraz wpływ architektury SPA na wyniki w Podstawowych wskaźnikach internetowych.
Odpowiedź na te pytania jest trudna, ponieważ problem jest dość zróżnicowany, więc W tym poście postaramy się odpowiedzieć na najczęstsze pytania. podając jak najwięcej szczegółów i kontekstu.
Zanim jednak przejdziemy do konkretów, zaznaczymy, że Google nie ma preferencji co do architektury lub technologii wykorzystywanej witrynie. Naszym zdaniem aplikacje SPA i aplikacje wielostronicowe dostarczanie użytkownikom wysokiej jakości usług, a naszym celem w internecie Inicjatywa Vitals ma na celu dostarczanie danych mierzących wrażenia użytkowników niezależnie z najnowszymi technologiami. Chociaż nie jest to obecnie możliwe w każdym przypadku (ze względu na na platformie internetowej), pracujemy nad ich rozwiązaniem .
Najczęstsze pytania
Czy dane dotyczące podstawowych wskaźników internetowych obejmują przejścia na trasy SPA?
Nie. Każdy wskaźnik Podstawowych wskaźników internetowych jest mierzony w odniesieniu do bieżącej, nawigacji po stronie najwyższego poziomu. Jeśli strona dynamicznie wczytuje się i aktualizuje adres URL strony w pasku adresu, nie zostanie dodany na sposób pomiaru podstawowych wskaźników internetowych. Wartości danych nie są resetowania, a adres URL powiązany z poszczególnymi pomiarami danych to adres URL użytkownik zainicjował wczytanie strony.
Czy dane dotyczące podstawowych wskaźników internetowych mogą traktować zmiany trasy w SPA tak samo jak w przypadku tradycyjnego wczytywania strony?
Nie. Jeszcze nie.
Obecnie nie ma ujednoliconego sposobu tworzenia SPA, w popularnych aplikacjach SPA i bibliotekach routingu, wrażenia użytkowników mogą być różne między aplikacjami:
- Niektóre aplikacje SPA aktualizują adres URL tylko podczas wczytywania nowej „pełnej strony” treści, podczas gdy inne witryny aktualizują URL w przypadku drobnych zmian treści lub tylko stanu interfejsu. zmian.
- Niektóre aplikacje SPA aktualizują adres URL za pomocą interfejsu History API, a inne – hasz na potrzeby obsługi starszych przeglądarek (inne nie aktualizują adresu URL ).
- Niektóre aplikacje SPA wczytują treść, a następnie aktualizują URL, a inne aktualizują URL. przed wczytaniem treści.
- Niektóre aplikacje SPA wczytują całą zawartość jednocześnie, synchronicznie, w pojedynczym kodzie JavaScript. podczas gdy inne przechodzą asynchronicznie między różnymi (bez wyraźnego zdarzenia końcowego przejścia).
- Niektóre aplikacje SPA zawsze ładują treści z sieci, a inne wstępnie ładują wszystkie treści z góry, dzięki czemu zmiany trasy są ładowane natychmiast z pamięci.
Różnice te decydują o tym, co składa się na trasę SPA. a nawet samą SPA, jest to bardzo trudne na dużą skalę.
W niektórych przypadkach zmiana trasy w aplikacji SPA jest logicznie taka sama jak wczytanie strony MPA. W takich przypadkach dobrze byłoby, gdyby dotychczasowe dane można zastosować.
Jednak bez solidnych metod heurystycznych, które pozwalałyby prawidłowo zidentyfikować „prawdziwe” zmiany trasy z wszystkich innych zmian adresów URL, a także wyraźnych sygnałów wskazujących początek i koniec i dostarczanie informacji o podstawowych wskaźnikach internetowych w takich przypadkach byłoby problematyczne. danych i zmniejszyć ich przydatność do rzeczywistych interakcji użytkowników w witrynie.
Czy aplikacje SPA mają większe szanse na osiągnięcie dobrych wskaźników internetowych niż MPA?
Architektura SPA nie ma w sobie nic wbudowanego, co uniemożliwiałoby SPA może się wczytywać równie szybko jak SPA, a także uzyskiwać dobre wyniki na całej platformie Dane wskaźników internetowych – jako podobna strona w MPA.
Właściwie zoptymalizowane MPA mają jednak pewne zalety w Wartości progowe, których obecnie nie mają aplikacji SPA. Dzieje się tak, ponieważ w ramach MPA architektura, każda „strona” jest wczytywany jako nawigacja na całą stronę (a nie dynamiczne pobieranie treści i umieszczanie jej na bieżącej stronie). oznacza, że użytkownicy odwiedzający MPA chętniej wczytają więcej niż jedną stronę witryny, co z kolei oznacza, że większy odsetek rozkładu wszystkich wczytanie strony w ramach MPA będzie obejmowało niektóre lub wszystkie zasoby podrzędne w pamięci podręcznej.
Przyznany, jeśli MPA ma lepsze wyniki w zakresie podstawowych wskaźników internetowych niż SPA wymaga spełnienia kilku warunków:
- MPA musi mieć zoptymalizowane buforowanie zasobów podrzędnych, aby zapewnić strony wczytywane z tej samej domeny są rzeczywiście szybsze niż strony z innych domen w 75 centyl.
- Użytkownicy, którzy odwiedzają MPA, muszą odwiedzić więcej niż jedną stronę, aby witryna uzyskać korzyści z buforowania, które pozwalają przyspieszyć wczytywanie stron.
Podstawowe wskaźniki internetowe uwzględniają 75. percentyl strony więcej wizyt na stronach o wysokiej skuteczności w zbiorze danych, prawdopodobieństwo, że odwiedziny 75. percentyla rozkładu będą mieści się w zalecanych progach.
Pamiętaj, że przy porównywaniu wyników podstawowych wskaźników internetowych, pamiętaj o tym, określa sposób agregacji danych, czyli to, czy zbiór danych w dystrybucji obejmuje wszystkie strony w Twojej witrynie lub w miejscu pochodzenia albo tylko strony wczytywane w konkretnej witrynie adresu URL strony.
Przy agregowaniu wyników wszystkich stron w źródle – poszczególne szybkie strony mogą poprawić 75. percentyl dla całego punktu początkowego. Jednak podczas agregacji przez poszczególne strony, wyniki jednej strony nie będą miały wpływu na wyniki co dalej. Innymi słowy, agregując wyniki MPA według strony, można szybko buforować dane wczytania widoczne na stronie płatności nie poprawią wyniku spowolnienia początkowego wczytywania strony docelowej witryny .
Wynik swojej witryny możesz sprawdzić za pomocą różnych metod agregacji: PageSpeed Insights lub Raport na temat użytkowania Chrome API który podaje wyniki zarówno dla poszczególnych adresów URL stron, jak i dla całego źródła.
Na wyniki Podstawowych wskaźników internetowych wpływa też architektura SPA, danych, które biorą pod uwagę cały okres eksploatacji strony. Użytkownicy odwiedzający SPA pozostają na tej samej „stronie” dane skumulowane podczas całej sesji, może z czasem być trudniejsze w przypadku aplikacji SPA niż MPA.
W kwietniu 2021 r. ogłosiliśmy zmiany w danych CLS, które: ale częściowo rozwiązano ten problem. Wcześniej CLS skumulował się przez przez cały okres istnienia strony, podczas gdy obecnie gromadzi się on tylko przez określony czas czas, czyli najgorszy moment przesunięć układu na danej stronie.
Jednak nawet przy nowej definicji CLS, aplikacje SPA wciąż są niekorzystne. ponieważ wartość CLS nie jest „resetowana”. po zmianie trasy, z ładowaniem całej strony w formacie MPA. Może to być mylące, ponieważ układ przesunięcia, które zachodzą po przejściu trasy, są przypisywane do adresu URL strony, a nie adresu URL z paska adresu w momencie najechania (więcej szczegółów poniżej).
Czy architektura SPA poprawia wygodę użytkowników, czy nie powinna również zostać odzwierciedlona w danych?
Tak. Chociaż, jak już mówiliśmy wcześniej, liczba danych o tym, że usprawnienie działania firmy jest trudne do realizacji na dużą skalę, biorąc pod uwagę sposobów wdrażania aplikacji SPA w internecie.
Jak wspomnieliśmy wcześniej, branża, w tym Google, poświęcili prawie tyle samo czasu i wysiłku w opracowanie ukierunkowanej na użytkowników wydajności po wczytaniu tak jak na wczytanie strony. Nie jest to spowodowane faktem, że po wczytaniu wydajności nie mają znaczenia. Dzieje się tak, bo UX i interakcje po wczytaniu bardziej zróżnicowane i mniej precyzyjnie zdefiniowane, co utrudnia projektowanie danych .
Ale nawet wtedy, gdy mamy dobrze zdefiniowane dane po wczytaniu się do pomiaru SPA wydajności, nie chcemy ignorować procesu wczytywania tylko dlatego, po wczytaniu się poprawiło.
Jednym z celów inicjatywy Web Vitals jest promowanie i zachęcanie i wrażeniami użytkowników na tak wiele aspektów wczytywania i używania strony jak to tylko możliwe. Nie chcemy zachęcać użytkowników do podejmowania działań, i nie warto mieć za nie dość dobrych wrażeń. Użytkownicy zależy nam na tym, by strony szybko się wczytywały oraz przechodziły do nowych treści. przy projektowaniu danych, które są preferowane przez użytkowników.
Wersja MPA może być jednak lepsza w Core Web. i mają poziom 75 centyla w porównaniu z wersją SPA dokładnie w tym zakresie. wersja SPA powinna także spełniać „dobrą” i konkretnego progu. Jeśli Wersja SPA nie spełnia „dobrej” dla większości użytkowników, początkowy próg interfejs może nadal nie być postrzegany jako dobry – nawet jeśli kolejne funkcja nawigacji na stronie jest bardzo przydatna.
W przyszłości planujemy opracować dane, które umożliwią uważamy, że jest to najlepszy sposób na zachęcenie użytkowników do korzystania z wysokiej jakości SPA w taki sposób, by nie naruszyć procesu wczytywania początkowego. Mamy dostarczamy już nowe dane o nazwie Interakcja do następnego wyrenderowania (INP), który mierzy czas oczekiwania na interakcję w całym cyklu życia strony. Pracujemy nad tym, oraz wskaźniki po wczytaniu, w tym dane mierzące przejścia tras SPA. (patrz poniżej).
Zmieniliśmy naszą witrynę z MPA na SPA i nasze wyniki pogorszyły się. Czy to się zgadza?
To zależy. Wyniki mogą się zmienić z wielu powodów: duża migracja architektury i zmniejszenie liczby wczytywanych pamięci podręcznej pamięci podręcznej możemy uwzględnić pewną zmianę.
Szybkim sposobem na sprawdzenie jest przetestowanie wersji MPA i SPA jednego ze strony docelowe z Lighthouse. Jeśli Wynik w Lighthouse jest niższy w przypadku dowolnego z podstawowych wskaźników internetowych w przypadku SPA wtedy ładowanie się pogorszyło najprawdopodobniej po .
Czy trzeba zmienić stronę ze SPA na MPA, aby uzyskać lepszy wynik w Core Web Vitals?
Raczej nie. Przejście ze SPA na MPA jest niezadowalające ze stosem SPA i masz powody, aby sądzić, że MPA zapewni użytkowników.
Z czasem w miarę zwiększania wskaźników podstawowych wskaźników internetowych i obejmą więcej przeglądanie stron internetowych, zespoły z dobrze zaprojektowanymi aplikacjami SPA, które zapewniają znakomity komfort użytkowania, Podstawowe wskaźniki internetowe będą to odzwierciedlać.
Jeśli wyniki podstawowych wskaźników internetowych są raportowane tylko w przypadku stron docelowych SPA, jak mogę debugować problemy, które pojawiają się na „stronach”? po zmianie trasy?
Narzędzia Google, które raportują dane z terenu na potrzeby podstawowych wskaźników internetowych (np. wyszukiwarka). Console i PageSpeed Insights) pobierają dane z interfejsu Chrome User Experience Zgłoś (CrUX). Z kolei raport CrUX agreguje dane według źródła lub adresu URL strony (czyli adresu URL strony podczas wczytywania).
Ze wszystkich powyższych powodów raport na temat użytkowania Chrome nie może agregować danych według Trasa SPA. Jednak jako właściciel witryny, który zna własną architekturę, można to zmierzyć samodzielnie, a wiele narzędzi analitycznych gdy nastąpi zmiana trasy SPA i zaktualizuje on pomiar odpowiednie dane.
Mierząc wskaźniki internetowe za pomocą narzędzia analitycznego, upewnij się, mierzyć zarówno adres URL bieżącej trasy, jak i URL strony oryginalnej. Dzięki temu pozwalają na debugowanie poszczególnych problemów występujących na całej stronie cyklu życia i agregacji według oryginalnego adresu URL strony, aby dopasować narzędzi do pomiaru danych i generowania raportów.
Więcej informacji i sprawdzone metody znajdziesz w artykule Debugowanie wydajności w .
Co robi Google, aby reklamy MPA nie miały nieuczciwej przewagi w porównaniu z SPA?
Jak wspomnieliśmy powyżej, prawidłowo zoptymalizowana MPA może w niektórych przypadkach generować lepsze raporty, wskaźniki internetowe na 75. percentylu, ponieważ prawdopodobnie mają wyższy odsetek wizyt na stronie z pamięci podręcznej. I na odwrót – istotne usprawnienia wrażenia użytkowników w odpowiednio zoptymalizowanych aplikacjach SPA nie są obecnie przechwytywane. według podstawowych wskaźników internetowych.
W Google zdajemy sobie sprawę, że tworzy to zachęty, które nie są w pełni dopasowane pod kątem realizacji wskaźników internetowych. Szukamy nowych możliwości, aby to naprawić. Obecnie analizujemy 2 potencjalne rozwiązania: jedno krótkoterminowe. i jeden długoterminowy:
- Wizyty na stronach w tej samej domenie i z innych domen oceniaj oddzielnie.
- Zaprojektować nowe interfejsy API, które umożliwiają lepsze pomiary SPA.
Oceń wizyty na stronach z innych domen i z tej samej domeny z osobna
Obecnie dane w Podstawowych wskaźnikach internetowych obejmują wszystkie wizyty na stronie grupy – nie rozróżniają wizyt nowych i powracających klientów ani stron w porównaniu ze stronami płatności lub innym typem agregacji, w którym stan pamięci podręcznej może wpłynąć na wydajność.
Jednym ze sposobów znormalizowania różnic między skutecznością SPA i MPA jest przypisać różną wagę do poszczególnych typów wizyt, nawet jeśli zupełnie inny próg .
Zależy nam na nagradzaniu skutecznych implementacji pamięci podręcznej, chcesz, aby szybka nawigacja w witrynie pokrywała się z powolnym działaniem strony docelowej . Nie chcemy również zachęcać witryn do dzielenia długich stron zbiór krótszych stron w celu poprawy wyników wskaźników.
Dzięki oddzielnej ocenie wizyt na stronach z innych domen i z tej samej domeny możemy pomóc upewnić się, że oba typy doświadczeń są ważne, nie pozwalając popularność danego typu w danej witrynie zniekształca rozkład danych.
Projektowanie nowych interfejsów API, które umożliwiają lepsze pomiary SPA
Innym rozwiązaniem, nad którym aktywnie pracujemy (równolegle z powyższym) jest nowy interfejs App History API, który ułatwia ustandaryzowanie w przypadku wzorców SPA i ułatwiają pomiary i zrozumienie wykorzystania SPA na dużą skalę.
Interfejs App History API wprowadza
navigate, które
ma 2 główne cechy charakterystyczne dla pomiaru SPA:
- O
userInitiated, która będzie ustawiona na „true” (prawda), tylko jeśli nawigacja została zainicjowana za pomocą kliknięcie linku, przesłanie formularza lub przejście wstecz lub dalej w przeglądarce. - O
transitionWhile()która wymaga obietnicy, która pozwoli programiście zasygnalizować, kiedy utwór którą zainicjowali, aby ukończyć nawigację.
Flaga userInitiated może służyć do określenia semantycznego punktu początkowego dla
przejście trasy SPA, co wskazuje na wyraźne intencje użytkownika; transitionWhile()
dzięki obietnicy rozwiązywania problemów może pomóc przeglądarce skorelować renderowanie z konkretną trasą
umożliwiające przejście do największego wyrenderowania treści
związane z tym przejściem.
Opierając się na koncepcji omówionej w poprzedniej sekcji, można nawet można zebrać czas przejścia trasy SPA w tym samym zasobniku co strona w tej samej domenie wczytuje się w MPA; To bardzo ekscytujące, ponieważ witryny migracji z MPA do SPA, aby porównać wydajność potem.
Oczywiście musimy przeprowadzić więcej badań, zanim będziemy mogli właściwie określić, do podejmowania decyzji. Jeśli masz jakieś sugestie lub opinie na ich temat propozycje, proszę wysłać e-mailem web-vitals-feedback@googlegroups.com.
Uwagi końcowe
Google dokłada wszelkich starań, aby ulepszać wskaźniki internetowe i zapewniać mierzą i zachęcają do tego wysokiej jakości użytkowników. Zdajemy sobie sprawę, że obecnie istnieją luki w pomiarach. nie obejmują obecnie każdego aspektu wrażeń użytkownika, ale nad wyeliminowaniem tych luk.
Niezależnie od bieżących ograniczeń uważamy, że obszary danych mają kluczowe znaczenie dla prawidłowego funkcjonowania i sukcesu sieci. witryny (niezależnie od architektury) nie osiągają zalecanych progów, uważamy, że można coś poprawić.
Mam nadzieję, że ten post pomógł Ci rozwiać ten trudny i złożony temat. Jeśli chcesz przekazać nam opinię na temat bieżących lub przyszłych wskaźników internetowych, wyślij e-maila web-vitals-feedback@googlegroups.com.