Najważniejsze rekomendacje dotyczące podstawowych wskaźników internetowych na 2023 rok

Zbiór sprawdzonych metod, które zdaniem zespołu Chrome DevRel pomogą Ci poprawić wydajność podstawowych wskaźników internetowych w 2023 roku.

Na przestrzeni lat w Google przesyłaliśmy wiele rekomendacji dla programistów stron internetowych na temat zwiększania wydajności.

Chociaż każda z tych rekomendacji pojedynczo może zwiększyć skuteczność w wielu witrynach, to jednak pełny zestaw zaleceń jest niewątpliwie przytłaczający i w rzeczywistości nie ma możliwości, aby pojedyncza osoba lub witryna mogła stosować je wszystkie.

Jeśli wydajność witryny nie jest Twoją pracą na co dzień, nie jest od razu jasne, które rekomendacje będą miały największy pozytywny wpływ na Twoją witrynę. Na przykład wiesz, że wdrożenie najważniejszych stylów CSS może poprawić szybkość wczytywania, i słyszysz również, że optymalizacja obrazów jest ważna. Ale jak wybrać jedną z nich, jeśli nie masz czasu na wykonywanie obu tych czynności?

W zeszłym roku zespół Chrome próbował odpowiedzieć na to pytanie: jakie są najważniejsze rekomendacje, jakie możemy przekazać deweloperom, aby pomóc im zwiększyć wydajność aplikacji?

Aby odpowiednio odpowiedzieć na to pytanie, musimy wziąć pod uwagę nie tylko zalety danej rekomendacji, ale także czynniki ludzkie i organizacyjne, które wpływają na prawdopodobieństwo, że deweloperzy będą w stanie zastosować te rekomendacje. Innymi słowy, niektóre rekomendacje mogą być w teorii bardzo skuteczne, ale w rzeczywistości niewiele witryn ma wystarczająco dużo czasu lub zasobów, by je wdrożyć. Niektóre rekomendacje są też bardzo ważne, ale większość witryn już stosuje te zasady.

Krótko mówiąc, chcieliśmy skupić się na:

• Rekomendacje, które naszym zdaniem będą miały największy rzeczywisty wpływ
• Rekomendacje, które są trafne i pasujące do większości witryn.
• zalecenia, które większość deweloperów może wdrożyć.

W ciągu ostatniego roku spędziliśmy dużo czasu na sprawdzaniu wszystkich naszych rekomendacji dotyczących skuteczności i ocenianiu każdego z nich (pod względem jakościowym i ilościowym) pod kątem powyższych 3 kryteriów.

W tym poście przedstawiamy nasze najważniejsze zalecenia dotyczące zwiększania wydajności każdego ze podstawowych wskaźników internetowych. Jeśli nie masz doświadczenia z wydajnością w internecie lub zastanawiasz się, co przyniesie największy zysk, te zalecenia będą dla Ciebie najlepsze.

Największe wyrenderowanie treści (LCP)

Pierwszy zestaw zaleceń dotyczy największego wyrenderowania treści (LCP), który określa wydajność wczytywania. Spośród 3 podstawowych wskaźników internetowych LCP to wartość, z którą boryka się największa liczba witryn – tylko około połowa wszystkich witryn w internecie osiąga zalecany próg – więc zacznijmy od tego.

Sprawdź, czy zasób LCP jest wykrywalny ze źródła HTML

Według raportu Web Almanac z archiwum HTTP z 2022 r. 72% stron mobilnych ma swój element LCP w postaci obrazu. Oznacza to, że w przypadku większości witryn, aby zoptymalizować LCP, obrazy muszą się szybko ładować.

Wielu programistów nie wie, że czas potrzebny na wczytanie obrazu to tylko jedna część wyzwania. Kolejna ważna część to czas, przed rozpoczęciem wczytywania obrazu, a dane z archiwum HTTP wskazują, że to właśnie w tym miejscu wiele witryn jest zaatakowanych.

W przypadku stron, na których element LCP był obrazem, 39% z nich miało źródłowe adresy URL, które nie były wykrywalne ze źródła dokumentu HTML. Inaczej mówiąc, nie znaleziono tych adresów URL w standardowych atrybutach HTML (takich jak <img src="..."> czy <link rel="preload" href="...">), które umożliwiałyby przeglądarce jej szybkie wykrycie i rozpoczęcie ładowania.

Jeśli strona musi poczekać na pełne pobranie, przeanalizowanie i przetworzenie pliku CSS lub JavaScript, zanim obraz zacznie się ładować, może już być za późno.

Ogólnie rzecz biorąc, jeśli element LCP jest obrazem, jego adres URL powinien być zawsze wykrywalny w źródle HTML. Oto kilka wskazówek, jak:

• Wczytaj obraz za pomocą elementu <img> z atrybutem src lub srcset. Nie używaj niestandardowych atrybutów, takich jak data-src, które wymagają JavaScriptu do renderowania, ponieważ będzie to zawsze wolniejsze. 9% stron zasłania obraz LCP za elementem data-src.

• Preferuj renderowanie po stronie serwera (SSR) zamiast renderowania po stronie klienta, ponieważ SSR sugeruje, że w źródle HTML znajdują się znaczniki całej strony (w tym obraz). Rozwiązania dotyczące podpisania certyfikatu wymagają uruchomienia JavaScriptu, zanim obraz zostanie wykryty.

• Jeśli do obrazu trzeba odwoływać się z zewnętrznego pliku CSS lub JS, możesz uwzględnić go w źródle HTML za pomocą tagu <link rel="preload">. Pamiętaj, że skaner wstępnego wczytywania w przeglądarce nie wykrywa obrazów, do których odwołują się style wbudowane. Dlatego nawet jeśli znajdują się one w źródle HTML, ich wykrycie może być zablokowane podczas wczytywania innych zasobów, więc w takich przypadkach warto skorzystać z wstępnego ładowania.

Aby pomóc Ci zrozumieć, czy obraz LCP ma problemy z wykrywalnością, w LCP znajdziesz nową kontrolę w wersji 10.0 (spodziewamy się to w styczniu 2023 r.).

Zapewnienie wykrywalności zasobu LCP ze źródła HTML może prowadzić do mierzalnych ulepszeń. Daje to też dodatkowe możliwości ustalania priorytetów zasobów, co jest naszą następną rekomendacją.

Sprawdź, czy zasób LCP ma priorytet

Zapewnienie możliwości wykrycia zasobu LCP w źródle HTML to kluczowy pierwszy krok do rozpoczęcia ładowania zasobu LCP. Kolejnym ważnym krokiem jest upewnienie się, że wczytywanie takiego zasobu ma priorytet i nie będzie czekało na kolejkę innych, mniej ważnych zasobów.

Na przykład, nawet jeśli obraz LCP znajduje się w źródle HTML przy użyciu standardowego tagu <img>, to jeśli w obiekcie <head> dokumentu znajduje się kilkanaście tagów <script> przed tagiem <img>, ładowanie zasobu obrazu może trochę potrwać.

Najłatwiejszym sposobem rozwiązania tego problemu jest wskazanie przeglądarce, które zasoby mają najwyższy priorytet, przez ustawienie nowego atrybutu fetchpriority="high" w tagu <img> lub <link>, który wczytuje obraz LCP. Sprawi to, że przeglądarka wczyta ją wcześniej, zamiast czekać na zakończenie działania skryptów.

Według raportu Web Almanac tylko 0,03% kwalifikujących się stron korzysta z tego nowego interfejsu API, co oznacza, że większość witryn ma wiele możliwości poprawy LCP przy niewielkim nakładzie pracy. Chociaż atrybut fetchpriority jest obecnie obsługiwany tylko w przeglądarkach opartych na Chromium, ten interfejs API jest progresywnym ulepszeniem, które jest ignorowane przez inne przeglądarki, dlatego zdecydowanie zalecamy korzystanie z niego już teraz.

W przypadku przeglądarek innych niż Chromium jedynym sposobem na zapewnienie priorytetu zasobu LCP przed innymi zasobami jest odwoływanie się do niego wcześniej w dokumencie. Posługując się ponownie przykładem witryny z dużą liczbą tagów <script> w dokumencie <head>. Jeśli chcesz mieć pewność, że zasób LCP ma wyższy priorytet niż zasoby skryptu, możesz dodać tag <link rel="preload"> przed dowolnym z tych skryptów lub przenieść te skrypty poniżej sekcji <img> w dalszej części skryptu <body>. Choć to rozwiązanie działa, jest mniej ergonomiczne niż fetchpriority. Mamy nadzieję, że wkrótce dodamy obsługę innych przeglądarek.

Innym ważnym aspektem nadawania priorytetu zasobowi LCP jest upewnienie się, że nie podejmiesz żadnych działań, które mogłyby spowodować obniżenie priorytetu zasobu LCP. Może to być na przykład dodanie atrybutu loading="lazy". Obecnie 10% stron ma ustawione ustawienie loading="lazy" w obrazie LCP. Wystrzegaj się rozwiązań do optymalizacji obrazów, które bez zastanowienia stosują leniwe ładowanie wszystkich obrazów. Jeśli pozwalają one zastąpić to działanie, pamiętaj, by użyć go w przypadku obrazu LCP. Jeśli nie masz pewności, który obraz będzie parametrem LCP, spróbuj użyć heurystyki, aby wybrać rozsądną kandydaturę.

Opóźnienie zasobów niekrytycznych to kolejny sposób na skuteczne zwiększenie względnego priorytetu zasobu LCP. Na przykład skrypty, które nie są wykorzystywane w interfejsie użytkownika (takie jak skrypty analityczne czy widżety społecznościowe), można bezpiecznie odłożyć do czasu wywołania zdarzenia load. Dzięki temu nie będą konkurować z innymi zasobami krytycznymi (takimi jak zasób LCP) o przepustowość sieci.

Podsumowując, postępuj zgodnie z tymi sprawdzonymi metodami, aby mieć pewność, że zasób LCP zostanie wczytany odpowiednio wcześnie i na wysokim priorytecie:

• Dodaj parametr fetchpriority="high" do tagu <img> obrazu LCP. Jeśli zasób LCP jest wczytywany za pomocą tagu <link rel="preload">, nie martw się, ponieważ możesz także w tym celu ustawić fetchpriority="high".
• Nigdy nie ustawiaj wartości loading="lazy" w tagu <img> obrazu LCP. Spowoduje to obniżenie priorytetu obrazu i opóźnienie rozpoczęcia ładowania.
• Jeśli to możliwe, odkładaj niekrytyczne zasoby. Możesz przenieść je na koniec dokumentu, zastosować natywne leniwe ładowanie obrazów lub elementów iframe albo wczytać je asynchronicznie przez JavaScript.

Używanie sieci CDN do optymalizacji TTFB dokumentu i zasobu

Poprzednie 2 rekomendacje skupiały się na zapewnieniu, że zasób LCP zostanie wykryty wcześnie i ustalony priorytet, aby mógł się od razu zacząć ładować. Ostatnim elementem tej łamigłówki jest to, aby pierwsza odpowiedź na dokument dotarła jak najszybciej.

Przeglądarka nie może zacząć wczytywać żadnych zasobów podrzędnych, dopóki nie otrzyma pierwszego bajtu początkowej odpowiedzi na żądanie dokumentu HTML. Im szybciej to się stanie, tym szybciej zaczną się również reszta.

Jest to tzw. czas do pierwszego bajtu (TTFB). Najlepszym sposobem na ograniczenie TTFB jest:

• Wyświetlaj treści jak najbliżej użytkowników w określonym regionie geograficznym
• Przechowywanie tych treści w pamięci podręcznej, by można było szybko wyświetlić te treści, których dotyczyło żądanie.

Najlepszym sposobem na wykonanie obu tych czynności jest użycie sieci CDN. Sieci CDN rozpowszechniają zasoby na serwerach brzegowych, które są rozproszone po całym świecie, co ogranicza odległość, jaką zasoby muszą pokonywać przewodami użytkowników. Sieci CDN zwykle mają też szczegółowe ustawienia buforowania, które można dostosować i zoptymalizować pod kątem potrzeb witryny.

Wielu deweloperów ma wiedzę o używaniu sieci CDN do hostowania zasobów statycznych. Jednak sieci CDN mogą wyświetlać i buforować dokumenty HTML, nawet jeśli są generowane dynamicznie.

Według raportu Web Almanac tylko 29% żądań dokumentów HTML pochodziło z sieci CDN, co oznacza, że mają duże możliwości uzyskania dodatkowych oszczędności.

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

• Zastanów się nad wydłużeniem okresu przechowywania treści w pamięci podręcznej (na przykład czy istotne jest, aby treści były zawsze aktualne? A może te informacje są nieaktualne?).
• Być może warto rozważyć przechowywanie treści w pamięci podręcznej bezterminowo, a następnie wyczyszczenie pamięci podręcznej w przypadku aktualizacji.
• Sprawdź, czy możesz przenieść logikę dynamiczną działającą obecnie na serwerze pierwotnym na wersję najnowszą (funkcję większości współczesnych sieci CDN).

Ogólnie rzecz biorąc, za każdym razem, gdy możesz wyświetlić treść bezpośrednio z brzegu (co pozwala uniknąć przejścia do serwera pierwotnego), jest to bardzo ważne. Nawet jeśli musisz dotrzeć z powrotem do serwera pierwotnego, sieci CDN są zwykle zoptymalizowane w taki sposób, by robić to znacznie szybciej, więc jest to korzystne dla obu stron.

Skumulowane przesunięcie układu (CLS)

Następny zestaw zaleceń to skumulowane przesunięcie układu (CLS), które pozwala mierzyć stabilność wizualną stron internetowych. Chociaż od 2020 roku nastąpił duży postęp w zakresie CLS w internecie, około 1/4 witryn nadal nie osiąga zalecanego progu, więc wiele witryn nadal ma szansę poprawić wrażenia użytkowników.

Ustaw rozmiary dla pełnoletnich 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. Podstawowym sposobem na złagodzenie tego zjawiska jest więc jak najszybsze zarezerwowanie wymaganej przestrzeni.

Najprostszym sposobem na poprawienie przesunięć układu spowodowanych przez obrazy o niewielkim rozmiarze jest jednoznaczne ustawienie atrybutów width i height (lub ich odpowiedników w przypadku właściwości CSS). Jednak według archiwum HTTP 72% stron zawiera co najmniej 1 obraz bez określonego rozmiaru. Jeśli nie podasz rozmiaru wyraźnego pliku, przeglądarki początkowo ustawią domyślną wysokość wynoszącą 0px, co może spowodować zauważalne przesunięcie układu, gdy obraz zostanie wczytany i jego wymiary zostaną wykryte. To ogromne możliwości dla całej sieci, które wymagają znacznie mniejszego wysiłku niż niektóre inne rekomendacje sugerowane w tym artykule.

Pamiętaj też, że obrazy nie są jedynym czynnikiem wpływającym na CLS. Przesunięcia układu mogą być spowodowane przez inne treści, które zwykle ładują się po początkowym wyrenderowaniu strony, w tym reklamy innych firm i umieszczone filmy. Możesz temu zapobiec, korzystając z właściwości aspect-ratio. To stosunkowo nowa funkcja CSS, która umożliwia programistom podawanie formatu obrazu zarówno obrazom, jak i innym elementom. Pozwoli Ci to ustawić dynamiczny element width (np. na podstawie rozmiaru ekranu), a przeglądarka będzie automatycznie obliczać odpowiednią wysokość, podobnie jak w przypadku obrazów z wymiarami.

Czasami nie można określić dokładnego rozmiaru zawartości dynamicznej, ponieważ jest ona z natury dynamiczna. Nawet jeśli nie znasz dokładnego rozmiaru, możesz spróbować zmniejszyć wagę przesunięć 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. Korzystanie z elementu min-height również zwykle jest łatwym rozwiązaniem, ponieważ w razie potrzeby umożliwia rozciągnięcie kontenera do ostatecznej wysokości zawartości – tylko zmniejszyło to jego rozbieżność z całkowitej ilości do bardziej dostępnego poziomu.

Sprawdź, czy strony kwalifikują się do użycia pamięci podręcznej stanu strony internetowej

Przeglądarki używają mechanizmu nawigacji zwanego pamięcią podręczną stanu strony internetowej (w skrócie bfcache), aby natychmiast wczytywać stronę z wcześniejszej lub późniejszej historii przeglądania bezpośrednio z migawki pamięci.

Pamięć podręczna stanu przeglądarki umożliwia znaczącą optymalizację wydajności na poziomie przeglądarki i całkowicie eliminuje zmiany układu podczas wczytywania strony – w przypadku wielu witryn znajduje się tam większość CLS. Wprowadzenie pamięci podręcznej (bfcache) przyniosło największą poprawę CLS, jaką odnotowaliśmy w 2022 r.

Mimo to znaczna liczba witryn nie kwalifikuje się do umieszczenia w pamięci podręcznej stanu strony internetowej, dlatego mogą one nie wykorzystać tego bezpłatnego potencjału, który zapewni użytkownikom większą liczbę nawigacji. O ile strona nie wczytuje informacji poufnych, których nie chcesz przywracać z pamięci, musisz sprawdzić, czy Twoje strony się kwalifikują.

Właściciele witryn powinni sprawdzić, czy ich strony kwalifikują się do korzystania z pamięci podręcznej stanu strony internetowej, i wyeliminować ewentualne przyczyny takiej sytuacji. Chrome ma już testera pamięci podręcznej przeglądarki Chrome w Narzędziach deweloperskich. W tym roku planujemy ulepszyć narzędzia, korzystając z nowego audytu w Lighthouse przeprowadzającego podobny test oraz interfejsu API do pomiaru skuteczności tej przeglądarki.

Pomimo tego, że w sekcji CLS uwzględniliśmy pamięć podręczną bfcache, jak dotąd zaobserwowaliśmy największe korzyści, pole bfcache poprawi się też ogólnie o innych podstawowych wskaźnikach internetowych. To jedna z wielu opcji błyskawicznych nawigacji, które pozwalają znacznie usprawnić nawigację na stronach.

Unikaj animacji/przejścia, które wykorzystują właściwości CSS wywołujące układ

Innym częstym źródłem przesunięć układu są animowane elementy. Na przykład banery dotyczące plików cookie lub inne banery powiadomień, które wysuwają się z góry lub u dołu, są często powiązane z CLS. Problem dotyczy szczególnie tych banerów, które „przesuwają na bok inne treści”, ale nawet jeśli ich nie widać, ich animacja może wpływać na CLS.

Chociaż dane z archiwum HTTP nie potrafią jednoznacznie powiązać animacji z przesunięciami układu, dane pokazują, że strony animujące dowolną właściwość CSS, która może wpływać na układ, mają o 15% mniej „dobrej” wartości CLS niż strony ogółem. Niektóre usługi są powiązane z gorszymi wartościami CLS niż inne. Na przykład strony z animacjami o szerokości margin lub border mają „niski” wskaźnik CLS prawie dwa razy częściej niż strony, które ogólnie są oceniane jako słabe.

Nie jest to zaskakujące, ponieważ za każdym razem, gdy przenosisz lub animujesz dowolną właściwość CSS wywołującą układ, powoduje to przesunięcia układu. Jeśli te przesunięcia układu nie mieszczą się w odległości 500 milisekund od interakcji użytkownika, będą miały wpływ na CLS.

Część programistów może zaskoczyć, że dzieje się tak nawet w przypadku, gdy element jest wychodzący poza normalny obieg dokumentów. Na przykład bezwzględnie rozmieszczone elementy, które animują top lub left, powodują przesunięcia układu, nawet jeśli nie przenoszą innych treści. Jeśli jednak zamiast animować element top lub left, animujesz transform:translateX() lub transform:translateY(), przeglądarka nie zmieni układu strony, więc nie spowoduje żadnych przesunięć układu.

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ż jest przenoszone do GPU i z wątku głównego. Oprócz tego, że jest to ogólna sprawdzona metoda dotycząca skuteczności, może też pomóc w poprawie CLS.

Ogólnie rzecz biorąc, nigdy nie animuj ani nie przenoś właściwości CSS, które wymagają aktualizacji układu strony przez przeglądarkę, chyba że robisz to w odpowiedzi na kliknięcie użytkownika lub naciśnięcie klawisza (choć nie hover). W miarę możliwości preferowane są przejścia i animacje korzystające z właściwości CSS transform.

Audyt Lighthouse Unikaj nieskomponowanych animacji ostrzega, gdy strona zawiera potencjalnie wolniejsze właściwości CSS.

Opóźnienie przy pierwszym działaniu (FID)

Ostatni zestaw rekomendacji dotyczy opóźnienia po pierwszym działaniu (FID), które pozwala określić responsywność strony na interakcje użytkowników. Choć większość witryn internetowych ma obecnie bardzo dobre wyniki w systemie FID, w przeszłości udokumentowaliśmy wady tego wskaźnika i uważamy, że mają one duże możliwości poprawy ogólnej reagowania na interakcje użytkowników.

Nasz nowy wskaźnik Interakcja z następnym wyrenderowaniem (INP) jest możliwym następcą FID, a wszystkie poniższe rekomendacje mają zastosowanie zarówno do FID, jak i INP. Witryny w skali INP radzą sobie gorzej niż FID, zwłaszcza w przypadku urządzeń mobilnych. Dlatego zachęcamy deweloperów do poważnego rozważenia tych zaleceń dotyczących elastyczności, mimo że wskaźnik FID jest „dobry”.

Unikanie długich zadań i dzielenie się nimi z innymi

Lista zadań to dowolny odrębny proces wykonywany przez przeglądarkę. Zadania obejmują renderowanie, układ, analizowanie oraz kompilowanie i wykonywanie skryptów. Gdy zadania stają się długimi zadaniami (czyli trwającymi co najmniej 50 milisekund), blokują wątki główne i nie mogą szybko reagować na dane wejściowe użytkownika.

Według raportu Web Almanac istnieje wiele dowodów na to, że deweloperzy mogą robić więcej, aby unikać długich zadań lub dzielić się nimi. Podział długich zadań może nie być tak pracochłonny, jak inne zalecenia w tym artykule, ale wymaga mniej wysiłku niż inne techniki nieopisane w tym artykule.

Staraj się zawsze starać się wykonywać jak najmniej pracy w języku JavaScript, ale możesz znacznie pomóc w wątku głównym, podzielając długie zadania na mniejsze. Możesz to zrobić, odpowiadając na wątek główny, co przyspieszy renderowanie aktualizacji i innych interakcji użytkowników.

Możesz też rozważyć korzystanie z interfejsów API takich jak isInputPending i Scheduler API. isInputPending to funkcja, która zwraca wartość logiczną wskazującą, czy oczekujemy na dane wejściowe użytkownika. Jeśli zwraca kod true, możesz uzyskać dostęp do wątku głównego, by obsługiwał oczekujące dane wejściowe użytkownika.

Interfejs Scheduler API to bardziej zaawansowane podejście, które umożliwia planowanie pracy na podstawie systemu priorytetów uwzględniających to, czy wykonywana praca jest widoczna dla użytkownika, czy w tle.

Rozdzielając długie zadania, dajesz przeglądarce więcej możliwości przystosowania się do najważniejszych zadań widocznych dla użytkowników, takich jak interakcje z nimi i wszelkie wynikające z nich aktualizacje renderowania.

Unikaj niepotrzebnego JavaScriptu

Nie ma co do tego wątpliwości: witryn wysyła więcej kodu JavaScript niż kiedykolwiek wcześniej, a trend nie powinien się w najbliższym czasie zmieniać. Wysyłając za dużo JavaScriptu, tworzysz środowisko, w którym zadania konkurują o uwagę wątku głównego. Może to z pewnością wpłynąć na szybkość reagowania witryny, zwłaszcza w tym kluczowym okresie startu.

Nie jest to jednak problem, którego nie da się rozwiązać. Masz kilka możliwości:

• Aby znaleźć nieużywany kod w zasobach witryny, użyj narzędzia do obudowy w Narzędziach deweloperskich w Chrome. Zmniejszając rozmiar zasobów potrzebnych podczas uruchamiania, sprawisz, że witryna będzie poświęcać mniej czasu na analizowanie i kompilowanie kodu, co zapewni płynniejsze działanie początkowe.
• Czasami nieużywany kod, który można znaleźć w narzędziu do ochrony środowiska, jest oznaczony jako „nieużywany”, ponieważ nie został wykonany podczas uruchamiania, ale nadal jest niezbędny do obsługi niektórych funkcji w przyszłości. Ten kod możesz przenieść do osobnego pakietu przez podział kodu.
• Jeśli korzystasz z menedżera tagów, pamiętaj, by okresowo sprawdzać tagi, by mieć pewność, że są zoptymalizowane (nawet jeśli nadal są używane). Starsze tagi z nieużywanym kodem można usunąć, by zmniejszyć rozmiar kodu JavaScript Menedżera tagów i zwiększyć jego wydajność.

Unikaj dużych aktualizacji renderowania

Język JavaScript nie jest jedyną rzeczą, która może wpływać na responsywność Twojej witryny. Renderowanie może być rodzajem kosztownej pracy, a gdy przeprowadzana jest duża aktualizacja renderowania, może zakłócać zdolność witryny do reagowania na dane wejściowe użytkownika.

Optymalizacja renderowania nie jest prostym procesem i często zależy od tego, co chcesz osiągnąć. Jest jednak kilka rzeczy, które możesz zrobić, aby aktualizacje renderowania były rozsądne i nie obejmowały długich zadań:

• Nie używaj requestAnimationFrame() do wykonywania pracy niewizualnej. Wywołania requestAnimationFrame() są obsługiwane na etapie renderowania pętli zdarzenia, a gdy na tym etapie jest za dużo pracy, aktualizacje renderowania mogą się opóźniać. Wszystkie czynności wykonywane w usłudze requestAnimationFrame() muszą być zarezerwowane wyłącznie do zadań wymagających aktualizacji z renderowania.
• Rozmiar DOM powinien być mały. Rozmiar DOM i intensywność pracy nad układem są ze sobą powiązane. Gdy mechanizm renderowania musi zaktualizować układ pod kątem bardzo dużego DOM, nakład pracy związany z ponownym obliczeniem układu może się znacznie zwiększyć.
• Stosuj ograniczenia CSS. Ograniczenia CSS opierają się na właściwości CSS contain, która informuje przeglądarkę o tym, jak przeprowadzić układ w kontenerze, w którym ustawiona jest właściwość contain, w tym nawet izolować zakres układu i renderowania do określonego poziomu głównego w DOM. Nie zawsze jest to łatwy proces, ale dzięki izolacji obszarów zawierających złożone układy można uniknąć niepotrzebnego edytowania i układania stron.

Podsumowanie

Poprawa wydajności stron może wydawać się trudnym zadaniem, zwłaszcza że w internecie jest mnóstwo wskazówek, które warto wziąć pod uwagę. Skupiając się jednak na tych zaleceniach, możesz podejść do problemu z odpowiednią koncentracją na celu i móc wykorzystać w nim podstawowe wskaźniki internetowe swojej witryny.

Podane tu zalecenia w żaden sposób nie są wyczerpujące, ale na podstawie szczegółowej analizy sytuacji w internecie wierzymy, że są to najskuteczniejsze sposoby na zwiększenie wydajności podstawowych wskaźników internetowych w 2023 r.

Jeśli chcesz skorzystać z innych zaleceń, które znajdziesz tutaj, więcej informacji znajdziesz w przewodnikach dotyczących optymalizacji:

• Optymalizacja LCP
• Optymalizacja CLS
• Optymalizacja FID
• Optymalizacja wartości INP

Przed Tobą nowy rok i szybszy internet dla wszystkich! Niech Twoje strony będą szybkie dla użytkowników pod każdym względem.

Fot. Devin Avery