Wymiar Core/Dash: Urls
Izoluj i naprawiaj wąskie gardła wydajności Core Web Vitals według konkretnych adresów URL
Trusted by market leaders
Wymiar: Strona i Nawigacja: adresy URL (u)
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 Attribution Element wskazuje dokładny węzeł DOM, wymiar Typ Elementu dyktuje strategię inżynieryjną wysokiego poziomu. LCP jest sumą czterech interwałów czasowych: TTFB, Load Delay, Load Time oraz Render Delay. Typ Elementu informuje, który z tych interwałó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 poprawieniu TTFB, które jest niezależne od typu elementu LCP, powinieneś przyjąć inne podejście do optymalizacji LCP, analizując poszczególne elementy LCP.
1. Tekst
Gdy CoreDash raportuje 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 Twój LCP jest tutaj wolny, problemem jest prawie wyłącznie Render Delay.
Aby to naprawić, skup się całkowicie na Critical Rendering Path. Przeglądarka jest prawdopodobnie blokowana przed namalowaniem tekstu przez ciężkie obliczenia CSS lub synchroniczny JavaScript w <head>. Dodatkowo sprawdź strategię ładowania fontów; jeśli nie używasz font-display: swap lub optional, przeglądarka sztucznie ukrywa tekst (FOIT) w oczekiwaniu na pobranie pliku fontu.
2. Obraz (<img>)
Ten typ uruchamia pełny potok zasobów: wykrywanie, pobieranie i dekodowanie. W przeciwieństwie do tekstu, LCP obrazu jest silnie zależne od Load Delay i Load Time. Walczysz tutaj z fizyką i opóźnieniami sieci, więc Twoim celem jest uczynienie zasobu lżejszym i szybciej wykrywalnym.
Optymalizacja w tym przypadku wymaga ścisłego 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 zajmij się Load Time, serwując formaty nowej generacji (AVIF/WebP) i używając srcset, aby zapobiec pobieraniu plików o rozmiarach desktopowych przez urządzenia mobilne.
3. Obraz tła (Background Image)
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 przetworzy arkuszy stylów. Tworzy to ogromny 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 ujawnić 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ż często stanowi to obciążenie w utrzymaniu w porównaniu z użyciem natywnego elementu obrazu.
4. Wideo
Gdy elementem LCP jest wideo, przeglądarka mierzy czas namalowania obrazu poster lub pierwszej klatki (jeśli odtwarzanie jest automatyczne). Zachowuje się to podobnie do typu Image, ale często jest cięższe ze względu na rozmiar plikó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 poster tak agresywnie, jak standardowy obraz LCP.
Workflow: 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 responsywnym designie.
Użyj filtra CoreDash Device Form Factor, aby porównać Typy Elementów między Mobile a Desktop. Często okaże się, że użytkownicy Desktop otrzymują obraz jako LCP (np. Hero Banner), podczas gdy użytkownicy Mobile otrzymują tekst jako LCP. Potwierdza to, że Twój układ CSS na urządzenia mobilne przesuwa Hero Banner poniżej linii zanurzenia lub skaluje go tak znacząco, że akapit tekstu staje się "Największym" elementem.
Jeśli w tym scenariuszu optymalizujesz obraz hero, aby poprawić mobilne LCP, marnujesz wysiłek. Przeglądarka nawet nie uwzględnia tego obrazu. Musisz albo dostosować układ, aby przywrócić obraz do głównego widoku, albo przenieść uwagę na optymalizację renderowania tekstu (fonty/CSS) dla użytkowników mobilnych.
