Core/Dash Dimensie: Element Type (LCP)
Verbeter de Largest Contentful Paint door verkeer te filteren op basis van het architecturale element type.
Trusted by market leaders · Client results
Dimensie: Resource: Element Type LCP (lcpet)
De Element Type (LCP) dimensie (lcpet) categoriseert de Largest Contentful Paint node in één van vier architecturale klassen: text, image, background-image of video.
Terwijl de Attribution Element dimensie de exacte DOM-node aanwijst, dicteert de Element Type dimensie je high-level engineering strategie. LCP is de som van vier tijdsintervallen: TTFB, Load Delay, Load Time, en Render Delay. Het Element Type vertelt je welke van deze intervallen je score schaadt, zodat je zonder te raden het juiste optimalisatieprotocol kunt selecteren.
De Core Web Vitals optimaliseren op basis van het LCP element type
Na het verbeteren van de TTFB, wat onafhankelijk is van het LCP element type, moet je een andere benadering kiezen voor het optimaliseren van de LCP door te kijken naar je LCP element type.
1. Tekst
Wanneer CoreDash tekst als het Element Type rapporteert, is de bandbreedte van statische netwerkbronnen zelden het knelpunt. Tekst bevindt zich direct in het HTML document, wat betekent dat de content direct beschikbaar is na de initiële serverreactie (TTFB). Als je LCP hier traag is, is het probleem vrijwel uitsluitend Render Delay.
Om dit op te lossen, focus je volledig op het Critical Rendering Path. De browser wordt waarschijnlijk geblokkeerd bij het renderen van de tekst door zware CSS berekeningen of synchrone JavaScript in de <head>. Controleer daarnaast je font loading strategie; als je geen font-display: swap of optional gebruikt, verbergt de browser de tekst kunstmatig (FOIT) terwijl hij wacht tot het fontbestand is gedownload.
2. Afbeelding (<img>)
Dit type activeert de volledige resource-pijplijn: discovery, download, en decode. In tegenstelling tot tekst is een image LCP sterk afhankelijk van Load Delay en Load Time. Je vecht hier tegen de wetten van de fysica en netwerklatency, dus je doel is om de asset lichter te maken en sneller vindbaar te laten zijn.
Optimalisatie vereist hier strikt assetmanagement. Zorg ervoor dat de <img> tag aanwezig is in de initiële HTML broncode (Server-Side Rendering) om Load Delay te minimaliseren. Voeg fetchpriority="high" toe en verwijder strikt alle loading="lazy" attributen, aangezien deze het verzoek van de browser vertragen. Pak ten slotte de Load Time aan door next-gen formaten (AVIF/WebP) te serveren en srcset te gebruiken om te voorkomen dat mobiele apparaten bestanden op desktopformaat downloaden.
3. Background Image
Deze classificatie wijst op een architecturale inefficiëntie. Omdat de afbeelding is gedefinieerd in CSS (bijv. background-image: url(...)), kan de browser de URL pas ontdekken nadat je stylesheets volledig zijn gedownload en geparseerd. Dit creëert een enorme Load Delay omdat de Preload Scanner de asset simpelweg niet kan zien.
De enige robuuste technische oplossing is refactoring. Verplaats de visuele asset van CSS naar een standaard HTML <img> tag om de URL direct aan de browser bloot te stellen. Als je de markup niet kunt refactoren, moet je <link rel="preload"> in de document head gebruiken om vroege ontdekking af te dwingen, hoewel dit vaak een extra onderhoudslast met zich meebrengt in vergelijking met het gebruik van een native image element.
4. Video
Wanneer het LCP element een video is, meet de browser de paint-tijd van de poster image of het eerste frame (indien autoplaying). Dit gedraagt zich vergelijkbaar met het Image type, maar is vaak zwaarder vanwege de bestandsgrootte van video assets.
Behandel dit strikt als een image optimalisatietaak. Zorg ervoor dat er een lichtgewicht poster attribuut aanwezig is in de HTML zodat de browser geen videosegmenten hoeft te downloaden om de eerste pixel te renderen. Comprimeer de poster image net zo agressief als je bij een standaard LCP image zou doen.
Workflow: LCP-problemen vinden op basis van het LCP element type
Het LCP Element Type is niet statisch en evenmin hetzelfde voor elke bezoeker. Het verandert regelmatig op basis van het apparaat van de gebruiker, wat fundamentele fouten in responsive design blootlegt.
Gebruik het CoreDash Device Form Factor filter om Element Types tussen Mobile en Desktop te vergelijken. Je zult vaak ontdekken dat Desktop gebruikers een image LCP krijgen (bijv. een Hero Banner), terwijl Mobile gebruikers een tekst LCP krijgen. Dit bevestigt dat je mobiele CSS lay-out de Hero Banner below the fold duwt, of deze zodanig verkleint dat een alinea met tekst het "Largest" element wordt.
Als je de hero image optimaliseert om de mobiele LCP in dit scenario te verbeteren, verspil je moeite. De browser telt de afbeelding niet eens mee. Je moet ofwel de lay-out aanpassen om de afbeelding terug in de primaire weergave te brengen, of je focus verleggen naar het optimaliseren van de text rendering (fonts/CSS) voor mobiele gebruikers.
