Wymiar Core/Dash: Typ elementu (LCP)
Popraw Largest Contentful Paint, filtrując ruch na podstawie typu architektonicznego elementu.
Trusted by market leaders · Client results
Wymiar: Zasób: Typ elementu LCP (lcpet)
Wymiar typu elementu (LCP) (lcpet) dzieli węzeł Largest Contentful Paint na jedną z czterech klas architektonicznych: text, image, background-image lub video.
Podczas gdy wymiar Element atrybucji precyzyjnie wskazuje dokładny węzeł DOM, wymiar Typ elementu dyktuje ogólną strategię inżynieryjną. LCP jest sumą czterech przedziałów czasowych: TTFB, Load Delay, Load Time oraz Render Delay. Typ elementu wskazuje, który z tych przedziałów obniża Twój wynik, pozwalając Ci wybrać odpowiedni protokół optymalizacji bez zgadywania.
Optymalizacja Core Web Vitals według typu elementu LCP
Po poprawieniu TTFB, które jest niezależne od typu elementu LCP, powinieneś przyjąć inne podejście do optymalizacji LCP, przyglądając się typowi elementu LCP.
1. Tekst
Gdy CoreDash raportuje tekst jako typ elementu, przepustowość zasobów sieci statycznej rzadko stanowi wąskie gardło. Tekst znajduje się bezpośrednio w dokumencie HTML, co oznacza, że treść jest dostępna natychmiast po początkowej odpowiedzi serwera (TTFB). Jeśli LCP jest w tym przypadku wolne, problemem jest prawie wyłącznie Render Delay.
Aby to naprawić, skup się całkowicie na krytycznej ścieżce renderowania (Critical Rendering Path). Przeglądarka jest prawdopodobnie blokowana przed wyrenderowaniem tekstu przez ciężkie obliczenia CSS lub synchroniczny JavaScript w sekcji <head>. Dodatkowo sprawdź strategię ładowania fontów; jeśli nie używasz właściwości font-display: swap lub optional, przeglądarka sztucznie ukrywa tekst (FOIT), czekając na pobranie pliku z fontem.
2. Obraz (<img>)
Ten typ uruchamia pełny potok zasobów: odkrywanie, pobieranie i dekodowanie. W przeciwieństwie do tekstu, LCP obrazu jest w dużym stopniu uzależnione od Load Delay i Load Time. Walczysz tutaj z fizyką i opóźnieniami sieci, więc Twoim celem jest zmniejszenie ciężaru zasobu i umożliwienie jego wcześniejszego wykrycia.
Optymalizacja w tym przypadku wymaga rygorystycznego zarządzania zasobami. Upewnij się, że tag <img> istnieje w początkowym kodzie źródłowym HTML (Server-Side Rendering), aby zminimalizować Load Delay. Dodaj fetchpriority="high" i bezwzględnie usuń wszelkie atrybuty loading="lazy", ponieważ opóźniają one żądanie przeglądarki. Na koniec rozwiąż problem Load Time, serwując formaty nowej generacji (AVIF/WebP) i używając atrybutu srcset, aby zapobiec pobieraniu przez urządzenia mobilne plików w rozmiarze przeznaczonym dla komputerów stacjonarnych.
3. Obraz w tle
Ta klasyfikacja sygnalizuje nieefektywność architektury. Ponieważ obraz jest zdefiniowany w CSS (np. background-image: url(...)), przeglądarka nie może odkryć adresu URL, dopóki w pełni nie pobierze i nie przetworzy arkuszy stylów. Powoduje to ogromne Load Delay, ponieważ Preload Scanner jest praktycznie ślepy na ten zasób.
Jedyną solidną naprawą inżynieryjną jest refaktoryzacja. Przenieś zasób wizualny z CSS do standardowego tagu HTML <img>, aby natychmiast udostępnić adres URL przeglądarce. Jeśli nie możesz zrefaktoryzować znaczników, musisz użyć <link rel="preload"> w nagłówku dokumentu, aby wymusić wczesne wykrycie, choć często stanowi to większe obciążenie w utrzymaniu w porównaniu z użyciem natywnego elementu obrazu.
4. Wideo
Gdy elementem LCP jest wideo, przeglądarka mierzy czas renderowania obrazu plakatu (poster) lub pierwszej klatki (przy automatycznym odtwarzaniu). Działa to podobnie do typu Image, ale zasoby wideo są często znacznie cięższe ze względu na ich rozmiar pliku.
Traktuj to ściśle jako zadanie optymalizacji obrazu. Upewnij się, że w HTML obecny jest lekki atrybut poster, dzięki czemu przeglądarka nie będzie musiała pobierać segmentów wideo, aby wyrenderować pierwszy piksel. Kompresuj obraz plakatu tak samo agresywnie, jak standardowy obraz LCP.
Przepływ pracy: znajdowanie problemów z LCP na podstawie typu elementu LCP
Typ elementu LCP nie jest statyczny ani taki sam dla każdego odwiedzającego. Często zmienia się w zależności od urządzenia użytkownika, ujawniając fundamentalne błędy w podejściu responsive design.
Użyj filtra CoreDash Device Form Factor, aby porównać typy elementów między urządzeniami mobilnymi a komputerami stacjonarnymi. Często odkryjesz, że użytkownicy komputerów stacjonarnych otrzymują obrazowe LCP (np. główny baner Hero), podczas gdy użytkownicy mobilni otrzymują tekstowe LCP. Potwierdza to, że Twój mobilny układ CSS spycha baner Hero poniżej linii zgięcia (below the fold) lub skaluje go w dół na tyle mocno, że akapit tekstu staje się „największym” (Largest) elementem.
Jeśli w tym scenariuszu optymalizujesz obraz hero, aby poprawić mobilne LCP, marnujesz wysiłek. Przeglądarka nawet nie bierze tego obrazu pod uwagę. Musisz albo dostosować układ, aby przywrócić obraz do głównego widoku, albo przenieść swoją uwagę na optymalizację renderowania tekstu (fonty/CSS) dla użytkowników mobilnych.
