Optymalizacja LCP za pomocą Signed Exchange

Mierzenie i optymalizowanie Signed Exchange w celu osiągnięcia jak najlepszych wyników

Devin Mullins

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):

Uwaga: wcześniej ten post pokazał poprawkę z 6 s do 0, 9 s. To prawda, ale testowana witryna działała wtedy wyjątkowo wolno. Może jednak służyć jako przykład w przypadku stron z większą liczbą zasobów podrzędnych, wolniejszych serwerów lub użytkowników z wolniejszymi typami połączeń.

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.

Uwaga: modele SXG mogą być przydatne w innych przypadkach użycia, które nie zostały omówione w tym artykule. Mogą na przykład włączyć odporność połączenia: aplikacja do obsługi czatu może wstępnie pobrać link wysłany do użytkownika, jeśli strona obsługuje SXG, aby użytkownik mógł go później wyświetlić bez połączenia z internetem. Zapoznaj się z dużą listą potencjalnych przypadków użycia.

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.

Uwaga: wyniki modułu mogą różnić się od rzeczywistych wrażeń użytkowników, ale są przydatnym narzędziem do diagnozowania obszarów wymagających optymalizacji i szybkiego wprowadzania poprawek. W sekcji Pomiar omówimy, jak mierzyć wynikowe dane o rzeczywistych użytkownikach.

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:

Uwaga: platformy SXG są przeznaczone dla robotów z obsługą SXG, aby umożliwiać wstępne pobieranie. Gdy użytkownicy odwiedzają Twoją witrynę bezpośrednio, nie należy im wyświetlać SXG, ponieważ nie są oni wstępnie pobierani, a dodatkowo zwiększa to tylko narzut. Cloudflare ASX automatycznie przeprowadza negocjacje treści.

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.

Uwaga: te ograniczenia można szczegółowo zobaczyć w kodzie ASX. Na przykład nagłówki sterujące pamięci podręcznej są sprawdzane przez kod, który określa, kiedy należy podpisać i jaki ma być czas trwania podpisu. Inne nagłówki są usuwane przed podpisaniem za pomocą tej konfiguracji lub za pomocą tego kodu. Inne nagłówki uniemożliwiają podpisywanie, jeśli nie są w inny sposób usunięte.

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.

Uwaga: w przyszłości strony używające Vary: Cookie będą obsługiwane przez SXG, ponieważ będą wyświetlane tylko użytkownikom bez plików cookie w Twojej witrynie. Jest to wdrożone w Chromium, a po pełnym wdrożeniu będzie dostępne w wyszukiwarce Google.

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.

Uwaga: planujemy w przyszłości ułatwić zarządzanie tym kompromisem, dodając interfejs API do czyszczenia pamięci podręcznej. Ogłosimy to na stronie webpackaging-announce.

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 do User-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ę.

Uwaga: ASX obsługuje obecnie pobieranie z wyprzedzeniem tylko w przypadku zasobów podrzędnych tej samej domeny (własnych). Jeśli znasz zewnętrznych dostawców zasobów podrzędnych, którzy obsługują SXG, daj nam znać, korzystając z tego błędu, abyśmy mogli priorytetowo dodać obsługę zasobów z innych domen.

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.

.

Uwaga: planujemy rozszerzyć konteksty, w których może nastąpić pobieranie z wyprzedzeniem SXG, m.in. na komputery. Z czasem może to zwiększyć się o X%, a także oznacza, że warto zaktualizować dane, aby dostosować je do tej zmiany. W takim przypadku należy poinformować o tym w usłudze webpackaging-announce.

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ę od https://www.google.
• Browser ściśle pasuje do Chrome
• Wersja Browser pasuje do wyrażenia regularnego ^(9[8-9]|[0-9]{3})
• isSXG ściśle pasuje do false

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.