Jak mierzyć i optymalizować podpisane giełdy, aby jak najlepiej wykorzystać ich potencjał
Signed Exchange (SXG) to sposób na przyspieszenie działania strony – głównie największe wyrenderowanie treści (LCP). Odsyłając witryny (obecnie wyszukiwarka Google) do strony, mogą wczytać ją z wyprzedzeniem do pamięci podręcznej przeglądarki, zanim użytkownik kliknie link.
Możliwe jest tworzenie stron internetowych, które po wstępnym załadowaniu nie wymagają sieci na krytycznej ścieżce renderowania strony. Przy połączeniu 4G ładowanie strony wynosi 2,8 s do 0,9 s (pozostałe 0,9 s zależy głównie od wykorzystania procesora):
Większość osób publikujących SXG obecnie korzysta z łatwej w użyciu funkcji Automatic Signed Exchange (ASX) Cloudflare (chociaż dostępne są też opcje open source):
W wielu przypadkach wystarczy zaznaczyć to pole wyboru, aby uzyskać znaczne ulepszenia opisane powyżej. Czasami trzeba wykonać kilka dodatkowych kroków, aby mieć pewność, że te SXG będą działać zgodnie z oczekiwaniami na każdym etapie potoku oraz zoptymalizować strony pod kątem pełnego wykorzystania możliwości pobierania z wyprzedzeniem.
W ciągu ostatnich kilku miesięcy od wprowadzenia Cloudflare czytam i odpowiadam na pytania na różnych forach oraz uczę się, jak doradzać witrynom, jak maksymalnie wykorzystać wdrożenie SXG. Ten post jest zbiorem moich porad. Przeprowadzę kolejne kroki, aby:
- Przeanalizuj wydajność SXG za pomocą narzędzia WebPageTest.
- Zdebuguj potok SXG, jeśli krok Analizuj wskazuje, że nie działa.
- Zoptymalizuj strony pod kątem pobierania z wyprzedzeniem SXG, w tym ustawienie optymalnego parametru
max-agei wstępne wczytywanie zasobów podrzędnych blokujących renderowanie. - Mierz poprawę skuteczności SXG za pomocą Google Analytics, wybierając odpowiednie grupy eksperymentalne i kontrolne.
Wstęp
SXG to plik zawierający adres URL, zestaw nagłówków odpowiedzi HTTP i jej treść – wszystkie są podpisane kryptograficznie certyfikatem Web PKI. Gdy przeglądarka wczytuje SXG, sprawdza wszystkie te informacje:
- Subskrypcja SXG nie wygasła.
- Podpis pasuje do adresu URL, nagłówków, treści i certyfikatu.
- Certyfikat jest prawidłowy i pasuje do adresu URL.
Jeśli weryfikacja się nie powiedzie, przeglądarka porzuci plik 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 komponentów SXG na dowolnym serwerze, o ile nie wygasł ani nie został zmodyfikowany od czasu podpisania.
W przypadku wyszukiwarki Google SXG włącza wstępne pobieranie stron z wyników wyszukiwania. W przypadku stron obsługujących SXG wyszukiwarka Google może pobrać z pamięci podręcznej kopię strony hostowaną na webpkgcache.com. Takie adresy URL webpkgcache.com nie wpływają na wyświetlanie ani działanie strony, ponieważ przeglądarka uwzględnia pierwotny, podpisany adres URL. Wstępne wczytywanie może umożliwić znaczne szybsze ładowanie strony.
Analizuj
Aby docenić korzyści SXG, zacznij od użycia narzędzia laboratoryjnego w celu przeanalizowania skuteczności SXG w powtarzalnych warunkach. Za pomocą narzędzia WebPageTest możesz porównywać kaskady – i LCP – z pobieraniem z wyprzedzeniem SXG i bez niego.
Wygeneruj test bez SXG w ten sposób:
- Otwórz stronę WebPageTest i zaloguj się. Gdy się zalogujesz, historia testów będzie zapisywana, aby można było później łatwiej porównywać dane.
- Wpisz adres URL, który chcesz przetestować.
- Otwórz Konfiguracja zaawansowana. (Aby przeprowadzić test SXG, trzeba skorzystać z konfiguracji zaawansowanej, więc użycie jej tutaj pomoże Ci zadbać o to, aby opcje testów były takie same).
- Na karcie Ustawienia testu warto ustawić Połączenie na 4G i zwiększyć „Liczbę testów do wykonania” do 7.
- Kliknij Rozpocznij test.
Wygeneruj test przy użyciu SXG, wykonując te same czynności co powyżej, ale zanim klikniesz Rozpocznij test, przejdź do karty Skrypt, wklej ten skrypt WebPageTest i zmodyfikuj 2 adresy URL w 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
W przypadku pierwszego adresu URL w usłudze navigate, jeśli Twoja strona nie pojawia się jeszcze w żadnych wynikach wyszukiwania Google, możesz użyć tej strony pobierania z wyprzedzeniem, aby wygenerować w tym celu stronę z udawaniem wyników wyszukiwania.
Aby określić drugi adres URL dla pliku navigate, odwiedź swoją stronę przy użyciu rozszerzenia do Chrome SXG Validator i kliknij ikonę rozszerzenia, aby wyświetlić adres URL pamięci podręcznej:
Po zakończeniu testów kliknij Historia testów, wybierz 2 testy i kliknij Porównaj:
Dołącz &medianMetric=LCP do adresu URL porównania, aby WebPageTest wybrał uruchomienie z medianą LCP dla każdej strony porównania. (Domyślna wartość to mediana według wskaźnika prędkości).
Aby porównać wodospady, rozwiń sekcję Przezroczystość wodospadu i przeciągnij suwak. Aby wyświetlić film, kliknij Dostosuj ustawienia paska zdjęć, przewiń w dół okna i kliknij Wyświetl film.
Jeśli pobieranie SXG z wyprzedzeniem się powiedzie, zobaczysz, że kaskada „z SXG” nie zawiera wiersza z kodem HTML, a pobieranie zasobów podrzędnych rozpocznie się wcześniej. Porównaj np. wartości „Przed” i „Po”:
Debugowanie
Jeśli WebPageTest pokazuje, że SXG jest wstępnie pobierany, oznacza to, że udało się wykonać wszystkie kroki potoku. Możesz przejść do sekcji Optimize, aby dowiedzieć się, jak dalej poprawić LCP. W przeciwnym razie musisz sprawdzić, w którym miejscu w potoku i dlaczego wystąpił błąd. W dalszej części tego artykułu dowiesz się, jak to zrobić.
Publikuję
Upewnij się, że Twoje strony są generowane jako strony SXG. W tym celu musisz udawać robota. Najłatwiejszym sposobem jest użycie rozszerzenia do Chrome SXG Walidator:
Rozszerzenie pobiera bieżący adres URL z nagłówkiem żądania Accept, który wskazuje, że preferuje wersję SXG. Jeśli obok pozycji Origin widzisz znacznik wyboru (✅), oznacza to, że SXG został zwrócony. Możesz przejść do sekcji Indeksowanie.
Jeśli zobaczysz krzyżyk (❌), oznacza to, że SXG nie został zwrócony:
Jeśli włączone jest Cloudflare ASX, najbardziej prawdopodobną przyczyną znaku towarowego (❌) jest to, że nagłówek odpowiedzi kontroli pamięci podręcznej tego uniemożliwia. ASX analizuje nagłówki o następujących nazwach:
Cache-ControlCDN-Cache-ControlSurrogate-ControlCloudflare-CDN-Cache-Control
Jeśli którykolwiek z tych nagłówków zawiera którykolwiek z poniższych wartości, uniemożliwi to wygenerowanie SXG:
privateno-storeno-cachemax-agemniej niż 120, chyba że zostanie zastąpione wartościąs-maxagewiększą niż lub równą 120
W takich przypadkach ASX nie tworzy SXG, ponieważ mogą być przechowywane w pamięci podręcznej i ponownie używane w przypadku wielu wizyt i wielu użytkowników.
Inną możliwą przyczyną znaku krzyżykowego (❌) jest obecność jednego z tych nagłówków stanowych 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 pliki SXG bez danych logowania użytkownika i może je wyświetlać wielu użytkownikom. Jeśli wyświetlasz różnym użytkownikom inny kod HTML na podstawie ich pliku cookie, mogą oni zobaczyć coś niewłaściwego, np. wyświetlenie się po wylogowaniu.
Oprócz rozszerzenia do Chrome możesz też 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 czytelny dla człowieka wydruk SXG. W przeciwnym razie pojawi się komunikat o błędzie.
Indeksowanie
Upewnij się, że Twoje obiekty SXG zostały prawidłowo zindeksowane przez wyszukiwarkę Google. Otwórz Narzędzia deweloperskie w Chrome, a następnie wyszukaj stronę w Google. Jeśli strona została zindeksowana jako SXG, link do Twojej strony w Google będzie zawierać kod data-sxg-url wskazujący kopię na webpkgcache.com:
Jeśli wyszukiwarka Google uzna, że użytkownik prawdopodobnie kliknie wynik, pobierze go z wyprzedzeniem:
Element <link> informuje przeglądarkę, że ma pobrać SXG do pamięci podręcznej pobierania z wyprzedzeniem. Gdy użytkownik kliknie element <a>, przeglądarka użyje tego elementu zapisanego w pamięci podręcznej do renderowania strony.
Dowody pobierania z wyprzedzeniem możesz też zobaczyć, otwierając kartę Sieć w Narzędziach deweloperskich i wyszukując adresy URL zawierające ciąg webpkgcache.
Jeśli <a> wskazuje na webpkgcache.com, oznacza to, że indeksowanie podpisanej komunikacji w wyszukiwarce Google działa. Możesz przejść do sekcji Przetwarzanie.
Jeśli nie jest, może się zdarzyć, że Twoja strona nie została jeszcze zindeksowana przez Google ponownie od momentu włączenia SXG. Wypróbuj narzędzie do sprawdzania adresów URL w Google Search Console:
Obecność nagłówka digest: mi-sha256-03=... oznacza, że robot Google zindeksował wersję SXG.
Jeśli brak nagłówka digest, może to oznaczać, że Googlebot nie otrzymał nagłówka SXG lub 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 wymagań dotyczących pamięci podręcznej SXG. Zostały one omówione w następnej sekcji.
Przetwarzanie
Gdy wyszukiwarka Google indeksuje plik SXG, wysyła jego kopię do Google SXG Cache, która sprawdza, czy spełnia wymagania dotyczące pamięci podręcznej. Rozszerzenie do Chrome pokazuje wynik:
Jeśli pojawi się znacznik wyboru (✅), możesz przejść od razu do sekcji Optymalizacja.
Jeśli nie spełni wymagań, zobaczysz krzyżyk (❌) i komunikat z ostrzeżeniem z wyjaśnieniem, dlaczego:
W takim przypadku strona będzie działać tak samo jak przed włączeniem SXG. Google zamieści link do strony na swoim pierwotnym hoście bez pobierania z wyprzedzeniem SXG.
Jeśli kopia z pamięci podręcznej wygasła i jest pobierana ponownie w tle, zobaczysz klepsydrę (⌛):
Dokument Google dla deweloperów dotyczący SXG zawiera też instrukcje dotyczące ręcznego wysyłania zapytań dotyczących pamięci podręcznej.
Optymalizuj
Jeśli rozszerzenie SXG Walidator do Chrome pokazuje wszystkie znaczniki wyboru (✅), masz SXG, który możesz wyświetlać użytkownikom. Czytaj dalej, aby dowiedzieć się, jak zoptymalizować stronę internetową pod kątem uzyskania największego wzrostu LCP z SXG.
max-age
Gdy ważność plików SXG wygaśnie, pamięć podręczna Google SXG pobierze nową kopię w tle. Podczas oczekiwania na pobranie użytkownicy są kierowani na stronę na pierwotnym hoście, który nie jest wstępnie pobierany. Im dłużej ustawisz Cache-Control: max-age, tym rzadziej pobieranie w tle ma miejsce i tym częściej LCP można obniżyć przez pobieranie z wyprzedzeniem.
Jest to kompromis między wydajnością a aktualnością. Pamięć podręczna pozwala właścicielom witryn na zaspokajanie konkretnych potrzeb każdej strony z maksymalnym okresem ważności od 2 minut do 7 dni. Anegdocznie zauważamy, że:
- Skuteczność kampanii sprawdza się co najmniej
max-age=86400(co najmniej 1 dzień) max-age=120(2 minuty) nie
Mamy nadzieję, że w miarę jak będziemy analizować dane, dowiemy się więcej o wartościach między nimi.
user-agent
Zaobserwowałem jeden raz wzrost LCP przy korzystaniu z pobieranego z wyprzedzeniem SXG. Uruchomiłem WebPageTest, który porównuje wyniki mediany bez pobierania SXG i z wynikami pobierania z wyprzedzeniem. Kliknij Po poniżej:
Widzę, że pobieranie z wyprzedzeniem działa. Kod HTML jest usuwany ze ścieżki krytycznej, dzięki czemu wszystkie zasoby podrzędne mogą wczytywać się wcześniej. Jednak wskaźnik LCP – ta zielona przerywana linia – zwiększył się z 2 do 2,1 s.
Aby to zdiagnozować, przyjrzałam się pasmom filmów. Zauważyliśmy, że strona renderuje się inaczej w SXG. W przypadku zwykłego kodu HTML Chrome ustalił, że „największym elementem” dla LCP jest nagłówek. Jednak w wersji SXG dodany został baner leniwy, który spychał nagłówek na część strony widoczną po przewinięciu, a największym elementem było okno z prośbą o zgodę na używanie leniwego ładowania plików cookie. Wszystko renderowało się szybciej niż wcześniej, ale zmiana układu sprawiła, że dane są wolniejsze.
Poszukałem dokładniej i odkryłem, że różnica w układzie polega na tym, że różni się ona o User-Agent, co spowodowało błąd w logice. Wskazuje on stronę na komputery, mimo że nagłówek indeksowania SXG wskazuje na urządzenia mobilne. Po rozwiązaniu problemu przeglądarka ponownie poprawnie zidentyfikowała nagłówek strony jako największy element.
Po kliknięciu „Po” widzę, że pobrany z wyprzedzeniem LCP spada do 1,3 s:
SXG jest włączone w przypadku wszystkich formatów. Aby przygotować się na to zmiany, upewnij się, że jest spełniony jeden z tych warunków:
- Twoja strona nie jest
VarywUser-Agent(np. jest projektowana responsywnie lub osobne adresy URL na urządzenia mobilne i komputery). - Jeśli Twoja strona korzysta z dynamicznego wyświetlania treści, zostanie oznaczona za pomocą
<meta name=supported-media content=...>jako dostępna tylko na urządzenia mobilne lub komputery.
Zasoby podrzędne
SXG może służyć do pobierania z wyprzedzeniem zasobów podrzędnych (w tym obrazów) razem z kodem HTML. Cloudflare ASX przeskanuje kod HTML pod kątem własnych elementów <link rel=preload> 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 pobrania z wyprzedzeniem z wyszukiwarki Google:
Aby zoptymalizować LCP, przyjrzyj się dokładnie kaskadzie i sprawdź, które zasoby znajdują się na ścieżce krytycznej renderowania największego elementu. Jeśli nie można ich pobrać z wyprzedzeniem, zastanów się, czy można je usunąć ze ścieżki krytycznej. Wypatruj skryptów, które ukrywają stronę do momentu zakończenia ich wczytywania.
Google SXG Cache pozwala na do 20 wstępnych wczytań zasobów podrzędnych, a ASX zapewnia, że ten limit nie zostanie przekroczony. Istnieje jednak ryzyko, że dodasz zbyt wiele wstępnego wczytywania zasobów podrzędnych. Przeglądarka korzysta wtedy z wstępnie załadowanych zasobów podrzędnych, gdy wszystkie skończyły pobieranie danych, aby uniknąć śledzenia w witrynach. Im więcej zasobów podrzędnych, tym mniejsze jest prawdopodobieństwo, że wszystkie z nich zostaną pobrane z wyprzedzeniem, zanim użytkownik przejdzie do Twojej strony.
SXG Walidator nie sprawdza obecnie zasobów podrzędnych. Do debugowania możesz użyć w tym czasie curl lub dump-signedexchange.
Zmierz odległość
Po zoptymalizowaniu poprawy LCP w narzędziu WebPageTest warto zmierzyć wpływ pobierania z wyprzedzeniem SXG na ogólną wydajność witryny.
Dane po stronie serwera
Przy pomiarze danych po stronie serwera, takich jak czas do pierwszego bajtu (TTFB), należy pamiętać, że witryna udostępnia SXG tylko robotom, które akceptują ten format. Ogranicz pomiary dotyczące TTFB do żądań pochodzących od prawdziwych użytkowników, a nie od botów. Może się zdarzyć, że generowanie SXG zwiększy liczbę TTFB w przypadku żądań robota, ale nie będzie to miało wpływu na wrażenia użytkowników.
Dane po stronie klienta
SXG zapewnia największą szybkość w przypadku wskaźników po stronie klienta, zwłaszcza LCP. Aby zmierzyć ich wpływ, możesz po prostu włączyć Cloudflare ASX, poczekać na jego ponowne zindeksowanie przez Googlebota, odczekać dodatkowe 28 dni na agregację Podstawowych wskaźników internetowych (CWV) i sprawdzić nowe wartości CWV. Zmiana może być jednak niewyraźna w przypadku pomieszania się z innymi zmianami w tym okresie.
Uważam, że warto „powiększyć” wczytywane strony, których może dotyczyć problem, i odpowiednio je wykadrować: „SXG ma wpływ na X% wyświetleń stron, co zwiększa ich LCP o Y ms w 75. percentylu”.
Obecnie pobieranie z wyprzedzeniem SXG odbywa się tylko pod pewnymi warunkami:
- Przeglądarka Chromium (np. Chrome lub Edge z wyjątkiem iOS), wersja M98 lub nowsza
Referer: google.comlub innych domenach wyszukiwania w Google. (W Google Analytics tag odesłania dotyczy wszystkich wyświetleń strony w ramach sesji, podczas gdy pobieranie z wyprzedzeniem SXG ma zastosowanie tylko do pierwszego wyświetlenia strony, bezpośrednio powiązanego z wyszukiwarką Google).
Zapoznaj się z sekcją dotyczącą badań równoczesnych, aby dowiedzieć się, jak mierzyć „X% wyświetleń strony” i „poprawić LCP o Y milisekund”.
Badania współczesne
W przypadku danych monitorowania rzeczywistych użytkowników (RUM) należy podzielić wczytywanie stron na SXG i inne niż SXG. W takim przypadku należy ograniczyć zbiór wczytywanych stron, aby strona inna niż SXG była zgodna z warunkami kwalifikacji dla SXG, i uniknął tendencyjności wyboru. W przeciwnym razie poniższe elementy będą istniały tylko w grupie wczytywania stron innych niż SXG, które mogą mieć inny wskaźnik LCP:
- Urządzenia z iOS: z powodu różnic w szybkości sprzętu lub szybkości sieci w przypadku 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 wybór innego „największego elementu”.
- Nawigacje w tej samej witrynie (użytkownicy klikający linki w witrynie): ponieważ mogą ponownie korzystać z zasobów podrzędnych zapisanych w pamięci podręcznej z poprzedniego wczytywania strony.
W Google Analytics (UA) utwórz 2 wymiary niestandardowe o zakresie „Działanie”, jednym o nazwie „isSXG”, a drugim o nazwie „strona odsyłająca”. (Wbudowany wymiar „Źródło” ma zakres sesji, więc nie wyklucza nawigacji w tej samej witrynie).
Utwórz segment niestandardowy o nazwie „Roszczenie wzajemne SXG” z połączonych ze sobą tych filtrów ORAZ:
referrerzaczyna się odhttps://www.google.Browserściśle pasuje doChrome- Wersja pola
Browserpasuje do wyrażenia regularnego^(9[8-9]|[0-9]{3}) isSXGściśle pasuje dofalse
Utwórz kopię tego segmentu o nazwie „SXG”. Wyjątek stanowi wartość isSXG ściśle pasuje do true.
W szablonie witryny dodaj ten fragment kodu nad fragmentem kodu Google Analytics. To jest 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 zgodnie z zaleceniami, aby rejestrować LCP. Jeśli korzystasz z tagu gtag.js, zmodyfikuj polecenie 'config', aby ustawić wymiar niestandardowy (zastępując 'dimension1' i 'dimension2' nazwami, których ma używać 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.
Odczekaj kilka dni, aby zebrać trochę danych, a potem otwórz raport Zdarzenia w Google Analytics i dodaj szczegółową analizę segmentu SXG. Powinno to spowodować wypełnienie pola X w przypadku „SXG ma wpływ na X% wyświetleń strony”:
Na koniec otwórz raport dotyczący wskaźników internetowych, kliknij „Wybierz segmenty”, a następnie wybierz „Kontrolny SXG” i „SXG”.
Kliknij „Prześlij”. Wyświetlą się rozkłady LCP dla obu segmentów. Powinno to spowodować wypełnienie wartości Y dla „poprawy LCP o Y milisekund przy 75. percentylu”:
Zastrzeżenia
Gdy zastosujesz wszystkie powyższe filtry, wczytywanie stron przeciwfaktycznych SXG powinno odbywać się w ten sposób:
- Niewykorzystane w pamięci podręcznej: jeśli w Google SXG Cache nie ma nowej kopii kodu SXG dla danego adresu URL, nastąpi przekierowanie na pierwotny adres 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 za pomocą SXG. Inne, takie jak fragmenty z odpowiedzią i karuzela najważniejszych artykułów, zawierają link do oryginalnego adresu URL Twojej witryny.
- Nieodpowiednie adresy URL: jeśli niektóre strony w Twojej witrynie nie kwalifikują się do korzystania z SXG (np. dlatego, że nie można ich buforować), mogą się pojawić w tej grupie.
Między wczytaniem strony SXG a powyższym zakresem wczytywania stron innych niż SXG mogą występować pozostałe odchylenia, ale powinny one być mniejsze niż odchylenia wymienione w górnej części sekcji badań współczesnych. Być może strony, których nie można buforować, są wolniejsze lub szybsze niż strony zapisywane w pamięci podręcznej. Jeśli podejrzewasz, że może to być problem, przejrzyj dane ograniczone do określonego adresu URL kwalifikującego się do SXG, aby sprawdzić, czy uzyskane wyniki pasują do ogólnego badania.
Jeśli Twoja witryna zawiera strony AMP, prawdopodobnie nie odnotują poprawy wydajności po włączeniu SXG, ponieważ mogą one już być wstępnie pobierane z wyszukiwarki Google. Rozważ dodanie filtra, aby wykluczyć takie strony i „powiększyć” odpowiednie zmiany.
Wreszcie, nawet biorąc pod uwagę wszystkie odchylenia związane z wyborem, istnieje ryzyko, że tendencyjność przetrwania sprawia, że poprawa LCP wygląda jak spadek w statystykach RUM. Ten artykuł zawiera świetne objaśnienie tego ryzyka i zachęca do zapoznania się z jakąś formą danych dotyczących porzuceń, aby ustalić, czy faktycznie tak się dzieje.
Badanie przed/po
Aby potwierdzić wyniki współczesnego badania, warto porównać LCP przed włączeniem SXG i po nim. Nie ograniczaj się do wyświetleń stron SXG, aby wyeliminować opisane powyżej potencjalne uprzedzenia. Zamiast tego sprawdzaj wyniki kwalifikujące się do SXG – podane wyżej definicje segmentów, ale bez ograniczenia isSXG.
Ponowne zindeksowanie wszystkich stron Twojej witryny przez wyszukiwarkę Google może potrwać nawet kilka tygodni, ponieważ sygnalizuje ona, że usługa SXG została w niej włączona. W ciągu tych kilku tygodni mogą wystąpić również inne potencjalne odchylenia:
- Nowe wersje przeglądarek lub ulepszenia sprzętu użytkowników mogą przyspieszyć wczytywanie stron.
- Istotne wydarzenie, np. święto, może spowodować zniekształcenie ruchu.
Pomocne może być również sprawdzenie ogólnego 75. percentyla LCP przed i po, w celu potwierdzenia powyższych badań. Poznawanie podzbioru populacji nie musi dostarczyć informacji o ogólnej populacji. Załóżmy na przykład, że usługa SXG poprawia 10% wczytań stron o 800 ms.
- Gdyby strony ładowały się już o 10% najszybciej, nie wpłynie to na 75 centyl.
- Jeśli witryny wczytywały się o 10% najwolniej niż w przypadku LCP o ponad 800 ms, to w ogóle ich to nie zmienia.
Są to ekstremalne przykłady, które prawdopodobnie nie odzwierciedlają rzeczywistej sytuacji, ale mam nadzieję, że zilustrują ten problem. W praktyce SXG jest prawdopodobne, że w przypadku większości witryn wpłynie na 75 centyl. Nawigacja między witrynami jest zwykle najwolniejsza, a ulepszenia wynikające z pobierania z wyprzedzeniem zwykle są istotne.
Zrezygnuj z niektórych adresów URL
Jednym ze sposobów porównywania skuteczności SXG może być wyłączenie SXG w przypadku niektórych podzbiorów adresów URL w witrynie. Możesz na przykład ustawić nagłówek CDN-Cache-Control: no-store, aby uniemożliwić Cloudflare ASX generowanie SXG. Nie zalecam tego.
Prawdopodobnie wiąże się to z większym ryzykiem odchylenia doboru niż w przypadku innych metod badania. Na przykład duże znaczenie może mieć to, czy strona główna witryny czy adres URL o podobnej popularności zostaną wybrane do grupy kontrolnej, czy do eksperymentalnej.
Badanie izolacji
Najlepszym sposobem na zmierzenie wpływu jest przeprowadzenie badania izolacji. Niestety obecnie nie można przeprowadzić takiego testu. W przyszłości planujemy wprowadzić obsługę takiego testu.
Badanie wstrzymania ma te właściwości:
- W grupie eksperymentalnej niektóre losowe wyświetlenia stron, które stanowiłyby SXG, są „wstrzymywane” i wyświetlane jako niezwiązane z SXG. Dzięki temu można przeprowadzić porównanie równoważnych użytkowników, urządzeń, scenariuszy i stron.
- Wstrzymane wyświetlenia strony (nazywane też kontrfaktycznymi) są odpowiednio oznaczone w statystykach. Dzięki temu dane można wyświetlić w powiększeniu, co pozwala porównać liczbę wczytań strony SXG w grupie kontrolnej z kontrfaktami w ramach eksperymentu. To z kolei eliminuje zakłócenia z innych stron, na które nie miałyby wpływu pobieranie z wyprzedzeniem SXG.
Pozwala to wyeliminować wspomniane wyżej możliwe źródła stronniczości w wyborze, chociaż nie eliminuje ryzyka związanego z utrzymaniem LCP. Obie te właściwości wymagają włączenia przeglądarki lub strony odsyłającej.
Podsumowanie
Uff... To dużo. Mamy nadzieję, że ukazuje pełniejszy obraz tego, jak testować wydajność SXG w testach laboratoryjnych, jak optymalizować wydajność w ramach ścisłej pętli informacji zwrotnych z testem laboratoryjnym, a na koniec jak mierzyć jego skuteczność w świecie rzeczywistym. Połączenie wszystkich tych elementów powinno pomóc Ci w pełni wykorzystać potencjał SXG i zapewnić korzyści Twojej witrynie i użytkownikom.
Jeśli masz więcej wskazówek, jak rejestrować wydajność SXG, daj nam znać. Zgłoś błąd na stronie developers.chrome.com, uwzględniając proponowane ulepszenia.
Więcej informacji o technologii Signed Exchange znajdziesz w dokumentacji web.dev i dokumentacji wyszukiwarki Google.