Productfotostrategie voor Hyvä-webshops

Hyvä haalt het grootste deel van het JavaScript- en CSS-gewicht weg dat Luma meesleept. Als dat gewicht weg is, blijven de afbeeldingen over.

Op de meeste product- en categoriepagina's is het grootste element op het scherm een productfoto. Daardoor is je afbeeldingsstrategie de grootste hefboom die je nog in handen hebt voor Largest Contentful Paint (LCP).

In dit artikel beschrijven we de aanpak die we op Hyvä-webshops gebruiken: hoe we afbeeldingen voorbereiden, hoe we ze serveren en welke fouten ons tijd kostten.

Waarom afbeeldingen na een overstap naar Hyvä zwaarder wegen

In onze benchmark van Hyvä versus Luma, woog een schone Hyvä-pagina ongeveer 200 KB en bevatte die zo'n 26 KB JavaScript.

Eén niet-geoptimaliseerde productfoto kan zwaarder zijn dan die hele pagina.

Op Hyvä kan één te grote hero-afbeelding of een galerij die alle foto's tegelijk laadt dus veel tenietdoen van wat het thema je oplevert.

Het goede nieuws: afbeeldingen zijn makkelijk te meten en makkelijk op te lossen, zodra de pipeline goed is ingericht.

Begin met consistente bronafbeeldingen

Performance begint vóór de upload. Consistente bronafbeeldingen maken elke volgende stap eenvoudiger.

• Eén beeldverhouding per afbeeldingstype. Als elke productfoto dezelfde verhouding heeft, verspringt het raster nooit en zien de geschaalde kopieën van Magento er allemaal hetzelfde uit.
• Een neutrale, consistente achtergrond. Zo blijven categoriepagina's rustig en comprimeren bestanden beter.
• Een vast aantal afbeeldingen per product. Op onze Hyvä-demowebshop gebruiken we twee consistente studiofoto's per product, zodat elke kaart en galerij zich hetzelfde gedraagt.
• Een verstandig bronformaat. Upload groot genoeg om in te zoomen, maar geen camera-originelen van vele megabytes.

Consistentie is ook een conversiethema. Klanten vergelijken producten sneller als de foto's dezelfde regels volgen.

Houd JPG als bron en laat Magento schalen

Het is verleidelijk om WebP-bestanden direct te uploaden. We hebben het geprobeerd, en met een standaardinrichting werkt dat niet goed.

De standaard GD-image-adapter van Magento weigert WebP-bronbestanden met de foutmelding “Unsupported image format”.

Daarom houden we JPG-bronnen in de mediagalerij. Magento genereert dan de geschaalde kopieën die nodig zijn voor elke afbeeldingsrol, zoals de thumbnail in het overzicht en de afbeelding op de productpagina.

Na een import of themawijziging genereren we de resize-cache vooraf, in plaats van te wachten tot bezoekers dat doen:

bin/magento catalog:images:resize

Dit commando kan op een grote catalogus even duren. Draai het buiten de piekuren en vóórdat je de CDN purget.

Voeg WebP-kopieën toe met een cronjob

Zodra de geschaalde JPG's bestaan, maken we naast elk bestand een WebP-kopie.

Een cronjob draait cwebp -q 80 en schrijft file.jpg.webp naast elke geschaalde afbeelding die nog geen WebP-kopie heeft.

find pub/media/catalog/product/cache -name '*.jpg' \
  ! -exec test -e '{}.webp' \; \
  -exec cwebp -quiet -q 80 '{}' -o '{}.webp' \;

De JPG blijft op de schijf staan, dus er gaat niets kapot als een WebP-kopie ontbreekt. Alle moderne browsers ondersteunen WebP, dus in de praktijk krijgt bijna elke bezoeker het kleinere bestand.

Thema-afbeeldingen zoals de tegels op de homepage en de inlogpagina exporteren we direct als WebP, 720 px breed en met een kwaliteit van ongeveer 72. Dat zijn designassets, geen catalogusafbeeldingen, dus ze hebben de resize-stap van Magento niet nodig.

Serveer de WebP-URL met een kleine plugin

De klassieke manier om WebP te serveren is Accept-header-negotiation in nginx. Dat werkte bij ons niet achter het instapabonnement van Cloudflare, omdat Cloudflare zijn afbeeldingscache niet laat variëren op de Accept-header.

Daarom hebben we de beslissing naar Magento verplaatst. Een kleine plugin op Magento\Catalog\Model\View\Asset\Image verandert de URL als er een WebP-kopie op de schijf staat.

public function afterGetUrl(Image $subject, string $result): string
{
    if (is_file($subject->getPath() . '.webp')) {
        return $result . '.webp';
    }
    return $result;
}

De HTML verwijst nu rechtstreeks naar het WebP-bestand. De CDN cachet het als een gewoon statisch bestand, en er is geen headerlogica die mis kan gaan.

De volledige opzet, inclusief de CDN-details, beschrijven we in WebP-productafbeeldingen in Magento achter Cloudflare.

Laadvolgorde: de LCP-afbeelding eerst

Ook een licht bestand laadt traag als de browser het laat ophaalt. De laadvolgorde is net zo belangrijk als de bestandsgrootte.

• Lazy-load de hoofdproductafbeelding nooit. De eerste galerijafbeelding is meestal het LCP-element op een productpagina, dus die moet direct laden.
• Overweeg fetchpriority="high" op die eerste afbeelding, zodat de browser hem vroeg ophaalt.
• Lazy-load alles onder de vouw. Verdere galerijafbeeldingen, gerelateerde producten en footerbanners kunnen wachten.
• Behandel de eerste rij van een categoriepagina anders. De eerste productkaarten zijn meteen zichtbaar, dus die mogen niet op lazy loading wachten.
• Stel altijd breedte en hoogte in. Expliciete afmetingen voorkomen dat de layout verspringt terwijl afbeeldingen binnenkomen.

Hyvä-templates zijn gewone PHTML met Alpine.js, dus deze wijzigingen zijn klein en leesbaar in een child theme. Bekijk onze gids over een Hyvä-child theme op de juiste manier bouwen om te zien waar zulke overrides thuishoren.

Valkuilen waar we tegenaan liepen

De meeste afbeeldingsproblemen die we zagen gingen niet over formaten, maar over timing en caching.

• Afbeeldingen die in de CDN waren gecachet voordat de resize-cache bestond. De CDN bleef het oude antwoord serveren. Na een volledige resize purgen we de CDN per hostname.
• WebP via de Accept-header genegeerd door de CDN. Daarom serveren we WebP via de URL.
• Homepagebanners geüpload op volledig cameraformaat. Eén CMS-banner kan zwaarder zijn dan de rest van de pagina, dus stellen we duidelijke exportregels op voor het contentteam.
• Te veel afbeeldingen in de eerste viewport. Sliders met meerdere grote slides laden meer dan de bezoeker ziet.

Een praktische checklist

1. Spreek één beeldverhouding en achtergrondstijl af voor productfoto's.
2. Upload JPG-bronnen in een verstandig formaat.
3. Voer catalog:images:resize na imports en themawijzigingen.
4. Maak WebP-kopieën met een cronjob en serveer ze via de afbeeldings-URL.
5. Laad de LCP-afbeelding direct en lazy-load de rest.
6. Purge de CDN na een volledige resize en test daarna opnieuw.

Op onze Hyvä-demowebshop helpt deze aanpak ons aan mobiele Lighthouse-scores van 96 op de homepage, 90 op een categorie en 92 op een product (mediane runs).

Afbeeldingen maken ook deel uit van de afspraak achter ons lanceringsdoel van minimaal 89 voor mobiele Lighthouse Performance op home-, categorie- en productpagina's. Dat doel gaat uit van een voor Hyvä geoptimaliseerde server en afgesproken afbeeldingen en scripts.

Veelgestelde vragen

Kan ik WebP-afbeeldingen direct naar Magento uploaden?

Niet betrouwbaar met de standaard GD-adapter, die WebP-bronnen weigert met de foutmelding “Unsupported image format”. We houden JPG-bronnen aan en genereren WebP-kopieën nadat Magento ze heeft geschaald.

Heb ik nog JPG-bestanden nodig als alle browsers WebP ondersteunen?

We houden ze, omdat Magento vanuit JPG schaalt en omdat ze een veilige fallback zijn. Ontbreekt een WebP-kopie, dan wordt automatisch de JPG-URL gebruikt.

Moet elke productafbeelding lazy-loaded worden?

Nee. De hoofdproductafbeelding en de eerste zichtbare categoriekaarten moeten direct laden. Lazy loading is voor afbeeldingen onder de vouw.

Wil je een Hyvä-webshop waarin afbeeldingen vanaf het begin zijn doordacht? Bekijk onze dienst voor Hyvä-themaontwikkeling, of vraag een audit van je huidige webshop.