Core Web Vitals op Hyvä: LCP onder 2 seconden op mobiel

Largest Contentful Paint, of LCP, meet hoe lang het duurt voordat het grootste element op het scherm verschijnt. Op een Magento-webshop is dat meestal de hoofdproductfoto, een categoriebanner of de hero op de homepage.

Google beschouwt een LCP van 2,5 seconden of minder als goed. Wij mikken lager, op minder dan 2 seconden op mobiel, omdat echte shoppers met middenklasse-telefoons en wisselende verbindingen trager zijn dan welke labtest ook. In dit artikel lees je wat Hyvä doet voor de LCP, en wat je zelf nog moet doen. Het weerspiegelt het snelheidswerk achter elke Hyvä-webshop die we bouwen.

Wat onze metingen laten zien

We vergeleken een schone Magento 2.4.9 met Hyvä 1.5.2 met het Luma-thema van Magento. Beide draaiden op dezelfde server met dezelfde catalogus, getest met Lighthouse 13, op basis van de mediaan van drie mobiele runs.

Dat is een ongeveer 35% snellere LCP op mobiel voor Hyvä. De volledige methode en alle paginatypen vind je in onze Hyvä vs Luma-benchmark.

Eén eerlijke kanttekening hoort hier. Een schone Luma-webshop op een snelle server achter Cloudflare, in production mode, scoort ook goed. Echte Luma-webshops met extensies en trackingscripts scoren meestal veel lager. Het echte verschil zit in hoeveel de browser moet laden, niet in de labscore.

Waarom Hyvä de LCP helpt

Een Luma-pagina moet ongeveer een halve megabyte JavaScript downloaden, parsen en uitvoeren voordat een groot deel van de pagina werkt. RequireJS laadt modules in ketens, en de main thread blijft bezig terwijl de afbeelding op haar beurt wacht.

Hyvä gebruikt in plaats daarvan Alpine.js en Tailwind CSS. Met ongeveer 26 KB JavaScript bereikt de browser de hoofdafbeelding sneller en heeft die minder werk dat ermee concurreert.

Op echte budgettelefoons weegt een halve megabyte JavaScript zwaarder dan het lab laat zien. Daarom doet Hyvä het ook vaak goed op Interaction to Next Paint, of INP: minder script betekent een main thread die klaar staat om op tikken te reageren.

Stap één: een snelle serverrespons

De LCP kan niet beginnen voordat de HTML binnen is. Als de server lang over een antwoord doet, kan geen enkele frontend dat goedmaken.

Onze stack voor Hyvä-webshops ziet er zo uit:

• Magento 2.4.9 op PHP 8.4, in production mode met static content deploy.
• Redis of Valkey voor cache en sessies, en OpenSearch voor het zoeken in de catalogus.
• nginx met een aparte PHP-FPM-pool per webshop.
• Cloudflare ervoor, en indexers op schema, zodat opslaan in de admin de storefront niet vertraagt.

Full-page cache maakt de meeste paginaweergaven snel. Een gecachete categorie- of productpagina wordt geserveerd zonder de volledige Magento-applicatie te draaien. Hostingkeuzes behandelen we uitgebreider in onze gids over de beste Magento-hosting.

Stap twee: zorg dat de LCP-afbeelding klopt

Op de meeste Magento-pagina's is het LCP-element een afbeelding. Vier gewoontes maken het grootste verschil.

1. Lazy-load de hoofdafbeelding nooit. Lazy loading is goed voor afbeeldingen verderop op de pagina, maar de eerste productfoto of hero moet meteen laden.
2. Vertel de browser dat het belangrijk is. De fetchpriority="high" -attribuut op de hoofdafbeelding helpt de browser om die te downloaden vóór minder belangrijke bestanden.
3. Serveer het juiste formaat. Een telefoon heeft geen foto op desktopformaat nodig, dus gebruik de geschaalde afbeeldingen die Magento voor elke afbeeldingsrol maakt.
4. Gebruik een lichter formaat. We serveren WebP voor product- en thema-afbeeldingen, zoals beschreven in ons artikel over WebP-afbeeldingen achter Cloudflare.

Stel ook altijd de breedte en hoogte van afbeeldingen in. Dat verandert de LCP niet direct, maar voorkomt layoutverschuivingen tijdens het laden van de pagina.

Stap drie: bescherm de pagina tegen nieuw gewicht

De meeste Hyvä-webshops zijn snel op de dag van de livegang. Het risico komt later, als trackingtags, chatwidgets, reviewwidgets en marketingpixels één voor één worden toegevoegd.

Elk script concurreert met de hoofdafbeelding om bandbreedte en processortijd. We houden ons aan een paar regels:

• Laad scripts van derden pas als de pagina bruikbaar is, tenzij ze nodig zijn voor de eerste weergave.
• Laad elke trackingtool één keer, het liefst via één tagmanager en niet via meerdere modules.
• Controleer nieuwe extensies op achtergebleven Luma-JavaScript voordat ze live gaan.
• Test home-, categorie- en productpagina's opnieuw na elke wijziging aan scripts of extensies.

Ook lettertypen tellen mee. Eén zelf gehoste fontfamilie met een paar gewichten is meestal genoeg, en voorkomt extra verbindingen met andere servers.

Stap vier: meet het goed

Labtests zijn alleen nuttig als ze het echte werk testen. We gebruiken Lighthouse 13 vanaf de commandline met headless Chrome, nemen de mediaan van drie runs en testen de echte URL achter de CDN nadat de cache is opgewarmd.

Eén valkuil kostte ons tijd: onze nginx blokkeert bot-user-agents met “lighthouse” of “headless” erin, wat een 403 en een betekenisloos resultaat opleverde. Door de tests met een normale browser-user-agent te draaien was het opgelost. Alle valkuilen zetten we op een rij in hoe we de snelheid van Hyvä testen met Lighthouse.

Labresultaten zijn een richtlijn, niet het eindoordeel. Velddata van echte bezoekers, zoals gerapporteerd in Search Console en het Chrome UX Report, is wat Google gebruikt voor Core Web Vitals.

Hoe dit eruitziet op echte webshops

Op onze Hyvä-demowebshop zijn de mediane mobiele Lighthouse-scores 96 voor de homepage, 90 voor een categorie en 92 voor een productpagina. Op desktop zijn dat 100, 100 en 98.

Bij een klantwebshop, een Duitse webshop die in negen landen verkoopt, ging de mobiele Lighthouse-score van een productpagina door de overstap naar Hyvä van 72 naar 94, en die van een categoriepagina van 88 naar 95. Die cijfers komen van een stagingbuild, volgens onze metingen.

Voor elke Hyvä-webshop die we lanceren, garanderen we een mobiele Lighthouse Performance-score van minimaal 89 op home-, categorie- en productpagina's. Dat geldt op een voor Hyvä geoptimaliseerde server, met vooraf afgesproken afbeeldingen en scripts.

Veelgestelde vragen

Garandeert Hyvä goede Core Web Vitals?

Geen enkel thema kan dat op zichzelf garanderen. Hyvä geeft je een veel lichter vertrekpunt, maar de server, afbeeldingen en scripts van derden bepalen nog steeds het eindresultaat.

Waarom is mijn Hyvä-webshop trager dan de benchmark?

De gebruikelijke oorzaken zijn een trage serverrespons, een niet-geoptimaliseerde hoofdafbeelding of scripts die na de livegang zijn toegevoegd. Een Magento 2-audit laat zien welke daarvan voor jouw webshop geldt.

Is de LCP de enige metric die telt?

Nee. INP en Cumulative Layout Shift zijn ook Core Web Vitals. Onze Core Web Vitals-checklist behandelt alle drie.

Wil je een LCP onder 2 seconden in je eigen webshop? Bekijk onze Hyvä-pakketten, of praat met ons over Magento-snelheidsoptimalisatie.