Zbiór sprawdzonych metod, które według zespołu Chrome DevRel będą najskuteczniejsze sposoby na poprawę wydajności w zakresie podstawowych wskaźników internetowych w 2023 roku.
Na przestrzeni lat skierowaliśmy w Google wiele rekomendacji dla programistów stron internetowych, aby dowiedzieć się, jak zwiększyć wydajność.
Choć każde z tych zaleceń może pojedynczo poprawić skuteczność w przypadku wielu witryn, pełen zestaw zaleceń jest przytłaczający i niestety nie ma możliwości, aby jedna osoba lub witryna wszystkie je obserwowała.
Jeśli wydajność działania witryny nie jest Twoją pracą na co dzień, nie jest jasne, które rekomendacje będą miały największy pozytywny wpływ na Twoją witrynę. Być może czytasz na przykład, że wdrożenie newralgicznych elementów CSS może przyspieszyć wczytywanie, a także że ważna jest optymalizacja obrazów. Ale jak nie masz czasu na pracę nad obiema tymi elementami?
W zeszłym roku zespół Chrome spędziliśmy czas, próbując odpowiedzieć na to pytanie: Jakie są najważniejsze zalecenia, które możemy przekazać deweloperom, aby pomóc im zwiększyć wydajność z myślą o użytkownikach?
Aby odpowiednio odpowiedzieć na to pytanie, musimy wziąć pod uwagę nie tylko możliwości techniczne danego zalecenia, ale także czynniki ludzkie i organizacyjne, które wpływają na prawdopodobieństwo, że deweloperzy będą w stanie je zastosować. Innymi słowy, niektóre rekomendacje mogą być teoretycznie bardzo skuteczne, ale w rzeczywistości niewiele witryn będzie mieć czas lub zasoby, by je wdrożyć. Niektóre rekomendacje są też bardzo ważne, ale większość witryn już je stosuje.
Krótko mówiąc, chcieliśmy, aby nasza lista najlepszych rekomendacji dotyczących skuteczności witryny skupiła się na:
- Rekomendacje, które naszym zdaniem będą miały największy rzeczywisty wpływ.
- Rekomendacje, które są trafne i mogą być zastosowane w większości witryn.
- rekomendacje, które są realistyczne dla większości deweloperów;
W ciągu ostatniego roku spędziliśmy wiele czasu na kontroli pełnego zestawu przygotowanych przez nas rekomendacji dotyczących skuteczności i ocenianiu każdego z nich (ilościowo i jakościowo) pod kątem powyższych 3 kryteriów.
W tym poście przedstawiamy nasze najważniejsze rekomendacje dotyczące poprawy skuteczności wszystkich podstawowych wskaźników internetowych. Jeśli dopiero zaczynasz korzystać z skuteczności w internecie lub zastanawiasz się, co przyniesie Ci największe korzyści, jesteśmy przekonani, że poniższe rekomendacje będą dla Ciebie najlepszym punktem wyjścia.
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 właśnie LCP, z którym ma ona najwięcej problemów – tylko około połowa wszystkich witryn w internecie osiąga obecnie zalecany próg. Zacznijmy więc od tego.
Sprawdź, czy zasób LCP jest wykrywalny w źródle HTML
Według 2022 Web Almanac Archiwum HTTP 72% stron mobilnych jako element LCP zawiera obraz, co oznacza, że w przypadku większości witryn zoptymalizowanie LCP musi zadbać o szybkie wczytywanie obrazów.
Dla wielu programistów może nie być oczywiste, że czas potrzebny na wczytanie obrazu to tylko jeden z wyzwań. Innym ważnym elementem jest czas przed rozpoczęciem ładowania obrazu, a dane z archiwum HTTP wskazują, że to właśnie na tym etapie wiele witryn się zawiesza.
W przypadku stron, na których elementem LCP był obraz, 39% z tych obrazów ma źródłowe adresy URL, które nie są wykrywalne w źródle dokumentu HTML. Innymi słowy, nie znaleziono tych adresów w standardowych atrybutach HTML (takich jak <img src="..."> czy <link rel="preload" href="...">), które pozwoliłyby przeglądarce na szybkie wykrycie tych adresów i rozpoczęcie ich wczytywania.
Jeśli strona musi czekać na pełne pobranie, przeanalizowanie i przetworzenie plików CSS lub JavaScript, zanim obraz zacznie się wczytywać, może być już za późno.
Ogólnie, jeśli elementem LCP jest obraz, adres URL obrazu powinien być zawsze wykrywalny w źródle HTML. Oto kilka wskazówek, które pomogą Ci to osiągnąć:
Wczytaj obraz za pomocą elementu
<img>z atrybutemsrclubsrcset. Nie używaj niestandardowych atrybutów, takich jakdata-src, które do renderowania wymagają JavaScriptu, ponieważ zawsze będzie to działać wolniej. 9% stron zasłania swój obraz LCP zadata-src.Preferuj renderowanie po stronie serwera (SSR) zamiast renderowania po stronie klienta (CSR), ponieważ SSR sugeruje, że w źródle HTML znajdują się znaczniki całej strony (wraz z obrazem). Rozwiązania dotyczące obsługi klienta wymagają uruchomienia JavaScriptu, aby możliwe było wykrycie obrazu.
Jeśli obraz powinien się odwoływać do zewnętrznego pliku CSS lub JS, nadal możesz umieścić go w źródle HTML za pomocą tagu
<link rel="preload">. Pamiętaj, że skaner wstępnego wczytywania przeglądarki nie wykrywa obrazów, do których odwołują się style wbudowane. Dlatego nawet jeśli znajdują się one w źródle HTML, ich wykrywanie może być zablokowane podczas wczytywania innych zasobów, więc wstępne wczytywanie może w tym przypadku pomóc.
Aby pomóc Ci zrozumieć, czy Twój obraz LCP zawiera problemy z wykrywalnością, Lighthouse opublikuje nowy audyt w wersji 10.0 (spodziewana data w styczniu 2023 r.).
Zapewnienie wykrywalności zasobu LCP w źródle HTML może prowadzić do wymiernych ulepszeń i otwiera dodatkowe możliwości określania priorytetów zasobów, co jest naszą kolejną rekomendacją.
Sprawdź, czy zasób LCP ma priorytet
Zadbaj o to, aby zasób LCP można było wykryć w źródle HTML. Jest to kluczowy pierwszy krok, który pozwoli na wcześniejsze ładowanie zasobu LCP. Kolejnym ważnym krokiem jest jednak określenie priorytetu ładowania zasobu i nie zostanie umieszczone w kolejce za innymi, mniej ważnymi zasobami.
Nawet jeśli na przykład obraz LCP jest umieszczony w źródle HTML za pomocą standardowego tagu <img>, to jeśli Twoja strona zawiera 10 tagów <script> w elemencie <head> dokumentu przed tagiem <img>, może upłynąć trochę czasu, zanim zasób graficzny zacznie się ładować.
Najprostszym sposobem rozwiązania tego problemu jest poinformowanie przeglądarki o tym, które zasoby mają najwyższy priorytet. Aby to zrobić, ustaw nowy atrybut fetchpriority="high" w tagu <img> lub <link>, który wczytuje obraz LCP. Dzięki temu przeglądarka załaduje ją wcześniej, a nie czeka na zakończenie działania skryptów.
Według raportu Web Almanac tylko 0,03% kwalifikujących się stron korzysta z nowego interfejsu API, co oznacza, że większość witryn w internecie ma wiele możliwości poprawy LCP przy niewielkim nakładzie pracy. Atrybut fetchpriority jest obecnie obsługiwany tylko w przeglądarkach opartych na Chromium, jednak ten interfejs API jest progresywnym ulepszeniem ignorowanym przez inne przeglądarki, dlatego zdecydowanie zalecamy deweloperom jego stosowanie już teraz.
W przypadku przeglądarek innych niż Chromium jedynym sposobem na zapewnienie, że zasób LCP będzie miał wyższy priorytet niż inne zasoby, jest odwołanie do niego wcześniej w dokumencie. Wróćmy do przykładu witryny, która zawiera wiele tagów <script> w elemencie <head> dokumentu. Jeśli chcesz, aby zasób LCP miał wyższy priorytet niż zasoby skryptu, możesz dodać tag <link rel="preload"> przed każdym z tych skryptów lub przenieść te skrypty do sekcji <img> w dalszej części instrukcji <body>. Ta metoda jest mniej ergonomiczna niż fetchpriority. Mamy więc nadzieję, że wkrótce inne przeglądarki ją obsługują.
Innym ważnym aspektem nadawania priorytetu zasóbowi LCP jest niewykonanie niczego, co spowodowałoby obniżenie jego priorytetu, na przykład dodanie atrybutu loading="lazy". Obecnie 10% stron ustawia parametr loading="lazy" w swoim obrazie LCP. Uważaj na rozwiązania do optymalizacji obrazów, które mają zbyt leniwe ładowanie i wczytują wszystkie obrazy. Jeśli umożliwiają one zastąpienie tego zachowania, użyj go w przypadku obrazu LCP. Jeśli nie masz pewności, które zdjęcie będzie LCP, użyj heurystyki, aby wybrać rozsądną propozycję.
Opóźnienie zasobów niekrytycznych to inny sposób na skuteczne zwiększenie względnego priorytetu zasobu LCP. Na przykład skrypty, które nie zasilają interfejsu użytkownika (takie jak skrypty analityczne czy widżety społecznościowe), można bezpiecznie odłożyć do czasu uruchomienia zdarzenia load. Dzięki temu nie będą one konkurować z innymi zasobami o znaczeniu krytycznym (takimi jak zasoby LCP) pod względem przepustowości sieci.
Podsumowując, postępuj zgodnie z tymi sprawdzonymi metodami, aby zasób LCP wczytywał się wcześnie i miał wysoki priorytet:
- Dodaj
fetchpriority="high"do tagu<img>obrazu LCP. Jeśli zasób LCP jest wczytywany przez tag<link rel="preload">, nie przejmuj się, ponieważ możesz go także ustawić w elemenciefetchpriority="high". - Nigdy nie ustawiaj
loading="lazy"w tagu<img>obrazu LCP. Spowoduje to obniżenie priorytetu obrazu i opóźnienie przed rozpoczęciem ładowania. - W miarę możliwości odkładaj zasoby niekrytyczne. Możesz to zrobić, przenosząc je na koniec dokumentu, korzystając z natywnego leniwego ładowania obrazów lub elementów iframe albo ładując je asynchronicznie w kodzie JavaScript.
Używaj sieci CDN do optymalizacji TTFB dokumentów i zasobów
Poprzednie 2 rekomendacje skupiały się na zapewnieniu szybkiego wykrycia zasobu LCP i nadania mu priorytetu, tak aby mógł się od razu rozpocząć ładowanie. Ostatnim elementem tej łamigłówki jest zadbanie o jak najszybsze dostarczenie pierwszej odpowiedzi dokumentu.
Przeglądarka nie może zacząć ładować żadnych zasobów podrzędnych, dopóki nie otrzyma pierwszego bajtu początkowej odpowiedzi dokumentu HTML. Im szybciej to nastąpi, tym szybciej zaczną się dziać wszystkie inne zdarzenia.
Jest to tak zwany czas do pierwszego bajtu (TTFB), a najlepszym sposobem na zmniejszenie liczby zdjęć jest:
- Udostępniaj treści w najbliższej lokalizacji użytkowników
- Przechowuj te treści w pamięci podręcznej, aby móc szybko wyświetlać żądane treści.
Najlepszym sposobem na wykonanie obu tych czynności jest użycie sieci CDN. Sieci CDN rozdzielają zasoby do serwerów brzegowych znajdujących się na całym świecie, ograniczając w ten sposób odległość, jaką te zasoby muszą pokonać, aby dotrzeć do użytkowników. Sieci CDN zwykle mają też szczegółowe ustawienia buforowania, które można dostosowywać i optymalizować pod kątem potrzeb witryny.
Wielu programistów korzysta z sieci CDN do hostowania zasobów statycznych, ale sieci CDN mogą również wyświetlać i przechowywać w pamięci podręcznej dokumenty HTML, nawet te generowane dynamicznie.
Według raportu Web Almanac tylko 29% żądań dokumentów HTML pochodziło z sieci CDN, co oznacza, że witryny mogą uzyskać dodatkowe oszczędności.
Oto kilka wskazówek dotyczących konfigurowania sieci CDN:
- Zastanów się, jak wydłużyć czas przechowywania treści w pamięci podręcznej (np. czy tak ważne jest, aby treści były zawsze aktualne? lub może być nieaktualny po kilku minutach?).
- Rozważ nawet bezterminowe przechowywanie treści w pamięci podręcznej i wyczyszczenie pamięci podręcznej w razie aktualizacji.
- Sprawdź, czy możesz przenieść logikę dynamiczną działającą obecnie na serwerze pierwotnym na nowoczesny (funkcja większości nowoczesnych sieci CDN).
Ogólnie rzecz biorąc, za każdym razem, gdy możesz wyświetlać treści bezpośrednio z brzegu (i unikać przechodzenia na serwer pierwotny), wiąże się to z maksymalną wydajnością. Nawet w przypadkach, w których konieczne jest dotarcie z powrotem na serwer pierwotny, sieci CDN są zwykle zoptymalizowane, aby robić to znacznie szybciej, więc i tak jest korzystne.
Skumulowane przesunięcie układu (CLS)
Następny zestaw zaleceń to skumulowane przesunięcie układu (CLS), które określa stabilność wizualną stron internetowych. Choć od 2020 roku wskaźnik CLS znacznie się poprawił w internecie od 2020 roku, około jedna czwarta witryn nadal nie osiąga zalecanego progu. Wiele witryn nadal ma ogromne możliwości poprawy komfortu użytkowników.
Ustaw rozmiary dla pełnoletnich w przypadku treści wczytywanych ze strony
Przesunięcia układu mają zwykle miejsce, gdy istniejące treści zostaną przeniesione po zakończeniu wczytywania innych treści. Dlatego głównym sposobem uniknięcia tego problemu jest rezerwowanie z wyprzedzeniem jak największej liczby miejsc.
Najprostszym sposobem rozwiązania problemów z przesunięciami układu spowodowanymi przez obrazy o niewielkim rozmiarze jest własne ustawienie atrybutów width i height (lub odpowiadających im właściwości CSS). Jednak według archiwum HTTP 72% stron zawiera co najmniej 1 obraz o zmienionym rozmiarze. Bez wyraźnego rozmiaru przeglądarki domyślnie ustawiają domyślną wysokość 0px, co może spowodować zauważalne przesunięcie układu po wczytaniu obrazu i wykryciu wymiarów. Według nas to ogromne możliwości dla całej sieci WWW – a ich realizacja wymaga znacznie mniejszego wysiłku niż niektóre z pozostałych rekomendacji sugerowanych w tym artykule.
Warto też pamiętać, że nie tylko obrazy mają wpływ na CLS. Przesunięcia układu mogą wynikać z powodu innych treści, które zwykle wczytują się po początkowym wyrenderowaniu strony, w tym reklam firm zewnętrznych i filmów umieszczonych na stronach. Właściwość aspect-ratio może pomóc w walce z tym problemem. To stosunkowo nowa funkcja CSS, która umożliwia programistom jawne podawanie współczynnika proporcji zarówno do obrazów, jak i do innych elementów. W ten sposób możesz ustawić dynamiczny parametr width (np. na podstawie rozmiaru ekranu), a przeglądarka automatycznie obliczy odpowiednią wysokość w taki sam sposób jak w przypadku obrazów o wymiarach.
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 zmniejszyć ryzyko przesunięć układu. Ustawianie rozsądnej wartości min-height jest prawie zawsze lepsze niż zezwolenie przeglądarce na używanie domyślnej wysokości 0px dla pustego elementu. Użycie elementu min-height jest zwykle łatwym rozwiązaniem, ponieważ nadal pozwala kontenerowi w razie potrzeby osiągnąć ostateczną wysokość zawartości. W rezultacie ilość przyrostu jest zmniejszona z pełnej do być może bardziej akceptowalna.
Sprawdź, czy strony kwalifikują się do korzystania z pamięci podręcznej stanu strony internetowej
Przeglądarki używają mechanizmu nawigacji nazywanego pamięcią podręczną stanu strony internetowej (w skrócie bfcache), aby błyskawicznie wczytywać stronę z historii przeglądania wcześniejszych lub późniejszych stron bezpośrednio ze zrzutu pamięci.
Pamięć podręczna stanu strony internetowej to istotny element optymalizacji wydajności na poziomie przeglądarki, który całkowicie eliminuje zmiany układu podczas wczytywania strony, które w wielu witrynach to miejsce, w którym zachodzi większość CLS. Wprowadzenie pola „bfcache” spowodowało największą poprawę CLS, jaką zaobserwowaliśmy w 2022 roku.
Pomimo to znaczna liczba witryn nie kwalifikuje się do korzystania z pamięci podręcznej stanu strony internetowej, co powoduje utratę potencjalnych korzyści związanych z wydajnością witryny przez znaczną liczbę użytkowników. Jeśli Twoja strona nie wczytuje informacji poufnych, których nie chcesz przywrócić z pamięci, sprawdź, czy Twoje strony kwalifikują się do korzystania z tej funkcji.
Właściciele witryn powinni sprawdzić, czy ich strony kwalifikują się do korzystania z pamięci podręcznej stanu strony internetowej i poszukać ewentualnych powodów, dla których tak nie jest. Chrome ma już testera plików BFcache w Narzędziach deweloperskich, a w tym roku planujemy ulepszyć to narzędzie dzięki nowi audytowi Lighthouse, które przeprowadzi podobny test oraz interfejsem API do pomiaru wyników w terenie.
Chociaż w sekcji CLS zawarliśmy dane dotyczące pamięci podręcznej (bfcache), co zaobserwowaliśmy w największych dotychczasowych możliwościach, bfcache będzie też zasadniczo poprawić również inne podstawowe wskaźniki internetowe. Jest to jedna z wielu opcji błyskawicznych dostępnych, które pozwalają znacznie usprawnić nawigację po stronach.
Unikaj animacji i przejść, które korzystają z właściwości CSS powodujących powstanie układu.
Innym częstym źródłem przesunięć układu są animacje elementów. Na przykład banery z plikami cookie lub inne banery powiadomień, które wsuwają się u góry lub u dołu, często mają wpływ na CLS. Jest to szczególnie problematyczne, gdy banery odpychają inne treści. Nawet jeśli tak nie jest, animowanie ich nadal może wpłynąć na CLS.
Chociaż dane w archiwum HTTP nie są w stanie jednoznacznie powiązać animacji ze zmianami układu, z danych wynika, ż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 w ogóle niż strony. Niektóre usługi mają gorszą wartość CLS niż inne. Na przykład strony z animacją o szerokości margin lub border mają „słabą” wartość CLS niemal dwukrotnie częściej, niż strony ogólnie ocenione są jako słabe.
Nie powinno to być zaskakujące, ponieważ każde przejście lub animowanie jakiejkolwiek właściwości CSS generującej układ spowoduje przesunięcia układu. Jeśli zmiany układu nie mieszczą się w zakresie 500 milisekund od interakcji użytkownika, będą one miały wpływ na CLS.
Dla niektórych programistów może to być zaskakujące, że dzieje się tak nawet wtedy, gdy element jest pobierany poza zwykły przepływ dokumentu. Na przykład bezwzględnie umieszczone elementy, które animują elementy top lub left, powodują przesunięcia układu, nawet jeśli nie przesuwają innych treści. Jeśli jednak zamiast animowania elementu top lub left zastosujesz animację transform:translateX() lub transform:translateY(), nie spowoduje to zmiany układu strony w przeglądarce i nie spowoduje żadnych przesunięć układu.
Preferowanie 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 ona działanie do GPU i z wątku głównego. Jest to nie tylko ogólna sprawdzona metoda dotycząca skuteczności, ale też pomoc w ulepszaniu CLS.
Ogólnie nigdy nie animuj ani nie zmieniaj żadnej właściwości CSS, która wymaga od przeglądarki aktualizacji układu strony, chyba że robisz to w reakcji na kliknięcie lub naciśnięcie klawisza przez użytkownika (ale nie hover). W miarę możliwości preferuj przejścia i animacje za pomocą właściwości CSS transform.
Audyt narzędzia Lighthouse Unikaj nieskomponowanych animacji wyświetla ostrzeżenie, gdy strona wykorzystuje potencjalnie powolne właściwości CSS.
Opóźnienie przy pierwszym działaniu (FID)
Ostatni zestaw zaleceń to opóźnienie po pierwszej interakcji (FID), które określa responsywność strony na interakcje użytkowników. Mimo że większość witryn w internecie obecnie uzyskiwała bardzo dobre wyniki w zakresie FID, w przeszłości udokumentowaliśmy jej słabe dane i wierzymy, że wciąż istnieje wiele możliwości poprawy ogólnej responsywności witryn na interakcje z użytkownikami.
Nasze nowe dane interakcji z kolejnym wyrenderowaniem (INP) mogą być następcom FID, a wszystkie poniższe rekomendacje mają zastosowanie zarówno w przypadku FID, jak i INP. Ponieważ strony w przypadku INP mają dobrą” skuteczność niż FID (zwłaszcza na urządzeniach mobilnych), zachęcamy deweloperów do poważnego rozważenia tych zaleceń dotyczących czasu reagowania pomimo „dobrego” FID.
Unikanie i dzielenie długich zadań
Zadania to dowolne pojedyncze zadania wykonywane przez przeglądarkę. Zadania obejmują renderowanie, układ, analizowanie oraz kompilowanie i wykonywanie skryptów. Gdy zadania stają się długimi zadaniami, czyli trwają co najmniej 50 milisekund, uniemożliwiają szybkie reagowanie w wątku głównym na dane wejściowe użytkownika.
Według Web Almanac jest wiele dowodów na to, że deweloperzy mogą robić więcej, aby unikać długich zadań lub je rozdzielać. Chociaż podział długich zadań może być mniej pracochłonny niż inne zalecenia w tym artykule, nie wymaga to większego wysiłku niż inne techniki opisane w tym artykule.
Choć powinieneś zawsze starać się robić jak najmniejszą ilość pracy w skrypcie JavaScript, możesz pomóc w znalezieniu głównego wątku, dzieląc długie zadania na mniejsze. Możesz to robić, często wycofując się z wątku głównego, aby aktualizacje renderowania i inne interakcje użytkowników mogły następować szybciej.
Możesz też skorzystać z interfejsów API takich jak isInputPending i Scheduler API. isInputPending to funkcja, która zwraca wartość logiczną wskazującą, czy użytkownik oczekuje na wprowadzenie danych wejściowych. Jeśli zwraca wartość true, możesz przejść do wątku głównego, aby mógł obsłużyć oczekujące dane wejściowe użytkownika.
Interfejs Scheduler API to bardziej zaawansowane podejście, które umożliwia planowanie pracy w oparciu o system priorytetów uwzględniających, czy praca jest widoczna dla użytkowników czy w tle.
Podział długich zadań daje przeglądarce więcej możliwości dostosowania się do ważnych zadań widocznych dla użytkowników, na przykład radzenia sobie z interakcjami i wynikającymi z nich aktualizacjami renderowania.
Unikanie zbędnego JavaScriptu
Nie ma co do tego wątpliwości: witryny przesyłają więcej kodu JavaScript niż kiedykolwiek wcześniej i prawdopodobnie nie zmienia się w najbliższym czasie. Gdy wysyłasz za dużo JavaScriptu, tworzysz środowisko, w którym zadania konkurują o uwagę głównego wątku. To z pewnością może wpłynąć na szybkość reagowania witryny, zwłaszcza w tym kluczowym okresie uruchamiania.
Nie jest to jednak problem nie do rozwiązania. Masz kilka możliwości:
- Użyj narzędzia do wykrywania danych w Narzędziach deweloperskich w Chrome, aby znaleźć nieużywany kod w zasobach witryny. Zmniejszając rozmiar zasobów niezbędnych do uruchomienia witryny, możesz skrócić czas potrzebny na analizowanie i kompilowanie kodu witryny, co usprawni jej działanie na początku.
- Czasami nieużywany kod wyświetlany w narzędziu do sprawdzania zasięgu jest oznaczony jako „nieużywany”, ponieważ nie został wykonany podczas uruchamiania, ale nadal jest niezbędny w przypadku niektórych funkcji. Jest to kod, który możesz przenieść do osobnego pakietu za pomocą podziału kodu.
- Jeśli korzystasz z menedżera tagów, pamiętaj, by okresowo sprawdzać swoje tagi, by mieć pewność, że są zoptymalizowane, a nawet czy nadal są używane. Starsze tagi z nieużywanym kodem możesz usunąć, by zmniejszyć kod JavaScript Menedżera tagów i zwiększyć jego wydajność.
Unikanie dużych aktualizacji renderowania
JavaScript nie jest jedynym działaniem, które może wpływać na responsywność witryny. Renderowanie może być samo w sobie rodzajem kosztownej pracy, a w przypadku dużych zmian w renderowaniu może zaburzać zdolność witryny do reagowania na dane wejściowe użytkownika.
Optymalizacja pracy renderowania nie jest prostym procesem i często zależy od tego, co chcesz osiągnąć. Jeśli jednak chcesz mieć pewność, że aktualizacje renderowania będą uzasadnione i nie będą się rozciągać na długie zadania:
- Nie używaj
requestAnimationFrame()do prac niewizualnych. WywołaniarequestAnimationFrame()są obsługiwane w fazie renderowania pętli zdarzeń, a jeśli wykonasz za dużo pracy, aktualizacje renderowania mogą być opóźnione. Ważne jest, aby wszystkie działania wykonywane w usłudzerequestAnimationFrame()były zarezerwowane wyłącznie do zadań związanych z renderowaniem. - Używaj małego rozmiaru DOM. Rozmiar DOM jest skorelowany z intensywnością pracy nad układem. Gdy mechanizm renderowania musi zaktualizować układ bardzo dużego DOM, nakład pracy potrzebny do ponownego obliczenia jego układu może się znacznie zwiększyć.
- Używaj blokady CSS. Ochrona arkusza CSS korzysta z właściwości CSS
contain, która przekazuje przeglądarce instrukcje dotyczące sposobu wyświetlania układu kontenera skonfigurowanego we właściwościcontain, w tym nawet wyizolowania zakresu układu i renderowania z konkretnym elementem głównym w DOM. Nie zawsze jest to łatwy proces, ale izolując obszary zawierające złożone układy, możesz uniknąć niepotrzebnych zadań związanych z układem i renderowaniem.
Podsumowanie
Poprawa wydajności strony może się wydawać trudnym zadaniem, zwłaszcza że w internecie jest mnóstwo wskazówek, które warto wziąć pod uwagę. Skupiając się na tych rekomendacjach, możesz jednak podejść do problemu z celem koncentracji i celem, a jeśli to konieczne, pomoże Ci w osiągnięciu podstawowych wskaźników internetowych witryny.
Wymienione tu zalecenia nie są wyczerpujące, ale na podstawie dokładnej analizy stanu internetu uważamy, że są one najskuteczniejszym sposobem zwiększania wydajności witryn w 2023 r. w zakresie podstawowych wskaźników internetowych.
Jeśli chcesz wyjść poza wymienione tutaj rekomendacje, więcej informacji znajdziesz w przewodnikach po optymalizacji:
Nadszedł nowy rok i szybszy internet dla wszystkich! Niech Twoje witryny będą szybko działać dla użytkowników pod każdym względem.
Fot. Devin Avery