Na przestrzeni lat społeczność internetowa zgromadziła ogromną wiedzę na temat optymalizacji wydajności stron internetowych. Chociaż każda optymalizacja może poprawić skuteczność wielu witryn, stosowanie ich wszystkich jednocześnie może być przytłaczające. W istocie 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 będą najbardziej korzystne dla Twojej witryny. 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 prawda o optymalizacji skuteczności: nie możesz oceniać jej wyłącznie pod kątem 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ą teoretycznie przynieść ogromne korzyści, ale w praktyce niewielu deweloperów ma czas lub zasoby na ich wdrożenie. 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 wpływ na rzeczywistość;
- są trafne i można je stosować w większości witryn;
- są realistyczne dla większości deweloperó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 zastanawiasz się, co przyniesie Ci największy zwrot z inwestycji, to jest najlepsze miejsce na rozpoczęcie.
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 kryterium „dobrego” działania. 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, analizowanie, kompilowanie i wykonywanie skryptów. Gdy 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.
Chociaż zawsze powinieneś starać się wykonywać jak najmniej pracy w JavaScript, możesz pomóc wątkowi głównemu, 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 za pomocą 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ń blokujących dostęp użytkownikowi.
2. Unikaj niepotrzebnego JavaScriptu
Witryny zawierają więcej kodu JavaScript niż kiedykolwiek wcześniej, a trend ten nie wydaje się ulegać zmianie. Jeśli wysyłasz zbyt dużo kodu JavaScript, tworzysz środowisko, w którym zadania konkurują o uwagę wątku głównego. Może to wpłynąć na szybkość działania witryny, zwłaszcza w tym ważnym okresie rozruchu.
Nie jest to jednak nierozwiązywalny problem. Możesz:
- Zamiast redundantnych implementacji opartych na JavaScript, używaj wartości odniesienia, czyli funkcji dostępnych na wielu platformach internetowych.
- 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ąć. Mimo to możesz podjąć kilka działań, aby zadania renderowania nie trwały zbyt długo:
- W kodzie JavaScript zreorganizuj odczyty i zapisy DOM, aby uniknąć wymuszonego układu oraz zwiększania się czasu ładowania 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-u, wymagana praca związana z ponownym obliczeniem układu może znacznie wzrosnąć.
- Użyj ograniczeń CSS, aby leniwie renderować zawartość 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. 40% witryn w raporcie na temat UX Chrome nie spełnia zalecanego progu LCP, który zapewnia dobre wrażenia użytkowników. Zespół Chrome zaleca stosowanie tych technik jako najskuteczniejszych sposobów na poprawę 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ł w przypadku LCP w internecie:
- Według Almanachu internetowego na rok 2024 opublikowanego przez HTTP Archive 73% stron mobilnych ma element LCP w postaci obrazu.
- 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 z niedostatecznym czasem LCP wczytywanie ich obrazów LCP jest opóźnione na kliencie o 1290 ms w 75. percentylu – to ponad połowa budżetu na szybkie działanie.
- Na stronach, na których element LCP był obrazem, 35% obrazów miało źródłowe adresy URL, których nie można było wykryć w pierwotnej odpowiedzi HTML (takich jak
<img src="...">
lub<link rel="preload" href="...">
), co uniemożliwia skanerowi wstępnego ładowania przeglądarki jak najszybsze ich wykrycie. - Według Web Almanac 15% 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 skryptu 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 to obraz, jego adres URL powinien być możliwy do znalezienia w odpowiedzi HTML, aby skrócić czas wczytywania zasobu. Oto kilka wskazówek, które Ci w tym pomogą:
- Wczytaj obraz za pomocą elementu
<img>
z atrybutemsrc
lubsrcset
. Nie używaj atrybutów niestandardowych, takich jakdata-src
, które wymagają JavaScriptu do renderowania, ponieważ zawsze będą działać wolniej. 7% stron ukrywa obraz LCP za pomocą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 musi 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. Dzięki temu unikniesz opóźnienia wczytywania spowodowanego potwierdzeniem, że obraz pojawia się w widoku lub w pobliżu. - W miarę możliwości odłóż zasoby, które nie są kluczowe. 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. Postaraj się o nawigację natychmiastową.
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. Jednak szybkość wczytywania tych bajtów przez sieć i ich wyświetlania na stronie ma swoje fizyczne ograniczenia. 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 umożliwić natychmiastową nawigację, musimy zastosować zupełnie 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 przejdzie 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ć, gdzie 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 niej korzystać, musisz się upewnić, że Twoje strony spełniają kryteria kwalifikacji bfcache. Najczęstsze przyczyny, dla których strony nie kwalifikują się do korzystania z bfcache, to ich wyświetlanie z no-store
dyrektywami dotyczącymi buforowania lub z unload
detektorów zdarzeń.
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 API reguł spekulacji. Aby jednak osiągnąć 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 szybszym prerenderowaniu stron o najwyższym prawdopodobieństwie odwiedzenia.
3. Optymalizacja czasu oczekiwania na odpowiedź serwera (TTFB) za pomocą sieci CDN
Poprzednia rekomendacja koncentrowała się na natychmiastowej nawigacji, która zapewnia użytkownikom jak najlepsze wrażenia, ale mogą wystąpić sytuacje, w których techniki bfcache i speculacyjnego wczytywania nie są odpowiednie. Użytkownik klika link do Twojej witryny w innej witrynie, a początkowa odpowiedź dokumentu HTML blokuje LCP. Przeglądarka nie może rozpocząć wczytywania żadnych zasobów podrzędnych, dopóki nie otrzyma pierwszego bajta odpowiedzi. Im szybciej to nastąpi, tym szybciej zaczną się dziać inne rzeczy.
Czas ten nazywa się czasem do pierwszego bajtu (TTFB). Najlepsze sposoby na zmniejszenie wartości TTFB to:
- Udostępniaj treści użytkownikom znajdującym się jak najbliżej ich lokalizacji.
- Zapisuje te treści w pamięci podręcznej, aby można je było szybko wyświetlić, jeśli w niedalekiej przyszłości zostaną ponownie zażądane.
Najlepszym sposobem na spełnienie tych wymagań jest użycie sieci CDN. Sieci CDN rozpowszechniają Twoje zasoby na serwerach peryferyjnych na całym świecie, co ogranicza odległość, jaką muszą pokonać te zasoby, aby dotrzeć do użytkowników. Sieci CDN mają też zwykle szczegółowe ustawienia pamięci podręcznej, które można dostosować do potrzeb Twojej witryny.
Sieci CDN mogą też dostarczać i przechowywać w pamięci podręcznej dokumenty HTML, ale według Web Almanac tylko 33% żądań dokumentów HTML zostało obsłużonych przez sieć CDN. Oznacza to, że witryny mają duże możliwości dodatkowego oszczędzania.
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ć to kilka minut?
- Sprawdź, czy możesz przenieść logikę dynamiczną działającą na serwerze źródłowym na peryferium, co jest funkcją większości nowoczesnych sieci CDN.
Każdy moment, w którym możesz wyświetlić treści bezpośrednio z peryferii, unikając przesyłania ich na serwer źródłowy, to wygrana w zakresie wydajności. Nawet wtedy, gdy musisz przebyć całą drogę do źródła, sieci CDN są zazwyczaj optymalizowane pod kątem szybszego przesyłania danych, więc w obu przypadkach jest to korzystne rozwiązanie.
Skumulowane przesunięcie układu (CLS)
Skumulowane przesunięcie układu (CLS) to wskaźnik stabilności wizualnej strony internetowej. Chociaż wskaźnik CLS jest wskaźnikiem, który w przypadku większości witryn ma tendencję do osiągania dobrych wyników, ćwierć z nich nadal nie osiąga zalecanego progu, więc wiele witryn ma jeszcze duże pole do poprawy w zakresie zapewniania użytkownikom wygody.
1. ustawiać dokładne rozmiary dla wszystkich treści wczytywanych ze strony;
Zmiana układu następuje zwykle, gdy istniejące treści są przenoszone po zakończeniu wczytywania innych treści. 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. 66% stron zawiera co najmniej 1 obraz bez wymiarów. Jeśli nie ma wyraźnie określonego rozmiaru, obrazy mają początkową wysokość 0px
, co może powodować przesunięcia układu podczas wczytywania tych obrazów i wykrywania ich 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
. Jest to dostępna powszechnie funkcja domyślna w CSS, która umożliwia deweloperom jawne ustawianie współczynnika proporcji dla obrazów i elementów niebędących obrazami. 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 odpowiedniej wartości min-height
jest prawie zawsze lepsze niż zezwolenie przeglądarce na użycie 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, jeśli zajdzie taka potrzeba. W tym przypadku wzrost został ograniczony do poziomu, który jest łatwiej akceptowalny.
2. Sprawdzanie, czy strony kwalifikują się do korzystania z pamięci podręcznej stanu strony internetowej
Jak już wspomnieliśmy w tym przewodniku, pamięć podręczna stanu strony internetowej (bfcache) natychmiast wczytuje stronę z wcześniejszej lub późniejszej historii przeglądarki na podstawie migawki pamięci. Pamięć podręczna stanu strony internetowej to rodzaj optymalizacji 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 korzystania z bfcache, przez co nie może korzystać z tej bezpłatnej funkcji poprawiającej wydajność. 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 bfcache, i usunąć przyczyny, dla których tak się nie kwalifikują. Chrome ma tester bfcache w Narzędziach deweloperskich. Możesz też użyć interfejsu API Not Restored Reasons, aby wykryć przyczyny braku kwalifikacji w polu.
3. Unikaj animacji i przejść, które wykorzystują właściwości CSS wpływające na 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 zwiększenia wartości CLS. Jest to szczególnie problematyczne, gdy banery zasłaniają inne treści, ale nawet wtedy, gdy tego nie robią, ich animacja może wpływać na CLS.
Dane z archiwum HTTP nie pozwalają jednoznacznie powiązać animacji z przesunięciami układu, ale wskazują, ż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ą CLS na poziomie „zły” prawie dwukrotnie częściej niż strony ocenione jako „słabe” w ogóle.
Nie powinno to być zaskoczeniem, 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ć top
lub left
, zdecydujesz się na animację transform:translateX()
lub transform:translateY()
, przeglądarka nie zaktualizuje układu strony, dzięki czemu unikniesz przesunięć.
Preferowanie animacji właściwości CSS, które można aktualizować na wątku kompozytora przeglądarki, od dawna jest najlepszą praktyką pod kątem wydajności, ponieważ przenosi to pracę z głównego wątku na procesor graficzny. 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 zmieniaj 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 (ale nie hover
). W miarę możliwości preferuj przejścia i animacje za pomocą właściwości CSS transform
.
Kontrola Lighthouse Unikaj nieskomponowanych animacji ostrzega, gdy strona animuje potencjalnie wolne właściwości CSS.
Podsumowanie
Poprawa wydajności strony może wydawać się trudna, zwłaszcza że w internecie można znaleźć mnóstwo wskazówek. Jeśli jednak skupisz się na tej krótkiej liście najskuteczniejszych sprawdzonych metod, możesz podejść do problemu z nową energią i być może poprawić wyniki swojej witryny w podstawowych wskaźnikach internetowych.
Jeśli chcesz zastosować inne optymalizacje niż wymienione tutaj, zapoznaj się z tymi przewodnikami:
Dodatek: historia zmian
Tutaj będziemy śledzić najważniejsze zmiany w tym dokumencie, aby pomóc Ci zrozumieć, 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 naszych założeniach znajdziesz w artykule Optymalizowanie długich zadań.
- LCP
- Połączyliśmy rekomendacje dotyczące widoczności i priorytetów.
- Dodaliśmy nową rekomendację, która ma na celu prowadzenie użytkowników do celu w najkrótszym czasie.
Styczeń 2023 r.
Oto wstępna lista rekomendacji:
- LCP
- Upewnij się, że zasób LCP jest wykrywalny z poziomu kodu źródłowego HTML
- Upewnij się, że zasób LCP ma priorytet
- Korzystanie z CDN do optymalizacji czasu oczekiwania na odpowiedź (TTFB) dokumentów i zasobów
- CLS
- ustawiać dokładne rozmiary 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 wpływające na 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.