LCP na stronie: co opóźnia wyświetlenie największego elementu i jak to naprawić

Czym jest LCP i jaki wynik uznaje się za dobry

LCP, czyli Largest Contentful Paint (największe wyrenderowanie treści), to czas, po którym przeglądarka kończy rysować największy obraz, blok tekstu lub film widoczny w oknie przeglądarki, liczony od chwili, gdy użytkownik rozpoczął przejście na stronę. W praktyce wskaźnik odpowiada na proste pytanie odwiedzającego: kiedy widać już to, po co tu przyszedłem. Według opisu wskaźnika w serwisie web.dev do tego czasu wliczają się także opóźnienia sprzed rysowania, na przykład zestawianie połączenia, przekierowania i oczekiwanie na pierwszą porcję danych z serwera.

Progi są stałe i takie same w dokumentacji Google oraz w raportach. Wynik do 2,5 sekundy jest dobry, powyżej 4 sekund słaby, a wartości pomiędzy oznaczają, że strona wymaga poprawy. Ocenia się 75. percentyl wizyt, osobno dla telefonów i komputerów. Oznacza to, że trzy czwarte odwiedzin powinno mieścić się w progu, a pojedynczy szybki pomiar na dobrym łączu w biurze niczego jeszcze nie dowodzi.

LCP jest jednym z trzech podstawowych wskaźników internetowych (Core Web Vitals), obok INP opisującego szybkość reakcji strony i CLS opisującego stabilność układu. Google w dokumentacji dla właścicieli witryn zaleca osiąganie dobrych wartości i wyjaśnia, że jego systemy rankingowe starają się nagradzać strony zapewniające dobrą jakość korzystania, do której te wskaźniki należą wraz z innymi cechami strony. Dokumentacja nie podaje wagi tego czynnika, dlatego nie należy oczekiwać, że sama poprawa LCP zmieni pozycje. To jeden z elementów szerszej pracy, którą opisujemy we wpisie o tym, jak poprawić LCP, INP i CLS na stronie firmy.

Który element strony jest liczony jako największy

Za element LCP przeglądarka uznaje największy pod względem zajmowanej powierzchni obraz, plakat filmu, tło wczytywane z pliku lub blok tekstu widoczny na pierwszym ekranie, bez przewijania. Na stronie firmowej jest to zwykle duże zdjęcie w górnej części strony, grafika w banerze albo nagłówek z akapitem wprowadzającym. Na karcie produktu w sklepie najczęściej zdjęcie produktu, a we wpisie blogowym grafika główna lub pierwszy akapit.

Lista typów elementów jest celowo krótka. Zgodnie z opisem w web.dev pod uwagę brane są znaczniki img, obrazy osadzone w grafice wektorowej, filmy (liczy się plakat albo pierwsza klatka, zależnie od tego, co pojawi się wcześniej), elementy z tłem wczytanym przez funkcję url() w arkuszu stylów oraz elementy blokowe zawierające tekst. Gradienty tworzone w stylach się nie liczą. Przeglądarka pomija też elementy całkowicie przezroczyste, obrazy pokrywające cały ekran, które najpewniej są tłem, oraz obrazy zastępcze o bardzo ubogiej zawartości.

Jak liczona jest wielkość elementu

Liczy się wyłącznie ta część elementu, którą widać w oknie przeglądarki. Fragmenty przycięte lub wychodzące poza ekran nie są wliczane, podobnie jak marginesy, odstępy wewnętrzne i obramowania. W przypadku obrazu wyświetlanego w innym rozmiarze niż rzeczywisty brana jest mniejsza z dwóch wartości: rozmiar widoczny albo rozmiar własny pliku. Dla tekstu liczy się najmniejszy prostokąt obejmujący cały tekst.

Z tych zasad wynika rzecz ważna w praktyce: element LCP bywa inny na telefonie i na komputerze. Na szerokim ekranie największe jest zdjęcie w banerze, a na telefonie to samo zdjęcie jest wąskie i ustępuje miejsca nagłówkowi z akapitem. Kancelaria z Krakowa może więc mieć na komputerach kłopot ze zdjęciem zespołu, a na telefonach z czcionką, która długo się wczytuje. Dlatego pomiar zawsze warto wykonać osobno dla obu rodzajów urządzeń.

Kiedy przeglądarka kończy pomiar

W trakcie wczytywania kandydat na element LCP może się zmieniać. Przeglądarka zgłasza pierwszego kandydata po narysowaniu pierwszej klatki, a następnie kolejnych za każdym razem, gdy pojawi się coś większego, na przykład późno wczytane zdjęcie. Zgłaszanie kończy się w chwili, gdy użytkownik dotknie ekranu, przewinie stronę lub naciśnie klawisz. Element usunięty ze strony pozostaje kandydatem, dopóki nie pojawi się większy. Ma to znaczenie dla stron z ekranem powitalnym, komunikatem o plikach cookie albo oknem z ofertą: jeśli taki element jest największy na pierwszym ekranie, to on może zostać uznany za element LCP.

Z jakich czterech części składa się czas LCP

Czas LCP dzieli się na cztery następujące po sobie części: odpowiedź serwera, opóźnienie pobrania zasobu, czas pobrania zasobu i opóźnienie renderowania elementu. Jak podaje opracowanie o optymalizacji LCP w web.dev, części te sumują się do pełnej wartości wskaźnika bez przerw i bez nakładania się. Dzięki temu każdą sekundę opóźnienia można przypisać do konkretnego etapu.

Pierwsza część to czas do pierwszego bajtu, w skrócie TTFB (Time to First Byte). Obejmuje okres od rozpoczęcia wczytywania do chwili, gdy przeglądarka otrzyma pierwszą porcję dokumentu HTML. Druga część, opóźnienie pobrania zasobu, to czas między otrzymaniem tej pierwszej porcji a rozpoczęciem pobierania pliku, z którego powstanie element LCP, najczęściej obrazu. Trzecia to samo pobieranie tego pliku. Czwarta, opóźnienie renderowania, to okres od zakończenia pobierania do pełnego narysowania elementu na ekranie. Jeżeli elementem LCP jest tekst wyświetlany czcionką systemową, części druga i trzecia wynoszą zero, bo nie ma czego pobierać.

Web.dev podaje orientacyjny rozkład, do którego warto dążyć: odpowiedź serwera i pobieranie zasobu po około 40 procent całego czasu, a obie części nazwane opóźnieniami poniżej 10 procent każda. Autorzy zastrzegają, że to wskazówka, a nie sztywna reguła, i że nie należy przeliczać tych udziałów na konkretne liczby milisekund. Sens jest prosty: czas powinien być zużywany na rzeczy nieuniknione, czyli na przesłanie dokumentu i obrazu, a nie na czekanie. Opóźnienia powinny być bliskie zeru.

Z podziału wynika jeszcze jedna ważna obserwacja opisana w tym samym źródle. Skrócenie jednej części nie zawsze skraca cały LCP, ponieważ czas może przenieść się do innej. Typowy przykład: sklep z Poznania zmniejsza wagę zdjęcia w banerze o połowę, pobieranie trwa krócej, ale strona i tak czeka na arkusz stylów blokujący rysowanie. Zaoszczędzony czas pojawia się wtedy w opóźnieniu renderowania, a wynik LCP pozostaje bez zmian. Stąd zasada, którą stosujemy w pracy przy SEO technicznym: najpierw pomiar i podział na części, dopiero potem naprawa.

Jak wskazać element LCP w PageSpeed Insights

Najprostszym sposobem jest PageSpeed Insights, publiczne narzędzie Google dostępne pod adresem pagespeed.web.dev, które nie wymaga logowania. Wystarczy wpisać adres badanej podstrony w pole na środku ekranu i uruchomić analizę przyciskiem obok. Narzędzie pokazuje raport osobno dla telefonów i dla komputerów, przełączany zakładkami u góry.

Raport ma dwie części, które odpowiadają na inne pytania. Jak wyjaśnia opis narzędzia PageSpeed Insights, górna część pokazuje dane z rzeczywistego użytkowania, zebrane od prawdziwych odwiedzających korzystających z Chrome w okresie 28 dni i podane dla 75. percentyla. Dolna część to dane laboratoryjne: jednorazowe, symulowane wczytanie strony przez narzędzie Lighthouse na jednym urządzeniu i przy stałych warunkach sieci. Dla telefonów symulowane jest urządzenie średniej klasy w sieci komórkowej.

O tym, czy strona spełnia próg, rozstrzygają dane z rzeczywistego użytkowania, a dane laboratoryjne służą do szukania przyczyny. Jeżeli dla badanego adresu jest zbyt mało odwiedzin, narzędzie pokazuje dane dla całej witryny, a gdy i tych brakuje, część z danymi rzeczywistymi w ogóle się nie wyświetla. Na małych stronach firmowych zdarza się to często i nie świadczy o błędzie.

Gdzie w raporcie szukać elementu i podziału czasu

W części laboratoryjnej, pod wynikiem wydajności i wartościami wskaźników, znajduje się lista diagnostyczna. Dwie pozycje są tu najważniejsze. Pierwsza pokazuje podział LCP na części, w dokumentacji Chrome opisany pod nazwą LCP breakdown: po rozwinięciu widać cztery wiersze z czasami oraz wskazany element strony. Druga, LCP request discovery, pojawia się, gdy elementem LCP jest obraz, i sprawdza trzy rzeczy: czy obraz ma ustawiony wysoki priorytet pobierania, czy da się go odnaleźć w głównym dokumencie HTML oraz czy nie zastosowano wobec niego opóźnionego wczytywania.

Nazwy tych pozycji w interfejsie zmieniają się wraz z kolejnymi wersjami narzędzia i zależą od języka, dlatego podajemy brzmienie z dokumentacji. Właściwe pozycje najłatwiej rozpoznać po zawartości: tabeli z czterema częściami czasu oraz krótkiej liście trzech warunków dotyczących obrazu.

Jak sprawdzić LCP w narzędziach Chrome i w Search Console

Narzędzia dla programistów w przeglądarce Chrome pokazują element LCP na żywo, na własnym komputerze, a Search Console wskazuje, których grup podstron problem dotyczy w skali całej witryny. Pierwsze źródło pozwala od razu oceniać poprawki, drugie pokazuje, gdzie kłopot występuje u prawdziwych odwiedzających.

Panel wydajności w Chrome

Po otwarciu narzędzi dla programistów z menu przeglądarki należy przejść do karty Performance (wydajność). Zgodnie z dokumentacją panelu ekran startowy pokazuje wskaźniki zmierzone lokalnie dla otwartej strony, w tym LCP oraz element LCP. Po najechaniu na niego kursorem przeglądarka podświetla go na stronie, co rozwiewa wątpliwości, o który fragment chodzi. Po najechaniu na wartość wskaźnika widać także podział na części.

W tym samym panelu można ustawić spowolnienie procesora i sieci oraz wyłączyć pamięć podręczną. Ma to duże znaczenie, bo szybki komputer w biurze i światłowód ukrywają większość problemów. Po nagraniu wczytania strony w lewej części panelu dostępna jest karta Insights (spostrzeżenia) z tymi samymi pozycjami co w PageSpeed Insights.

Raport w Search Console

W Search Console raport nosi nazwę Core Web Vitals (w polskich opisach także Podstawowe wskaźniki internetowe). Według pomocy Search Console dane pochodzą z raportu na temat użytkowania Chrome, a adresy otrzymują jeden z trzech stanów: dobrej jakości, wymagana poprawa albo słabej jakości. O stanie decyduje najsłabszy ze wskaźników.

W raporcie szczegółowym, osobnym dla telefonów i komputerów, tabela zatytułowana Dlaczego adresy URL nie są uważane za prawidłowe wymienia problemy. Po kliknięciu wiersza otwiera się strona szczegółów z tabelą Przykłady. Raport nie pokazuje każdego adresu z osobna, lecz grupy podobnych stron, na przykład karty produktów zbudowane z jednego szablonu, wraz z wartością LCP grupy. To wygodne, bo naprawa szablonu poprawia zwykle całą grupę. Brak danych nie musi oznaczać błędu: dzieje się tak, gdy usługa jest nowa albo gdy zebrano za mało pomiarów.

Co zrobić, gdy najdłużej trwa odpowiedź serwera

Jeżeli największą częścią LCP jest czas do pierwszego bajtu, przyczyna leży po stronie serwera lub drogi do niego i żadna praca nad obrazami tego nie zmieni. Dopóki przeglądarka nie otrzyma dokumentu HTML, nie wie nawet, jakie pliki ma pobrać. Opracowanie web.dev o czasie do pierwszego bajtu podaje orientacyjny cel na poziomie najwyżej 0,8 sekundy i uznaje wartości powyżej 1,8 sekundy za słabe.

Pierwszą rzeczą do oceny jest hosting. Źródło wskazuje, że współdzielone serwery są zazwyczaj wolniejsze, co bywa wystarczające dla małej, prostej strony, ale nie dla rozbudowanego serwisu z bazą danych. Na stronach opartych na WordPressie duży wpływ mają także motyw i wtyczki. Strona hydraulika z Łodzi z kilkunastoma podstronami może działać wolno nie z powodu zdjęć, lecz dlatego, że każde wejście wymaga zbudowania strony od zera z udziałem kilkudziesięciu wtyczek.

Drugim obszarem jest pamięć podręczna. Strona, która nie różni się między odwiedzającymi, nie musi być za każdym razem składana od nowa. Gotowy dokument można przechowywać na serwerze albo w sieci dostarczania treści, w skrócie CDN, czyli na serwerach rozmieszczonych bliżej użytkowników. Web.dev ostrzega jednak, że pamięć podręczna potrafi ukryć wolne zaplecze: rzadziej odwiedzane podstrony mogą się w niej nie znajdować i wczytywać znacznie dłużej niż strona główna.

Trzecim obszarem są przekierowania, z których każde dodaje kolejne zapytanie przed otrzymaniem właściwego dokumentu. Do częstych przyczyn należą odnośniki bez protokołu https oraz niekonsekwentne ukośniki na końcu adresów. Unikalne parametry w adresach, na przykład znaczniki kampanii reklamowych, mogą z kolei powodować pominięcie pamięci podręcznej. Dlatego dane z rzeczywistego użytkowania pokazują czasem dłuższą odpowiedź serwera niż test laboratoryjny.

Gdy żadna z tych zmian nie pomaga, najrozsądniejszym rozwiązaniem bywa zmiana serwera, którą warto zaplanować tak jak każdą migrację domeny i hostingu, aby przy okazji nie utracić widoczności.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl

Dlaczego przeglądarka zbyt późno zaczyna pobierać obraz główny

Opóźnienie pobrania zasobu powstaje wtedy, gdy przeglądarka przez dłuższy czas nie wie o istnieniu obrazu LCP albo wie, lecz traktuje go jako mało ważny. Według web.dev wzorcem jest sytuacja, w której plik elementu LCP zaczyna się pobierać w tym samym momencie co pierwszy zasób strony. Na stronach firmowych ta część bywa najbardziej zaniedbana, a jednocześnie najłatwiejsza do naprawienia, bo wymaga zmian w kodzie strony, a nie w serwerze.

Obraz musi być widoczny w kodzie HTML

Przeglądarka przegląda dokument HTML z wyprzedzeniem i od razu zleca pobranie plików, które w nim znajdzie. Obraz wstawiony zwykłym znacznikiem img zostanie odnaleziony natychmiast. Inaczej jest w trzech sytuacjach wymienionych w źródle: gdy obraz dodaje do strony skrypt, gdy biblioteka do opóźnionego wczytywania ukrywa adres w atrybucie data-src oraz gdy obraz jest tłem ustawionym w arkuszu stylów. Przeglądarka musi wtedy najpierw pobrać i przetworzyć inny plik, zanim w ogóle dowie się o obrazie.

Tło w stylach to na stronach firmowych częsty przypadek: duży baner zbudowany w kreatorze stron jako sekcja z obrazem w tle. Jeśli układ strony na to pozwala, najlepiej zastąpić go zwykłym znacznikiem img. Gdy nie jest to możliwe, obraz można zgłosić przeglądarce z wyprzedzeniem znacznikiem link z atrybutem rel o wartości preload (wstępne wczytanie), umieszczonym w nagłówku dokumentu.

<link rel="preload" fetchpriority="high" as="image"
      href="/path/to/hero-image.webp" type="image/webp">

Priorytet pobierania i opóźnione wczytywanie

Samo odnalezienie obrazu nie wystarcza, ponieważ przeglądarka domyślnie nadaje obrazom niski priorytet i podnosi go dopiero po ustaleniu układu strony. Opisuje to materiał web.dev o priorytetach pobierania. Atrybut fetchpriority z wartością high podpowiada przeglądarce, że ten plik jest ważny od początku. Nie należy stosować go do więcej niż jednego lub dwóch obrazów. W tym samym źródle opisano test na stronie Google Flights, w którym wysoki priorytet dla obrazu tła będącego elementem LCP skrócił ten wskaźnik z 2,6 do 1,9 sekundy. To wynik jednego testu, a nie obietnica dla każdej strony.

Odwrotny skutek ma atrybut loading z wartością lazy, czyli opóźnione wczytywanie. Jest pożyteczny dla zdjęć położonych niżej, ale zastosowany wobec obrazu na pierwszym ekranie opóźnia dokładnie ten element, który powinien pojawić się pierwszy. Opis tej funkcji w web.dev zaleca, aby nie stosować jej do obrazów widocznych zaraz po wczytaniu strony, a zwłaszcza do obrazu LCP.

<img src="/obrazy/baner-glowny.webp" alt="Opis zdjęcia"
     width="1200" height="600" fetchpriority="high">

<img src="/obrazy/realizacja-3.webp" alt="Opis zdjęcia"
     width="600" height="400" loading="lazy">

Jak opisali twórcy WordPressa, system sam dodaje wysoki priorytet do pierwszego dużego obrazu, który uznaje za prawdopodobny element LCP, a obrazom położonym dalej nadaje opóźnione wczytywanie. Mechanizm obejmuje jednak tylko znaczniki img wstawiane w sposób znany systemowi. Obrazy tła, suwaki oraz sekcje budowane przez kreatory stron mogą go omijać, a wtyczka przyspieszająca potrafi nałożyć opóźnione wczytywanie na wszystkie obrazy, w tym na baner. Dlatego wynik zawsze warto sprawdzić w narzędziu. Szerzej o przygotowaniu grafik piszemy we wpisie o obrazach na stronie a SEO.

Jak skrócić samo pobieranie obrazu

Czas pobrania zasobu skraca się na cztery sposoby opisane w web.dev: zmniejszając plik, skracając drogę, którą musi przebyć, ograniczając konkurencję o łącze oraz eliminując pobieranie przy kolejnych wizytach. Źródło zastrzega, że ta część często nie jest główną przyczyną słabego wyniku, dlatego przed kompresowaniem wszystkich zdjęć warto upewnić się, że to rzeczywiście najdłuższy etap.

Zmniejszenie pliku oznacza trzy rzeczy. Obraz powinien mieć wymiary dopasowane do miejsca, w którym jest wyświetlany: zdjęcie o szerokości kilku tysięcy pikseli pokazane w ramce o szerokości telefonu to zmarnowane sekundy. Współczesne formaty AVIF i WebP dają mniejsze pliki, a obraz należy dodatkowo skompresować. Jeśli elementem LCP jest tekst, rolę obrazu odgrywa plik czcionki i to jego rozmiar warto ograniczyć.

Skróceniu drogi służy sieć dostarczania treści, która podaje pliki z serwera położonego bliżej odwiedzającego. Konkurencja o łącze pojawia się wtedy, gdy strona jednocześnie pobiera wiele plików oznaczonych jako ważne. Pomaga obniżenie priorytetu zasobów niewidocznych na starcie, na przykład kolejnych zdjęć w suwaku, atrybutem fetchpriority z wartością low. Przy powrotach na stronę pobieranie można wyeliminować całkowicie: właściwie ustawione nagłówki pamięci podręcznej sprawiają, że przeglądarka korzysta z zapisanej kopii obrazu i czcionek.

Co wstrzymuje narysowanie pobranego już elementu

Opóźnienie renderowania występuje wtedy, gdy obraz jest już pobrany albo tekst gotowy, a przeglądarka nadal nie może go narysować, ponieważ czeka na arkusze stylów, wykonuje skrypty albo element dopiero ma zostać dodany do strony przez kod. Web.dev wymienia trzy główne źródła tej zwłoki: style blokujące renderowanie, skrypty blokujące renderowanie oraz długie zadania zajmujące główny wątek przeglądarki.

Arkusz stylów wstrzymuje rysowanie strony do czasu jego pobrania. Kłopot zaczyna się wtedy, gdy arkusz jest duży i pobiera się dłużej niż sam obraz. Zalecenia są trzy: usunąć nieużywane reguły, odłożyć wczytywanie stylów niepotrzebnych na pierwszym ekranie oraz zmniejszyć i skompresować to, co niezbędne. W przypadku tekstu wyświetlanego czcionką internetową pomaga właściwość font-display o wartości innej niż auto lub block, dzięki której tekst jest widoczny od razu w czcionce zastępczej.

Skrypty umieszczone w nagłówku dokumentu bez atrybutów async lub defer działają podobnie: przeglądarka przerywa pracę nad stroną, pobiera skrypt, wykonuje go i dopiero wtedy idzie dalej. Dotyczy to między innymi kodów analitycznych i reklamowych, okien czatu oraz map. Nawet po pobraniu obrazu długie zadania skryptów mogą opóźnić jego narysowanie, ponieważ rysowanie odbywa się w tym samym głównym wątku.

Najpoważniejsza odmiana tego problemu dotyczy stron, których treść w całości buduje skrypt w przeglądarce. Dokument HTML jest wtedy niemal pusty, a nagłówek i zdjęcie pojawiają się dopiero po uruchomieniu kodu aplikacji. Web.dev zaleca w takich przypadkach generowanie HTML po stronie serwera albo przygotowanie gotowych stron statycznych. To decyzje, które najłatwiej podjąć na etapie tworzenia strony, a znacznie trudniej wprowadzić później.

W jakiej kolejności prowadzić naprawy i jak sprawdzić efekt

Naprawy warto prowadzić od pomiaru u prawdziwych użytkowników, przez wskazanie elementu i najdłuższej części czasu, po poprawki zaczynające się od opóźnień, które powinny być bliskie zeru. Usunięcie czekania wymaga zwykle niewielkich zmian w kodzie, a przyspieszenie serwera lub przebudowa sposobu generowania strony to prace większe i droższe.

1. Ustalenie, gdzie jest problem

   Raport Core Web Vitals w Search Console pokazuje grupy adresów ze słabym LCP. Z każdej grupy wystarczy wybrać jeden lub dwa przykładowe adresy.

2. Wskazanie elementu LCP

   W PageSpeed Insights lub w panelu wydajności Chrome należy ustalić, który element jest największy na telefonie, a który na komputerze.

3. Odczytanie podziału na cztery części

   Najdłuższa część wyznacza kierunek pracy. Jeśli długie są opóźnienia, od nich warto zacząć.

4. Poprawki w kodzie strony

   Obraz główny w kodzie HTML, wysoki priorytet pobierania, brak opóźnionego wczytywania na pierwszym ekranie, odłożenie zbędnych stylów i skryptów.

5. Poprawki pliku i serwera

   Właściwe wymiary i format obrazu, pamięć podręczna, ograniczenie przekierowań, a w razie potrzeby zmiana serwera.

6. Ponowny pomiar i obserwacja

   Test laboratoryjny potwierdza zmianę od razu, a dane od użytkowników zmieniają się stopniowo.

Kiedy widać efekt w raportach Google

Dane z rzeczywistego użytkowania obejmują okres 28 dni, dlatego poprawka wdrożona dzisiaj nie zmieni wyniku nazajutrz. Pełny obraz po zmianie widać mniej więcej po czterech tygodniach. W Search Console po naprawie można uruchomić weryfikację poprawki przyciskiem na stronie szczegółów problemu. Pomoc Search Console podaje, że rozpoczyna to 28-dniowy okres monitorowania i że problem zostaje uznany za naprawiony, jeśli w tym czasie żaden adres go nie wykazuje.

Typowe pomyłki przy pracy nad LCP

Najczęstszą pomyłką jest ocenianie strony po wyniku punktowym z testu laboratoryjnego. Liczba w kolorowym okręgu jest oceną jednego symulowanego wczytania i nie jest tym samym co LCP mierzony u odwiedzających. Punktem odniesienia powinna być górna część raportu, jeśli tylko jest dostępna.

Druga pomyłka to badanie wyłącznie strony głównej, podczas gdy klienci z wyszukiwarki trafiają najczęściej na podstrony usług, kategorie i wpisy. Trzecia to kompresowanie wszystkich zdjęć bez sprawdzenia podziału czasu: praca zostaje wykonana, a wynik się nie zmienia, bo wąskim gardłem był serwer lub arkusz stylów.

Czwarta pomyłka dotyczy wtyczek przyspieszających. Włączenie wszystkich opcji naraz potrafi pogorszyć LCP, na przykład gdy opóźnione wczytywanie obejmie baner. Każdą opcję lepiej włączać osobno i po każdej zmianie powtarzać pomiar. Piąta to traktowanie LCP jako celu samego w sobie. Szybkie wyświetlenie treści pomaga odwiedzającym, ale nie zastąpi treści odpowiadających na pytania klientów ani poprawnej budowy serwisu. Dlatego pracę nad szybkością warto osadzić w szerszym planie, którego punktem wyjścia jest zwykle audyt SEO. O tym, co powinien zawierać, piszemy we wpisie o zawartości audytu SEO i czytaniu raportu.

Co można zrobić samodzielnie, a kiedy potrzebna jest pomoc

Bez wiedzy programistycznej można wykonać pomiar, wskazać element LCP, przygotować lżejsze zdjęcia, zrezygnować z suwaka na pierwszym ekranie i usunąć nieużywane wtyczki. Zmiany w szablonie, w sposobie wczytywania stylów i skryptów oraz w konfiguracji serwera wymagają osoby znającej kod strony, ponieważ błąd w tych miejscach potrafi zepsuć wygląd lub działanie serwisu. Dotyczy to zwłaszcza sklepów, w których poprawka szablonu nie może naruszyć koszyka i płatności, o czym piszemy szerzej przy usłudze pozycjonowania sklepów.

• LCP sprawdzony osobno dla telefonów i komputerów, na danych od użytkowników, jeśli są dostępne.
• Element LCP wskazany dla każdego rodzaju podstron.
• Odczytany podział na cztery części i wskazana najdłuższa z nich.
• Obraz główny wstawiony w kodzie HTML albo zgłoszony do wstępnego wczytania.
• Obraz główny ma wysoki priorytet pobierania i nie ma opóźnionego wczytywania.
• Obraz ma wymiary dopasowane do miejsca wyświetlania i współczesny format.
• Style i skrypty niepotrzebne na pierwszym ekranie nie blokują rysowania strony.
• Odpowiedź serwera sprawdzona także dla rzadziej odwiedzanych podstron.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl