Najskuteczniejsze sposoby na poprawę podstawowych wskaźników internetowych

Na przestrzeni lat społeczność internetowa zgromadziła ogromną wiedzę na temat optymalizacji wydajności witryny. Chociaż każda optymalizacja może poprawić skuteczność wielu witryn, zastosowanie ich wszystkich naraz może przytłoczyć, a w rzeczywistości tylko niektóre z nich są przydatne w przypadku danej witryny.

Chyba że zajmujesz się optymalizacją wydajności stron internetowych, prawdopodobnie nie jest Ci wiadome, które optymalizacje przyniosą największe korzyści Twojej witrynie. Prawdopodobnie nie będziesz mieć czasu na wszystkie z nich, dlatego ważne jest, aby zastanowić się, jakie optymalizacje przyniosą największe korzyści użytkownikom.

Oto cała prawda o optymalizacji skuteczności: nie można oceniać ich wyłącznie na podstawie ich zalet technicznych. Musisz też wziąć pod uwagę czynniki ludzkie i organizacyjne, które wpływają na to, jak prawdopodobne jest wdrożenie danej optymalizacji. Niektóre ulepszenia wydajności mogą w teorii mieć ogromne znaczenie, ale w rzeczywistości niewiele deweloperów ma na to czas i zasoby. Z drugiej strony mogą istnieć sprawdzone metody, które mają ogromny wpływ na skuteczność i są stosowane przez niemal wszystkich. Ten przewodnik zawiera informacje o optymalizacji skuteczności witryny, która:

• mają największy rzeczywisty wpływ,
• są trafne i można je stosować w większości witryn;
• są realistyczne dla większości programistów,

Łącznie są to najbardziej realistyczne i skuteczne sposoby na poprawę wyników podstawowych wskaźników internetowych. Jeśli dopiero zaczynasz się interesować wydajnością witryn internetowych lub nadal nie wiesz, co przyniesie Ci największy zwrot z inwestycji, zacznij od tego.

Interakcja do kolejnego wyrenderowania (INP)

Jako najnowszy podstawowy wskaźnik internetowy interakcja do kolejnego wyrenderowania (INP) daje największe możliwości poprawy. Jednak w porównaniu z wycofanym poprzednikiem znacznie mniej witryn spełnia wartość progową dla „dobrych” wrażeń. Dlatego możesz być jednym z wielu deweloperów, którzy po raz pierwszy uczą się optymalizować szybkość reakcji na interakcje. Zacznij od tych niezbędnych technik, aby dowiedzieć się, jak skutecznie zwiększać INP.

1. Często używaj Yield, aby podzielić długie zadania.

Zadania to dowolne działania wykonywane przez przeglądarkę, w tym renderowanie, układ, parsowanie, kompilowanie lub wykonywanie skryptów. Jeśli czas trwania zadania przekroczy 50 milisekund, staje się ono długim zadaniem. Długie zadania mogą być problematyczne, ponieważ mogą uniemożliwić wątkowi głównemu szybkie reagowanie na interakcje użytkownika.

Staraj się zawsze starać się wykonywać jak najmniej pracy w JavaScript, ale możesz pomóc w głównym wątku, dzieląc długie zadania. Możesz to zrobić, często oddając kontrolę nad wątkiem głównemu, aby aktualizacje renderowania i inne interakcje z użytkownikiem mogły nastąpić szybciej.

Interfejs Scheduler API umożliwia umieszczanie zadań w kolejce przy użyciu systemu priorytetów. W szczególności interfejs API scheduler.yield() dzieli długie zadania, jednocześnie zapewniając, że interakcje mogą być obsługiwane bez rezygnacji z miejsca w kole zadań.

Podzielając długie zadania, dajesz przeglądarce więcej możliwości wykonania ważnych zadań, które blokują działanie użytkownika.

2. Unikaj niepotrzebnego JavaScriptu

Strony internetowe wysyłają więcej JavaScriptu niż kiedykolwiek wcześniej, a ten trend się nie zmienia. Wysyłając za dużo JavaScriptu, tworzysz środowisko, w którym zadania konkurują o uwagę wątku głównego. Może to wpływać na szybkość reagowania witryny, zwłaszcza w tym kluczowym okresie startowym.

Nie jest to jednak nierozwiązywalny problem. Możesz:

• Użyj podstawowych funkcji platformy internetowej zamiast zbędnych implementacji opartych na języku JavaScript.
• Aby znaleźć nieużywany kod w skryptach, użyj narzędzia do pomiaru pokrycia kodu w Narzędziach deweloperskich w Chrome. Zmniejszenie rozmiaru zasobów potrzebnych podczas uruchamiania aplikacji pozwala skrócić czas analizowania i kompilowania kodu, co zapewnia płynniejsze działanie aplikacji na początku.
• Użyj dzielenia kodu, aby utworzyć osobny pakiet dla kodu, który nie jest potrzebny do początkowego renderowania, ale będzie używany później.
• Jeśli używasz menedżera tagów, okresowo optymalizuj tagi. Aby zmniejszyć rozmiar kodu JavaScript w Menedżerze tagów, możesz usunąć starsze tagi z nieużywanym kodem.

3. Unikaj dużych aktualizacji renderowania

Wykonywanie kodu JavaScript to tylko jeden z czynników wpływających na szybkość reakcji witryny. Renderowanie to samo w sobie jest kosztownym procesem, a podczas dużych aktualizacji renderowania Twoja witryna może reagować na interakcje użytkowników jeszcze wolniej.

Optymalizacja renderowania nie jest prostym procesem i zależy od tego, czego chcesz osiągnąć. Oto kilka rzeczy, które możesz zrobić, aby zadania renderowania nie stały się długimi zadaniami:

• Zmień kolejność odczytu i zapisu DOM w kodzie JavaScript, aby uniknąć wymuszonego układu oraz zmiennego układu.
• Zachowaj małe rozmiary DOM. Rozmiar DOM i intensywność pracy nad układem są ze sobą powiązane. Gdy renderowanie musi zaktualizować układ bardzo dużego DOM, konieczne może być znaczne zwiększenie nakładu pracy związanego z ponownym obliczeniem układu.
• Używaj ograniczenia CSS, by leniwie renderować treści DOM poza ekranem. Nie zawsze jest to proste, ale dzięki izolowaniu obszarów zawierających złożone układy możesz uniknąć niepotrzebnej pracy związanej z układem i renderowaniem.

Największe wyrenderowanie treści (LCP)

Największe wyrenderowanie treści (LCP) to podstawowy wskaźnik internetowy, z którym deweloperzy mają najwięcej problemów. W raporcie na temat UX Chrome 40% witryn nie spełnia zalecanego progu LCP, który zapewnia dobre wrażenia użytkowników. Zespół Chrome rekomenduje następujące metody zwiększania wskaźnika LCP.

1. Upewnij się, że zasób LCP jest możliwy do znalezienia w źródle HTML i ma nadany priorytet.

Zespół Chrome zauważył te kwestie dotyczące LCP w internecie:

• Według Almanachu internetowego na rok 2022 opublikowanego przez HTTP Archive 72% stron mobilnych ma obraz jako element LCP.
• Analiza danych pochodzących od prawdziwych użytkowników Chrome pokazuje, że większość źródeł o niskiej wartości LCP spędza mniej niż 10% czasu p75 LCP na pobieranie obrazu LCP.
• W przypadku stron o niskiej wartości LCP wczytywanie obrazów LCP jest opóźnione o 1290 milisekund w 75. centylu, co stanowi ponad połowę budżetu,które zapewnia szybką obsługę.
• 39% tych obrazów spośród stron, których element LCP był obrazem, miało źródłowe adresy URL, których nie można było znaleźć w początkowej odpowiedzi HTML (np. <img src="..."> lub <link rel="preload" href="...">). Dzięki temu skaner wstępnego wczytywania przeglądarki mógł szybko je wykryć.
• Według Web Almanac tylko 0,03% kwalifikujących się stron korzystało z atrybutu HTML fetchpriority, aby przypisać wyższy priorytet zasobom, w tym tym, które mogłyby poprawić LCP strony przy stosunkowo niewielkim wysiłku.

Te statystyki wskazują, że deweloperzy mają duże możliwości zmniejszenia zarówno opóźnienia ładowania zasobów, jak i czasu ładowania zasobów w przypadku obrazów LCP.

Jeśli problemem jest opóźnienie wczytywania zasobów, pamiętaj, że jeśli strona musi poczekać, aż wczytanie pliku CSS lub JavaScriptu zostanie zakończone, zanim rozpocznie się wczytywanie obrazów, osiągnięcie dobrego wyniku LCP może być już niemożliwe. Czas wczytywania zasobu obrazu LCP można skrócić, zmieniając jego priorytet, aby otrzymał więcej przepustowości i wczytywał się szybciej za pomocą atrybutu HTML fetchpriority.

Jeśli element LCP jest obrazem, jego adres URL powinien być widoczny w odpowiedzi HTML, aby zmniejszyć opóźnienie wczytywania zasobów. Oto kilka wskazówek, jak:

• Wczytaj obraz za pomocą elementu <img> z atrybutem src lub srcset. Nie używaj atrybutów niestandardowych, takich jak data-src, które wymagają JavaScriptu do renderowania, ponieważ zawsze będą wolniejsze. 9% stron zasłania obraz LCP za elementem data-src.
• Preferuj renderowanie po stronie serwera (SSR) zamiast renderowania po stronie klienta (CSR), ponieważ SSR zakłada, że w źródle HTML znajduje się pełny znacznik strony (w tym obraz). Rozwiązania CSR wymagają uruchomienia kodu JavaScript, zanim obraz zostanie odnaleziony.
• Jeśli obraz ma być wywoływany z zewnętrznego pliku CSS lub JS, możesz go nadal uwzględnić w źródle HTML za pomocą tagu <link rel="preload">. Pamiętaj, że obrazy, do których odwołują się style wbudowane, nie są dostępne dla skanera do wstępnego ładowania w przeglądarce. Oznacza to, że nawet jeśli znajdują się w źródle HTML, ich wykrywanie może być zablokowane podczas wczytywania innych zasobów. W takich przypadkach wstępne ładowanie może być pomocne.

Możesz też skrócić czas wczytywania zasobu, upewniając się, że zasób LCP jest wczytywany wcześnie i ma wysoki priorytet:

• Dodaj atrybut fetchpriority="high" do tagu <img> lub <link rel="preload"> obrazu LCP. Zwiększa to priorytet zasobu obrazu, dzięki czemu może on zacząć się wczytywać wcześniej.
• Usuń atrybut loading="lazy" z tagu <img> obrazu LCP. Pozwala to uniknąć opóźnienia wczytywania spowodowanego sprawdzeniem, czy obraz pojawia się w widocznym obszarze lub w jego pobliżu.
• Jeśli to możliwe, odkładaj niekrytyczne zasoby. Przeniesienie tych zasobów na koniec dokumentu, opóźnione wczytywanie obrazów lub elementów iframe albo wczytywanie ich asynchronicznie za pomocą JavaScriptu ułatwi szybsze wczytywanie ważniejszych zasobów, takich jak obraz LCP.

2. Korzystaj z nawigacji

Idealne wrażenia użytkownika to brak konieczności czekania na załadowanie strony. Optymalizacje LCP, takie jak możliwość wykrywania zasobów i przypisywanie im priorytetów, skutecznie skracają czas oczekiwania użytkownika na wczytanie i wyświetlenie elementu LCP. Istnieje jednak fizyczny limit szybkości, z jaką te bajty są wczytywane przez sieć i wyświetlane na stronie. Zanim osiągniesz ten limit, będziesz musiał włożyć nieproporcjonalnie dużo wysiłku, aby skrócić czas o zaledwie kilka milisekund. Aby zapewnić natychmiastową nawigację, musimy przyjąć radykalnie inne podejście.

Nawigacja błyskawiczna próbuje wczytać i renderować stronę przed rozpoczęciem nawigacji przez użytkownika. Dzięki temu strona z przedrenderowaniem może być wyświetlana natychmiast z prawie zerowym czasem LCP. Możesz to zrobić na 2 sposoby: przywracając dane lub tworząc przypuszczenia. Gdy użytkownik przechodzi do wcześniej odwiedzonej strony, może ona zostać szybko przywrócona z pamięci podręcznej i wyświetlona dokładnie w tym stanie, w jakim użytkownik ją opuścił. Aplikacje internetowe mogą też próbować przewidzieć, dokąd użytkownik się uda. Jeśli się uda, następna strona zostanie już wczytana i wyświetlona, zanim użytkownik ją otworzy.

Przywracanie wcześniej odwiedzonych stron jest możliwe dzięki pamięci podręcznej stanu strony internetowej (bfcache). Aby z niego korzystać, musisz mieć pewność, że Twoje strony spełniają kryteria kwalifikacji do pamięci podręcznej Bfcache. Strony nie mogą korzystać z pamięci podręcznej stanu strony internetowej na przykład wtedy, gdy są obsługiwane z dyrektywami buforowania no-store lub mają detektory zdarzeń unload.

Przywracanie w pełni wyrenderowanych stron poprawia nie tylko wydajność wczytywania, ale też stabilność układu. Więcej informacji o pamięci podręcznej stanu strony internetowej i o tym, jak skutecznie poprawia ona CLS, znajdziesz w sekcji Sprawdzanie, czy strony kwalifikują się do korzystania z pamięci podręcznej stanu strony internetowej.

Wstępne renderowanie następnej strony, którą użytkownik odwiedza, to kolejny skuteczny sposób na znaczną poprawę wskaźnika LCP. Umożliwia to interfejs Speculation Rules API. Aby jednak uzyskać te korzyści, upewnij się, że odpowiednie strony są renderowane wstępnie. Nieprawidłowe spekulacje marnują zasoby zarówno na serwerze, jak i na kliencie, co może negatywnie wpływać na wydajność. Im mniej wiesz o tym, jak będzie wyglądać następna strona, tym bardziej ostrożnie powinieneś podchodzić do jej wstępnego renderowania. W przypadku wątpliwości dane z narzędzia analitycznego mogą Ci pomóc w bardziej zdecydowanym prerenderowaniu stron o najwyższym prawdopodobieństwie odwiedzenia.

3. Używanie sieci CDN do optymalizacji TTFB

Wcześniejsze zalecenie dotyczyło natychmiastowej nawigacji, która zapewnia użytkownikom najlepsze wrażenia, ale mogą wystąpić sytuacje, w których nie można zastosować techniki bfcache i speculatywnego wczytywania. Użytkownik klika link do Twojej witryny w innej witrynie, a początkowa odpowiedź dokumentu HTML skutecznie blokuje LCP. Przeglądarka nie może rozpocząć wczytywania żadnych zasobów podrzędnych, dopóki nie otrzyma pierwszego bajta odpowiedzi. Im szybciej to się stanie, tym szybciej zaczną się dziać wszystkie inne rzeczy.

Jest on nazywany czasem do pierwszego bajtu (TTFB). Najlepsze sposoby na zmniejszenie wartości TTFB to:

• Udostępniaj treści w jak najbliższym możliwym regionie geograficznym, w jakim jest to możliwe.
• Przechowuj tę treść w pamięci podręcznej, by mogła szybko zostać dostarczona na każde żądanie w najbliższej przyszłości.

Najlepszym sposobem na spełnienie tych wymagań jest użycie sieci CDN. Sieci CDN rozpowszechniają zasoby na serwerach brzegowych na całym świecie, co ogranicza odległość, jaką zasoby muszą pokonywać przewodami użytkowników. Sieci CDN zwykle mają również szczegółowe ustawienia buforowania, które można dostosować do potrzeb witryny.

Sieci CDN mogą wyświetlać i buforować dokumenty HTML, ale według Web Almanac 29% żądań dokumentów HTML pochodziło z sieci CDN. Oznacza to, że witryny mają dużą szansę na uzyskanie dodatkowych oszczędności.

Oto kilka wskazówek dotyczących konfigurowania sieci CDN:

• przechowywać w pamięci podręcznej statyczne dokumenty HTML nawet przez krótki czas; Czy na przykład ważne jest, aby treści były zawsze aktualne? Czy może być kilka minut?
• Sprawdź, czy możesz przenieść logikę dynamiczną działającą na serwerze pierwotnym na brzeg, co jest funkcją większości nowoczesnych sieci CDN.

Za każdym razem, gdy możesz wyświetlać treści bezpośrednio z serwera brzegowego i unikać przechodzenia do serwera pierwotnego, zapewnia to większą wydajność. Nawet jeśli musisz dotrzeć do punktu początkowego, sieci CDN są zwykle zoptymalizowane tak, by robić to szybciej, więc jest to korzystne dla obu stron.

Skumulowane przesunięcie układu (CLS)

Skumulowane przesunięcie układu (CLS) to wskaźnik stabilności wizualnej strony internetowej. Chociaż CLS to wskaźnik, który zwykle dobrze wypada w przypadku większości witryn, około ćwierć z nich nadal nie osiąga zalecanego progu, więc wiele witryn ma jeszcze spore pole do poprawy w zakresie zapewniania użytkownikom wygody.

1. ustawiać dokładne rozmiary dla wszystkich treści wczytywanych ze strony,

Przesunięcia układu mają zwykle miejsce, gdy istniejąca treść przesuwa się po zakończeniu wczytywania innej. Głównym sposobem na poprawę CLS jest jak najszybsze zarezerwowanie wymaganej przestrzeni.

Najlepszym sposobem na naprawienie przesunięć układu spowodowanych przez nierozmiarowane obrazy jest jawne ustawienie atrybutów width i height lub ich odpowiednich właściwości CSS. 72% stron zawiera co najmniej 1 obraz bez rozmiaru. Jeśli nie ma określonego rozmiaru, początkowa wysokość tych obrazów wynosi 0px, co może powodować przesunięcia układu podczas ich wczytywania i wykrywania wymiarów przez przeglądarkę. To ogromna szansa dla sieci zbiorowej, a wymaga mniej wysiłku niż niektóre inne rekomendacje zawarte w tym przewodniku.

CLS nie zależy tylko od obrazów. Zmiany układu mogą być spowodowane przez inne treści, które zwykle wczytują się po renderowaniu strony, w tym reklamy zewnętrzne lub osadzone filmy. W takiej sytuacji może Ci pomóc właściwość aspect-ratio. To powszechnie dostępna podstawowa funkcja CSS, która umożliwia programistom ustawienie formatu obrazu zarówno dla obrazów, jak i elementów innych niż graficzne. Dzięki temu możesz ustawić dynamiczną wartość width (np. na podstawie rozmiaru ekranu), a przeglądarka automatycznie obliczy odpowiednią wysokość w sposób podobny do tego, w jaki działa to w przypadku obrazów z wymiarami.

Nie zawsze jednak można określić dokładny rozmiar treści dynamicznych. Nawet jeśli nie znasz dokładnego rozmiaru, możesz zmniejszyć zakres zmian układu. Ustawienie rozsądnej wartości min-height jest prawie zawsze lepsze niż zezwalanie przeglądarce na używanie domyślnej wysokości 0px dla pustego elementu. Użycie opcji min-height jest też zwykle prostym rozwiązaniem, ponieważ nadal pozwala na rozszerzenie kontenera do ostatecznej wysokości treści w razie potrzeby. Zmniejsza ono tylko ilość rozszerzenia do poziomu, który jest łatwiejszy do zaakceptowania.

2. Sprawdzanie, czy strony kwalifikują się do korzystania z pamięci podręcznej stanu strony internetowej

Jak wspomnieliśmy wcześniej w tym przewodniku, pamięć podręczna stanu strony internetowej (bfcache) natychmiast wczytuje stronę z wcześniejszego lub późniejszego okresu w historii przeglądarki na podstawie zrzutu pamięci. Pamięć podręczna stanu strony internetowej to znacząca optymalizacja wydajności na poziomie przeglądarki, która poprawia LCP, a także całkowicie eliminuje zmiany układu. W fakt wprowadzenie w 2022 r. pamięci podręcznej bfcache było odpowiedzialne za największe w tym roku polepszenie CLS.

Mimo to znaczna liczba witryn nie kwalifikuje się do umieszczenia w pamięci podręcznej stanu strony internetowej, co oznacza, że nie mogą oni skorzystać z tej bezpłatnej wygranej w internecie. Jeśli strona nie wczytuje informacji poufnych, których nie chcesz przywracać z pamięci, sprawdź, czy Twoje strony kwalifikują się do korzystania z pamięci podręcznej stanu strony internetowej.

Właściciele witryn powinni sprawdzić, czy strony kwalifikują się do korzystania z pamięci podręcznej stanu strony internetowej, i poprawić wszystkie powody, dla których tak nie jest. Chrome udostępnia testera pamięci podręcznej przeglądarki Chrome w Narzędziach deweloperskich. Aby wykryć przyczyny niekwalifikowania się, możesz też użyć interfejsu API Not Restored Reasons.

3. Unikaj animacji i przejść, które wykorzystują właściwości CSS wywołujące układ

Innym częstym źródłem przesunięć układu jest animacja elementów. Na przykład banery z powiadomieniem o plikach cookie lub inne banery z powiadomieniem, które przesuwają się od góry lub od dołu, często przyczyniają się do wzrostu wartości CLS. Problem jest szczególnie problematyczny, gdy banery te rozpraszają inne treści, ale nawet jeśli ich nie widać, ich animacja może wpływać na CLS.

Chociaż dane z archiwum HTTP nie pozwalają jednoznacznie powiązać animacji z przesunięciami układu, wskazują one, że strony, które animują dowolną właściwość CSS, która może wpływać na układ, mają o 15% mniejsze szanse na uzyskanie „dobrego” CLS niż inne strony. Niektóre właściwości są powiązane z gorszym CLS niż inne. Na przykład strony, które animują szerokość margin lub border, mają wartość CLS „niska” prawie dwukrotnie częściej niż strony oceniane jako „niska” w ogóle.

Nie powinno to być zaskakujące, ponieważ każda zmiana lub animacja jakiejkolwiek właściwości CSS wpływającej na układ powoduje zmiany układu. Jeśli te przesunięcia układu nie nastąpią w ciągu 500 milisekund od interakcji użytkownika, wpłyną na CLS.

Co może być zaskakujące dla niektórych deweloperów, jest to możliwe nawet wtedy, gdy element jest przenoszony poza normalny przepływ dokumentu. Na przykład elementy z pozycjonowaniem bezwzględnym, które animują się za pomocą top lub left, powodują zmiany układu, nawet jeśli nie przesuwają innych treści. Jeśli jednak zamiast animować element top lub left, zdecydujesz się na animację elementu transform:translateX() lub transform:translateY(), nie spowoduje to aktualizacji układu strony przez przeglądarkę, dzięki czemu unikniesz przesunięć.

Wybieranie animacji właściwości CSS, które można aktualizować w wątku kompozytora przeglądarki, od dawna jest sprawdzoną metodą dotyczącą wydajności, ponieważ przenosi tę czynność z głównego wątku do GPU. Jest to sprawdzona metoda dotycząca ogólnej skuteczności, która może też pomóc w zwiększeniu CLS.

Zasadniczo nigdy nie animuj ani nie przejdź do właściwości CSS, które wymagają od przeglądarki aktualizacji układu strony, chyba że robisz to w odpowiedzi na kliknięcie przez użytkownika lub naciśnięcie klawisza (nie hover). W miarę możliwości preferuj przejścia i animacje korzystające z właściwości CSS transform.

Audyt Lighthouse Unikaj nieskomponowanych animacji ostrzega, gdy strona zawiera animacje, które mogą spowalniać działanie właściwości CSS.

Podsumowanie

Zwiększanie wydajności strony może wydawać się przytłaczające, zwłaszcza że w internecie można znaleźć mnóstwo wskazówek, które warto wziąć pod uwagę. Skupiając się jednak na tej krótkiej liście najskuteczniejszych sprawdzonych metod, możesz ponownie skupić się na tym problemie i móc wykorzystać w nim podstawowe wskaźniki internetowe swojej witryny.

Jeśli chcesz zastosować inne optymalizacje niż te wymienione powyżej, zapoznaj się z tymi przewodnikami:

• Optymalizacja INP
• Optymalizacja LCP
• Optymalizacja CLS

Załącznik: Historia zmian

W tym miejscu będą śledzone istotne zmiany w tym dokumencie, aby wyjaśnić, kiedy i dlaczego zmieniły się najważniejsze rekomendacje.

Październik 2024 r.

Aktualizacja z 2024 r.:

• INP
  • W związku z wprowadzeniem INP jako podstawowego wskaźnika internetowego zmieniliśmy ten wskaźnik z FID na INP i umieściliśmy go na liście na pierwszym miejscu.
  • Odstąpiliśmy od zalecenia korzystania z interfejsu API isInputPending w ramach dzielenia długich zadań. Więcej informacji o naszym rozumowaniu znajdziesz w artykule Optymalizowanie długich zadań.
• LCP
  • Połączyliśmy rekomendacje dotyczące widoczności i priorytetów w jedną.
  • Dodaliśmy nową rekomendację, która ma dotyczyć błyskawicznej nawigacji.

Styczeń 2023 r.

Oto wstępna lista rekomendacji:

• LCP
  • Upewnij się, że zasób LCP jest wykrywalny z poziomu kodu HTML.
  • Upewnij się, że zasób LCP ma priorytet
  • Używanie sieci CDN do optymalizacji TTFB dokumentu i zasobu
• CLS
  • Ustaw rozmiary dla pełnoletnich dla wszystkich treści wczytywanych ze strony
  • Sprawdzanie, czy strony kwalifikują się do korzystania z pamięci podręcznej stanu strony internetowej
  • Unikaj animacji i przejść, które wykorzystują właściwości CSS wywołujące układ
• FID:
  • Unikaj długich zadań lub dziel je na mniejsze części.
  • Unikaj niepotrzebnego JavaScriptu
  • Unikaj dużych aktualizacji renderowania

Aby zapoznać się z podsumowaniem, możesz też obejrzeć prezentację z Google I/O 2023.