Wymiar Core/Dash: Typ elementu (LCP)
Napraw Largest Contentful Paint, filtrując ruch na podstawie architektonicznego typu elementu.
Trusted by market leaders · Client results
Wymiar: Zasób: Typ elementu LCP (lcpet)
Wymiar Typ elementu (LCP) (lcpet) kategoryzuje węzeł Largest Contentful Paint do jednej 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 to suma czterech przedziałów czasowych: TTFB, Load Delay, Load Time i Render Delay. Typ elementu informuje, który z tych przedziałów obniża Twój wynik, pozwalając na wybór właściwego protokołu optymalizacji bez zgadywania.
Optymalizacja Core Web Vitals według typu elementu LCP
Po poprawie TTFB, które jest niezależne od typu elementu LCP, powinieneś przyjąć inne podejście do optymalizacji LCP, przyglądając się swojemu typowi elementu LCP.
1. Tekst
Gdy CoreDash zgłasza tekst jako Typ elementu, przepustowość statycznych zasobów sieciowych rzadko jest wąskim gardłem. Tekst znajduje się bezpośrednio w dokumencie HTML, co oznacza, że treść jest dostępna natychmiast po początkowej odpowiedzi serwera (TTFB). Jeśli Twoje LCP jest tutaj wolne, problemem jest prawie wyłącznie Render Delay.
Aby to naprawić, skup się całkowicie na Krytycznej Ścieżce Renderowania. Przeglądarka jest prawdopodobnie blokowana przed namalowaniem tekstu przez ciężkie obliczenia CSS lub synchroniczny JavaScript w sekcji <head>. Dodatkowo sprawdź swoją strategię ładowania czcionek; jeśli nie używasz font-display: swap lub optional, przeglądarka sztucznie ukrywa tekst (FOIT) w oczekiwaniu na pobranie pliku czcionki.
2. Obraz (<img>)
Ten typ uruchamia pełny potok zasobów: wykrywanie, pobieranie i dekodowanie. W przeciwieństwie do tekstu, obraz LCP jest silnie zależny od Load Delay i Load Time. Walczysz tutaj z fizyką i opóźnieniami sieci, więc Twoim celem jest uczynienie zasobu lżejszym i szybszym do wykrycia.
Optymalizacja w tym przypadku wymaga rygorystycznego zarządzania zasobami. Upewnij się, że tag <img> istnieje w początkowym źródle 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 zajmij się Load Time, serwując formaty nowej generacji (AVIF/WebP) i używając srcset, aby zapobiec pobieraniu przez urządzenia mobilne plików w rozmiarze desktopowym.
3. Obraz tła
Ta klasyfikacja sygnalizuje nieefektywność architektoniczną. Ponieważ obraz jest zdefiniowany w CSS (np. background-image: url(...)), przeglądarka nie może wykryć adresu URL, dopóki w pełni nie pobierze i nie sparsuje arkuszy stylów. Tworzy to ogromne Load Delay, ponieważ Preload Scanner jest w rzeczywistości ś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, chociaż jest to często obciążenie w utrzymaniu w porównaniu do użycia natywnego elementu obrazu.
4. Wideo
Gdy elementem LCP jest wideo, przeglądarka mierzy czas renderowania obrazu plakatu lub pierwszej klatki (przy autoodtwarzaniu). Zachowuje się to podobnie do typu obrazu, ale często jest cięższe ze względu na rozmiar plików zasobów wideo.
Traktuj to ściśle jako zadanie optymalizacji obrazu. Upewnij się, że w HTML obecny jest lekki atrybut poster, aby przeglądarka nie musiała pobierać segmentów wideo w celu wyrenderowania pierwszego piksela. Kompresuj obraz plakatu równie 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 wady w responsywnym designie.
Użyj filtra CoreDash Device Form Factor, aby porównać typy elementów między urządzeniami mobilnymi (Mobile) a komputerami stacjonarnymi (Desktop). Często odkryjesz, że użytkownicy Desktop mają obraz jako LCP (np. Hero Banner), podczas gdy użytkownicy Mobile mają tekst jako LCP. Potwierdza to, że Twój mobilny układ CSS spycha Hero Banner poniżej linii zgięcia (below the fold) lub skaluje go w dół na tyle znacząco, że akapit tekstu staje się elementem "Largest".
Jeśli w tym scenariuszu optymalizujesz hero image, 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 (czcionki/CSS) dla użytkowników mobilnych.
