Core/Dash Dimensie: Element Type (LCP)
Verbeter de Largest Contentful Paint door verkeer te filteren op basis van het architectonische 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 een van de vier architectonische 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, waardoor je het juiste optimalisatieprotocol kunt selecteren zonder te raden.
Het optimaliseren van de Core Web Vitals per LCP element type
Na het verbeteren van de TTFB, wat onafhankelijk is van het LCP element type, moet je een andere aanpak kiezen voor het optimaliseren van de LCP door te kijken naar je LCP element type.
1. Tekst
Wanneer CoreDash tekst rapporteert als het Element Type, is de bandbreedte van statische netwerkbronnen zelden de bottleneck. Tekst bevindt zich direct in het HTML document, wat betekent dat de content onmiddellijk beschikbaar is na de initiële serverrespons (TTFB). Als je LCP hier traag is, is het probleem vrijwel uitsluitend Render Delay.
Om dit te verhelpen, focus je 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 strategie voor het laden van lettertypen; als je geen gebruik maakt van font-display: swap of optional, verbergt de browser de tekst kunstmatig (FOIT) terwijl deze wacht tot het lettertypebestand is gedownload.
2. Afbeelding (<img>)
Dit type activeert de volledige resource pipeline: discovery, download, en decode. In tegenstelling tot tekst is een afbeelding LCP sterk afhankelijk van Load Delay en Load Time. Je vecht hier tegen fysica en netwerklatentie, dus je doel is om de asset lichter en sneller ontdekbaar te maken.
Optimalisatie vereist hier strikt asset management. 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 consequent alle loading="lazy" attributen, aangezien deze het verzoek van de browser vertragen. Pak tot slot de Load Time aan door next-gen formaten (AVIF/WebP) aan te bieden en gebruik te maken van srcset om te voorkomen dat mobiele apparaten bestanden op desktopformaat downloaden.
3. Achtergrondafbeelding
Deze classificatie wijst op een architectonische inefficiëntie. Omdat de afbeelding is gedefinieerd in CSS (bijv. background-image: url(...)), kan de browser de URL pas ontdekken nadat deze je stylesheets volledig heeft gedownload en geparseerd. Dit veroorzaakt een enorme Load Delay omdat de Preload Scanner in feite blind is voor de asset.
De enige robuuste technische oplossing is refactoring. Verplaats de visuele asset van CSS naar een standaard HTML <img> tag om de URL onmiddellijk bloot te stellen aan de browser. Als je de markup niet kunt refactoren, moet je <link rel="preload"> gebruiken in de document head om vroege ontdekking af te dwingen, hoewel dit vaak een onderhoudslast met zich meebrengt vergeleken met het gebruik van een native afbeeldingselement.
4. Video
Wanneer het LCP element een video is, meet de browser de paint time van de poster image of de eerste frame (bij autoplaying). Dit gedraagt zich vergelijkbaar met het Afbeeldingstype, maar is vaak zwaarder vanwege de bestandsgrootte van video assets.
Behandel dit strikt als een beeldoptimalisatietaak. 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 afbeelding zou doen.
Workflow: LCP problemen vinden op basis van LCP element type
Het LCP Element Type is niet statisch en ook niet voor elke bezoeker hetzelfde. Het verandert regelmatig op basis van het apparaat van de gebruiker, wat fundamentele tekortkomingen in responsive design aan het licht brengt.
Gebruik het CoreDash Device Form Factor filter om Element Types te vergelijken tussen Mobiel en Desktop. Je zult vaak ontdekken dat Desktop gebruikers een afbeelding LCP krijgen (bijv. een Hero Banner), terwijl Mobiele gebruikers een tekst LCP krijgen. Dit bevestigt dat je mobiele CSS lay-out de Hero Banner below the fold duwt of deze zo aanzienlijk verkleint dat een alinea tekst het "Grootste" (Largest) element wordt.
Als je de hero afbeelding aan het optimaliseren bent om de mobiele LCP in dit scenario te verbeteren, verspil je 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 tekstrekering (fonts/CSS) voor mobiele gebruikers.
