Natychmiastowe ładowanie stron dzięki Speculation Rules
Dowiedz się, jak poprawić Core Web Vitals, sprawiając, że strony ładują się natychmiastowo dzięki nowemu API speculation rules
Natychmiastowa poprawa Core Web Vitals dzięki 'Speculation Rules API'
Czy zastanawiałeś się kiedyś, dlaczego niektóre strony wydają się ładować natychmiastowo? To prawdopodobnie dlatego, że ta strona zaimplementowała Speculation Rules!
API Speculation Rules przyspiesza ładowanie przyszłych stron w aplikacjach wielostronicowych (MPA) poprzez prefetching lub nawet prerendering. Programiści mogą skonfigurować speculation rules, aby sugerować przeglądarce prefetching lub prerendering dokumentów w celu szybszego (lub natychmiastowego) ładowania stron. Speculation rules zastępują starsze techniki takie jak `<link rel="prefetch">` do prefetchingu zasobów lub przestarzałą funkcję dostępną wyłącznie w Chrome `<link rel="prerender">`.
Speculation rules działają na poziomie dokumentu, co czyni je odpowiednimi dla MPA obejmujących pełne nawigacje stron. Aplikacje jednostronicowe (SPA), które głównie korzystają z wywołań API lub częściowych aktualizacji treści, nie skorzystałyby tak bardzo z tego API dla swoich wewnętrznych zmian tras. Jednak Speculation Rules mogą nadal przynosić korzyści SPA poprzez prerendering początkowego stanu aplikacji ze strony docelowej, potencjalnie kompensując początkowy czas ładowania.
Szybki start ze Speculation Rules
Wiesz już, czym są speculation rules? Świetnie! Oto gotowe fragmenty kodu, które pozwolą Ci natychmiast rozpocząć. Wystarczy wybrać odpowiedni fragment i umieścić go w <head> swojej strony (możesz zmienić preload na prefetch lub zmienić eagerness)!
<!--
WordPress speculation rules by corewebvitals.io
prefetches all internal links
skips links that match wp-login, wp-admin, wp content
skips links that have the nofollow attribute
skips links that have a questy string for example: /search->
<script type="speculationrules">
{
"prefetch": [{
"source": "document",
"where": {
"and": [{ "href_matches": "\/*"},{ "not": { "href_matches": [ "\/wp-login.php", "\/wp-admin\/*", "\/*\\?*", "\/wp-content\/*", ] }
},{ "not": { "selector_matches": "a[rel~=\\"nofollow\\"]" }
}]
},
"eagerness": "moderate"
}]
}
</script> <!-- Data-preload triggered speculation rules by corewebvitals.io -->
<script type="speculationrules">
{
"prefetch": [{
"source": "document",
"where": {
"selector_matches": "a[data-preload]"
},
"eagerness": "moderate"
}]
}
</script> Wskazówka: jeśli chcesz szybko zbudować własne speculation rules, wypróbuj generator speculation rules
Zalety Speculation Rules
Lepsza user Experience (UX): Przewidując i wstępnie ładując treści, Speculation Rules zapewniają niemal natychmiastowe ładowanie stron, sprawiając, że nawigacja jest płynna dla użytkowników. Dorównuje to wydajności aplikacji jednostronicowych nawet w przypadku tradycyjnych wielostronicowych stron internetowych bez złożoności i zależności od JavaScript. Szybsze czasy ładowania oznaczają lepsze wrażenia z przeglądania, prawdopodobnie zwiększając zaangażowanie użytkowników i zmniejszając współczynnik odrzuceń.
Korzyści SEO: Ponieważ lepsza szybkość strony jest bezpośrednim czynnikiem rankingowym, a lepszy Time to First Byte przełoży się na lepszy Largest Contentful Paint, wdrożenie speculation rules z pewnością poprawi Core Web Vitals i da Ci bonus za szybkość strony.
Mniejsza złożoność: Niemal natychmiastowe ładowanie stron było wcześniej możliwe dzięki użyciu SPA lub pisaniu własnej logiki prefetchingu dla MPA.
Dla wielu zastosowań wadą SPA jest początkowy czas uruchamiania, który może być znaczny, ponieważ w dużym stopniu opierają się na JavaScript, oraz zwiększona złożoność w porównaniu z MPA. Speculation rules nie mają tych problemów. Dzięki temu szybkie ładowanie jest osiągalne dla szerszego zakresu stron internetowych, szczególnie tych nastawionych na treści.
API upraszcza również proces decydowania, które strony mają być prerenderowane, delegując znaczną część logiki do przeglądarki. Jest to ogromna poprawa w porównaniu z poprzednimi metodami, które opierały się na JavaScript do wykonywania tych sprawdzeń i wstrzykiwania stron do wstępnego ładowania. Przeglądarki mogą natywnie uwzględniać kontekst użytkownika, taki jak niska pamięć na urządzeniach mobilnych lub tryb oszczędzania baterii, przy podejmowaniu decyzji o prerenderingu. Ta dynamiczna adaptacja pomaga oszczędzać zasoby użytkownika i zapewnia płynniejsze wrażenia nawet w warunkach ograniczeń.
Inne korzyści: Nagłówek HTTP Speculation-Rules umożliwia łatwiejsze wdrażanie za pośrednictwem sieci dostarczania treści (CDN), eliminując potrzebę bezpośredniej modyfikacji zawartości dokumentu. Szczegółowa kontrola dzięki regułom dokumentu pozwala programistom definiować precyzyjne warunki prefetchingu lub prerenderingu na podstawie wzorców URL lub selektorów CSS. Zmniejsza to ręczne specyfikowanie URL i umożliwia tworzenie zestawów speculation rules obejmujących całą witrynę. Ustawienie "eagerness" zapewnia precyzyjną kontrolę nad tym, kiedy spekulacja ma miejsce, równoważąc szybkość wstępnego ładowania ze zużyciem zasobów. Pomaga to ograniczyć niepotrzebne wstępne ładowanie i zapobiega marnowaniu zasobów.
Mechanika Speculation Rules
Speculation rules definiuje się za pomocą struktury JSON i można je wdrożyć na dwa sposoby:
- Skrypt inline: Umieść JSON w tagu `<script type="speculationrules">` w `<head>` lub `<body>` głównego dokumentu HTML.
- Nagłówek HTTP: Dostarcz reguły za pomocą nagłówka HTTP `Speculation-Rules` w odpowiedzi dokumentu. Ten nagłówek wskazuje na plik JSON zawierający reguły, ułatwiając wdrażanie przez CDN bez bezpośredniej modyfikacji zawartości HTML.
Struktura JSON używa tablic "prefetch" i "prerender" do zawierania reguł dla każdego typu ładowania spekulatywnego. Każda reguła może używać różnych źródeł: listy adresów URL lub reguł dokumentu
- urls (lista adresów URL) Tablica adresów URL do prefetchingu lub prerenderingu.
- where (reguły dokumentu) Obiekt używający warunków do określenia, które linki na stronie powinny być prefetchowane lub prerenderowane.
Każda reguła jest zdefiniowana jako obiekt zawierający właściwości takie jak:
- requires Tablica ciągów znaków do ustawiania ograniczeń spekulacji. Obecnie jedynym prawidłowym ciągiem jest "anonymous-client-ip-when-cross-origin," wskazujący, że prefetch cross-origin powinien anonimizować adres IP klienta.
- target_hint Ciąg znaków zapewniający wskazówkę dotyczącą nazwy celu nawigacji, pozwalający agentowi użytkownika optymalizować proces ładowania. Nie ma żadnych normatywnych implikacji poza byciem wskazówką.
- referrer_policy Polityka referrera stosowana do prefetchowanych lub prerenderowanych adresów URL.
- relative_to (Tylko dla źródła "list") Określa, czy adresy URL podane w tablicy "urls" są względne do bazowego URL dokumentu ("document") czy lokalizacji pliku JSON speculation rules ("ruleset").
- eagerness Kontroluje, jak agresywnie przeglądarka powinna prefetchować lub prerenderować. Dostępne ustawienia to "immediate," "eager," "moderate," i "conservative," każde z innymi wyzwalaczami.
- expects_no_vary_search Ciąg znaków używany do dostarczenia wskazówki dotyczącej wariancji wyszukiwania URL, pozwalający programistom sygnalizować, czy spekulowany URL ma mieć inną odpowiedź w zależności od parametrów wyszukiwania. .
Wreszcie każda reguła ma ustawienie eagerness, które pozwala określić, kiedy spekulacje powinny się uruchamiać, oddzielając moment spekulacji od adresów URL, na których mają być wykonywane. Ustawienie eagerness jest dostępne zarówno dla reguł list, jak i reguł dokumentu i ma cztery ustawienia: immediate, eager, moderate i conservative.
- immediate: Służy do spekulacji najszybciej jak to możliwe, zaraz po wykryciu speculation rules.
- eager: Obecnie zachowuje się identycznie jak ustawienie immediate, ale w przyszłości zostanie umieszczone gdzieś pomiędzy immediate a moderate.
- moderate: Wykonuje spekulacje, gdy najedziesz kursorem na link przez 200 milisekund (lub przy zdarzeniu pointerdown, jeśli nastąpi wcześniej, oraz na urządzeniach mobilnych, gdzie nie ma zdarzenia hover).
- conservative: Spekuluje przy zdarzeniu pointer lub touch down.
Prefetch czy Prerender
API Speculation Rules obsługuje dwie podstawowe formy ładowania spekulatywnego: prefetching i prerendering. Chociaż obie techniki mogą skutkować szybszym ładowaniem stron, różnią się złożonością i zużyciem zasobów.
- Prefetching to "lżejsza forma" ładowania spekulatywnego. Pobiera i zapisuje w pamięci podręcznej HTML docelowego adresu URL bez renderowania strony ani jej podzasobów. To podejście głównie poprawia Time To First Byte. Lepszy Time to First Byte prowadzi do lepszych metryk renderowania, takich jak Largest Contentful Paint i First Contentful Paint.
- Prerendering robi znacznie więcej niż tylko pobieranie HTML. Pobiera HTML, wszystkie podzasoby i renderuje całą stronę w ukrytej, niewidocznej karcie. Przy nawigacji do tej strony skutkuje to niemal natychmiastowym wyświetleniem. Ta technika poprawia Largest Contentful Paint na więcej sposobów niż tylko poprzez poprawę Time to First Byte. Pobiera i renderuje również element LCP. Prerendering może także wyeliminować Cumulative Layout Shift, ponieważ wymiary zasobów są już znane po prerenderingu.
Więc co jest lepsze? Prerendering czy Prefetching? To zależy od strony i "przeciętnego odwiedzającego". Chociaż prerendering może być z założenia szybszy, zużywa też znacznie więcej zasobów, zarówno po stronie klienta, jak i serwera. Wybór między prerenderingiem a prefetchingiem zależy od:
- Możliwości urządzenia użytkownika: Prerendering może nie być najlepszym wyborem, jeśli wysoki procent odwiedzających korzysta z urządzeń o ograniczonej pamięci
- Specyficzność reguł prerender lub prefetch. "Niektóre linki są bardziej prawdopodobne do kliknięcia, a niektóre strony mają większe szanse na konwersję". Te strony są idealnymi kandydatami do reguły prerender. Inne strony mogą być bardziej odpowiednie do prefetchingu.
CoreWebVitals.io przestrzega przed nadmiernym prerenderingiem ze względu na wymagania zasobowe, szczególnie na urządzeniach mobilnych lub przy wolniejszych połączeniach. Potencjalne korzyści prerenderingu muszą być zważone z ryzykiem pogorszenia wydajności i marnowania zasobów.
Ustawienie odpowiedniego 'Eagerness' - sztuka równowagi
Wybór ustawienia eagerness zależy od Twojej witryny. Dla bardzo prostej statycznej strony, bardziej agresywna spekulacja może mieć niewielki koszt i być korzystna dla użytkowników. Witryny o bardziej złożonej architekturze i cięższych payload stron mogą preferować ograniczenie spekulacji, spekulując rzadziej, aż uzyskasz wyraźniejszy sygnał intencji od użytkowników, aby ograniczyć marnotrawstwo.
Ustawienie eagerness w API Speculation Rules wpływa na to, kiedy przeglądarka powinna prefetchować lub prerenderować treści na podstawie przewidywanej nawigacji użytkownika. To ustawienie oferuje kompromis między maksymalizacją korzyści z wstępnego ładowania a minimalizacją marnowania zasobów.
Domyślne ustawienie eagerness dla reguł list to immediate. Opcje moderate i conservative mogą być używane do ograniczenia reguł list do adresów URL, z którymi użytkownik wchodzi w interakcję na określonej liście. W wielu przypadkach reguły dokumentu z odpowiednim warunkiem where mogą być bardziej odpowiednie.
Domyślne ustawienie eagerness dla reguł dokumentu to conservative. Biorąc pod uwagę, że dokument może zawierać wiele adresów URL, użycie immediate lub eager dla reguł dokumentu powinno być stosowane z ostrożnością.
Wybór eagerness zależy od struktury witryny, wzorców zachowań użytkowników i oceny programisty dotyczącej potencjalnego zużycia zasobów w porównaniu z korzyściami dla user experience. Na przykład prosta strona statyczna może skorzystać z ustawienia "eager", prowadzącego do szybszych czasów ładowania. Natomiast witryny o złożonej architekturze i wymagających payload stron mogą wybrać mniej agresywne podejście "moderate" lub "conservative", aby ograniczyć zużycie zasobów, dopóki nie zostanie wykryty wyraźniejszy zamiar użytkownika.
Podczas konfigurowania eagerness programiści powinni uwzględnić user experience, koszty zasobów i ograniczenia przeglądarek. Nadmierna spekulacja może obciążyć przepustowość, pamięć i procesor użytkownika, potencjalnie pogarszając wydajność, szczególnie w ograniczonych sieciach lub na urządzeniach. Chrome narzuca limity na jednoczesne prefetchowane i prerenderowane strony, aby zapobiec nadużywaniu. Ponadto czynniki takie jak skonfigurowany przez użytkownika tryb oszczędzania danych, niski poziom baterii lub rozszerzenia przeglądarki mogą nadpisać speculation rules, priorytetyzując oszczędzanie zasobów.
Sprawdzanie i debugowanie speculation rules
Aby sprawdzić speculation rules na stronie, otwórz Chrome DevTools, przejdź do panelu Application i nawiguj do Background Services > Speculative Loads > Speculations. (otwórz panel Speculations przed załadowaniem strony, którą chcesz debugować) Ten panel dostarcza informacji o:
- Liczbie udanych spekulacji.
- Poszczególnych adresach URL poddawanych prerenderingowi lub prefetchingowi.
- Statusie każdej spekulacji.
Ścieżka Network w panelu Performance wyświetla aktywność sieciową związaną z prerenderowanymi zasobami bez konieczności przełączania kontekstu DevTools. Dodatkowo możesz przełączyć kontekst DevTools na prerenderowaną stronę, aby ją inspekcjonować jak zwykłą stronę.
Monitorowanie i analiza Speculation Rules
- Real User Monitoring (RUM): Wykorzystuj narzędzia RUM do mierzenia rzeczywistego user experience. Obserwuj metryki takie jak Largest Contentful Paint (LCP), aby ocenić wpływ speculation rules na czasy ładowania stron. Szukaj poprawy LCP dla prerenderowanych stron w porównaniu z nieprerenderowanymi stronami.
- Testy A/B: Przeprowadzaj testy A/B, aby porównać różne konfiguracje speculation rules i zidentyfikować najbardziej optymalną konfigurację dla Twojej konkretnej witryny i bazy użytkowników.
Uwagi - potencjalne problemy
Zużycie zasobów: Nadmierne stosowanie spekulacji może negatywnie wpływać na przepustowość, pamięć i wykorzystanie procesora.
Kompatybilność przeglądarek: Nie wszystkie przeglądarki w pełni obsługują API Speculation Rules, dlatego sprawdź kompatybilność przeglądarek przed wdrożeniem.
Prywatność: Programiści powinni mieć na uwadze, jak speculation rules mogą ujawniać wzorce przeglądania użytkowników i wdrożyć odpowiednie środki ochrony prywatności.
API Speculation Rules oferuje potężne podejście do poprawy wydajności i user experience aplikacji internetowych. Rozumiejąc jego mechanikę, zalety i uwagi, programiści mogą wykorzystać to API do budowania szybszych i bardziej angażujących stron internetowych.
Speculation Rules - kod dla WordPress
Zespół WordPress Core Performance stworzył wtyczkę Speculation Rules, która umożliwia dodanie obsługi reguł dokumentu do dowolnej witryny WordPress jednym kliknięciem. Wtyczka oferuje dwie grupy ustawień:
- Tryb spekulacji: Wybierz między prefetch a prerender. Prerendering zapewni szybsze czasy ładowania niż prefetching. Jednak prefetching może być bezpieczniejszym wyborem dla interaktywnych treści.
- Eagerness: Wybierz między conservative (zazwyczaj przy kliknięciu), moderate (zazwyczaj przy najechaniu kursorem) lub eager (przy najmniejszej sugestii). Ustawienie eagerness określa, jak szybko ładowanie spekulatywne jest uruchamiane.
