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 stron – dotyczy to głównie największego wyrenderowania treści (LCP). Gdy witryny odsyłające (obecnie wyszukiwarka Google) zawierają linki do strony, mogą pobrać ją z wyprzedzeniem do pamięci podręcznej przeglądarki, zanim użytkownik kliknie ten link.
Możesz tworzyć strony internetowe, które po pobraniu nie wymagają sieci na krytycznej ścieżce renderowania. 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 obecnie SXG korzysta z łatwej w użyciu funkcji automatycznej wymiany podpisanej (ASX) dostępnej w Cloudflare (ale istnieją też opcje open source):
W wielu przypadkach zaznaczenie pola wyboru w celu włączenia tej funkcji wystarczy, aby uzyskać wskazaną powyżej istotną poprawę. Czasami trzeba wykonać jeszcze kilka dodatkowych czynności, aby upewnić się, że SXG działają zgodnie z oczekiwaniami na każdym etapie procesu, i zoptymalizować strony, aby w pełni wykorzystać pobieranie z wyprzedzeniem.
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. Omówię teraz wszystkie kroki, które pozwolą Ci:
- Przeanalizuj wydajność SXG przy użyciu WebPageTest.
- Zdebuguj potok SXG, jeśli krok analizy wykaże, że nie działa.
- Optymalizacja stron pod kątem pobierania z wyprzedzeniem SXG, w tym ustawienie optymalnego
max-age
i wstępne wczytywanie podzasobów blokujących renderowanie. - Mierz poprawę SXG za pomocą Google Analytics, wybierając odpowiednie grupy eksperymentalne i kontrolne.
Wprowadzenie
SXG to plik zawierający adres URL, zestaw nagłówków odpowiedzi HTTP i treść odpowiedzi – wszystkie są podpisane kryptograficznie za pomocą certyfikatu Web PKI. Po wczytaniu pliku SXG przeglądarka sprawdza wszystkie te elementy:
- Subskrypcja SXG nie wygasła.
- Podpis jest zgodny z adresem URL, nagłówkami, treścią i certyfikatem.
- Certyfikat jest ważny i pasuje do adresu URL.
Jeśli weryfikacja się nie powiedzie, przeglądarka porzuci SXG i 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 pobierać kopię strony z pamięci podręcznej przechowywanej na stronie webpkgcache.com. Adresy URL webpkgcache.com nie mają wpływu na wyświetlanie ani zachowanie strony, ponieważ przeglądarka przestrzega pierwotnego, podpisanego adresu URL. Wstępne wczytywanie może przyspieszyć wczytywanie strony.
Analizuj
Aby przekonać się, jakie korzyści przynoszą SXG, zacznij od użycia narzędzia laboratoryjnego, aby przeanalizować wydajność SXG w powtarzalnych warunkach. Za pomocą narzędzia WebPageTest możesz porównać 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 je później łatwo porównywać.
- Wpisz adres URL, który chcesz przetestować.
- Przejdź do sekcji Advanced Configuration (Konfiguracja zaawansowana). (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 na 4G i zwiększyć liczbę 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ć udawanie wyników wyszukiwania.
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 testów otwórz Historię testów, wybierz oba 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ć wodospady, rozwiń sekcję Przezroczystość wodospadu i przeciągnij suwak. Aby wyświetlić film, kliknij Dostosuj ustawienia paska zdjęć, przewiń w dół i kliknij Wyświetl film.
Jeśli pobieranie z wyprzedzeniem SXG się powiedzie, zobaczysz, że kod „z SXG” kaskada nie zawiera wiersza kodu HTML, a pobieranie zasobów podrzędnych rozpocznie się wcześniej. np. „Przed” i „Po” tutaj:
Debugowanie
Jeśli WebPageTest pokazuje, że interfejs SXG jest wstępnie wczytywany, oznacza to, że udało się wykonać wszystkie kroki potoku. możesz przejść do sekcji Optymalizacja, aby dowiedzieć się, jak jeszcze bardziej poprawić LCP. W przeciwnym razie musisz sprawdzić, w którym miejscu potoku wystąpił błąd i dlaczego. , aby dowiedzieć się, jak to zrobić.
Publikowanie
Upewnij się, że strony są generowane jako 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 informuje, że preferuje wersję SXG. Jeśli obok Origin zobaczysz znacznik wyboru (✅), oznacza to, że został zwrócony SXG. możesz przejść do sekcji Indeksowanie.
Jeśli widzisz krzyżyk (❌), oznacza to, że kod SXG nie został zwrócony:
Jeśli opcja Cloudflare ASX jest włączona, najprawdopodobniej przyczyną pojawiania się krzyżyka (❌) jest to, że uniemożliwia to nagłówek odpowiedzi dotyczącej kontroli pamięci podręcznej. ASX analizuje nagłówki o następujących nazwach:
Cache-Control
CDN-Cache-Control
Surrogate-Control
Cloudflare-CDN-Cache-Control
Jeśli którykolwiek z tych nagłówków zawiera dowolną z tych wartości, uniemożliwi wygenerowanie pliku SXG:
private
no-store
no-cache
max-age
mniejsze niż 120, chyba że zostanie zastąpione przez wartośćs-maxage
o wartości większej lub równej 120
ASX nie tworzy w takich przypadkach SXG, ponieważ mogą one być przechowywane w pamięci podręcznej i używane w przypadku wielu wizyt i wielu 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 zapewnić zgodność ze specyfikacją SXG.
Inną możliwą przyczyną jest obecność nagłówka odpowiedzi Vary: Cookie
. Googlebot pobiera strony SXG bez danych logowania użytkownika i może je wyświetlać wielu użytkownikom. Jeśli udostępnisz różnym użytkownikom kod HTML na podstawie ich plików cookie, mogą oni zauważyć nieprawidłowe działanie, na przykład wyświetlenie jako wylogowany.
Zamiast rozszerzenia do 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 wyszukaj w Google swoją stronę. Jeśli strona została zindeksowana jako SXG, link Google do Twojej strony będzie zawierał atrybut data-sxg-url
wskazujący kopię webpkgcache.com:
Jeśli wyszukiwarka Google uzna, że użytkownik prawdopodobnie kliknie wynik, również pobierze go z wyprzedzeniem:
Element <link>
informuje przeglądarkę, że ma pobrać obiekt SXG do swojej pamięci podręcznej pobierania z wyprzedzeniem. Gdy użytkownik kliknie element <a>
, przeglądarka użyje SXG zapisanego w pamięci podręcznej do renderowania strony.
Dowody pobrania z wyprzedzeniem możesz też zobaczyć, otwierając kartę Sieć w Narzędziach deweloperskich i wyszukując adresy URL zawierające 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.
W przeciwnym razie strona może nie zostać jeszcze zindeksowana przez Google 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 wersja SXG została zindeksowana.
Jeśli brak nagłówka digest
, może to oznaczać, że komponent SXG nie został udostępniony Googlebotowi 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 obiekt SXG, wysyła jego kopię do pamięci podręcznej Google SXG, która sprawdza jej zgodność z wymaganiami dotyczącymi pamięci podręcznej. Rozszerzenie do Chrome pokazuje wynik:
Jeśli pojawi się znacznik wyboru (✅), możesz od razu przejść do sekcji Optymalizacja.
Jeśli nie spełnia on wymagań, zobaczysz krzyżyk (❌) i ostrzeżenie z informacją o przyczynie:
W takim przypadku strona będzie działać tak samo jak przed włączeniem SXG. Google udostępni link do strony na pierwotnym hoście bez pobierania z wyprzedzeniem SXG.
Jeśli kopia w pamięci podręcznej wygasła i jest ponownie pobierana w tle, zobaczysz klepsydrę (⌛):
Dokument Google dla deweloperów w SXG zawiera też instrukcje ręcznego wysyłania zapytań do pamięci podręcznej.
Optymalizuj
Jeśli rozszerzenie do Chrome SXG Validator widzisz wszystkie znaczniki wyboru (✅), masz SXG, który 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 zapytania SXG wygasną, Google SXG Cache 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. Odkrywamy, że:
max-age=86400
(co najmniej 1 dzień) pozwala zwiększyć skutecznośćmax-age=120
(2 minuty) – nie
Mamy nadzieję, że w miarę analizy danych będziemy mogli dowiedzieć się więcej o wartościach pomiędzy nimi.
user-agent
Raz zaobserwowałem wzrost wartości LCP po zastosowaniu pobranego z wyprzedzeniem SXG. Wykonałem test WebPageTest, porównując medianę wyników bez pobierania z wyprzedzeniem SXG oraz bez 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 wczytują się wcześniej. Jednak LCP – zielona przerywana linia – wzrosła z 2 s do 2,1 s.
Aby zdiagnozować ten problem, przyjrzałem się taśmom filmowym. Okazało się, że strona renderowała się inaczej w SXG. W zwykłym języku HTML przeglądarka Chrome ustaliła, że „największy element” dla LCP. Jednak w wersji SXG do strony dodano baner leniwie ładowany, który spychał nagłówek na część strony widoczną po przewinięciu i spowodował, że nowym największym elementem będzie okno z prośbą o zgodę na stosowanie plików cookie. 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. Wyświetlana była strona na komputery, chociaż nagłówek indeksowania SXG wskazywał jej wersję mobilną. Po rozwiązaniu tego problemu przeglądarka ponownie poprawnie zidentyfikowała nagłówek strony jako jego największy element.
Po kliknięciu „Po” widzę, że wstępnie pobierany LCP spada do 1,3 s:
Usługi SXG są włączone w przypadku wszystkich formatów. Aby się do tego przygotować, upewnij się, że jest spełniony jeden z tych warunków:
- Twoja strona nie jest
Vary
doUser-Agent
(np. korzysta z elastycznego projektowania stron lub osobnych adresów URL na urządzenia mobilne i komputery). - Jeśli Twoja strona korzysta z dynamicznego wyświetlania treści, w kodzie
<meta name=supported-media content=...>
zostanie oznaczona adnotacją tylko na urządzenia mobilne lub komputery.
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óły w kodzie źródłowym znajdziesz tutaj i tutaj.
Jeśli to zadziała, zobaczysz dodatkowe pobrania z wyprzedzeniem z 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ć z wyprzedzeniem, zastanów się, czy można je usunąć z krytycznej ścieżki. Zwracaj uwagę na skrypty, które ukrywają stronę, dopóki nie zostanie wczytana.
Google SXG Cache umożliwia wstępne załadowanie do 20 zasobów podrzędnych, a ASX zapewnia, że ten limit nie zostanie przekroczony. Istnieje jednak ryzyko dodania zbyt wielu wstępnych załadowań zasobów podrzędnych. 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 masz zasobów podrzędnych, tym mniej prawdopodobne, że wszystkie zostaną wstępnie wczytane, zanim użytkownik kliknie Twoją stronę.
Walidator SXG nie sprawdza obecnie zasobów podrzędnych; do debugowania, możesz w międzyczasie używać narzędzia curl
lub dump-signedexchange
.
Zmierz odległość
Po zoptymalizowaniu poprawy LCP w ramach WebPageTest warto zmierzyć wpływ pobierania z wyprzedzeniem SXG na ogólną wydajność witryny.
Wskaźniki 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. Może się okazać, że generowanie SXG zwiększa ilość TTFB w przypadku żądań robota, ale nie ma to wpływu na i uzyskiwanie dodatkowych informacji.
Dane po stronie klienta
SXG dają największe korzyści w zakresie szybkości wczytywania wskaźników po stronie klienta, a zwłaszcza LCP. Aby zmierzyć ich wpływ, możesz po prostu włączyć Cloudflare ASX, poczekać na ponowne zindeksowanie strony przez Googlebota, odczekać dodatkowe 28 dni na agregację podstawowych wskaźników internetowych (CWV) i sprawdzić nowe wartości CWV. Trudno jednak dostrzec tę zmianę po jej połączeniu z innymi zmianami z tego okresu.
Lepiej „powiększyć” widok na załadowanej stronie, której dotyczy problem, i umieść w ramce taki komunikat: „SXG wpływa na X% wyświetleń strony, zwiększając LCP o Y milisekund na 75. percentylu”.
Obecnie pobieranie z wyprzedzeniem SXG odbywa się tylko pod pewnymi warunkami:
- przeglądarkę Chromium (np. Chrome lub Edge z wyjątkiem iOS), w wersji M98 lub nowszej;
Referer: google.com
lub w innych domenach wyszukiwarki Google. Pamiętaj, że w Google Analytics tag odesłania odnosi się do wszystkich wyświetleń strony w sesji, natomiast pobieranie z wyprzedzeniem SXG dotyczy tylko pierwszego wyświetlenia strony, do którego bezpośredniego linku z wyszukiwarki Google prowadzi link.
Przeczytaj sekcję o badaniach współczesnych, by dowiedzieć się, jak mierzyć „X% wyświetleń strony”. i „poprawianie LCP o Y ms”.
Współczesna nauka
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 SXG i uniknąć efektu błędu doboru. W przeciwnym razie te elementy występują tylko w zestawie ładowań stron nieobjętych SXG, które mogą mieć naturalnie różne wartości 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 inny „największy element”. który ma zostać wybrany.
- Nawigacje w tej samej witrynie (użytkownicy korzystający z linków w witrynie): mogą wykorzystać zasoby podrzędne zapisane w pamięci podręcznej z poprzedniego wczytywania strony.
W Google Analytics (UA) utwórz 2 wymiary niestandardowe z zakresem „Działanie”, a 1 o nazwie „isSXG”. i drugą o nazwie „referrer”. Wbudowany wymiar „Źródło” ma zakres sesji, więc nie wyklucza nawigacji w tej samej witrynie.
Utwórz segment niestandardowy o nazwie „SXG kontrafaktyczny”. z następującymi filtrami połączonymi ORAZ:
referrer
zaczyna się odhttps://www.google.
Browser
ściśle pasuje doChrome
- Wersja
Browser
pasuje do wyrażenia regularnego^(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 poniższy 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, zmodyfikuj polecenie 'config'
, aby ustawić wymiar niestandardowy (zastąp wartości 'dimension1'
i 'dimension2'
nazwami, których powinien 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.
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” i wybierz „SXG kontrfaktyczny”. i „SXG”.
Kliknij „Prześlij”. Powinny być widoczne rozkłady LCP obu 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 kontrfaktyczne wczytywanie strony SXG powinno przebiegać w następujący sposób:
- 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 standard SXG w przypadku 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.
Między wczytaniem strony SXG a powyższym zestawem stron niepochodzących z SXG może występować odchylenie, ale jego wartość powinna być mniejsza niż ta, o której wspominaliśmy w górnej części sekcji poświęconej badaniom współczesnym. Na przykład strony, których nie można zapisać w pamięci podręcznej, są wolniejsze lub szybsze niż te, które można zapisać 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. Rozważ dodanie filtra, który wykluczy takie strony i zwiększy powiększenie o odpowiednich zmianach.
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 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 przejrzyj wyniki kwalifikujące się do SXG – powyższe definicje segmentów, ale bez ograniczenia isSXG
.
Ponowne zindeksowanie wszystkich stron w Twojej witrynie przez wyszukiwarkę Google może potrwać nawet kilka tygodni, aby ustalić, czy zostały w nich włączone SXG. W tym czasie mogą też wystąpić inne potencjalne uprzedzenia:
- nowe wersje przeglądarek lub ulepszenia dotyczące działania użytkowników, sprzęt może przyspieszyć wczytywanie stron.
- Znaczne wydarzenie, np. święto, może odkształcać ruch od normalnego ruchu.
Warto też przyjrzeć się ogólnemu 75-centylowi LCP przed i po, aby potwierdzić powyższe badania. Uzyskanie informacji o podzbiorze populacji nie musi koniecznie dotyczyć całej populacji. Załóżmy na przykład, że SXG skraca czas wczytywania strony o 10% 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 stron było o 10% najwolniejsze, ale początkowo były o ponad 800 ms wolniejsze niż od początku 75 centyla LCP, nie wpłynie to na 75 centyl.
Są to ekstremalne przykłady, które prawdopodobnie nie odzwierciedlają rzeczywistości, ale mają nadzieję, że zilustrują problem. W praktyce jest prawdopodobne, że w przypadku większości witryn SXG będzie miało wpływ na 75 centyl. Nawigacja w różnych witrynach jest zwykle najwolniejsza, a ulepszenia wynikające z pobierania z wyprzedzeniem są znaczne.
Zrezygnuj z niektórych adresów URL
I ostatnim sposobem na porównanie skuteczności SXG może być wyłączenie SXG w przypadku części adresów URL w Twojej 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. Na przykład duże znaczenie może mieć wybór strony głównej witryny lub adresu URL o podobnej popularności wśród członków grupy kontrolnej lub eksperymentalnej.
Badanie na zbiorze testowym
Najlepszym sposobem na zmierzenie wpływu jest przeprowadzenie izolacji kampanii. Niestety nie można obecnie wykonać tego typu testów. W przyszłości planujemy dodać obsługę tego typu testów.
Badanie po wstrzymaniu ma takie właściwości:
- W grupie eksperymentalnej pewne losowe wyświetlenia stron, które mogłyby zostać oznaczone jako SXG, są „wstrzymywane” i zamiast tego wyświetlane są jako reklamy nieobjęte SXG. W ten sposób można utworzyć porównanie odpowiednich użytkowników, urządzeń, scenariuszy i stron.
- Wstrzymane (kontrfaktyczne) wyświetlenia strony są odpowiednio oznaczone w statystykach. Umożliwia to powiększenie obrazu możemy porównać wczytania stron SXG w grupie kontrolnej z kontrfaktami SXG w eksperymencie. To z kolei redukuje zakłócenia podczas wczytywania innych stron, na które nie miał wpływu pobieranie z wyprzedzeniem SXG.
Wyeliminuje to wspomniane wyżej potencjalne źródła odchyleń doboru, ale nie eliminuje ryzyka stronniczości przetrwania 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 dzięki nim uzyskasz pełniejszy obraz tego, jak testować wydajność SXG w ramach testów laboratoryjnych, jak zoptymalizować wydajność w ścisłej pętli informacji zwrotnych podczas testów laboratoryjnych, a na koniec dowiedzieć się, jak mierzyć wydajność w praktyce. Połączenie tych wszystkich elementów powinno pomóc Ci w pełni wykorzystać możliwości SXG oraz zadbać o korzyści zarówno Twojej witryny, jak i użytkowników.
Jeśli masz dodatkowe porady na temat rejestrowania skuteczności SXG, daj nam znać. Zgłoś błąd na stronie developer.chrome.com, podając sugerowane ulepszenia.
Więcej informacji o technologii Signed Exchange znajdziesz w dokumentacji web.dev i dokumentacji wyszukiwarki Google.