Jak mierzyć i optymalizować podpisane umowy wymiany reklam, aby uzyskać jak najlepsze wyniki
Podpisane wymiany (SXG) to sposób na poprawę szybkości strony, 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. Przy połączeniu 4G czas wczytywania tej strony zmienia się z 2,8 s na 0,9 s (pozostałe 0,9 s to głównie czas wykorzystania 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 ostatnich kilku miesięcy od wprowadzenia Cloudflare czytałam i odpowiadałam na pytania na różnych forach. Doradzamy też stronom, by w pełni wykorzystać możliwości wdrożenia SXG. Ten post zawiera moje porady. Pokaże Ci, jak:
- Analizować wydajność SXG za pomocą WebPageTest.
- Debuguj potok SXG, jeśli krok Analizuj pokazuje, że nie działa.
- Optymalizacja stron pod kątem pobierania z wyprzedzeniem SXG, w tym ustawienie optymalnego
max-agei wstępne wczytywanie podzasobów blokujących renderowanie. - Zmierz 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:
- SXG nie wygasł.
- 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. Umożliwia to przechowywanie danych SXG na dowolnym serwerze, o ile nie wygasły ani nie zostały zmodyfikowane 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 pobrać ich kopię z buforu, która jest hostowana na stronie webpkgcache.com. Adresy URL z domeny webpkgcache.com nie wpływają na wyświetlanie ani zachowanie strony, ponieważ przeglądarka respektuje oryginalny, podpisany adres 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 jak powyżej, ale przed kliknięciem Rozpocznij test otwórz kartę Skrypt, wklej ten skrypt WebPageTest i zmodyfikuj 2 adresy URL navigate zgodnie z instrukcjami:
// 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 Twoja strona nie pojawia się jeszcze w żadnych wynikach wyszukiwania Google, możesz użyć tej strony z wczytywaniem wstępnym, aby wygenerować fikcyjną stronę wyników wyszukiwania.
Aby określić drugi adres URL navigate, otwórz stronę za pomocą rozszerzenia do Chrome SXG Validator i kliknij ikonę rozszerzenia, aby wyświetlić adres URL pamięci podręcznej:
Po zakończeniu tych testów otwórz Historię testów, wybierz 2 testy i kliknij Porównaj:
Dodaj &medianMetric=LCP do adresu URL porównywania, aby WebPageTest wybrał uruchomienie z medianą LCP dla każdej strony porównywanej. (wartość domyślna to mediana według wskaźnika Szybkość indeksu).
Aby porównać wodospady, rozwiń sekcję Przezroczystość wodospadu i przeciągnij 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 okresy „przed” i „po” tutaj:
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. Najłatwiej jest użyć 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 sprawdza nagłówki o tych 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-agemniejsza niż 120, chyba że jest zastąpiona przez wartośćs-maxagewiększą lub równą 120
W takich przypadkach ASX nie tworzy SXG, ponieważ można przechowywać i wykorzystywać SXG w przypadku wielu wizyt i użytkowników.
Inną możliwą przyczyną pojawienia się znaku krzyżowego (❌) jest obecność jednego z tych stanowych nagłówków odpowiedzi (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 kod SXG jest dostępny i prawidłowy, zobaczysz jego czytelny dla człowieka wydruk. W przeciwnym razie pojawi się komunikat o błędzie.
Indeksowanie
Sprawdź, czy wyszukiwarka Google zindeksuje Twoje zapytania SXG. 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 stronę webpkgcache.com, oznacza to, że indeksowanie podpisanej komunikacji w wyszukiwarce Google działa. 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 Google pomyślnie zindeksowało wersję SXG.
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 SXG został zindeksowany, ale nadal nie jest połączony, może to oznaczać, że nie spełnia on wymagań dotyczących pamięci podręcznej. 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. Podczas oczekiwania na pobranie użytkownicy są przekierowywani na stronę na pierwotnym hoście, który nie jest wstępnie pobierany. 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ę pogłębiania analizy danych dowiemy się więcej o wartościach pośrednich.
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ć problem, sprawdziłem paski filmu. Strona renderuje się inaczej w SXG. W zwykłym języku HTML „największym elementem” LCP był 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ż do tej pory, ale zmiana układu spowodowała, że dane są raportowane wolniej.
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” zauważyłem, że wstępnie pobrane LCP spadło 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
VarydoUser-Agent(np. korzysta z elastycznego projektowania stron 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 skanuje kod HTML w poszukiwaniu elementów <link rel=preload> z tej samej domeny (własnych) i przekonwertuje je na nagłówki linków 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 zoptymalizować LCP, przyjrzyj się dokładniej wykresowi kaskadowemu i ustal, które zasoby znajdują się na ścieżce krytycznej do renderowania 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ć.
Google SXG Cache umożliwia wstępne załadowanie do 20 zasobów podrzędnych, 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 wczytywanych zasobów podrzędnych tylko wtedy, gdy wszystkie pliki zostały już pobrane, aby zapobiegać śledzeniu w wielu witrynach. Im więcej zasobów podrzędnych, tym mniejsze prawdopodobieństwo, że wszystkie z nich zostaną pobrane z zapasem przed tym, jak 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.
Dane po stronie serwera
Mierząc dane po stronie serwera, takie jak czas do pierwszego bajtu (TTFB), należy pamiętać, że Twoja witryna wyświetla SXG tylko robotom, które akceptują 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 związane z szybkością działania wskaźników po stronie klienta, a 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 warto powiększyć widok wczytywania strony, której dotyczy problem, i umieścić go w taki sposób: „SXG wpływa na X% wyświetleń stron, zwiększając LCP o Y milisekund na 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 w innych domenach wyszukiwarki 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. Trzeba przy tym ograniczyć zestaw wczytywanych stron, aby strona inna niż SXG spełniała warunki kwalifikacji do korzystania z technologii SXG i uniknąć efektu błędu 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: różnice w sprzęcie lub szybkości sieci wśród użytkowników tych urządzeń.
- 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 niestandardowy segment o nazwie „SXG kontrafaktyczny” z tymi filtrami połączonymi ORAZ:
referrerzaczyna się odhttps://www.google.Browserściśle pasuje doChromeBrowserWersja zgodna z wyrażeniem regularnym^(9[8-9]|[0-9]{3})isSXGściśle pasuje dofalse
Utwórz kopię tego segmentu o nazwie „SXG”, ale wymiar isSXG ściśle pasuje do true.
W szablonie witryny nad fragmentem kodu Google Analytics dodaj ten fragment kodu. To specjalna składnia, którą ASX zmieni z false na true podczas generowania SXG:
<script data-issxg-var>window.isSXG=false</script>
Aby rejestrować LCP, dostosuj skrypt raportowania Google Analytics zgodnie z zaleceniami. 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, zmodyfikuj 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. W tym miejscu powinna pojawić się wartość X w kolumnie „SXG wpływają na X% odsłon stron”:
Na koniec otwórz raport Web Vitals, wybierz „Wybierz segmenty” i kliknij „SXG w wersji kontrafacktualnej” oraz „SXG”.
Kliknij „Prześlij”. Powinny wyświetlić się rozkłady LCP obu segmentów. Wartość Y w ramach „poprawiania LCP o Y milisekund w 75. percentylu” powinna być wypełniona:
Zastrzeżenia
Po zastosowaniu wszystkich powyższych filtrów załadowania stron SXG w ramach eksperymentu kontrafaktualnego powinny obejmować takie działania:
- Błędy pamięci podręcznej: jeśli pamięć podręczna SXG Google nie ma aktualnej kopii SXG dla danego adresu URL, przekieruje na pierwotny adres URL w Twojej witrynie.
- Inne typy wyników: obecnie wyszukiwarka Google obsługuje tylko SXG dla standardowych wyników wyszukiwania w internecie i kilku innych typów. Inne, np. fragmenty z odpowiedzią i karuzela najważniejszych artykułów, zawierają link do pierwotnego adresu URL w Twojej witrynie.
- Nieodpowiednie adresy URL: jeśli niektóre strony w Twojej witrynie nie kwalifikują się do obsługi SXG (np. dlatego, że nie można ich przechowywać w pamięci podręcznej), mogą się one pojawić w tym zestawie.
Mogą występować odchylenia między wczytaniem strony SXG a powyższym zestawem stron nieobjętych SXG, ale powinna ona być mniejsza niż odchylenie wymienione w górnej części sekcji poświęconej badaniom współczesnym. 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, sprawdź dane ograniczone do konkretnego adresu URL kwalifikującego się do SXG, aby sprawdzić, czy wyniki są zgodne z ogólnymi wynikami badania.
Jeśli w Twojej witrynie są strony AMP, to prawdopodobnie nie zauważysz poprawy wydajności po włączeniu SXG, ponieważ mogą one być już pobierane z wyszukiwarki Google. Rozważ dodanie filtra, który pozwoli wykluczyć takie strony i zwiększyć widoczność istotnych zmian.
I wreszcie, nawet w obliczu wszystkich uprzedzeń doboru, istnieje ryzyko, że przez przetrwanie poprawa LCP będzie wyglądać jak pogorszenie statystyk RUM. Ten artykuł świetnie wyjaśnia to ryzyko. Proponujemy też zapoznanie się z jakąś formą danych porzuceń, która pomoże Ci wykryć, czy tak właśnie jest.
Przed i po badaniu
Aby potwierdzić wyniki z aktualnego badania, warto porównać LCP przed i po włączeniu SXG. Aby wyeliminować potencjalne błędy opisane powyżej, nie ograniczaj się do wyświetleń stron SXG. 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ło to już 10% najkrótszych czasów wczytywania strony, nie wpłynie to na 75 centyl.
- 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.
To przykłady skrajowe, które prawdopodobnie nie odzwierciedlają rzeczywistości, ale mam nadzieję, że pomogą zilustrować problem. W praktyce jest prawdopodobne, że w przypadku większości witryn SXG będzie miało wpływ na 75 centyl. Przechodzenie między witrynami zwykle trwa najdłużej, a poprawa dzięki pobieraniu wstępnemu może być znaczna.
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.
Z dużym prawdopodobieństwem tkwi w niej większe ryzyko błędów doboru treści niż w przypadku innych metod badawczych. 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 z izolacją grupy eksperymentalnej
Najlepszym sposobem pomiaru wpływu jest przeprowadzenie badania z zatrzymaniem danych. Niestety nie można obecnie wykonać tego typu testów. 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.
- Te odsłony (czyli odrzucone) 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. Aby włączyć te właściwości, musisz użyć przeglądarki lub witryny 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.