Aktualizacja Google z maja 2021 r.: bliższe spojrzenie na Core Web Vitals

AKTUALIZACJA: Świat marketingu cyfrowego ciągle się zmienia, ale nie martw się, jesteśmy na topie. Google zmieniło zdanie na temat nadchodzącego algorytmu.

Przeczytaj najnowsze zmiany tutaj w naszej aktualizacji, ale zachęcam do lektury tego bloga.

W maju 2021 r. Google wprowadzi wskaźniki Core Web Vitals (CWV), które będą częścią algorytmu rankingu wyszukiwania. Oto, co musisz wiedzieć i zrobić przed tym…

Wszyscy wiemy, że szybkie strony są ważne. Zapewniają lepsze wrażenia użytkownika, co skutkuje zwiększonymi współczynnikami konwersji i już uwzględniają ranking wyszukiwania mobilnego w Google wraz z innymi wskaźnikami jakości strony, takimi jak przyjazność dla urządzeń mobilnych.

Ale Google nie poprzestaje na tym. W maju 2020 r. opowiedzieli nam o Core Web Vitals, a 10 listopada 2020 r. ogłosili, że w maju 2021 r. Core Web Vitals zostaną włączone jako sygnał wyszukiwania w ogólnym algorytmie rankingu.

Ponadto planują „przetestować wizualny wskaźnik, który wyróżnia strony w wynikach wyszukiwania, które mają świetną jakość strony”. Tak więc nie tylko mamy zwiększoną szansę na wyższe pozycje w rankingu dzięki optymalizacji CWV, ale także mamy perspektywę zwiększonych współczynników klikalności ze stron wyników wyszukiwania.

Podjęcie działań mających na celu przeprowadzenie audytu i naprawienie wszelkich potencjalnych problemów oznaczonych tymi nowymi danymi CWV da naszym witrynom większą szansę na wyższą pozycję w rankingu Google, gdy ta zmiana wejdzie w życie w 2021 r.

Ale najpierw podsumowanie…

Przypomnijmy: co to są podstawowe wskaźniki internetowe?

Podstawowe wskaźniki internetowe to zestaw 3 nowych wskaźników jakości strony, które wpływają na ogólne wyniki szybkości witryny. Te dane już teraz odgrywają znaczącą rolę w narzędziu Google PageSpeed ​​Insights PSI i monitorowaniu wydajności Lighthouse w innych miejscach.

Nowe metryki CWV obejmują:

Największa zawartość farby (LCP)

Jest to czas potrzebny do wyrenderowania największego elementu nad elementem zawinięcia. Stanowi 25% całego mechanizmu oceny szybkości i dlatego jest niezwykle ważne, aby usprawnić dostarczanie największego elementu do 2,5 sekundy lub mniej na urządzeniu mobilnym.

Wiele czynników wpływa na wysoki LCP, w tym czas reakcji serwera, skrypty i style blokujące renderowanie, złożoność CSS, czcionki i obrazy

Opóźnienie pierwszego wejścia (FID)

Mierzy to interaktywność; jak reaguje strona na dane wejściowe użytkownika, na przykład poprzez dotknięcia lub kliknięcia. Docelowa prędkość, z jaką przeglądarka odpowiada na pierwsze dane wejściowe, powinna wynosić 100 ms lub mniej.

Jeśli przeglądarka analizuje lub wykonuje dużo kodu JavaScript podczas ładowania strony, obciąży to procesor lub zablokuje „główny wątek”, powodując, że urządzenia będą mniej reagować na dane wejściowe. Wysoki FID jest zwykle wskaźnikiem złożonego JavaScript. Może to być pojedynczy skrypt, funkcja lub wiele skryptów.

Istniejące wskaźniki PSI dotyczące czasu do interakcji i całkowitego czasu blokowania są powiązane z FID i łącznie stanowią aż 35% ogólnych wyników szybkości.

Zbiorcza zmiana układu (CLS)

Jest to miara wizualnej stabilności zawartości strony widocznej na ekranie. Chociaż obejmuje tylko 5% ogólnych wyników szybkości, nadal warto wziąć pod uwagę ogólny obraz. Wysoki CLS może często wskazywać na jedną lub więcej zmian w układzie wizualnym podczas ładowania strony, na przykład, gdy ładowane są banery przesuwające zawartość strony w dół.

Podział wyniku szybkości

Poniższy diagram pokazuje podział ogólnego wyniku prędkości i jak dużą rolę odgrywają te nowe wskaźniki CWV w wynikach GPSI.

Dane źródłowe z aktualizacji wyniku Lighthouse

Podczas gdy metryki inne niż CWV również tworzą ogólny wynik, w tym First Content Paint (FCP), Time to Interactive (TTI) i Całkowity czas blokowania (TBT), skupienie się na trzech metrykach CWV będzie miało bezpośredni wpływ na pozostałe. Szybki LCP nie jest możliwy na przykład bez szybkiego FCP, a na wysokie wyniki FID mają bezpośredni wpływ TBT i TTI.

Wskazówki dotyczące optymalizacji największej zawartości treści

Wskaźnik LCP składa się z wielu indywidualnych czynników, na które ma bezpośredni wpływ wysoki FCP. Jeśli FCP jest oznaczony jako słaby, możesz zacząć tutaj. Wszystko, od łączności sieciowej, czasu reakcji serwera, czasu do pierwszego bajtu TTFB i plików blokujących renderowanie, wpływa na wartość FCP. Aby dokładniej zapoznać się z niektórymi z tych bardziej ogólnych zaleceń dotyczących szybkości strony, zapoznaj się z naszym e-bookiem dotyczącym szybkości strony na ten temat, a także z poniższymi wskazówkami dotyczącymi LCP.

Jeśli wartość LCP jest znacznie wyższa niż FCP, musimy przyjrzeć się, jak lepiej usprawnić wyświetlanie tego największego elementu.

Określ największy element

Pierwszą rzeczą, którą prawdopodobnie chciałbyś zrobić, to określić, jaki jest największy element. Największy element opiera się na obszarze pikseli, który może się zmieniać w różnych punktach przerwania, więc skanowanie wizualne niekoniecznie identyfikuje właściwy element.

W PSI powinien znajdować się panel „Największy element malowania treści” w sekcji Diagnostyka. Możesz też wyświetlić LCP, najeżdżając kursorem na wskaźnik w narzędziu do monitorowania wydajności przeglądarki Chrome, jak pokazano poniżej.

W witrynie Hallam w powyższym przykładzie Monitor wydajności pokazuje LCP jako główny nagłówek „Thrive Online”. Idealnie, LCP powinien natychmiast podążać za FCP, jak w tym przykładzie, a jeśli istnieje luka między nimi, musimy spróbować zrozumieć, dlaczego.

Czy czcionki są zoptymalizowane?

Jeśli największym elementem powyżej strony przewinięcia jest typografia, musimy zadbać o to, aby dostarczanie czcionek było jak najbardziej uproszczone. To zawiera:

1. Użyj wyświetlania czcionek CSS: swap; aby zapewnić natychmiastowe wyświetlanie czcionki podczas ładowania pliku czcionki. Zarówno Google Fonts, jak i Adobe Typekit mają możliwość ustawienia parametru wyświetlania czcionki.
2. Spróbuj lokalnie hostować pliki czcionek .woff i .woff2 na serwerze zamiast wysyłać żądania międzydomenowe do czcionek innych firm. Czcionki Google są dość szybkie, czcionki Typekit są wolniejsze, a niektóre zewnętrzne odlewnie czcionek mogą być mniej niezawodne.
3. Pomocne może być wstępne ładowanie plików czcionek. Czcionki hostowane lokalnie będą często zawarte w głównym arkuszu stylów witryny, ale ten arkusz stylów musi zostać pobrany i przeanalizowany przed wysłaniem dodatkowego żądania dotyczącego czcionki w nim zawartej. Wstępne ładowanie informuje przeglądarkę, aby zaczęła pobierać czcionkę wcześniej, bez czekania na przeanalizowanie kodu CSS.
4. Użyj funkcji preconnect i dns-prefetch dla zewnętrznych odlewni czcionek. Dyrektywy te pomogą ustanowić połączenia DNS, TLS i TCP między domenami stron trzecich przed wysłaniem żądania do czcionek.
5. Uwzględnij tylko pliki czcionek dla typografii wymagane dla nad składanym wyświetlaczem. Zasoby czcionek dla bibliotek ikon, takich jak Font Awesome, są notorycznie ciężkie, ale żądania do nich (i odpowiedniego CSS biblioteki ikon) można zwykle odroczyć i załadować po elemencie <head>.
6. Nie wysyłaj żądań międzydomenowych do plików czcionek w arkuszu stylów witryny głównej, ponieważ opiera się to na łączności i dodatkowym wyszukiwaniu domeny innej firmy.
7. Weź pod uwagę bezpieczne czcionki internetowe. Nie wymagają one żadnych próśb o pliki czcionek, chociaż mogą być bardzo ograniczone pod względem estetyki.

Czy obrazy są zoptymalizowane?

Dość często największy nad składanym elementem będzie obraz tak ważny, aby zapewnić jego optymalizację. Poniżej przedstawiono ogólnie dobrą praktykę, ale szczególnie ważne dla elementu LCP.

1. Użyj prawidłowego typu pliku obrazu. Obrazy JPG powinny być używane do zdjęć, SVG do grafiki wektorowej i ikon lub PNG do bardziej złożonych, niefotograficznych obrazów i jeśli wymagana jest przezroczystość.
2. Upewnij się, że obrazy JPG są zapisywane lub drukowane w jakości około 50-60%. Na tym poziomie nie powinno być dostrzegalnej utraty jakości. Upewnij się również, że obrazy zostały usunięte z metadanych.
3. Wtyczki lub usługi kompresji, takie jak tinypng.com, mogą automatycznie i zbiorczo optymalizować obrazy i usuwać niepotrzebne metadane.
4. Obrazy powinny być odpowiednio dopasowane do obszaru, w którym są wyświetlane. Nie wyświetlaj wysokiej jakości obrazu na pulpicie na urządzeniu mobilnym.
5. Obrazy powinny być generowane przy użyciu standardowego tagu <img> z atrybutem „srcset” dla elastycznych obrazów.
6. Pod obrazami po przewinięciu lub poza ekranem należy użyć atrybutu loading=”lazy”.
7. Użyj formatu plików graficznych nowej generacji .web, aby uzyskać jeszcze lepsze współczynniki kompresji. Może to z łatwością zaoszczędzić 30%, a w wielu przypadkach znacznie więcej.
8. Rozważ wstępne wczytanie największego obrazu znajdującego się w części strony widocznej na ekranie, aby szybciej rozpocząć pobieranie przed innymi, potencjalnie mniej krytycznymi treściami.

Zmniejsz pliki blokujące renderowanie

Każdy plik JavaScript lub CSS załadowany w elemencie <head></head> jest uważany za blokujący renderowanie, ponieważ te pliki należy pobrać przed rozpoczęciem renderowania strony. Może to mieć ogromny wpływ zarówno na metrykę FCP, jak i LCP. Pliki blokujące renderowanie w nagłówku powinny być używane tylko wtedy, gdy mają kluczowe znaczenie dla początkowego wyświetlania w części strony widocznej na ekranie.

Usuwanie wszelkich nieużywanych plików w <head>, ładowanie niekrytycznych plików w stopce lub łączenie wielu plików w mniej plików zmniejszy ilość zasobów blokujących renderowanie.

Nie używaj JavaScript do wyświetlania LCP

Przed CWV nie było to nic wielkiego. JavaScript jest często używany do animowania lub wyświetlania powyżej elementów przewinięcia, takich jak zanikający tekst lub karuzele bohaterów, często z niewielkim lub zerowym wpływem na wyniki szybkości.

Jeśli wyświetlanie największego elementu opiera się na JavaScript, może to często powodować duże opóźnienie, ponieważ JavaScript musi zostać pobrany, przeanalizowany i wykonany przed pojawieniem się elementu. Pliki JavaScript są zwykle (i całkiem słusznie) ładowane po elemencie <head>, więc nie są „blokujące renderowanie”, ale to oznacza, że ​​nadal mogą skutecznie blokować renderowanie LCP.

Spójrz na poniższy przykład (rozmyte logo i zmieniony nagłówek) pochodzi z witryny o wysokiej punktacji w PSI. LCP (główny tekst nagłówka) znajduje się kilka sekund dalej od FCP, co jest spowodowane wymaganiem JavaScript (reprezentowanego przez żółte paski) do pobrania, przeanalizowania i wykonania, zanim tekst będzie mógł zanikać.

Problemem może być również sam zanikający tekst, powodujący opóźnione wyświetlanie największego elementu.

Techniki JavaScript, takie jak ta, mogą natychmiast zmniejszyć ogólne wyniki szybkości o 25% i nie powinny być w żaden sposób wykorzystywane do utrudniania lub zapobiegania ładowaniu największego elementu.

Wykonywanie skryptów przy ładowaniu okna

JavaScript jest rzadko wymagany (i nie powinien być wymagany) do wyświetlania krytycznej zawartości powyżej części strony widocznej na ekranie, jednak częstym problemem, który widzimy, jest to, że funkcje mogą być uruchamiane, gdy tylko DOM jest gotowy. W popularnym frameworku jQuery odbywa się to poprzez zdarzenie „ready”. Menedżer tagów Google może również uruchamiać funkcje lub „tagi” na gotowość.

Rozważ wyzwolenie wszystkich skryptów JavaScript, które nie są wymagane do krytycznego wyświetlania treści w zdarzeniu ładowania okna, po załadowaniu zawartości strony głównej, aby zapobiec potencjalnym zakłóceniom w renderowaniu zawartości powyżej części widocznej na ekranie i elementu LCP.

Przełącz LCP

Bez względu na to, jak dobrze zoptymalizowany i usprawniony jest obraz, prawie zawsze pobranie i wyświetlenie zajmie więcej czasu niż element typograficzny. Chociaż uzyskanie szybkich wyników LCP dla obrazów jest całkowicie możliwe, czasami modyfikacja polegająca na zmniejszeniu największego elementu obrazu tak, aby był mniejszy niż największy element tekstowy, będzie oznaczać, że zamiast tego można użyć tekstu w LCP.

Może to mieć duży wpływ na wyniki, jeśli projekt na to pozwala, jak pokazano w poniższym przykładzie, w którym LCP został przełączony na element tekstowy.

Wskazówki dotyczące optymalizacji opóźnienia pierwszego wejścia

Jak wspomnieliśmy wcześniej, FID mierzy, w jakim stopniu strona reaguje na dane wprowadzane przez użytkownika. Łączy w sobie Time To Interactive TTI i Total Blocking Time TBT, które mogą stanowić do 35% ogólnych wyników szybkości.

Na te dane wpływają przede wszystkim skrypty analizujące i wykonywane podczas ładowania strony; blokowanie głównego wątku procesora i potencjalne wpływanie na szybkość reakcji urządzenia, szczególnie w przypadku słabszych smartfonów.

Należy zauważyć, że „Dane laboratoryjne” pokazane w PSI nie mierzą bezpośrednio FID. Wynika to z interaktywnego charakteru pomiaru z dotknięć lub kliknięć przez użytkownika, co jest trudne do symulacji. Zamiast tego są gromadzone przez „Dane terenowe”; pomiary zebrane od rzeczywistych użytkowników w ciągu 28 dni na podstawie raportu CrUX Chrome User Experience Report.

W związku z tym optymalizacja pod kątem FID jest nieco trudniejsza, ponieważ nie możemy niczego zmienić i czekać 28 dni na zebranie większej ilości danych. Dlatego powinniśmy użyć do tego metryk TTI i TBT w danych laboratoryjnych, ponieważ niskie czasy dla tych metryk będą korelować z niskim FID.

Jak więc mamy zoptymalizować te dane?

Sprawdź swój JavaScript

JavaScript może mieć różne kształty i rozmiary i często zdarza się, że pojedyncze osadzanie wideo, widżet czatu, skrypt ReCaptcha lub integracja HubSpot są jedyną przyczyną wysokich wskaźników FID, TTI i TBT.

Panele diagnostyczne w Page Speed ​​Insights to dobry początek. Sekcja „Minimalizuj pracę głównego wątku” poinformuje Cię, ile czasu wykonania zajmuje JavaScript, sekcja „Skróć czas wykonywania JavaScript” wskaże, które pliki mają wysokie czasy przetwarzania i wykonania oraz „Zmniejsz wpływ stron trzecich kod” podświetli i zgrupuje skrypty stron trzecich o dużym wpływie.

Poniższy zrzut ekranu pokazuje witrynę, która cierpi z powodu kilku ciężkich skryptów, z miernikiem czasu do interakcji wynoszącym 15 sekund. Wiele skryptów pochodzi od stron trzecich, w tym HubSpot i Vimeo.

Aby uzyskać głębszą analizę i wizualizację wpływu tych skryptów na ładowanie strony, narzędzie Monitor wydajności przeglądarki Chrome może być świetnym sposobem na zbadanie, jakie skrypty i funkcje są uruchamiane, jaki wpływ mają te skrypty oraz w którym momencie ładowania strony są one uruchamiane. są wykonywane długie skrypty.

Poniższy przykład pochodzi z tej samej witryny i pokazuje JavaScript reprezentowany przez żółte, różowe i pomarańczowe paski, przy czym dłuższe paski pokazują dłużej wykonywane zadania. Kiedy klikamy te dłuższe zadania, widzimy, że podświetlone skrypty są skorelowane z dużymi skryptami wyróżnionymi przez PSI powyżej.

Gdy mamy lepszy obraz tego, jakie skrypty wpływają na wydajność, istnieje kilka technik, których możemy użyć, aby zminimalizować ich wpływ, jak opisano poniżej.

Wczytaj skrypty asynchronicznie

JavaScript domyślnie będzie wykonywany po kolei. Jeśli istnieją jakieś skrypty, które nie są zależne od ładowania innych, skrypty te powinny być ładowane z atrybutem „async”, aby nie blokowały analizowania i wykonywania innych skryptów.

Warunkowo załaduj JavaScript

Częstym problemem, który widzimy w wielu witrynach, jest to, że ciężkie skrypty są ładowane globalnie lub na stronach, gdy nie są potrzebne. Jeśli potrzebujesz na przykład skorzystać z ReCaptcha, aby powstrzymać spam podczas przesyłania formularzy, pamiętaj, aby ładować skrypty tylko na stronach, które zawierają formularze.

Usprawnij pakiety JavaScript

Biblioteki JavaScript, takie jak jQuery UI lub Bootstrap, są często używane do dostarczania dodatkowych cech i funkcji JavaScript. Jeśli korzystasz z pakietu, upewnij się, że zawiera on tylko odpowiednie funkcje, aby uniknąć pobierania i analizowania niepotrzebnego kodu JavaScript.

Skrypty z leniwym ładowaniem w razie potrzeby

Nawet jeśli JavaScript jest ładowany tylko na stronach, na których jest potrzebny, sam skrypt niekoniecznie musi być analizowany i wykonywany podczas ładowania strony lub zdarzenia ładowania okna. Ładowanie JavaScriptu tylko wtedy, gdy jest rzeczywiście potrzebne, może mieć ogromne znaczenie dla wskaźników TTI, TBT i FID. Oto kilka przykładów:

1. Osadzone wideo, takie jak YouTube i Vimeo, mają zazwyczaj duży wpływ. Rozważ wczytanie tych skryptów tylko wtedy, gdy klikniesz miniaturę wideo.
2. Integracje formularzy innych firm, takie jak HubSpot, mogą być intensywne. Jeśli formularz pojawia się w trybie modalnym lub na dole strony, rozważ załadowanie lub wstrzyknięcie wymaganego skryptu podczas przewijania lub aktywacji modalnej zamiast ładowania strony.
3. Widżety czatu na żywo mogą wpływać na ogólne wyniki szybkości nawet o 35%. Rozważ przeniesienie widżetu czatu na żywo na dedykowaną stronę kontaktową z obsługą globalnego CTA „czatu na żywo” lub wstrzyknięcie skryptu czatu na żywo tylko po kliknięciu przycisku „Czat z nami”.
4. Dodanie atrybutu „loading=”lazy” do osadzonej zawartości opartej na iFrame może pomóc, ale jest to nowa funkcja przeglądarki i będzie wymagała przetestowania w zależności od użytego osadzania iFrame.

Oceń narzędzia Business Intelligence

Analiza zachowań użytkowników za pomocą narzędzi takich jak Hotjar lub oprogramowanie do testowania A/B, takie jak VWO, jest naprawdę ważna dla analizy biznesowej, a w wielu przypadkach korzyści z niej płynące przewyższą wpływ na szybkość witryny.

To powiedziawszy, nadal warto ocenić znaczenie uruchamiania tych narzędzi 24 godziny na dobę, 7 dni w tygodniu, w zależności od tego, jak często dane są analizowane. Testy A/B powinny być wyłączone, jeśli na przykład nie są uruchomione żadne aktywne testy, a narzędzia do analizy zachowania, takie jak Hotjar, mogą zostać dezaktywowane po zebraniu i przetworzeniu wystarczającej ilości danych.

Wskazówki dotyczące optymalizacji skumulowanego przesunięcia układu

Kumulatywne przesunięcie układu (CLS) może stanowić tylko 5% ogólnych wyników szybkości, ale nadal stanowi ważną część ogólnego obrazu, zwłaszcza że duża liczba elementów zmieniających się podczas ładowania strony może być irytującym doświadczeniem dla użytkownika.

Określ element CLS

Czasami może wydawać się oczywiste, który element lub elementy powodują zmianę treści, ale zawsze warto to sprawdzić za pomocą panelu Zmiany układu w PSI, jak pokazano poniżej.

Metryka CLS powinna być poniżej 0,1, ale w powyższym przykładzie jest przekroczona o ponad 400% i będzie kosztować 5% spadek wyników. Jeśli jest to problem globalny, to 5% na każdej stronie.

Przesuwające się elementy powinny być zidentyfikowane i uwzględnione w kolejności wpływu i mogą obejmować elementy powyżej i poniżej fałdy. Poniżej wymieniliśmy niektóre z najczęstszych przyczyn i rozwiązań przesunięcia układu.

Uważaj na animację

Często zdarza się, że niektóre techniki animacji są używane do zmiany sposobu prezentacji treści użytkownikowi, na przykład poprzez zanikanie lub przesuwanie obrazów, tekstu lub paneli treści podczas przewijania strony w dół. Chociaż mogą one być estetyczne (w zależności od tego, kogo zapytasz), ważne jest, aby te techniki nie przesuwały żadnej treści podczas ładowania strony.

Jeśli musisz ukryć, a następnie zanikać zawartość dla użytkownika, upewnij się, że rozmiar kontenera lub całkowita wysokość strony nie zmienia się w miarę ładowania zawartości. Zawartość może być ukryta (jeśli to konieczne) za pomocą reguł widoczności CSS zamiast wyświetlania: brak; co pozwoli zachować podstawową ilość miejsca, której potrzebuje.

Określ wymiary obrazu

Jeśli tag <img> nie ma ustawionych atrybutów szerokości i wysokości lub CSS nie jest używany do ustawiania wymiarów lub proporcji obrazu, przeglądarki będą musiały najpierw pobrać obraz, zanim będą w stanie określić obszar pikseli, którego potrzebuje display in. Może to spowodować przesunięcie dowolnej treści renderowanej pod obrazem podczas ładowania obrazu.

Określenie szerokości i wysokości obrazu lub ustawienie wymiarów lub proporcji obrazu (lub kontenera nadrzędnego) w CSS przed pobraniem obrazu zapewni, że przeglądarki będą znać obszar, w którym obraz ma być wyświetlany, i uniknąć potencjalnego układu Zmiana.

Banery

Reklamy, zakazy dotyczące plików cookie lub wszelkie inne informacje używane do wyświetlania ważnych informacji w banerze są prawdopodobnie jedną z najczęstszych przyczyn wysokiego CLS.

Często zdarza się, że treść banera jest ładowana z zewnętrznego źródła danych lub przez JavaScript z tej samej witryny, co oznacza, że ​​rozmiar kontenera banera może nie być możliwy do obliczenia, dopóki zawartość nie zostanie załadowana. W takim przypadku zawartość pod banerem zostanie przesunięta w dół po załadowaniu zawartości banera i wyświetleniu jej użytkownikowi.

Istnieje kilka rozwiązań tego problemu:

1. Ustaw minimalną wysokość banera lub kontenera banera w CSS, aby przeglądarka mogła efektywnie renderować symbol zastępczy. Chociaż może to być problematyczne, jeśli ilość treści jest dynamiczna i nieznana.
2. Absolutnie lub popraw pozycję banera na górze lub na dole ekranu. W przypadku banerów, które można zamknąć lub odrzucić, jest to dobry pomysł, ponieważ stałe elementy nie wpływają na pozycjonowanie innych elementów.
3. Jeśli to możliwe, przyjrzyj się renderowaniu treści baneru po stronie serwera, co oznacza, że ​​treść i wymiary banera można załadować z góry, zanim dotrą do użytkownika.

streszczenie

Mamy nadzieję, że niektóre z wyżej wymienionych technik będą przydatne w diagnozowaniu i rozwiązywaniu problemów z wydajnością związanych z nowymi Core Web Vitals firmy Google. W ciągu ostatnich kilku miesięcy w Hallam pomogliśmy wielu klientom poprawić wydajność ich witryny, zarówno pod względem naszych audytów prędkości, jak i bezpośrednich ulepszeń wprowadzanych przez nasz zespół programistów.

Jeśli uważasz, że ten artykuł był pomocny, możesz również zapoznać się z naszym e-bookiem dotyczącym wydajności witryny, który zawiera bardziej ogólne zalecenia dotyczące szybkości strony, z których może skorzystać każdy, kto tworzy witrynę lub zarządza nią.