Mierzenie i optymalizowanie Signed Exchange w celu osiągnięcia jak najlepszych wyników
Signed Exchange (SXG) to sposób na zwiększenie szybkości działania strony – dotyczy to głównie największego wyrenderowania treści (LCP). Gdy witryny odsyłające (obecnie wyszukiwarka Google) zawierają link do strony, mogą wstępnie pobrać ją do pamięci podręcznej przeglądarki, zanim użytkownik kliknie link.
Można tworzyć strony internetowe, które po wstępnym pobraniu nie wymagają dostępu do sieci na krytycznym etapie renderowania strony. W przypadku połączenia 4G wczytywanie strony wynosi od 2,8 s do 0,9 s (pozostałe 0,9 s to głównie wykorzystanie procesora):
Większość osób publikujących SXG korzysta obecnie z łatwej w użyciu funkcji Automatic Signed Exchanges (ASX) firmy Cloudflare (chociaż istnieją też opcje open source):
W wielu przypadkach zaznaczenie pola umożliwiającego włączenie tej funkcji wystarczy, aby uzyskać znaczną poprawę widoczną powyżej. Czasami trzeba wykonać kilka dodatkowych czynności, aby mieć pewność, że te SXG działają zgodnie z oczekiwaniami na każdym etapie procesu, oraz zoptymalizować strony, aby w pełni korzystać z wstępnego pobierania.
W ciągu kilku ostatnich miesięcy, odkąd Cloudflare zostało uruchomione, czytałem i odpowiedziałem na pytania na różnych forach oraz uczyłem się, jak doradzać właścicielom witryn, aby mogli w pełni wykorzystać potencjał wdrożeń SXG. Ten post to zbiór moich porad. Omówię teraz wszystkie kroki, które pozwolą Ci:
- Analizować wydajność SXG za pomocą WebPageTest.
- Debuguj potok SXG, jeśli krok Analizuj pokazuje, że nie działa.
- Optymalizuj strony pod kątem wstępnego pobierania SXG, w tym ustawiania optymalnego
max-agei wstępnego pobierania zasobów podrzędnych blokujących renderowanie. - Mierz poprawę SXG za pomocą Google Analytics, wybierając odpowiednie grupy eksperymentalne i kontrolne.
Wprowadzenie
Plik SXG to plik zawierający adres URL, zestaw nagłówków odpowiedzi HTTP i treść odpowiedzi, które są podpisane kryptograficznie za pomocą certyfikatu PKI sieci. Gdy przeglądarka wczytuje plik SXG, sprawdza te elementy:
- Subskrypcja SXG nie wygasła.
- Podpis jest zgodny z adresem URL, nagłówkami, treścią i certyfikatem.
- Certyfikat jest ważny i zgodny z adresem URL.
Jeśli weryfikacja się nie powiedzie, przeglądarka zrezygnuje z SXG i zamiast tego pobierze podpisany adres URL. Jeśli weryfikacja się powiedzie, przeglądarka wczyta podpisaną odpowiedź, traktując ją tak, jakby pochodziła bezpośrednio z podpisanego adresu URL. Dzięki temu usługi SXG mogą być ponownie hostowane na dowolnym serwerze, o ile nie wygasł ani nie został zmodyfikowany od momentu podpisania.
W przypadku wyszukiwarki Google mechanizm SXG włącza wstępne pobieranie stron z wyników wyszukiwania. W przypadku stron obsługujących SXG wyszukiwarka Google może z wyprzedzeniem pobrać jej kopię z pamięci podręcznej, która znajduje się na stronie webpkgcache.com. Te adresy URL webpkgcache.com nie wpływają na wyświetlanie ani działanie strony, ponieważ przeglądarka przestrzega pierwotnego, podpisanego adresu URL. Wstępne pobieranie może znacznie przyspieszyć wczytywanie strony.
Analizuj
Aby zobaczyć korzyści płynące z SXG, zacznij od użycia narzędzia laboratoryjnego do analizy wydajności SXG w powtarzalnych warunkach. Za pomocą WebPageTest możesz porównywać wykresy kaskadowe i LCP z wykorzystaniem lub bez wykorzystania pobierania wstępnego SXG.
Aby wygenerować test bez SXG:
- Otwórz stronę WebPageTest i zaloguj się. Gdy się zalogujesz, historia testów będzie zapisywana, aby można było je później łatwo porównywać.
- Wpisz adres URL, który chcesz przetestować.
- Otwórz Konfigurację zaawansowaną. (Test SXG wymaga konfiguracji zaawansowanej, więc warto użyć jej tutaj, aby mieć pewność, że opcje testu są takie same).
- Na karcie Ustawienia testu warto ustawić połączenie z 4G i zwiększyć „Liczba testów do wykonania” do 7.
- Kliknij Rozpocznij test.
Wygeneruj test z SXG, wykonując te same czynności co powyżej, ale zanim klikniesz Rozpocznij test, przejdź na kartę Skrypt, wklej ten skrypt WebPageTest i zmodyfikuj 2 adresy URL navigate w sposób podany poniżej:
// Disable log collection for the first step. We only want the waterfall for the target navigation.
logData 0
// Visit a search result page that includes your page.
navigate https://google.com/search?q=site%3Asigned-exchange-testing.dev+image
// Wait for the prefetch to succeed.
sleep 10
// Re-enable log collection.
logData 1
// Navigate to the prefetched SXG on the Google SXG Cache.
navigate https://signed--exchange--testing-dev.webpkgcache.com/doc/-/s/signed-exchange-testing.dev/sxgs/valid-image-subresource.html
Jeśli w przypadku pierwszego adresu URL (navigate) Twoja strona nie pojawia się jeszcze w żadnych wynikach wyszukiwania Google, możesz użyć tej strony pobierania z wyprzedzeniem, aby w tym celu utworzyć stronę wyników wyszukiwania udającą.
Aby określić drugi URL navigate, otwórz swoją stronę za pomocą rozszerzenia SXG Validator do Chrome, a następnie kliknij ikonę rozszerzenia, aby zobaczyć adres URL pamięci podręcznej:
Po zakończeniu tych testów otwórz Historię testów, wybierz 2 testy i kliknij Porównaj:
Dołącz &medianMetric=LCP do adresu URL porównania, aby WebPageTest wybierał uruchomienie ze medianą LCP dla każdej strony porównania. (Wartość domyślna to mediana według wskaźnika prędkości).
Aby porównać kaskadowe przejścia, rozwiń sekcję Przezroczystość kaskadowego przejścia i przesuń suwak. Aby wyświetlić film, kliknij Dostosuj ustawienia paska filmowego, przewiń w dół w oknie dialogowym i kliknij Wyświetl film.
Jeśli pobieranie wstępne SXG się powiedzie, zobaczysz, że kaskada „z SXG” nie zawiera wiersza dla HTML, a pobieranie zasobów podrzędnych rozpoczyna się wcześniej. Porównaj na przykład „Przed” i „Po”:
Debugowanie
Jeśli WebPageTest pokazuje, że SXG jest pobierana w ramach przewidywania, oznacza to, że wszystkie etapy łańcucha zostały wykonane prawidłowo. Możesz przejść do sekcji Optymalizuj, aby dowiedzieć się, jak jeszcze bardziej poprawić LCP. W przeciwnym razie musisz ustalić, gdzie w potoku wystąpił błąd i dlaczego. Dowiedz się, jak to zrobić.
Publikowanie
Upewnij się, że strony są generowane jako pliki SXG. Aby to zrobić, musisz udawać robota indeksującego. Najprostszym sposobem jest użycie rozszerzenia do Chrome SXG Validator:
Rozszerzenie pobiera bieżący adres URL z nagłówkiem żądania Accept, który wskazuje, że preferuje wersję SXG. Jeśli obok pola Źródło widzisz znacznik wyboru (✅), oznacza to, że zwrócono SXG. Możesz przejść do sekcji Indeksowanie.
Jeśli widzisz znak krzyżyka (❌), oznacza to, że nie zwrócono SXG:
Jeśli włączona jest usługa ASX Cloudflare, najprawdopodobniej przyczyną oznaczenia krzyżykiem (❌) jest nagłówek odpowiedzi z kontrolą pamięci podręcznej. ASX analizuje nagłówki o następujących nazwach:
Cache-ControlCDN-Cache-ControlSurrogate-ControlCloudflare-CDN-Cache-Control
Jeśli któryś z tych nagłówków zawiera którąś z tych wartości, nie pozwoli na wygenerowanie SXG:
privateno-storeno-cachemax-agemniejsze niż 120, chyba że zostanie zastąpione przez wartośćs-maxageo wartości większej lub równej 120
W takich przypadkach ASX nie tworzy SXG, ponieważ można przechowywać i wykorzystywać SXG w przypadku wielu wizyt i użytkowników.
Innym możliwym powodem oznaczenia krzyżykiem (❌) jest obecność jednego z tych nagłówków odpowiedzi z stanem, z wyjątkiem Set-Cookie. ASX usuwa nagłówek Set-Cookie, aby zachować zgodność ze specyfikacją SXG.
Inną możliwą przyczyną jest obecność nagłówka odpowiedzi Vary: Cookie. Googlebot pobiera elementy SXG bez danych logowania użytkownika i może wyświetlać je wielu użytkownikom. Jeśli na podstawie plików cookie udostępnisz różnym użytkownikom kod HTML, mogą oni zauważyć nieprawidłowe działanie, na przykład wyświetlenie strony jako wylogowany użytkownik.
Zamiast rozszerzenia Chrome możesz użyć narzędzia takiego jak curl:
curl -siH "Accept: application/signed-exchange;v=b3" $URL | less
lub dump-signedexchange:
dump-signedexchange -verify -uri $URL
Jeśli plik SXG jest obecny i prawidłowy, zobaczysz wydruk SXG w formie czytelnej dla człowieka wersji. W przeciwnym razie pojawi się komunikat o błędzie.
Indeksowanie
Upewnij się, że Twoje SXG są zaindeksowane przez wyszukiwarkę Google. Otwórz Narzędzia deweloperskie w Chrome i znajdź swoją stronę w Google. Jeśli strona została zindeksowana jako SXG, link Google do tej strony będzie zawierał atrybut data-sxg-url wskazujący kopię webpkgcache.com:
Jeśli wyszukiwarka Google uzna, że użytkownik prawdopodobnie kliknie wynik, pobiera go w ramach wstępnego pobierania:
Element <link> instruuje przeglądarkę, aby pobrała plik SXG do pamięci podręcznej z pobieraniem z wyprzedzeniem. Gdy użytkownik kliknie element <a>, przeglądarka użyje z pamięci podręcznej SXG do renderowania strony.
Możesz też sprawdzić, czy dane zostały pobrane z zapasu, otwierając w Narzędziach dla programistów kartę Sieć i szukając adresów URL zawierających webpkgcache.
Jeśli <a> wskazuje na webpkgcache.com, oznacza to, że indeksowanie przez wyszukiwarkę Google podpisanej giełdy działa prawidłowo. Możesz przejść do sekcji Przetwarzanie.
Inaczej może się zdarzyć, że od momentu włączenia SXG Google nie zindeksował jeszcze ponownie Twojej strony. Użyj narzędzia do sprawdzania adresów URL w Google Search Console:
Obecność nagłówka digest: mi-sha256-03=... oznacza, że wersja SXG została zindeksowana.
Jeśli nagłówek digest jest nieobecny, może to oznaczać, że usługa SXG nie została wyświetlona robotowi Googlebot lub że indeks nie został zaktualizowany od czasu włączenia SXG.
Jeśli plik SXG został zindeksowany, ale nadal nie jest z nim połączony, może to oznaczać, że nie spełnia on wymagań dotyczących pamięci podręcznej SXG. Omówimy je w następnej sekcji.
Przetwarzanie
Gdy wyszukiwarka Google indeksuje SXG, wysyła jego kopię do pamięci podręcznej Google SXG, która sprawdza, czy spełnia ona wymagania dotyczące pamięci podręcznej. Rozszerzenie do Chrome wyświetla wynik:
Jeśli widzisz znacznik wyboru (✅), możesz przejść do sekcji Optymalizuj.
Jeśli nie spełnia wymagań, zobaczysz krzyżyk (❌) i komunikat ostrzegawczy z wyjaśnieniem, dlaczego:
W takim przypadku strona będzie działać tak samo jak przed włączeniem SXG. Google będzie prowadzić do strony na jej pierwotnym hoście bez wstępnego pobierania SXG.
Jeśli kopia w pamięci podręcznej wygasła i jest ponownie pobierana w tle, zobaczysz piasek w klepsydrze (⌛):
Dokumentacja Google dla deweloperów dotycząca SXG zawiera też instrukcje ręcznego wysyłania zapytań do pamięci podręcznej.
Optymalizuj
Jeśli rozszerzenie SXG Validator w Chrome pokazuje wszystkie znaczniki wyboru (✅), oznacza to, że SXG może być wyświetlany użytkownikom. Czytaj dalej, aby dowiedzieć się, jak zoptymalizować stronę internetową, by uzyskać największy wzrost LCP dzięki SXG.
max-age
Gdy wygaśnie termin ważności danych SXG, pamięć podręczna Google SXG pobierze nową kopię w tle. W czasie oczekiwania na pobranie użytkownicy są kierowani na stronę na jej pierwotnym hoście, która nie jest pobierana wstępnie. Im dłużej ustawisz Cache-Control: max-age, tym rzadziej będzie przeprowadzane pobieranie w tle, a tym samym częściej zmniejszanie LCP przez pobieranie z wyprzedzeniem.
Jest to kompromis między wydajnością a aktualnością, a pamięć podręczna pozwala właścicielom witryn oferować SXG maksymalny wiek od 2 minut do 7 dni, zgodnie z konkretnymi potrzebami każdej strony. Z naszych obserwacji wynika, że:
max-age=86400(1 dzień) lub dłuższy działa dobrze w zakresie wydajnościmax-age=120(2 minuty) nie
Mamy nadzieję, że w miarę przyglądania się danym będziemy lepiej poznać wartości między tymi dwoma elementami.
user-agent
Raz zaobserwowałem wzrost czasu LCP podczas korzystania z wstępnie pobranego SXG. Uruchomiłem WebPageTest, aby porównać medianę wyników z włączonym i wyłączonym wstępnym pobieraniem SXG. Kliknij Dalej poniżej:
Widzę, że funkcja wstępnego pobierania działa. Kod HTML zostaje usunięty z ścieżki krytycznej, dzięki czemu wszystkie zasoby podrzędne mogą zostać wczytane wcześniej. Jednak LCP (zielona przerywana linia) zwiększył się z 2 s do 2,1 s.
Aby zdiagnozować ten problem, przyjrzałem się taśmom filmowym. Strona renderuje się inaczej w SXG. W czystym kodzie HTML Chrome uznało, że „największym elementem” w przypadku LCP jest nagłówek. Jednak w wersji SXG dodano na stronie baner wczytywany z opóźnieniem, który przesunął nagłówek poniżej pola widocznego na ekranie, przez co nowym największym elementem stało się okno do wyrażenia zgody na wykorzystanie plików cookie wczytywane z opóźnieniem. Wszystko renderowało się szybciej niż wcześniej, ale zmiana układu spowodowała, że dane wskazywały na wolniejsze działanie.
Po dokładnym zbadaniu sprawy udało mi się odkryć przyczynę różnic w układzie, że strona różni się w zależności od tego parametru (User-Agent), a to w kodzie logicznym jest błąd. Strona wyświetlała stronę na komputery, mimo że nagłówek indeksowania SXG wskazywał urządzenie mobilne. Po naprawieniu problemu przeglądarka ponownie prawidłowo zidentyfikowała nagłówek strony jako największy element.
Po kliknięciu „Po” widzę, że wstępnie pobierany LCP spada do 1,3 s:
SXG są włączone na wszystkich urządzeniach. Aby się do tego przygotować, upewnij się, że spełniasz co najmniej jeden z tych warunków:
- Twoja strona nie jest
VaryprzezUser-Agent(np. używa elastycznego projektowania lub osobnych adresów URL na urządzenia mobilne i komputery). - Jeśli strona korzysta z dynamicznego wyświetlania treści, jest adnotowana jako przeznaczona tylko na urządzenia mobilne lub tylko na komputery za pomocą tagu
<meta name=supported-media content=...>.
Zasoby podrzędne
SXG można używać do wstępnego pobierania zasobów podrzędnych (w tym obrazów) razem z kodem HTML. Cloudflare ASX przeskanuje kod HTML pod kątem elementów <link rel=preload> pochodzących z tego samego źródła (własnych) i konwertuje je na nagłówki Link zgodne z SXG. Szczegółowe informacje znajdziesz w kodzie źródłowym tutaj i tutaj.
Jeśli działa, zobaczysz dodatkowe zapytania do wyszukiwarki Google:
Aby przeprowadzić optymalizację pod kątem LCP, przyjrzyj się dokładnie kaskadzie i sprawdź, które zasoby znajdują się na krytycznej ścieżce prowadzącej do wyrenderowania największego elementu. Jeśli nie można ich pobrać w ramach wstępnego pobierania, zastanów się, czy można je usunąć z ścieżki krytycznej. Zwracaj uwagę na skrypty, które ukrywają stronę, dopóki nie skończą się wczytywać.
Pamięć podręczna Google SXG umożliwia do 20 załadowań podzasobów, a ASX zapewnia, że ten limit nie zostanie przekroczony. Dodanie zbyt wielu zasobów wstępnego wczytania może jednak wiązać się z ryzykiem. Przeglądarka będzie używać wstępnie załadowanych zasobów podrzędnych tylko wtedy, gdy wszystkie z nich zostaną pobrane, aby zapobiec śledzeniu w wielu witrynach. Im więcej masz zasobów podrzędnych, tym mniej prawdopodobne, że wszystkie zostaną wstępnie wczytane, zanim użytkownik kliknie Twoją stronę.
Narzędzie SXG Validator nie sprawdza obecnie zasobów podrzędnych. Aby debugować, użyj w międzyczasie curl lub dump-signedexchange.
Zmierz odległość
Po optymalizacji LCP w WebPageTest warto sprawdzić wpływ wstępnego pobierania SXG na ogólną wydajność witryny.
Wskaźniki po stronie serwera
Podczas pomiaru danych po stronie serwera, takich jak czas do pierwszego bajta (TTFB), pamiętaj, że Twoja witryna udostępnia pliki SXG tylko robotom, które obsługują ten format. Ogranicz pomiary TTFB do żądań pochodzących od prawdziwych użytkowników, a nie od botów. Generowanie SXG może wydłużać czas TTFB w przypadku żądań robota, ale nie ma to wpływu na komfort użytkowników.
Dane po stronie klienta
SXG przynoszą największe korzyści w zakresie szybkości dla danych po stronie klienta, zwłaszcza LCP. Aby zmierzyć ich wpływ, możesz po prostu włączyć ASX Cloudflare, poczekać, aż Googlebot ponownie zindeksuje stronę, odczekać kolejne 28 dni na zsumowanie danych Core Web Vitals, a potem sprawdzić nowe wartości CWV. Jednak zmiana może być trudna do zauważenia, ponieważ wpisuje się w tło innych zmian w tym okresie.
Uważam, że lepszym rozwiązaniem jest „przybliżenie” się do potencjalnie dotkniętych stron i omówienie ich w ten sposób: „SXG wpływają na X% wyświetleń stron, poprawiając ich LCP o Y milisekund w 75. percentylu”.
Obecnie prefetching SXG odbywa się tylko pod pewnymi warunkami:
- przeglądarka Chromium (np. Chrome lub Edge, z wyjątkiem iOS), w wersji M98 lub nowszej.
Referer: google.comlub innych domen wyszukiwania Google. Pamiętaj, że w Google Analytics tag odsyłający ma zastosowanie do wszystkich wyświetleń stron w sesji, a prefetch SXG dotyczy tylko pierwszego wyświetlenia strony, która została bezpośrednio połączona z wyszukiwarką Google.
W sekcji poświęconej współczesnym badaniom znajdziesz informacje o tym, jak mierzyć „X% odsłon stron” i „poprawę LCP o Y milisekund”.
Współczesne badania
Gdy przeglądasz dane z monitorowania rzeczywistych użytkowników (RUM), musisz podzielić wczytywanie stron na SXG i inne niż SXG. W tym celu bardzo ważne jest ograniczenie zestawu wczytanych stron, aby strona niebędąca objęta usługą porównywania cen spełniała warunki programu SXG, co pozwoli uniknąć stronniczego doboru. W przeciwnym razie wszystkie te elementy znajdowałyby się tylko w zestawie wczytań stron nieobejmujących SXG, które mogą mieć zupełnie inny LCP:
- Urządzenia z iOS: z powodu różnic pod względem sprzętu lub szybkości sieci między użytkownikami mającymi te urządzenia.
- Starsze przeglądarki Chromium: z tych samych powodów.
- Komputery: z tych samych powodów lub dlatego, że układ strony powoduje wybranie innego „największego elementu”.
- Nawigacja w tej samej witrynie (użytkownicy klikający linki w witrynie): użytkownicy mogą ponownie używać zasobów podrzędnych z pamięci podręcznej z poprzedniego wczytania strony.
W Google Analytics (UA) utwórz 2 niestandardowe wymiary o zakresie „Uderzenie”: jeden o nazwie „isSXG” i drugi o nazwie „referrer”. (wbudowany wymiar „Źródło” ma zakres sesji, więc nie wyklucza nawigacji na tej samej stronie).
Utwórz segment niestandardowy o nazwie „SXG counterfactual” z tymi filtrami połączonymi za pomocą operatora AND:
referrerzaczyna się odhttps://www.google.Browserściśle pasuje doChrome- Wersja
Browserpasuje do wyrażenia regularnego^(9[8-9]|[0-9]{3}) isSXGściśle pasuje dofalse
Utwórz kopię tego segmentu o nazwie „SXG”, z tym że isSXG jest dokładnie takie samo jak true.
W szablonie witryny nad fragmentem kodu Google Analytics dodaj ten fragment kodu. To specjalna składnia, którą ASX zmieni false na true podczas generowania SXG:
<script data-issxg-var>window.isSXG=false</script>
Dostosuj skrypt raportowania Google Analytics jako zalecane, aby rejestrować LCP. Jeśli używasz tagu gtag.js, zmień polecenie 'config', aby ustawić wymiar niestandardowy (zastępując wartości 'dimension1' i 'dimension2' nazwami zalecanymi przez Google Analytics):
gtag('config', 'YOUR_TRACKING_ID', {
'dimension1': String(isSXG),
'dimension2': document.referrer,
});
Jeśli używasz tagu analytics.js, zmień polecenie 'create' w sposób opisany tutaj.
Po odczekaniu kilku dni na zebranie danych otwórz raport Zdarzenia w Google Analytics i dodaj szczegółową analizę segmentu SXG. Powinien wypełnić symbol X: „SXGs wpływają na X% wyświetleń strony”:
Na koniec otwórz raport dotyczący wskaźników internetowych, kliknij „Wybierz segmenty”, a potem wybierz „SXG kontrfaktyczny” i „SXG”.
Kliknij „Prześlij”, aby wyświetlić rozkłady LCP dla 2 segmentów. Powinno ono wypełnić symbol Y dla „zwiększenia LCP o Y milisekundy w 75 centylu”:
Zastrzeżenia
Po zastosowaniu wszystkich powyższych filtrów załadowania stron SXG w ramach eksperymentu kontrafaktualnego powinny obejmować takie działania:
- Brak w pamięci podręcznej: jeśli Google SXG Cache nie ma nowej kopii SXG dla danego adresu URL, nastąpi przekierowanie do pierwotnego adresu URL w Twojej witrynie.
- Inne typy wyników: obecnie wyszukiwarka Google obsługuje tylko standardowe wyniki wyszukiwania w internecie i kilka innych typów wyników SXG. Inne, takie jak fragmenty z odpowiedzią i karuzela Najważniejsze artykuły, będą zawierać link do oryginalnego adresu URL w Twojej witrynie.
- Niekwalifikujące się adresy URL: jeśli niektóre strony w Twojej witrynie nie kwalifikują się do SXG (np. dlatego, że nie można ich przechowywać w pamięci podręcznej), mogą się pojawić w tym zestawie.
Pomiędzy wczytywaniem stron SXG a powyżej wymienionym zestawem stron nieobsługiwanych przez SXG może wystąpić pewien bias, ale powinien on być mniejszy niż biasy wymienione na początku sekcji dotyczącej współczesnych badań. Może się na przykład okazać, że strony, które nie mogą być przechowywane w pamięci podręcznej, wczytują się wolniej lub szybciej niż strony, które mogą być przechowywane w pamięci podręcznej. Jeśli podejrzewasz, że może to być problem, przejrzyj dane dotyczące konkretnego adresu URL kwalifikującego się do SXG, aby sprawdzić, czy wyniki są zgodne z ogólnymi wynikami badania.
Jeśli Twoja witryna zawiera strony AMP, raczej nie zwiększą się one wydajności po włączeniu SXG, ponieważ mogą one być już pobierane z wyprzedzeniem z wyszukiwarki Google. Możesz dodać filtr, aby wykluczyć takie strony i w ten sposób jeszcze bardziej zawęzić zakres analizy.
Nawet po uwzględnieniu wszystkich błędów selekcji istnieje ryzyko, że w statystykach RUM poprawa LCP będzie wyglądać jak pogorszenie. Ten artykuł dobrze wyjaśnia to ryzyko i podpowiada, jak sprawdzić, czy tak się dzieje, korzystając z jakiegoś rodzaju danych o porzuceniu.
Przed i po
Aby potwierdzić wyniki współczesnego badania, warto porównać LCP przed włączeniem SXG i po nim. Nie ograniczaj do wyświetleń strony SXG, aby wyeliminować wymienione powyżej potencjalne uprzedzenia. Zamiast tego sprawdź wyniki kwalifikujące się do SXG – definicje segmentów powyżej, ale bez ograniczenia isSXG.
Pamiętaj, że wyszukiwarka Google może potrzebować nawet kilku tygodni na ponowne zindeksowanie wszystkich stron w Twojej witrynie, aby wykryć, że włączono dla nich tag SXG. W ciągu tych kilku tygodni mogą wystąpić inne potencjalne błędy:
- Szybsze wczytywanie stron może być możliwe dzięki nowym wersjom przeglądarek lub ulepszeniom sprzętu użytkowników.
- Ważne wydarzenie, np. święto, może spowodować odchylenia w zwykłym ruchu.
Warto też sprawdzić ogólny LCP w 75. percentylu przed i po zmianach, aby potwierdzić wyniki badań. Informacje o podzbiorze populacji niekoniecznie odzwierciedlają całej populacji. Załóżmy na przykład, że SXG przyspiesza wczytywanie 10% stron o 800 ms.
- Jeśli były to już 10 najszybszych stron, nie wpłynie to w ogóle na 75. percentyl.
- Jeśli wczytywanie tych stron należało do 10 najwolniejszych, ale było o ponad 800 ms wolniejsze od 75. procentyla LCP, to w ogóle nie wpłynie to na 75. procentyl.
Są to ekstremalne przykłady, które prawdopodobnie nie odzwierciedlają rzeczywistości, ale mają nadzieję, że zilustrują problem. W praktyce SXG prawdopodobnie wpłynie na 75. procentyl w większości witryn. Nawigacja w różnych witrynach jest zwykle najwolniejsza, a ulepszenia wynikające z pobierania z wyprzedzeniem są znaczne.
Wykluczanie niektórych adresów URL
Na koniec warto porównać skuteczność SXG, wyłączając ją w przypadku niektórych adresów URL w witrynie. Możesz na przykład ustawić nagłówek CDN-Cache-Control: no-store, aby zapobiec generowaniu przez Cloudflare ASX generowania SXG. Nie zalecam tego.
W przypadku tej metody badania istnieje większe ryzyko wystąpienia stronniczości wyboru niż w przypadku innych metod. Może to mieć duży wpływ na wyniki, np. czy strona główna Twojej witryny czy inny popularny adres URL zostanie wybrany do grupy kontrolnej lub eksperymentalnej.
Badanie na zbiorze testowym
Najlepszym sposobem pomiaru wpływu jest przeprowadzenie badania z zatrzymaniem danych. Obecnie nie możesz przeprowadzić tego typu testu. W przyszłości planujemy wprowadzić obsługę takiego testu.
Badanie z zatrzymaniem danych ma te właściwości:
- W grupie eksperymentalnej pewna losowa część wyświetleń stron, które miałyby być wyświetlane w ramach SXG, jest „zatrzymywana” i zamiast tego wyświetlana jako strona, która nie jest SXG. Dzięki temu można porównywać ze sobą użytkowników, urządzenia, scenariusze i strony o podobnych cechach.
- Wstrzymane (kontrfaktyczne) wyświetlenia strony są odpowiednio oznaczone w statystykach. Dzięki temu możemy uzyskać bardziej szczegółowy widok danych, w którym możemy porównać wczytywanie strony SXG w grupie kontrolnej z wczytywaniem strony SXG w grupie eksperymentalnej. To z kolei redukuje zakłócenia podczas wczytywania innych stron, na które nie miał wpływu pobieranie z wyprzedzeniem SXG.
Pozwoli to wyeliminować wspomniane wyżej możliwe źródła stronnicości doboru, ale nie wyeliminuje ryzyka stronnicości o przetrwaniu w przypadku LCP. Obie te właściwości wymagają włączenia przeglądarki lub strony odsyłającej.
Podsumowanie
Uff... To było dużo. Mamy nadzieję, że pomoże Ci to lepiej zrozumieć, jak testować wydajność SXG w testach laboratoryjnych, jak optymalizować jej działanie w ramach ścisłej pętli sprzężenia zwrotnego z testem laboratoryjnym oraz jak mierzyć jej skuteczność w rzeczywistych warunkach. Połączenie tych wszystkich elementów powinno pomóc Ci w najlepszym wykorzystaniu plików SXG i zapewnić, że przyniosą one korzyści Twojej witrynie i użytkownikom.
Jeśli masz dodatkowe wskazówki dotyczące rejestrowania wyników SXG, daj nam znać. Zgłoś błąd na stronie developer.chrome.com, podając sugerowane ulepszenia.
Więcej informacji o giełdach podpisanych znajdziesz w dokumentacji web.dev i dokumentacji wyszukiwarki Google.