Hoe afbeeldingsgrootte de Core Web Vitals beïnvloedt

Welke Core Web Vitals spelen mee?

Largest Contentful Paint (LCP) meet wanneer de grootste zichtbare afbeelding of tekstgroep verschijnt. Dat kan een opvallende foto zijn, maar niet automatisch het logo of grootste bestand. Bepaal eerst het gemeten element. Googles LCP-gids onderscheidt ontdekking, downloaden en weergave.

Cumulative Layout Shift (CLS) meet onverwachte verschuivingen. Zonder gereserveerde ruimte kan een geladen afbeelding inhoud wegduwen. De CLS-gids adviseert afmetingen zodat de browser de verhouding vooraf kan reserveren.

Interaction to Next Paint (INP) betreft reacties op interacties. Een foto comprimeren verhelpt niet vanzelf een traag menu of zware klikafhandeling. Onderzoek die apart met de INP-documentatie.

Wanneer is een Core Web Vitals-resultaat goed?

De tabel toont de goede grenswaarden uit Googles Core Web Vitals-richtlijnen. Alle drie moeten hun doel halen op het 75e percentiel van echte bezoeken, waarbij mobiel en desktop apart worden beoordeeld. Een kleiner beeldbestand of één goede laboratoriumtest bewijst nog niet dat de pagina slaagt. Als INP het probleem is, onderzoek dan interactievertragingen in plaats van de foto steeds opnieuw te comprimeren.

Begin bij het zichtbare hoofdbeeld

Bekijk op een productpagina de hoofdfoto, bij een artikel de door het rapport genoemde afbeelding of titel. Noteer bestandsgrootte, pixelafmetingen en weergavegrootte voordat je een kopie maakt voor een bruikbare vergelijking.

Is de foto veel groter dan nodig, maak dan een kleinere versie met de resizer. Vergelijk vervolgens WebP via JPG naar WebP. Beoordeel noodzakelijke productdetails en tekst, niet alleen bespaarde kilobytes.

Laat de browser het hoofdbeeld vroeg laden

Gebruik geen lazy loading voor het LCP-beeld. Een klein bestand kan toch laat verschijnen als scripts de ontdekking uitstellen. Laat de thema- of siteontwikkelaar de echte aanvraag bekijken als compressie weinig helpt.

Gebruik vertraagd laden gericht voor afbeeldingen lager op de pagina. De eerste zichtbare galerijfoto is direct nodig; volgende foto's kunnen laden wanneer de bezoeker nadert.

Identificeer het gemeten LCP-beeld op de gepubliceerde pagina. Het moet vroeg vindbaar zijn en niet vertraagd laden. Een ontwikkelaar kan fetchpriority="high" voor dat specifieke beeld overwegen; dezelfde prioriteit voor alle galerijbeelden ondermijnt de keuze. Controleer de netwerkverzoeken opnieuw.

Houd de lay-out stabiel

Vermeld breedte en hoogte in de code en behoud de verhouding met responsieve stijlen. Controleer smalle telefoons en brede desktops. Reserveer bij bewuste uitsneden steeds de juiste weergaveruimte.

Onderzoek ook banners, ingesloten inhoud en lettertypen als beweging blijft. Een foto vervangen verhelpt geen melding die later boven het artikel wordt ingevoegd.

HTML-maten zoals width="1200" en height="800" geven de verhouding aan. CSS kan het beeld smaller tonen met max-width: 100% en height: auto. Controleer of het thema geen onverenigbare vaste hoogte oplegt. Bewust bijgesneden kaarten vragen een passend gereserveerd vlak.

Springt de alinea nog wanneer het kleinere beeld verschijnt, dan ontbreekt mogelijk nog gereserveerde ruimte. Herstel afmetingen of container en meet opnieuw. Omgekeerd kan een stabiel kader een traag beeld bevatten: ruimte reserveren verkleint het bestand niet.

Controleer één wijziging tegelijk

1. Noteer URL, testapparaat en probleemelement.
2. Wijzig één afbeelding of laadinstelling.
3. Controleer of de livepagina het nieuwe bestand aanvraagt in plaats van de oude cacheversie.
4. Herhaal dezelfde test en inspecteer het openingsscherm.
5. Behoud de wijziging wanneer kwaliteit en meting haar ondersteunen.

Exporteren is maar een onderdeel van prestaties. Ga verder met de PageSpeed-werkwijze.