Kompletny przewodnik po Core Web Vitals z opisami problemów oraz wskazówkami ich optymalizacji, dzięki którym sam wykonasz audyt Core Web Vitals.
Przeprowadzenie audytu Core Web Vitals podzieliłem na 3 rozdziały dotyczące:
- Largest Contentful Paint (LCP),
- First Input Delay (FID),
- Cumulative Layout Shift (CLS).
W każdym rozdziale znajdziesz po kilkanaście punktów, w których opisuję, jak poszczególne elementy mogą wpłynąć na podstawowe wskaźniki internetowe (Core Web Vitals) oraz umieszczam wskazówki jak rozwiązać dany problem.
Narzędzia do audytu Core Web Vitals
Przed rozpoczęciem optymalizacji podstawowych wskaźników internetowych (Core Web Vitals) powinieneś rozpocząć od przeprowadzenia testów na swojej stronie za pomocą dostępnych narzędzi.
Narzędzia do mierzenia danych rzeczywistych (field data)
Poniżej znajdziesz listę narzędzi do mierzenia rzeczywistych danych (field data), które Ci się przydadzą podczas audytu Core Web Vitals. Rzeczywiste dane zebrane przez Google bazują na aktualnym doświadczeniu użytkowników z ostatnich 28 dni, więc są bardziej dokładne od tych, które zobaczysz w narzędziach laboratoryjnych.
- Google PageSpeed Insights – Podstawowe narzędzie do analizy Core Web Vitals dla każdej ze stron Twojej witryny.
- Google Search Console raport Podstawowe Wskaźniki Internetowe – Raport do zbiorczej analizy Core Web Vitals dostępny w Google Search Console
- Chrome User Experience Report
- biblioteka JavaScript web-vitals – Dla deweloperów, którzy chcą mierzyć Core Web Vitals za pomocą swoich aplikacji.
Narzędzia do mierzenia danych laboratoryjnych (lab data)
Narzędzia laboratoryjne udostępniają dane laboratoryjne pochodzące z pomiarów wykonanych za pomocą specjalistycznych narzędzi. Danych laboratoryjnych możesz użyć do sprawdzenia różnych implementacji elementów budowy witryny, by zweryfikować czy wykonana optymalizacja działa i czy może poprawić wskaźniki Core Web Vitals.
Warto pamiętać, że dane laboratoryjne są po prostu bardziej wyobrażeniem jak powinna działać konkretna witryna niż faktycznymi danymi, które odnajdziesz wyłącznie w narzędziach do mierzenia danych rzeczywistych (field data).
Audyt Core Web Vitals
Poniżej znajdziesz kilkadziesiąt podpunktów zawierających potencjalne przyczyny problemów skutkujących niską oceną w testach Core Web Vitals. Warto krok po kroku przejrzeć wszystkie punkty audytu Core Web Vitals, by określić przyczyny a następnie rozwiązać problemy ze stroną.
Wdrożenie wielu z poniższych zaleceń może wymagać wiedzy programistycznej. W związku z tym rekomenduję byś przeprowadził audyt podstawowych wskaźników internetowych, stworzył listę problemów wraz z zalecanymi rozwiązaniami, a następnie skonsultował ich implementację ze swoim web developerem.
LARGEST CONTENTFUL PAINT (LCP)
Largest Contentful Paint (LCP) mierzy postrzeganą szybkość wczytywania strony internetowej. Wartość LCP jest określana na podstawie szybkości ładowania największego bloku tekstowego lub elementu graficznego wewnątrz widocznego fragmentu strony tzw. above-the-fold.
Więcej informacji o Largest Contentful Paint.
Strona zapewniająca dobre doświadczenie dla użytkowników posiada LCP równe lub niższe niż 2,5 sekundy.
Narzędzia do mierzenia danych rzeczywistych, którymi sprawdzisz LCP:
Narzędzia do mierzenia danych laboratoryjnych, którymi sprawdzisz LCP:
Do przeprowadzenie poniższego audytu polecam skorzystać szczególnie z narzędzi PageSpeed Insights oraz raportu “Podstawowe Wskaźniki Internetowe” w Google Search Console, by analizować rzeczywiste dane dotyczące Largest Contentful Paint (LCP).
1. Optymalizacja serwera
Brak optymalizacji i przeciążony serwer może zwiększyć czas potrzebny do pobrania danych strony internetowej.
Wszelkie skomplikowane zapytania, złożone operacje potrzebują dużej ilości czasu aby zostały wykonane co wpływa na czas odpowiedzi serwera a następnie na wskaźniki Core Web Vitals. Powolna odpowiedź serwera praktycznie zawsze wpływa na niską wartość wskaźnika LCP.
Wskazówki optymalizacji:
- Przeprowadź test strony za pomocą PageSpeed Insights. Narzędzie wskaże Ci czy występują problemy z powolnym czasem reakcji serwera. Jeśli błędy występują przejdź do dalszych kroków.
- Wiele dostawców hostingów pozwala na wdrożenie podstawowej optymalizacji serwera. Sprawdź, czy Twój dostawca serwera to umożliwia lub przejrzyj, co w tym aspekcie oferują konkurencyjni dostawcy serwerów.
- Jeśli jest to możliwe, zmień na serwerze wersję PHP na najnowszą.
- Więcej szczegółowych informacji jak rozwiązać problem z przeciążonym serwerem znajdziesz na stronie “Fix an overloaded server”.
2. Wykorzystanie CDN
Strony wykorzystujące CDN będą wczytywać się szybciej, gdyż użytkownicy nie muszą czekać tak długo na odpowiedzi serwera, który często znajduje się bardzo daleko od ich fizycznej lokalizacji. W przypadku CDN wykorzystywany jest serwer, który jest najbliżej danego użytkownika.
Wskazówki optymalizacji:
- Sprawdź, czy strona używa CDN np. za pomocą narzędzia CDN Finder
- Jeśli strona nie używa CDN, rozważ jego wdrożenie. Najbardziej popularnym jest Cloudflare (dostępna jest nawet bezpłatna wersja).
3. Pamięć podręczna (cache)
Efektywne stosowanie pamięci podręcznej (cache) ma bardzo duży wpływ na wydajność i szybkość a zarazem na wartość wskaźnika Largest Contentful Paint (LCP).
Jeśli strona jest statyczna, nie ma potrzeby żeby jej kod był od nowa generowany z każdym żądaniem wysłanym do serwera. Stosowanie pamięci podręcznej ma znaczący wpływ na redukcję wskaźnika TTFB i minimalizację używania zasobów.
Wskazówki optymalizacji:
- Za pomocą narzędzia Google PageSpeed Insights sprawdź, czy zasoby w Twojej witrynie są przechowywane w pamięci podręcznej (cache).
- Narzędzie wskaże Ci listę zasobów, które nie są przechowywane w pamięci podręcznej lub nie używają efektywnego sposobu cachowania.
- Zacznij przechowywać statyczne zasoby w pamięci podręcznej. W tym celu wykorzystaj jeden z wielu sposobów:
- Skonfiguruj Varnish Cache lub NGINX Content Caching
- Skonfiguruj cache u swojego dostawcy jak Azure czy AWS
- Wykorzystaj CDN (np. bezpłatny Cloudflare).
4. Wykorzystanie Service Worker
Znaczącą poprawę wskaźnika Largest Contentful Paint (LCP) możesz uzyskać jeśli skorzystasz z Service Workera, który działa w tle w zupełnie oddzielnym wątku od kodu naszej witryny.
Service Workera możesz użyć do serwowania użytkownikom wersji strony z pamięci podręcznej zamiast za każdym razem generować kod HTML.
Wskazówki optymalizacji:
- Sprawdź, czy witryna już używa Service Workera za pomocą wtyczki do Chrome Service Worker Detector
- Jeśli Service Worker nie jest używany, rozważ jego wdrożenie przez swojego web developera.
- Przydatne mogą być narzędzia od Google do wykorzystania Service Workera do generowania pamięci podręcznej (cache): sw-precache oraz sw-toolbox.
5. Połączenia z zewnętrznymi źródłami
Istotną kwestią dla poprawy wskaźnika LCP jest możliwie jak najszybsze ustanowienie połączeń z zewnętrznymi źródłami szczególnie jeśli te są wykorzystywane do wyświetlania krytycznej zawartości strony. W tym celu użyj komend rel="preconnect"
lub rel="dns-prefetch"
.
Wskazówki optymalizacji:
- Wykonaj test za pomocą narzędzia Google PageSpeed Insights, by sprawdzić czy połączenia z zewnętrznymi źródłami są ustanawiane odpowiednio wcześnie.
- Jeśli w witrynie nie są stosowane komendy
rel="preconnect"
lubrel="dns-prefetch"
ten punkt audytu zostanie wymieniony w rozdziale “Możliwości”.
- Do ładowania zewnętrznych źródeł w większości przypadków zalecanym rozwiązaniem będzie użycie
rel="preconnect"
. W przypadku przeglądarek, którego go nie wspierają użyjrel="dns-prefetch".
6. Minifikacja CSS
Arkusze stylów i skrypty są zasobami, które często mają negatywny wpływ zarówno na wartość wskaźnika First Input Delay (FID), jak i Largest Contentful Paint (LCP). Minifikacja plików CSS jest jednym ze sposobów na zredukowanie ładunków sieciowych.
Wskazówki optymalizacji:
- Przeprowadź test za pomocą Google PageSpeed Insights, żeby sprawdzić czy pliki CSS są minifikowane.
- Jeśli minifikacja CSS nie jest stosowana, wykorzystaj jeden z wielu dostępnych pluginów np.:
- optimize-css-assets-webpack-plugin
- gulp-clean-css
- rollup-plugin-css-porter
- WP Rocket (wtyczka do WordPress).
7. Opóźnienie ładowania CSS
Kolejnym ze sposobów optymalizacji dostarczania CSS jest opóźnienie tych stylów, które nie są krytyczne dla naszej witryny. Opóźnienie ładowania stylów CSS, które nie są używane w widocznej części strony na ekranie bez przewijania zmniejszy ładunek sieciowy witryny.
Wskazówki optymalizacji:
- Sprawdź w Chrome DevTools w zakładce “Coverage”, które z plików CSS nie są krytyczne dla strony.
- Wykonując test narzędziem Google PageSpeed Insights otrzymasz także listę plików, których ładowanie powinno zostać opóźnione.
- Zalecane jest również usunięcie plików, które nie są używane w witrynie.
- W przypadku jeśli arkusz stylów CSS nie jest wymagany do wstępnego renderowania zalecane jest asynchroniczne ładowanie plików z wykorzystaniem loadCSS.
<link rel="preload" href="stylesheet.css" as="style" onload="this.rel='stylesheet'">
8. Osadzenie styli inline
Poprzez umieszczenie krytycznych stylów CSS w kodzie strony metodą inline możliwe jest polepszenie wskaźnika Largest Contentful Paint (LCP).
Wszystkie krytyczne style CSS wykorzystywane w sekcji above-the-fold powinny zostać dodane metodą inline bezpośrednio w sekcji <head>
.
Wskazówki optymalizacji:
- Wykonaj test narzędziem Google PageSpeed Insights i sprawdź, czy krytyczne style CSS zostały umieszczone inline.
- Jeśli style te nie zostały dodane poprzez inline zrób to wykorzystując jedną z metod:
- Ręcznie dodaj style do strony.
- Użyj jednej z bibliotek, które automatyzują proces np. Critical, CriticalCSS lub Penthouse.
- Wykorzystaj wtyczkę do WordPressa WP Rocket.
9. Minifikacja JavaScript
Zmniejszając ilość i objętość skryptów JavaScript znacząco możesz poprawić wskaźnik LCP strony. Celem minifikacji JavaScript jest stworzenie mniejszego objętościowo lecz w dalszym ciągu funkcjonalnego pliku poprzez usunięcie zbędnego kodu czy odstępów.
Wskazówki optymalizacji:
- Przeprowadź test narzędziem Google PageSpeed Insights, zweryfikuj czy skrypty JavaScript na stronie są już zminifikowane.
- Jeśli minifikacja JavaScript nie została zrobiona użyj jednego z narzędzi i bibliotek:
10. Opóźnienie ładowania JavaScript
Im strona używa mniej JavaScript, tym mniej czasu przeglądarka będzie potrzebowała do jego wykonania, a w związku z tym będzie szybciej gotowa na interakcję użytkownika.
Poprzez redukcję nieużywanych plików JavaScript możesz poprawić jednocześnie wskaźniki LCP oraz FID. Zalecaną praktyką jest wczytywanie jedynie tych plików, które są niezbędne do działania strony.
Wskazówki optymalizacji:
- Wykonaj test strony za pomocą Google PageSpeed Insights lub Chrome DevTools i sprawdź, czy na stronie ładowane są nieużywane pliki JavaScript
- Opóźnij ładowanie wszystkich plików JavaScript, które nie są krytyczne dla działania strony poprzez wykorzystanie funkcji
async
lubdefer
. - Wszelkie pliki JavaScript pochodzące z zewnętrznych źródeł także powinny zostać opóźnione poprzez
async
lubdefer
.<script defer src="…"></script>
<script async src="…"></script>
11. Obsługa JavaScript przez nowoczesne przeglądarki
W celu poprawnego działania plików JavaScript przez starsze przeglądarki mogą być wykorzystywane elementy polyfill lub przekształcenia, co może przekładać się na obniżenie wartości wskaźnika LCP.
Nowe przeglądarki internetowe z kolei nie potrzebują do działania JavaScript elementów polyfill w związku z czym warto rozważyć optymalizację skryptów także pod tym kątem.
Wskazówki optymalizacji:
- W przypadku stron używających transpilatora Babel użyj @babel/preset-env by zoptymalizować wykorzystanie elementów polyfill dla konkretnych przeglądarek.
- Użyj funkcji
<script type="module">
by zablokować wysyłanie transpilowanego kodu do przeglądarek, które go nie potrzebują. - Stwórz dwa osobne zestawy skryptów opartych na wykrywaniu atrybutów „module” i „nomodule”.
- Zobacz więcej informacji odnośnie optymalizacji nieużywanych elementów polyfill.
12. Optymalizacja i kompresja obrazów
Czas niezbędny na załadowanie obrazów również ma wpływ na wartość wskaźnika Largest Contentful Paint (LCP). Najlepszą praktyką, by poprawić czas wczytywania obrazów jest ich optymalizacja oraz kompresja.
Wskazówki optymalizacji:
- Po przeprowadzeniu testu z użyciem Google PageSpeed Insights otrzymasz listę zasobów, które wymagają optymalizacji.
- Sprawdź, czy jakiś obraz jest największym elementem w obszarze viewport po załadowaniu strony. Przykładem takiego obrazu może być baner lub slider.
- Sposoby na poprawę szybkości wczytywanie obrazów to m.in.:
- Unikanie stosowania obrazów jako główny element w obszarze viewport.
- Kompresja obrazów np. za pomocą Tiny JPG.
- Używanie responsywnych obrazów.
- Konwersja obrazów na nowe formaty jak JPEG 2000, JPEG XR lub WebP.
- W przypadku WordPressa przetestuj wtyczki takie jak WP Rocket oraz Imagify.
13. Wstępne ładowanie zasobów
Wstępne ładowanie zasobów, które są potrzebne na dalszym etapie ładowania strony, by te pobierały się szybciej, może znacząco wpłynąć na polepszenie wskaźnika LCP.
Ważne jest by wstępnie załadować wszelkie krytyczne dla działania strony zasoby takie jak pliki JavaScript, arkusze stylów CSS czy obrazy, które znajdą się w obszarze above-the-fold.
Wskazówki optymalizacji:
- Wykonaj test za pomocą Google PageSpeed Insights, który wskaże zasoby, które warto wstępnie załadować.
- Jeśli dany zasób nie jest wstępnie ładowany użyj funkcji
<link rel="preload">
. - W przypadku WordPressa możesz skorzystać z wtyczki WP Rocket.
14. Kompresja tekstu
Kompresja zasobów plików tekstowych może poprawić czas ładowania strony i przez to polepszyć wartość wskaźnika Largest Contentful Paint.
Waga plików tekstowych z kodem HTML, JavaScript czy CSS może być znacząco zredukowana dzięki wykorzystaniu algorytmów kompresji takich jak Gzip czy Brotli.
Wskazówki optymalizacji:
- Przeprowadź test strony narzędziem Google PageSpeed Insights i sprawdź, czy pliki tekstowe na serwerze zostały skompresowane. Wiele oferowanych na rynku serwerów ma domyślnie włączoną kompresję plików.
- Jeśli jednak kompresja tekstu jest wyłączona, spróbuj samemu lub poprzez administrację serwera włączyć kompresję Gzip lub Brotli.
- Warto wiedzieć, że kompresja Gzip jest wspierana przez wszystkie dostępne przeglądarki lecz jest mniej wydajna od kompresji Brotli, która to jest wspierana przez praktycznie większość nowych przeglądarek internetowych.
- Zasoby powinny być kompresowane z wyprzedzeniem, nie w trakcie dostępu do nich przez użytkownika.
15. Warunkowe ładowanie zasobów
Wskaźnik LCP możesz także poprawić poprzez warunkowe pobieranie zasobów w zależności od szybkości łącza internetowego oraz urządzenia użytkownika.
Jeśli witryna posiada duże zasoby, które są krytyczne do renderowania dobrym rozwiązaniem jest udostępnianie różnych wersji zasobów w zależności od szybkości połączenia internetowego i urządzenia użytkownika.
Wskazówki optymalizacji:
- Jeśli strona nie posiada wdrożonego warunkowego udostępniania zasobów, rozważ skorzystanie z poniższych API:
- Przykładowo możesz wyświetlać obraz zamiast wideo dla użytkowników, którzy posiadają połączenie wolniejsze niż 4G.
if (navigator.connection && navigator.connection.effectiveType) {
if (navigator.connection.effectiveType === '4g') {
// Load video
} else {
// Load image
}
}
Więcej informacji znajdziesz na stronie Adaptive serving based on network quality.
16. Minifikacja krytycznego JavaScript
Renderowanie JavaScript głównie po stronie klienta może mieć negatywny wpływ na wyniki osiągane przez wskaźnik Largest Contentful Paint (szczególnie, gdy używane są duże pliki JavaScript).
Jeśli pliki JavaScript nie są zoptymalizowane, użytkownicy mogą nie być w stanie wejść w żadną interakcję ze stroną dopóki cały krytyczny kod JavaScript nie zostanie wykonany.
Najprostszym sposobem optymalizacji stron, które są renderowane po stronie klienta jest minimalizacja ilości używanego JavaScriptu.
Wskazówki optymalizacji:
- Wykonaj test za pomocą Google PageSpeed Insights i sprawdź, czy pliki JavaScript są zoptymalizowane. Jeśli nie, zobaczysz listę plików z potencjalnymi oszczędnościami po ich optymalizacji.
- Wykonaj optymalizację plików wedle wskazówek z punktów:
- 9. Minifikacja JavaScript
- 10. Opóźnienie JavaScript
- 11. Obsługa JavaScript przez nowoczesne przeglądarki
17. Zastosowanie Server Side Rendering
Stosowanie Server Side Rendering może być pomocne w osiągnięciu wyższej oceny wskaźnika Largest Contentful Paint (LCP).
Server Side Rendering działa w taki sposób, że zawartość strony jest renderowana po stronie serwera a nie po stronie klienta. Może to znacząco poprawić wskaźnik LCP, lecz z drugiej strony może zwiększyć czas odpowiedzi serwera i pogorszyć wskaźniki TTFB (Time to First Byte) oraz TTI (Time to Interactive).
Wskazówki optymalizacji:
- Jeśli do zbudowania strony użyto duże ilości JavaScript, rozważ wdrożenie renderowania strony po stronie serwera a nie klienta (Server Side Rendering).
- Pamiętaj, że osobą, która zadecyduje, czy na pewno i w jaki sposób wdrożyć Server Side Rendering powinien być webdeveloper.
- Przeczytaj więcej na temat renderowania na stronie Google.
18. Zastosowanie pre-renderowania
Pre-renderowanie jest kolejnym ze sposobów na poprawienie wskaźnika Largest Contentful Paint.
Pre-renderowanie nie działa tak kompleksowo, jak zastosowanie Server Side Rendering lecz również może poprawić LCP. Podobnie jak Server Side Rendering ,tak i pre-renderowanie negatywnie wpływa na Time to Interactive (TTI), lecz nie zwiększa aż tak czasu odpowiedzi serwera jak całkowite renderowanie witryny po stronie serwera.
Wskazówki optymalizacji:
- Rozważ wdrożenie pre-renderowania strony jeśli do jej stworzenia użyto dużej ilości JavaScript.
- Ustal z webdeveloperem co wdrożyć pre-renderowanie czy Server Side Rendering.
FIRST INPUT DELAY (FID)
First Input Delay (FID) mierzy czas, po którym użytkownik może rozpocząć interakcję ze stroną. W przypadku tego wskaźnika sprawdzany jest czas opóźnienia jaki ma przeglądarka odpowiadając na akcję użytkownika.
Więcej informacji o First Input Delay.
Strona zapewniająca dobre doświadczenie dla użytkowników posiada FID równe lub niższe niż 100 milisekund.
Wskaźnik First Input Delay bazuje na danych rzeczywistych więc narzędzia laboratoryjne w tym wypadku bazują zastępczo na wskaźnikach Total Blocking Time (TBT), który jest najbliższy FID. Ewentualnie brany pod uwagę może być także wskaźnik Time to Interactive (TTI), który również jest powiązany ze wskaźnikiem FID.
Narzędzia do mierzenia danych rzeczywistych, którymi sprawdzisz FID:
Narzędzia do mierzenia danych laboratoryjnych, którymi sprawdzisz wskaźniki powiązane z FID takie jak TTB oraz TTI:
Do przeprowadzenie poniższego audytu polecam skorzystać szczególnie z narzędzi PageSpeed Insights oraz raportu “Podstawowe Wskaźniki Internetowe” w Google Search Console, gdzie sprawdzisz rzeczywiste dane dotyczące First Input Delay (FID).
19. Podział długich zadań JavaScript
Znaczący wpływ na polepszenie wskaźnika First Input Delay (FID) może mieć podział długo wykonywanych zadań JavaScript na mniejsze zadania wykonywane asynchronicznie.
Długie zadania wykonywane przez JavaScript mogą blokować główny wątek nawet na ponad 50 ms. Podczas wykonywania takiego JavaScriptu użytkownik może nie mieć możliwości interakcji ze stroną.
Najlepszym sposobem, by polepszyć First Input Delay (FID) jest właśnie podział długich zadań wykonywanych za pomocą JavaScript na mniejsze.
Wskazówki optymalizacji:
- Przeprowadź test za pomocą Google PageSpeed Insights i sprawdź, czy są możliwości optymalizacji plików JavaScript.
- Za pomocą Chrome DevTools w zakładce “Performance” zweryfikuj, czy na stronie są wykonywane długie zadania JavaScript. Wszystkie długo wykonywane zadania JavaScript będą oznaczone na czerwono.
- Do weryfikacji długo wykonywanych zadań JavaScript możesz wykorzystać także Lighthouse.
- Przeprowadź analizę długo wykonywanych zadań JavaScript, a następnie poproś web developera o ich podział na mniejsze zadania.
- Przeczytaj więcej o długo wykonywanych zadaniach JavaScript na stronie Web.dev.
20. Wykonywanie własnych skryptów
Nieefektywne wykonywanie własnych skryptów również będzie miało wpływ na czas gotowości do interakcji strony, a w efekcie wskaźniki FID, TBT oraz TTI.
Głównymi przyczynami opóźnień gotowości do interakcji strony są przeładowanie JavaScript, jego długie czasy wykonywania czy też niewłaściwy podział plików na mniejsze.
Wskazówki optymalizacji:
- Wykonaj test strony za pomocą narzędzia Google PageSpeed Insights lub Lighthouse i sprawdź wskaźniki gotowości strony do interakcji First Input Delay (FID), Total Blocking Time (TBT) oraz Time to Interactive (TTI).
- Do weryfikacji wskaźników możesz także użyć Chrome DevTools.
- Zalecanymi sposobami poprawy wskaźników są:
- Progresywne ładowanie kodu.
- Wdrożenie Server Side Rendering lub pre-renderowania.
- Usunięcie wszelkich nieistotnych skryptów z krytycznej ścieżki renderowania.
21. Zasoby blokujące renderowanie
Pobieranie danych strony również ma wpływ na wiele aspektów gotowości strony do interakcji.
Zazwyczaj problemy tego typu występują w witrynach, które opierają się na kaskadowym pobieraniu danych i duża część skryptów wykonywana jest po stronie klienta.
Wskazówki optymalizacji:
- W zależności od wyników uzyskanych przez wskaźniki FID, TTI oraz TBT, które wskazuje narzędzie Google PageSpeed Insights, rozważ przeprowadzenie optymalizacji pobierania danych JavaScript i CSS.
- Optymalizacja JavaScript w tym przypadku polega na:
- Minimalizacji kaskadowego ładowania danych.
- Minimalizacji ilości JavaScript wykonywanego po stronie klienta.
- Wszystkie sposoby optymalizacji wspomniane w poprzednich punktach audytu.
22. Wpływ kodu spoza witryny
Kod spoza witryny (szczególnie jeśli jest go dużo) może mieć negatywny wpływ na gotowość strony do interakcji.
Kod od zewnętrznych dostawców, który jest wczytywany na stronie może dodatkowo zajmować główny wątek przez co strona przez dłuższy czas nie będzie interaktywna dla użytkowników.
Wskazówki optymalizacji:
- Przeprowadź test z użyciem Google PageSpeed Insights i przeanalizuj, czy zewnętrzne skrypty mają negatywny wpływ na wskaźniki FID, TTB oraz TTI.
- Sprawdź w głównym wątku, czy zewnętrzne skrypty są wykonywane przed Twoimi własnymi skryptami. Weryfikację możesz wykonać za pomocą Chrome DevTools w zakładce “Network”.
- Rozważ wykonanie poniższych czynności:
- Ładowanie skryptów reklam below-the-fold po przewinięciu strony bliżej widocznego obszaru.
- Zmianę priorytetów ładowania skryptów.
- Wszelkie decyzje odnośnie optymalizacji skonsultuj z web developerem.
23. Zastosowanie Web Worker
Dzięki użyciu Web Workerów, kod JavaScript może być uruchomiony poza głównym wątkiem (w tle), co zmniejsza jego blokowanie przez skrypty, w efekcie czego może to przyczynić się do poprawy FID.
Wskazówki optymalizacji:
- Wykonaj test strony za pomocą Google PageSpeed Insights, Lighthouse oraz Chrome DevTools, by zweryfikować czy główny wątek jest blokowany i przez co.
- W zależności od typu strony zalecane jest użycie jednego z Web Workerów:
24. Opóźnienie JavaScript
Jednym z najlepszych sposobów na zmniejszenie ilości wykonywanego na stronie JavaScript jest opóźnienie lub całkowite usunięcie nieużywanych skryptów.
Poprzez opóźnienie wykonania nieużywanych na danej stronie skryptów JavaScript możesz polepszyć zarówno wskaźnik Largest Contentful Paint oraz First Input Delay.
Wskazówki optymalizacji znajdziesz w punkcie 10 audytu Core Web Vitals
25. Obsługa JavaScript przez nowoczesne przeglądarki
Dobrym rozwiązaniem, by zmniejszyć czas wykonywania skryptów JavaScript jest minimalizacja używanych elementów polyfill.
Dzięki minimalizacji wykorzystania elementów polyfill możesz polepszyć jednocześnie Largest Contentful Paint (LCP) oraz First Input Delay (FID).
Wskazówki optymalizacji znajdziesz w punkcie 11 audytu Core Web Vitals
CUMULATIVE LAYOUT SHIFT (CLS)
Cumulative Layout Shift (CLS) mierzy ilość i wielkość przesunięć elementów strony podczas jej wczytywania i wyświetlania.
Więcej informacji o Cumulative Layout Shift.
Strona zapewniająca dobre doświadczenie dla użytkowników posiada CLS równe lub niższe niż 0,1.
Narzędzia do mierzenia danych rzeczywistych, którymi sprawdzisz LCP:
Narzędzia do mierzenia danych laboratoryjnych, którymi sprawdzisz LCP:
Do przeprowadzenie poniższego audytu polecam skorzystać szczególnie z narzędzi PageSpeed Insights oraz raportu “Podstawowe Wskaźniki Internetowe” w Google Search Console by analizować rzeczywiste dane dotyczące Cumulative Layout Shift (CLS).
26. Szerokość i wysokość elementów graficznych
Znajdujące się na stronie obrazy oraz wideo bez określonych atrybutów szerokości i wysokości mogą powodować przesunięcie układu a w następstwie tego pogorszenie wskaźnika Cumulative Layout Shit (CLS).
W celu uniknięcia przesunięć układu strony rekomendowane jest zawsze wyraźne określanie szerokości i wysokości obrazów i wideo. Drugim z dostępnych rozwiązań jest używanie współczynnika proporcji CSS (aspect-ratio CSS) do określenia niezbędnej przestrzeni jaką będzie zajmować obraz lub wideo.
Wskazówki optymalizacji:
- Wykonaj test strony za pomocą Google PageSpeed Insights lub Lightouse i sprawdź, dla jakich obrazów zalecane jest zarezerwowanie określonych rozmiarów przestrzeni na obraz lub wideo.
- Dodaj do obrazów lub wideo atrybuty szerokości i wysokości jak na poniższym przykładzie:
<!-- set a 640:360 i.e a 16:9 - aspect ratio -->
<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons" />
- Wszystkie nowoczesne przeglądarki domyślnie ustawią współczynnik proporcji obrazów na podstawie określonych rozmiarów co zapobiegnie przesunięciom układu.
- W przypadku WordPressa optymalizację możesz wykonać za pomocą jednej z wtyczek np. WP Rocket.
27. Lokalizacja reklam na stronie
Wszelkiego rodzaju reklamy bardzo często powodują przesunięcia układu strony. Powszechną przyczyną jest sytuacja, gdy kontener z reklamą jest dodawany do struktury DOM, a następnie zwiększany jest jego rozmiar.
Dobrym rozwiązaniem jest unikanie przesunięcia układu poprzez określenie miejsca pod boks reklamowy.
Wskazówki optymalizacji:
- Zrób test za pomocą Google PageSpeed Insights i sprawdź wynik wskaźnika CLS.
- Jeśli to jest możliwe, przeprowadź analizę danych rzeczywistych znajdującą się w raporcie “Podstawowe Wskaźniki Internetowe” w Google Search Console.
- Spróbuj także sprawdzić CLS za pomocą Chrome DevTools, Lighthouse lub WebPageTest przy różnych rozdzielczościach.
- Zweryfikuj czy problem z wynikiem wskaźnika CLS może dotyczyć reklam na stronie. Jeśli tak, rozważ wykonanie czynności:
- Określ przestrzeń na reklamę na stronie poprzez ostylowanie elementu zanim zostanie wczytana dana reklama.
- Reklamy ładowane poza widoczną częścią strony również powinny mieć określoną przestrzeń, jednakże nie powodują one problemów ze wskaźnikiem CLS.
28. Obecność reklam na górze strony
Reklamy, które zostały umieszczone na górze widocznego obszaru strony także mogą powodować niską ocenę wskaźnika CLS. W przypadku takiego umieszczenia reklam należy zachować szczególną ostrożność, aby uniknąć lub zminimalizować przesunięcie układu.
Wskazówki optymalizacji:
- Przeprowadź test za pomocą Google PageSpeed Insights i sprawdź wyniki wskaźnika CLS.
- Jeśli w Google Search Console znajduje się raport “Podstawowe Wskaźniki Internetowe” koniecznie sprawdź znajdujące się tutaj informacje.
- Zweryfikuj CLS za pomocą innych narzędzi (np. Chrome DevTools czy Web Page Test) przy różnych rozdzielczościach.
- Jeśli przyczyną problemów z CLS jest reklama umieszczona na górze widocznego obszaru strony rozważ wykonanie poniższych czynności:
- Przenieś reklamę niżej by jej lokalizacją nie była sama góra widocznego obszaru lub zupełnie przenieś reklamę poza pierwszy widoczny ekran.
- Określ przestrzeń dla reklamy analogicznie do poprzedniego punktu audytu Core Web Vitals.
29. Rezerwacja przestrzeni dla reklam
Przesunięcie układu może również wystąpić w przypadku, gdy przestrzeń zarezerwowana na reklamę zostanie zwinięta, jeśli reklama nie zostanie wyświetlona.
Najlepszym sposobem na uniknięcie powyższego problemu jest pokazywanie placeholdera w miejscu reklamy, która z jakichś przyczyn nie została wyświetlona.
Wskazówki optymalizacji:
- Wykonaj test strony za pomocą przynajmniej kilku narzędzi.
- Spróbuj odtworzyć sytuację, podczas której reklama nie zostanie wyświetlona i sprawdź, czy miejsce zarezerwowane dla reklamy zostało zwinięte/schowane. Możesz spróbować zablokować wyświetlanie reklamy poprzez użycie Adblock.
- Jeśli przestrzeń zarezerwowana dla reklamy jest głównym winowajcą problemu z CLS, rozważ wdrożenie rozwiązań:
- Zarezerwuj dla reklamy możliwie największą przestrzeń.
- W przypadku problemów z wyświetlaniem reklam zawsze pokazuj placeholder.
- Powyższe zalecenia mogą powodować wyświetlenie pustej przestrzeni, ale zapobiegną przesunięciu układu.
30. Rezerwacja przestrzeni dla elementów osadzonych oraz iframe
Elementy osadzone na stronie, takie jak filmy YouTube, Mapy Google, czy posty social media mogą również powodować przesunięcie układu w przypadku jeśli nie została dla nich zarezerwowana wystarczająca ilość miejsca.
Wskazówki optymalizacji:
- Przeprowadź za pomocą kilku narzędzi test strony, sprawdź wyniki pod kątem przesunięć układu.
- Jeśli odkryjesz, że któryś z osadzonych elementów przyczynia się do problemu z CLS rozważ wdrożenie rozwiązań:
- Określ rozmiar niezbędnej przestrzeni dla osadzonego elementu za pomocą Chrome DevTools.
- Ostyluj placeholder wedle powyższych rozmiarów.
31. Elementy pop-up
Przesunięcie układu mogą powodować elementy typu pop-up, które to pojawiają się nagle ponad treścią strony. Oprócz pop-upów kłopotliwe będą również okna z zapisem na newsletter, czy okna z polityką Cookie.
Jedyną sytuacją kiedy pojawia się pop-up i nie spowoduje to przesunięcia układu będzie pojawienie się okna w odpowiedzi na akcję użytkownika.
Wskazówki optymalizacji:
- Przetestuj stronę za pomocą przynajmniej 2-3 narzędzi i sprawdź, czy występuje przesunięcie układu.
- Jeśli przesunięcie układu jest powiązane z wyskakującym oknem, podobnie jak w przypadku rozwiązania dla reklam należy pozostawić wolną przestrzeń dla tej treści w widocznej części strony. Możesz to zrobić poprzez placeholder lub skeleton UI.
32. Zamiana czcionki zastępczej na nową czcionkę (FOUT)
Podczas procesu pobierania i renderowania czcionek również może dojść do przesunięcia układu. Zjawisko to występuje w chwili błysku nieostylowanego tekstu (The Flash of Unstyled Text).
Wskazówki optymalizacji:
- Za pomocą narzędzia Google PageSpeed Insights wykonaj test strony i sprawdź, czy występuje problem wywoływany przez FOUT (The Flash of Unstyled Text).
- Rekomendowanym rozwiązaniem jest zastosowanie
font-display: optional
lub using<link rel="preload">
. - Więcej informacji znajdziesz na stronie Prevent layout shifting and flashes of invisibile text (FOIT) by preloading optional fonts.
33. Widoczność czcionek podczas renderowania (FOIT)
W trakcie renderowania czcionek może wystąpić błysk z niewidocznym tekstem (The Flash of Invisible Text), co skutkuje przesunięciem układu.
Wskazówki optymalizacji są identyczne co w przypadku błysku nieostylowanego tekstu (The Flash of Unstyled Text) w punkcie 32 audytu Core Web Vitals.
34. Wstępne ładowanie czcionek
Jeśli w witrynie nie zostało wdrożone wstępne ładowanie czcionek prawdopodobnie wystąpi problem z przesunięciem układu.
W celu uniknięcia problemów wywołanych przez czcionki, warto rozważyć wstępne ładowanie kluczowych dla strony czcionek poprzez użycie <link rel="preload">
.
Wskazówki optymalizacji:
- Przetestuj stronę za pomocą Google PageSpeed Insights oraz sprawdź raport “Podstawowe Wskaźniki Internetowe” w Google Search Console.
- Jeśli stwierdzisz, żę czcionki powodują przesunięcie układu możesz to naprawić poprzez użycie:
font-display: optional
- Font Loading API
<link rel="preload">
dla kluczowych czcionek<link rel="preload">
wraz zfont-display: optional
.
35. Animacje powodujące przesunięcie układu
Niektóre właściwości CSS mogą powodować przesunięcie układu, w efekcie czego powodować złe doświadczenia u użytkowników strony.
Rozwiązaniem problemu i uniknięcia przesunięcia układu jest użycie transformacji zamiast właściwości CSS.
Przykładami właściwości CSS, które mogą powodować przesunięcie układu jest box-shadow
lub box-sizing
.
Wskazówki optymalizacji:
- Przeprowadź test za pomocą Google PageSpeed Insights oraz WebPageTest.
- Sprawdź co powoduje przesunięcie układu.
- Jeśli za przesunięcie układu odpowiadają właściwości animacji, dowiedz się więcej o wyzwalaczach CSS i animacjach o wysokiej wydajności i zastosuj inną implementację animacji.
Podsumowanie
Optymalizacja podstawowych wskaźników internetowych (Core Web Vitals) i osiągnięcie dobrych wartości wskaźników może być dla wielu stron dużym wyzwaniem. Tym bardziej, że przy wielu z wymienionych wyżej podpunktów konieczna będzie pomoc web developera.
Jednakże warto powalczyć o jak najlepszą optymalizację Core Web Vitals, by nie tylko móc pochwalić się dobrą optymalizacją strony kolegom z branży, ale też zapewnić użytkownikom możliwie jak najlepsze doświadczenie z jej korzystania. Jeśli nie teraz, to w dłuższej perspektywie czasu z pewnością pozytywnie wpłynie to (pośrednio) na widoczność strony w wyszukiwarkach internetowych.
Dajcie znać w komentarzach, czy udało Wam się już przygotować strony do aktualizacji Core Web Vitals w maju 2021 🙂
W oparciu o Core Web Vitals audit ze strony SEOSLY
Jestem pasjonatem SEO z ponad 10-letnim doświadczeniem w branży (praca w agencji, in-house, jako freelancer oraz niezależny konsultant SEO). Najważniejszy jest dla mnie ciągły rozwój oraz poszerzanie swojej wiedzy i umiejętności. Do każdego projektu podchodzę indywidualnie oraz z wielkim entuzjazmem.
Skontaktuj się ze mną jeśli potrzebujesz pomocy w zwiększeniu widoczności Twojej strony internetowej!