Werkt Magento 2 met het Hyvä-thema altijd sneller dan met elk ander thema?

Stel u twee Magento-webshops voor. De eerste gebruikt Hyvä, maar laadt bij binnenkomst meteen een tiental marketingtools, haalt grote afbeeldingen op en genereert de pagina telkens opnieuw. De tweede heeft een ander, zorgvuldig geoptimaliseerd thema, een goed werkende cache en alleen de scripts die de klant nodig heeft.

Welke is sneller? De naam van het thema is niet genoeg om daar antwoord op te geven.

Hyvä geeft Magento een zeer goed vertrekpunt voor het bouwen van een snelle webshop. Het biedt echter geen onvoorwaardelijk voordeel ten opzichte van elke andere implementatie. Het resultaat hangt af van het hele traject tussen het klikken op een link en het moment waarop de klant het product ziet en kan kopen.

Daarom is het de moeite waard om een Hyvä-implementatie te combineren met een controle van de server, modules, afbeeldingen en het interfaceontwerp. Dan kunt u werken aan een ambitieus doel: 95–100 punten in Google PageSpeed Insights, met behoud van de functies die nodig zijn voor verkoop.

Wat betekent een score van 95–100 in PageSpeed eigenlijk?

In de praktijk spreken we vaak over 100% in PageSpeed, maar de tool toont punten op een schaal van 0 tot 100. In het onderdeel dat op Lighthouse is gebaseerd, worden vier verschillende gebieden beoordeeld:

Deze beoordelingen vervangen elkaar niet. Een snelle webshop kan onduidelijke knoppen hebben. Een technisch correcte webshop kan te veel JavaScript downloaden. Lighthouse is een diagnostische tool en de reikwijdte van de audits omvat niet de volledige kwaliteit van de webshop. Beschrijving van Lighthouse.

De Performance-score komt uit een laboratoriummeting en kan per test verschillen. PageSpeed toont ook, indien beschikbaar, gegevens van echte gebruikers uit CrUX, verzameld over een voortschrijdende periode van 28 dagen. Een nieuwe implementatie verandert niet meteen deze volledige dataset. Hoe PageSpeed Insights werkt.

In de praktijk hebben we twee doelen nodig: herhaalbaar goede tests en goede klantervaringen. Voor Core Web Vitals betekent dit:

• LCP tot 2,5 s — snelle weergave van het grootste element in het zichtbare gebied;
• INP tot 200 ms — vlotte reactie op interacties;
• CLS tot 0,1 — een stabiele pagina-indeling.

Deze drempels worden beoordeeld op het 75e percentiel, afzonderlijk voor mobiele apparaten en desktops. De standaard laadtijdtest van Lighthouse meet geen INP; voor de diagnose van browserblokkering gebruikt deze onder meer TBT. Een lage TBT is niet automatisch een bevestiging van een goede INP. Core Web Vitals.

Hoe helpt Hyvä Magento sneller te maken?

Hyvä vermindert het gewicht van de frontend ten opzichte van de standaard Luma. Het gebruikt Alpine.js voor interacties en Tailwind CSS voor styling. Minder code om te downloaden en uit te voeren geeft de browser meer ruimte om het aanbod snel te tonen. De Hyvä-documentatie wijst het beperken van JavaScript en CSS aan als een belangrijk onderdeel van deze architectuur. Hyvä-prestaties.

Dat voordeel kan echter gemakkelijk kleiner worden. Het is voldoende om aan een lichte frontend een uitgebreide slider, chat, meerdere trackers en modules toe te voegen die oude afhankelijkheden uit het vorige thema meenemen.

Hyvä lost ook geen trage databasequery, niet-werkende cache of server op die bezig is met import. Daarom zou de vraag vóór implementatie moeten zijn: wat vertraagt vandaag de aankoop en welke van deze problemen lost een wijziging van de frontend op?

1. Server: nginx en Varnish moeten het juiste werk doen

Voordat de browser een product toont, moet deze het HTML-document ontvangen. Als er lang wordt gewacht op de eerste byte van de response, start zelfs een licht thema met vertraging.

Nginx: efficiënte levering van resources

In een typische Magento-architectuur verwerkt nginx onder meer HTTPS, statische bestanden en het doorsturen van requests naar volgende services. Het is de moeite waard om compressie van tekstresponses, HTTP/2 en cacheheaders voor geversioneerde CSS- en JS-bestanden te controleren. Adobe biedt een voorbeeldconfiguratie van nginx als uitgangspunt voor een implementatie met Varnish. Varnish-configuratie in Adobe Commerce.

Niet alle responses moeten dezelfde bewaartijd krijgen. Een geversioneerd CSS-bestand kan lang vanuit de browsercache worden gebruikt. Prijs, winkelwageninhoud en een response met betrekking tot een ingelogde klant vereisen een andere behandeling.

Als de server WebP kiest op basis van de header Accept, moeten ook de cache key en de header Vary: Accept worden gecontroleerd. De browser en tussenliggende cachelagen moeten afbeeldingsvarianten kunnen onderscheiden.

Varnish: we controleren cachehits, niet alleen of de service is geïnstalleerd

Met Varnish kunnen publieke pagina’s vanuit de cache worden bediend zonder dat Magento al het werk opnieuw hoeft uit te voeren. Adobe raadt het gebruik ervan aan in een productieomgeving. Magento-cachebeheer.

De praktische test is eenvoudig: we openen hetzelfde publieke adres meerdere keren en controleren of er na de eerste response HIT-treffers verschijnen. Vervolgens vergelijken we de responstijd vanuit cache met de tijd die nodig is om de pagina te genereren bij MISS.

Als een populaire categorie de cache voortdurend omzeilt, moet de oorzaak worden gevonden: configuratie, cookies, URL-parameters, personalisatie of de werking van een module. Het kopen van een grotere server kan het probleem dan alleen maskeren.

Ook correctheid is belangrijk. De cache mag de winkelwagen of gegevens van de ene klant niet aan een andere gebruiker tonen. Winkelvarianten, valuta’s en klantgroepen moeten worden getest, evenals het verversen van content na een productwijziging. Een snelle maar verouderde prijs is geen succes van optimalisatie.

Naast nginx en Varnish controleren we PHP-FPM, OPcache, backend cache die past bij de Magento-versie, de database, cron en indexering. Het aantal PHP-processen moet voortkomen uit het beschikbare geheugen en de werkelijke belasting. Dit aantal zonder meting verhogen kan de situatie verslechteren.

2. Modules voor Hyvä: compatibiliteit is pas het begin

Een module kan correct werken met Hyvä en toch te veel werk uitvoeren bij het openen van de pagina. Goede optimalisatie omvat daarom zowel de functie als de kosten om deze te starten.

Bij kowal.store passen we onze modules aan Hyvä aan en ontwikkelen we ze met het oog op het behoud van de prestaties van dit thema na installatie. We zorgen ervoor dat nieuwe functies de frontend niet onnodig belasten — door afhankelijkheden te beperken en JavaScript en CSS op de juiste manier te laden. Bekijk onze Magento 2-modules en kies extensies voor uw webshop. Het effect van een specifieke implementatie is het waard om met metingen te bevestigen, omdat het ook afhangt van de configuratie en de overige integraties.

Neem chat als voorbeeld. Een klant die een categorie bekijkt, heeft in het begin een knop nodig om een gesprek te openen. De uitgebreide chatinterface en de bijbehorende bibliotheken kunnen worden gedownload bij het openen. Op vergelijkbare wijze kunnen volledige zoeksuggesties worden voorbereid wanneer het zoekveld wordt geactiveerd, terwijl het formulier direct zichtbaar en bruikbaar blijft.

Deze aanpak beschrijft Hyvä ook in de aanbevelingen voor het laden van externe JavaScript.

defer, async en het uitstellen van een component zijn verschillende dingen

defer maakt het mogelijk om een extern klassiek script uit te voeren nadat het document is verwerkt en behoudt de volgorde van scripts van dit type. async voert het script uit zodra het klaar is, zonder garantie voor de volgorde ten opzichte van andere scripts. Geen van deze attributen betekent op zichzelf dat het bestand pas na een klik wordt gedownload.

Hyvä biedt ook x-defer, waarmee de initialisatie van een Alpine-component kan worden uitgesteld, bijvoorbeeld tot deze in de buurt van het zichtbare gebied komt. Dit is geen automatische uitstel van het downloaden van al zijn bestanden. U moet ook rekening houden met events die de component vóór initialisatie kan missen, bijvoorbeeld events die verband houden met klantgegevens. x-defer-documentatie.

Wijzigingen moeten worden gecontroleerd in de winkelwagen, filters, formulieren en analytics-events. Alleen de aanwezigheid van het attribuut defer bewijst niet dat de module goed is geoptimaliseerd.

CSS: de benodigde vormgeving moet klaar zijn vóór de eerste render

Stijlen voor de header, productlijst en mobiele lay-out zijn vanaf het begin nodig. Als ze te laat worden geladen, kan dit flikkeren van de pagina en verschuivende elementen veroorzaken. Tegelijkertijd hoeft een productcategorie niet alle stijlen van elke geïnstalleerde module te downloaden.

Het is de moeite waard om globale stylesheets te beperken, restanten van het oude thema te verwijderen en de productie-build van Tailwind te controleren. Bij dynamisch gemaakte classes moet u ervoor zorgen dat de benodigde regels in de uiteindelijke CSS terechtkomen. Kritische CSS die in HTML is opgenomen kan helpen, maar vereist onderhoud en tests; het zou niet het eerste antwoord op elk probleem moeten zijn. Resources die renderen blokkeren.

Analytics en SEO-gegevens hebben ook hun prijs

Tijdens het optimaliseren van een webshop op Magento 2 hebben we de belasting door analytics op een categoriepagina gecontroleerd. GTM en gtag waren verantwoordelijk voor ongeveer 304 KB, oftewel 44% van de overdracht die in de eerste mobiele meting werd geregistreerd. Dat is een goede reden om tags en triggers te bekijken. Het betekent niet dat u alle analytics zonder nadenken moet uitstellen: zo’n wijziging kan het aantal geregistreerde bezoeken en events veranderen.

Het is ook de moeite waard om naar de HTML zelf te kijken. Uitgebreide JSON-LD-gegevens, gedupliceerde productinformatie en moduleconfiguraties vergroten de serverresponse. JSON-LD wordt niet uitgevoerd als een gewoon JavaScript-programma, maar moet nog steeds worden verzonden. Gestructureerde gegevens van de categorie moeten overeenkomen met de zichtbare lijst, de paginering en de volgorde.

3. Afbeeldingen: formaat, grootte en downloadmoment tellen mee

Een bronafbeelding van enkele duizenden pixels breed zou niet onnodig in een kleine producttegel terecht moeten komen. We bereiden varianten voor die passen bij de weergavegrootte en schermdichtheid, en srcset en sizes helpen de browser het juiste bestand te kiezen. WebP of AVIF kunt u het beste vergelijken op kwaliteit en gewicht voor specifieke afbeeldingen.

Het belangrijkste onderscheid gaat over afbeeldingen die direct zichtbaar zijn en afbeeldingen die lager op de pagina staan. Een afbeelding die de LCP vormt, moet gemakkelijk in de HTML te ontdekken zijn, zonder loading='lazy'; fetchpriority='high' kan gerechtvaardigd zijn. Afbeeldingen buiten het eerste scherm zijn goede kandidaten voor lazy loading. Afmetingen of verhoudingen reserveren voor hen ruimte in de lay-out. Responsieve afbeeldingen.

We geven echter niet elke afbeelding een hoge prioriteit. De browser heeft informatie nodig over wat echt het belangrijkst is. Fetch Priority.

We controleren ook CMS-banners, logo, favicon, videothumbnails en popup-afbeeldingen. Optimalisatie moet het proces voor het toevoegen van nieuwe bestanden omvatten, anders brengt de volgende campagne zware afbeeldingen terug.

Alleen een adres dat eindigt op .png bepaalt niet wat de browser downloadt. De server kan onder dat adres WebP leveren. We verifiëren Content-Type en de overdracht op het tabblad Network.

4. Kleurgebruik: de grootste invloed ziet u bij toegankelijkheid

Een blauwe knop groen maken versnelt Magento niet. Kleur is echter wel van groot belang voor leesbaarheid en de Accessibility-score.

De meest voorkomende problemen worden veroorzaakt door lichtgrijze beschrijvingen, pastelkleurige knoppen met witte tekst, promotielabels en tekst op afbeeldingen. Volgens WCAG moet het contrast van gewone tekst minimaal 4,5:1 bedragen en dat van grote tekst 3:1. Grote tekst betekent minimaal 18 pt, oftewel ongeveer 24 px, of 14 pt bij vetgedrukte tekst, oftewel ongeveer 18,7 px. Vereisten voor tekstcontrast.

Voor belangrijke visuele elementen van controls en statusindicatoren geldt ook een contrastvereiste van 3:1 ten opzichte van aangrenzende kleuren, met de uitzonderingen die in de standaard zijn beschreven. Contrast van niet-tekstuele elementen.

Het is verstandig om het palet centraal te definiëren, bijvoorbeeld via CSS-variabelen of de configuratie van een kleurmodule. Daardoor omvat een wijziging van tekst- of knopkleur de hele webshop. Ook hover-, focus- en foutstatussen van formulieren en geselecteerde filters moeten worden gecontroleerd. Een rode rand mag niet de enige informatie zijn dat een veld een fout bevat.

De manier waarop de vormgeving wordt geïmplementeerd kan invloed hebben op de prestaties: extra stylesheets, een script dat kleuren na het laden wijzigt of zware visuele effecten. Het palet zelf is echter geen vervanging voor optimalisatie van JS, afbeeldingen en server.

Waarom is één goede score niet genoeg?

Bij het optimaliseren van een Magento 2-webshop met Hyvä hebben we twee lokale Lighthouse-metingen uitgevoerd voor dezelfde categoriepagina. Op mobiel behaalden we 94 en 73 punten. De LCP bedroeg respectievelijk 2,5 en 5,7 s, hoewel het in beide gevallen om dezelfde afbeelding van het eerste product ging. Desktop haalde 100 punten.

Al deze runs meldden een overschrijding van de laadtijdlimiet, dus we behandelden de resultaten als diagnostisch en mogelijk onvolledig. Het waren geen bevestigde PageSpeed Insights-resultaten of CrUX-gegevens. Het is ook geen vergelijking van Hyvä met een ander thema.

In de zwakkere test werd de afbeelding snel gedownload, maar de weergave ervan vond later plaats. Dit laat zien waarom u downloadtijd en rendertijd van elkaar moet scheiden. Het bestand verder comprimeren verklaart zo’n probleem op zichzelf niet. Analyse van LCP-fasen.

Bij het werken aan een webshop vergelijken we meerdere tests, de mediaan en de spreiding, met behoud van dezelfde omstandigheden. Rapporten met fouten behandelen we niet als stabiel referentiepunt. We controleren ook het gedrag na het accepteren van cookies, na het openen van de zoekfunctie en na het toevoegen van een product aan de winkelwagen.

Magento- en Hyvä-checklist: de weg naar 95–100 punten

De onderstaande lijst helpt bij het plannen van een audit en de oplevering van werkzaamheden. Het is geen garantie op vier scores van 100/100. De beoordeling hangt af van de pagina, configuratie, testomstandigheden en Lighthouse-versie. Een groene score vervangt ook geen handmatige toegankelijkheidstests, beveiligingsaudit of SEO-strategie.

Meting en referentiepunt

• De homepage, categorie, productpagina, zoekfunctie en belangrijke aankoopstappen zijn onderzocht.
• Er zijn afzonderlijke metingen voor mobiel en desktop uitgevoerd, in meerdere vergelijkbare tests.
• De toolversie, het apparaatprofiel, de toestemmingsstatus en de resultaatrange zijn vastgelegd; time-outs zijn verklaard.
• LCP, INP en CLS zijn gecontroleerd met CrUX of eigen monitoring, indien beschikbaar.
• Gegevens van één URL zijn onderscheiden van gegevens van het hele domein.
• Het eerste bezoek, een terugkerende gebruiker en de werking na interactie zijn getest.

Server, nginx en Varnish — Performance

• Magento draait in productiemodus, met correct voorbereide statische resources.
• Publieke pagina’s behalen Varnish HIT; ook de responstijd bij MISS is gecontroleerd.
• De cache onderscheidt winkelvarianten correct en privégegevens komen niet in een gedeelde response terecht.
• Een wijziging van product, prijs of content maakt de juiste cache correct ongeldig.
• Nginx comprimeert geschikte tekstresources en ondersteunt een modern HTTP-protocol.
• Geversioneerde bestanden hebben passende cacheheaders; HTML en privéresponses hebben een afzonderlijk beleid.
• PHP-FPM, OPcache en backend cache zijn geconfigureerd in overeenstemming met de Magento-versie en serverresources.
• Cron, indexering, imports en bots veroorzaken geen pieken in responstijd.

Modules, JavaScript en CSS — Performance

• Elke actieve module heeft een zakelijke rechtvaardiging; onnodige functieduplicaten zijn verwijderd.
• Hyvä-integraties brengen niet onnodig zware afhankelijkheden van de vorige frontend terug.
• JS en CSS van modules komen alleen terecht op pagina’s die hun functies gebruiken.
• Scripts zijn uitgesteld met behoud van afhankelijkheden, volgorde en initialisatie-events.
• Selectieve x-defer en het laden van componenten bij gebruik zijn getest.
• Kritische stijlen zijn beschikbaar vóór de eerste render; er treedt geen lay-outflikkering op.
• GTM, pixels, chat en widgets hebben gecontroleerde triggers en opstartkosten.
• Wijzigingen in analytics behouden het afgesproken toestemmingsgedrag en correcte e-commerce-events.
• HTML, DOM en JSON-LD bevatten geen overbodige, gedupliceerde gegevens.
• Winkelwagen, filters, sortering, paginering en checkout werken na optimalisatie.

Afbeeldingen en lay-outstabiliteit — Performance

• Afbeeldingen hebben passende afmetingen, kwaliteit en formaat; de daadwerkelijke overdracht is geverifieerd.
• Responsieve afbeeldingsvarianten komen overeen met de weergaveformaten.
• Het LCP-element is afzonderlijk voor mobiel en desktop geïdentificeerd.
• De LCP-afbeelding wordt niet vertraagd door lazy loading of onnodige JS-initialisatie.
• Een hoge prioriteit is alleen toegekend aan gerechtvaardigde resources.
• Afbeeldingen, banners en ingesloten content hebben gereserveerde ruimte in de lay-out.
• Logo, favicon, CMS-afbeeldingen en afbeeldingen die door modules worden toegevoegd zijn gecontroleerd.
• Het publicatieproces voor nieuwe afbeeldingen omvat het genereren van geoptimaliseerde varianten.

Kleuren en interfacebediening — Accessibility

• Tekst, prijzen, knoppen en meldingen hebben het vereiste contrast op echte achtergronden.
• Het contrast van belangrijke controls en de zichtbaarheid van keyboard focus zijn gecontroleerd.
• Fouten, promoties en selecties worden niet uitsluitend met kleur gecommuniceerd.
• Links en knoppen hebben begrijpelijke toegankelijke namen; formulieren hebben labels.
• Informatieve afbeeldingen hebben passende alt-tekst en decoratieve afbeeldingen een lege alt.
• Menu, filters, popups en winkelwagen kunnen met het toetsenbord worden bediend.
• Paginazoom, klein scherm en basisbediening met een screenreader zijn gecontroleerd.

Technische kwaliteit — Best Practices

• De pagina en de resources werken via HTTPS, zonder mixed content.
• Consolefouten, mislukte requests en waarschuwingen die door de audit zijn aangegeven, zijn verklaard.
• Bibliotheken en modules worden onderhouden; gemelde kwetsbaarheden zijn bekeken.
• Afbeeldingen behouden hun verhoudingen en functies gebruiken niet onnodig verouderde API’s.
• Een hoge score is bevestigd samen met werkende betalingen, formulieren en toestemmingen.

Technische zichtbaarheid — SEO

• Pagina’s die bedoeld zijn voor indexering geven de juiste status terug en hebben geen toevallige noindex.
• robots.txt blokkeert geen benodigde pagina’s of resources.
• Titel en meta description komen overeen met de inhoud van de pagina.
• Canonical is correct; taalversies en hreflang zijn afzonderlijk beoordeeld.
• Navigatielinks zijn leesbaar voor bots en paginering werkt correct.
• Gestructureerde gegevens zijn met een afzonderlijke tool geverifieerd en komen overeen met de zichtbare content.
• Sitemap en indexering in Search Console zijn beoordeeld — ook buiten de Lighthouse-score om.

Automatische toegankelijkheidstests omvatten slechts een deel van de mogelijke problemen. Zelfs een score van 100 moet worden aangevuld met een handmatige test. Hoe toegankelijkheid in Lighthouse wordt berekend.

Waar begint u met werken aan uw webshop?

Eerst bepalen we waar de klant op wacht. Als het om de serverresponse gaat — beginnen we bij de backend en cache. Als het om de afbeelding gaat — controleren we detectie, download en weergave. Als de pagina zichtbaar is, maar vertraagd reageert — analyseren we het werk van JavaScript en componenten.

Daarna implementeren we één logische groep verbeteringen en herhalen we de metingen en aankooptests. Zo is duidelijk wat heeft geholpen en of de kosten van de wijziging gerechtvaardigd waren. Alleen het behalen van de Core Web Vitals-drempels garandeert geen score van 95: Performance wordt berekend uit meerdere gewogen metrics. Regels voor Lighthouse-scoreberekening.

Hyvä maakt het mogelijk om te starten met een lichte frontend. Het behouden van dit voordeel vraagt om bewuste keuzes bij elke volgende module, banner en marketingtool. Daarom is het verstandig prestaties te behandelen als acceptatiecriterium voor volgende implementaties, en niet als een eenmalig project dat eindigt met een screenshot van een groene score.

Als u een Hyvä-implementatie plant of een bestaande webshop wilt versnellen, neem dan contact op met het team van kowal.store. Het vertrekpunt moet een audit zijn van concrete pagina’s en het aankooptraject — met een lijst van oorzaken, prioriteiten en metingen voor en na de wijzigingen.