Optymalizacja strony to proces ciągły i na stałe wpisany w realia współczesnego SEO. Optymalizacji podlega kod źródłowy strony, szybkość jej działania, przejrzystość i łatwość obsługi, jakość treści, schematy linkowania wewnętrznego i wiele więcej.

Nie inaczej jest i tym razem, gdzie motywem przewodnim jest dobry UX i sprawne działanie strony internetowej. Stawka optymalizacji jest dosyć wysoka, bowiem może przynieść realne wzrosty widoczności i pozycji w wyszukiwarce Google.

10 listopada 2020 Google ogłosiło, że w maju* 2021 r. Core Web Vitals staną się integralną częścią algorytmu Google. Wejdą one w skład Page Experiance Signals – czyli czynników oceniających strony internetowe pod kątem UX i mających realny wpływ na jakość wyników wyszukiwania.

*[AKTUALIZACJA: Page Experiance Update został przełożony na połowę czerwca, a pełny efekt zmian algorytmu mają być widoczne dopiero pod koniec sierpnia. Oficjalne ogłoszenie dostępne TUTAJ]

Czym są Core Web Vitals?

Core Web Vitals stanowi zbiór metryk i wskaźników związanych z szybkością, responsywnością oraz stabilnością wizualną stron internetowych.

Na Core Web Vitals składają się następujące czynniki:

• LCP – Largest Contentful Paint (Loading)
• FID – First Input Delay (Interactivity)
• CLS – Cumulative Layout Shift (Visual stability)

Metryki CWV dołączą do czynników, które już mają ogromny wpływ na wyniki wyszukiwania, uzupełniając w ten sposób Page Experiance Signals, na które składają się:

• Mobile Friendly – dostosowanie strony do urządzeń mobilnych
• Safe Browsing – bezpieczeństwo w sieci
• HTTPS – szyfrowanie połączenia
• No Intrusive Interstitials – brak elementów, np. reklam, które zasłaniają treści

Core Web Vitals – Omówienie poszczególnych czynników:

Largest Contentful Paint (LCP)

Czynnik LCP określa szybkość wczytywania największego elementu graficznego lub bloku tekstowego, który widoczny jest od razu po otwarciu strony. LCP dotyczy fragmentu strony Above The Fold, czyli bez jej przewijania.

Czynnik LCP mierzony jest w sekundach i oceniany jest następująco:

• Dobry wynik: < 2.5 s
• Wymagający poprawy: pomiędzy 2.5 a 4 s
• Zły wynik: > 4 s

Podczas pomiarów wskaźnika LCP w warunkach rzeczywistych, jego pomiar zatrzymuje się, gdy użytkownik wchodzi w interakcję ze stroną.

W przypadku, gdy największym elementem uwzględnionym jako LCP jest obraz, wówczas czas renderowania to wartość, która następuje bezpośrednio po jego pełnym załadowaniu.

Jeżeli największym elementem jest blok tekstowy, pod uwagę brane są czcionki, które ładowane są najwcześniej.

First Input Delay (FID)

Czynnik FID związany jest bezpośrednio z szybkością działania strony i określa czas, w którym strona gotowa jest do interakcji i wykonania działania przez użytkownika, np. kliknięcie w button.

Czynnik FID mierzony jest w milisekundach i oceniany jest następująco:

• Dobry wynik: < 100 milisekund
• Wymagający poprawy: pomiędzy 100 a 300 milisekund
• Zły wynik: > 300 milisekund

Cumulative Layout Shift (CLS)

Czynnik CLS mierzy wartość przesunięcia strony w czasie jej ładowania, tj. jak zachowują się poszczególne elementy (obrazy, bannery, reklamy) wyświetlane podczas wczytywania zasobów.

Czynnik CLS mierzony jest w określonych wartościach i oceniany jest następująco:

• Dobry wynik: < 0.1
• Wymagający poprawy: pomiędzy 0.1 a 0.25
• Zły wynik: > 0.25

OPTYMALIZACJA CORE WEB VITALS – jakie działania mają realny wpływ na wyniki

Optymalizacja strony pod kątem LCP

Według oficjalnej dokumentacji Google (https://web.dev/optimize-lcp/) najczęstsymi  przyczynami słabego wyniku LCP są:

• Długi czas odpowiedzi serwera
• Blokujące renderowanie pliki CSS i skrypty JS
• Długi czas ładowania zasobów strony
• Renderowanie client-side

Im dłużej przeglądarka musi czekać na pobranie zasobów serwera, tym dłużej trwa ich renderowanie na ekranie.

Optymalizację odpowiedzi serwera, by poprawić współczynnik LCP warto rozpocząć od poprawy parametru TTFB (Time to First Byte).

TTFB można usprawnić poprzez:

• Optymalizację serwera – poprzez bezpośrednie udostępnianie statycznej strony (gotowy plik HTML) na żądanie przeglądarki. Dynamiczne tworzenie strony internetowej po stronie serwera wydłuża czas renderowania przez konieczność oczekiwania na wysłanie zapytania do bazy danych.

• Wykorzystanie pobliskich sieci CDN – serwowanie całego contentu strony z jednego serwera może powodować opóźnienia dla użytkowników znajdujących się dalej od niego.

• Wykorzystanie zasobów pamięci podręcznej – dla statycznych stron HTML warto rozważyć przechowywanie kopii wygenerowanej strony na dysku.

• Serwowanie pliku HTML strony cache-first – możliwość wykorzystania pamięci podręcznej do przechowywania  pewnych elementów contentu strony i aktualizowanie ich w momencie, w którym content ulega zmianie.

• Szybsze nawiązywanie połączeń z zasobami zewnętrznymi – zalecane jest wykorzystanie wskazówki rel=”preconnect” do poinformowania przeglądarki o tym, że strona chce wykonać połączenie jak najszybciej jest to możliwe. Można wykorzystać również rel=”dns-prefetch” do szybszego wyszukania DNS.

Chociaż obie wskazówki działają inaczej warto rozważyć użycie dns-prefetch jako rozwiązania zastępczego dla przeglądarek, które nie obsługują połączenia wstępnego preconnect.

<head>

 <link rel=”preconnect” href=”https://example.com”>

 <link rel=”dns-prefetch” href=”https://example.com”>

</head>

Optymalizacja strony pod kątem FID

Według oficjalnej dokumentacji Google (https://web.dev/optimize-fid/) najczęstszą przyczyną słabego wyniku FID jest:

• Zbyt długi czas wykonywania kodu JavaScript

Przeglądarka nie może poprawnie odpowiadać na akcje użytkownika zanim nie wykona JavaScript. Jest to o tyle ważne, że wskaźnik FID bardzo mocno opiera się na realnych danych zbieranych od użytkowników, dlatego szybkość ich interakcji ze stroną ma duże znaczenie.

Jak można wpłynąć na zmniejszenie czasu wykonywania JS:

• Redukując wpływ kodu i skryptów z zewnętrznych serwisów
• Rozdzielenie długich zadań wykonywanych przez przeglądarkę – podzielenie koniecznego do wykonania kodu na mniejsze fragmenty ładowane asynchronicznie
• Odłożyć w czasie niewykorzystany JavaScript, który nie jest krytyczny do prawidłowego funkcjonowania strony.

Optymalizacja strony pod kątem CLS

Według oficjalnej dokumentacji Google (https://web.dev/optimize-cls/) najczęstszymi przyczynami słabego wyniku CLS są:

• Obrazy bez określonych wymiarów
• Pliki video bez określonych wymiarów
• Reklamy, embedy, iframe bez określonych wymiarów
• Wczytywany dynamicznie content
• Używanie czcionek internetowych powodujących FOIT/FOUT –  (flash of invisible text / flash of unstyled text)
• Działania, które muszą czekać na odpowiedź przed aktualizacją DOM
• Animacje na stronie, które powodują zmianę pozycji obiektów

Jedną z najistotniejszych cech optymalizacji w celu zmniejszenia wskaźnika CLS jest wykorzystanie parametrów width i height w obrazach w tagu <img>.

Daje to możliwość zarezerwowania przestrzeni na stronie dla ładujących się zasobów i uniknięcie przesunięcia strony wraz z wczytywanymi na bieżąco obrazami.

Podobne zastosowanie dotyczy plików video i wszelkich zasobów, które mogą powodować Layout Shift.

Przeczytaj również: Optymalizacja Core Web Vitals – Zbiór porad