De Core Web Vitals (CWV) zijn in 2024 een directe rankingfactor voor Google geworden, en hun gewicht in de ranking van e-commercepagina’s blijft in 2026 toenemen. Op PrestaShop 8 is CWV-optimalisatie zowel SEO-werk als werk aan de ervaringskwaliteit: een LCP die van 4,2 s naar 1,8 s gaat, betekent mechanisch +20-40% mobiele conversieratio volgens de Google-studies en onze eigen metingen op de shops die wij begeleiden. Toch blijft CWV-optimalisatie slecht begrepen. De meeste verkopers draaien een Lighthouse, zien een rode score, installeren een generieke cachemodule en stellen vast dat de score nauwelijks beweegt: de echte hefbomen zitten niet in de cache, maar in precieze technische details.
Deze checklist beschrijft de CWV-optimalisaties die op PrestaShop 8 in 2026 echt resultaten opleveren, met echte PHP- en SQL-code aangepast aan de PrestaShop-architectuur, geen generieke adviezen gekopieerd uit een Google-documentatie.
De 3 Core Web Vitals van 2026 en hun drempels
Google meet drie metrics om de laad- en interactiekwaliteit van een pagina te beoordelen.
LCP (Largest Contentful Paint) meet de tijd tussen het begin van het laden en de rendering van het grootste zichtbare element (typisch de hoofdafbeelding van een productpagina, of de herotekst van een categoriepagina). Drempels: goed onder 2,5 s, te verbeteren tussen 2,5 en 4 s, slecht boven 4 s.
INP (Interaction to Next Paint) verving FID in maart 2024. Het meet de latentie tussen een gebruikersinteractie (klik, tap, toetsaanslag) en de volgende zichtbare rendering. Drempels: goed onder 200 ms, te verbeteren tussen 200 en 500 ms, slecht boven 500 ms.
CLS (Cumulative Layout Shift) meet de onverwachte visuele verschuivingen tijdens het laden (afbeelding die de tekst wegduwt, banner die laat verschijnt). Drempels: goed onder 0,1, te verbeteren tussen 0,1 en 0,25, slecht boven 0,25.
Om een pagina in Search Console als “Goed” te laten gelden, moeten de drie metrics groen zijn op het 75e percentiel van de echte ladingen (de 25% traagste bezoeken mogen erboven zitten, maar de 75% snelste moeten goed zijn). Dat maakt de optimalisatie moeilijk: uw shop kan snel zijn voor een desktopbezoeker op glasvezel en catastrofaal voor een bezoeker op zwakke 4G met een entry-level Android. Google berekent de score op echte gebruikers (Field Data via het Chrome User Experience Report).
De CWV van uw shop meten: Lab Data versus Field Data
Er bestaan twee soorten metingen die u moet onderscheiden.
Lab Data (synthetische meting). PageSpeed Insights, Lighthouse, WebPageTest. De pagina wordt door een robot geladen in een gestandaardiseerde omgeving (gesimuleerde 3G, mid-range mobiel). De cijfers zijn reproduceerbaar maar weerspiegelen niet de ervaring van uw echte bezoekers. Nuttig voor diagnose en ontwikkeling.
Field Data (echte metingen). Het Chrome User Experience Report (CrUX), toegankelijk in Search Console > Verbeteringen > Core Web Vitals. Dit zijn de cijfers die Google voor de ranking gebruikt. Geaggregeerde meting van de echte ladingen van uw bezoekers over de laatste 28 dagen. Dit is de metric die telt voor SEO.
Het verschil tussen Lab Data en Field Data kan enorm zijn: een site met een Lighthouse-score van 95 kan rode Field Data hebben als het merendeel van zijn bezoekers op tragere apparaten zit dan het standaard Lighthouse-profiel. Omgekeerd kan een site met een Lighthouse van 60 correct zijn in Field Data als zijn publiek voornamelijk desktop is.
De tool om nu op te zetten. Configureer Real User Monitoring (RUM) op uw shop. Meerdere gratis opties: de web-vitals library van Google die zich in enkele regels JS integreert en de metingen naar GA4 stuurt, of tools als Cloudflare Web Analytics, SpeedCurve, Calibre. RUM-metingen zijn het meest getrouw aan wat Google ziet en laten segmenteren per apparaattype, land en browser, wat onthult waar uw echte problemen zitten.
LCP: de optimalisaties die echt werken
De LCP is doorgaans de metric met de meeste businessimpact op PrestaShop, omdat hij direct de snelheidsperceptie bij het laden van een productpagina betreft. Dit zijn de hefbomen op volgorde van typische impact.
1. Het LCP-element precies identificeren
Identificeer eerst welk element de LCP triggert op uw sleutelpagina’s. Lighthouse geeft het aan in zijn rapport, maar de preciezere tool is de Chrome-extensie Web Vitals Extension, die het LCP-element in realtime markeert op elke pagina. Op een PrestaShop-productpagina is de LCP bijna altijd de hoofdafbeelding van het product. Op een categorie is het doorgaans de eerste zichtbare afbeelding van het productgrid. Op de homepage is het de hero/slider.
Eenmaal geïdentificeerd is dat LCP-element wat u prioriteert in de optimalisatie: preloading, conversie naar een modern formaat, dimensionering, lazy loading uitgeschakeld.
2. Preloading van de LCP-afbeelding
Op productpagina’s levert een <link rel="preload"> in de head voor de hoofdafbeelding 200 tot 500 ms winst op de LCP, omdat de browser het downloaden van de afbeelding start nog vóór hij de HTML heeft geparset die haar bevat.
Implementatie in de template van de productpagina (themes/uw-thema/templates/catalog/product.tpl in Smarty, of het equivalente bestand voor moderne thema’s):
{if isset($product.cover.bySize.large_default.url)}
<link rel="preload" as="image"
href="{$product.cover.bySize.large_default.url}"
imagesrcset="..." imagesizes="..." fetchpriority="high">
{/if}Het attribuut fetchpriority="high" is belangrijk: het zegt de browser dat deze resource kritiek is en vóór de andere in de downloadqueue moet.
3. WebP / AVIF conversie met correcte dimensies
Uw productafbeeldingen in WebP serveren verlaagt hun gewicht met 25 tot 35% ten opzichte van JPEG bij gelijkwaardige visuele kwaliteit. AVIF bespaart nog 20% extra, maar met een iets duurder decoderen aan browserzijde. Het compromis van 2026 blijft: overwegend WebP, AVIF voor de kritieke hero-afbeeldingen.
Op PrestaShop 8 doen meerdere modules de automatische conversie (het native PrestaShop heeft een basale WebP-optie, modules van derden doen het beter met AVIF en adaptieve compressie). Controleer ook of de geserveerde dimensies overeenkomen met de reële weergave: een afbeelding van 2000×2000 serveren die op 400×400 wordt getoond, verspilt bandbreedte en verhoogt de LCP. Gebruik srcset om meerdere formaten aan te bieden afhankelijk van de viewport.
4. TTFB en SQL-queries op de server
De LCP wordt van onderen begrensd door de TTFB (Time To First Byte): zolang uw server geen HTML begint te sturen, kan de browser niets renderen. Op PrestaShop kan de TTFB gesloopt worden door niet-geoptimaliseerde SQL-queries in zware hooks.
De audit om te doen: de PrestaShop profiler activeren (Configuratie > Prestaties > debugmodus + profiler aan) en het tabblad Database bekijken. Ziet u een query die 50 keer per productpaginalading draait met een cumulatieve tijd van 200 ms, dan is dat waarschijnlijk een N+1 query in een slecht gecodeerde module. De module in kwestie moet gepatcht of uitgeschakeld worden.
De meest voorkomende schuldigen op de shops die wij auditen: reviewmodules die de gemiddelde score voor elk getoond product zonder cache opvragen, related products modules die één query per aanbevolen product doen, voorraadmodules die de beschikbaarheid bij elke productweergave berekenen. Onze categorie Prestaties & Core Web Vitals behandelt meerdere van deze patterns.
INP: de moderne performancekiller (en de slechtst begrepen)
De INP verving FID in maart 2024 en is nu de moeilijkst te optimaliseren metric op PrestaShop. De reden: FID mat alleen de eerste interactie, INP meet alle interacties en houdt het slechtste 98e percentiel. Eén trage interactie op 50 (bijvoorbeeld een klik op een categoriefilter die 500 ms bevriest) weegt dus zwaarder dan 49 snelle interacties.
1. De trage interacties identificeren
De Chrome-extensie Web Vitals Extension toont de INP in realtime tijdens het navigeren. Klik overal op uw shop (filters, toevoegen aan winkelwagen, popups, FAQ-accordeons, productswiper) en kijk welke interacties boven de 200 ms uitkomen. Op PrestaShop zijn de typische schuldigen:
- de categoriefilters (faceted search) die het hele grid in AJAX herladen;
- de winkelwagentoevoegingen die zware hooks triggeren;
- het openen van productmodals (Quick View);
- de wissels van productvariant (kleur, maat).
2. Long tasks en yield naar de main thread
Een trage interactie wordt bijna altijd veroorzaakt door een JavaScript “long task” (een functie die de main thread langer dan 50 ms blokkeert). De browser kan niet reageren op volgende klikken zolang de long task niet klaar is.
De moderne oplossing: long tasks opdelen met scheduler.yield() (native API in recente Chromium-browsers) of met een setTimeout(fn, 0) patroon om tussen de rekenblokken de hand terug te geven aan de browser. Voorbeeld: heeft u een lus die 1000 producten aan de frontkant verwerkt, deel haar dan op in chunks van 50 met een yield tussen elke chunk.
async function processProducts(products) {
for (let i = 0; i < products.length; i += 50) {
const chunk = products.slice(i, i + 50);
chunk.forEach(processProduct);
if ('scheduler' in window && 'yield' in scheduler) {
await scheduler.yield();
} else {
await new Promise(r => setTimeout(r, 0));
}
}
}3. Debounce en throttle op de inputs
Trigger op zoekfilters, variantselects en hoeveelheidsinputs niet bij elke keypress een AJAX-call. Debounce van 200 tot 300 ms vóór het versturen van de request. Zonder dat detail genereert een snel typende bezoeker 10 AJAX-requests die allemaal de main thread verzadigen.
4. JS code splitting en uitgesteld laden
Veel PrestaShop-modules laden hun JS op alle pagina’s terwijl ze maar op sommige worden gebruikt (een Quick View module die op de homepage laadt, een FAQ-module die op categoriepagina’s laadt). Audit uw front/controllers/... en gebruik $this->context->controller->registerJavascript() met de juiste controller als parameter om het laden te beperken tot de pagina’s waar de JS nodig is.
Laad voor echt zware functionaliteit (een Swiper-slider, een WYSIWYG-editor) de JS lazy via dynamische import() op het moment van de eerste interactie, niet bij het laden van de pagina.
CLS: de visuele stabiliteit
De CLS is doorgaans de eenvoudigst te corrigeren metric op PrestaShop, omdat de oorzaken beperkt in aantal en goed bekend zijn.
1. Ruimtereservering voor afbeeldingen. Elke afbeelding in de HTML moet expliciete width– en height-attributen hebben (of een CSS aspect-ratio). Zonder dat laat de afbeelding de layout verspringen wanneer ze laadt. Op PrestaShop moeten alle productafbeeldingen gegenereerd door de displayProduct... hooks hun dimensies hebben. Controleer uw themacode: elke <img src="..." /> zonder width en height is verdacht.
2. Webfonts en FOIT/FOUT. Gebruikt u Google Fonts of custom fonts, dan kan de browser onzichtbare tekst tonen (FOIT) en daarna bruusk omschakelen (FOUT) wanneer het font arriveert, wat alle content verschuift. Oplossing: font-display: optional in de CSS voor de secundaire fonts, en font-display: swap met een metrisch compatibele fallback (gebruik CSS size-adjust om het fallbackfont te matchen met het custom font en de shift te elimineren).
3. Uitgestelde banners en popups. Cookiebanners, newsletterpopups en top bars die 1 tot 3 seconden na het laden verschijnen, zijn frequente CLS-bronnen. Oplossing: reserveer de ruimte vanaf het begin in CSS (met min-height) als u weet dat de banner gaat verschijnen, of laat de banner in overlay verschijnen (position fixed/absolute) zodat ze de bestaande content niet verschuift.
4. Externe iframes en embeds. YouTube-, Vimeo- en Calendly-iframes die uitgesteld laden, verschuiven de content. Reserveer systematisch hun ruimte met een wrapper in aspect-ratio: 16/9 of equivalent.
PrestaShop-specifieke SQL- en database-optimalisaties
Op PrestaShop komt een belangrijk deel van de TTFB (en dus de LCP) van de SQL-queries. Dit zijn de patterns om te kennen.
Profiling met EXPLAIN
Onthult de PrestaShop-profiler een trage query (meer dan 50 ms), haal haar dan door MySQL met EXPLAIN om te begrijpen wat er gebeurt. Ziet u een type: ALL met een groot aantal gescande rows, dan ontbreekt waarschijnlijk een index. Ziet u Using filesort of Using temporary, dan doet de query onnodig werk en moet ze herschreven worden.
Typisch ontbrekende indexen op PrestaShop
Op shops met een grote catalogus (5000+ producten) en veel modules van derden ontbreken bepaalde indexen vaak. De patterns die wij in audits zien:
- Ontbrekende index op
id_product, id_shopin de custom tabellen van modules; - Ontbrekende index op de kolommen gebruikt voor de categoriefilters (faceted search);
- Ontbrekende index op
id_order, date_addvoor de bestelstatistiekqueries.
Voeg de ontbrekende indexen direct in SQL toe via PhpMyAdmin of via een modulemigratie. Meet vóór/na: één goed geplaatste index kan een querytijd door 50 delen.
N+1 queries in de hooks
Het meest destructieve pattern voor PrestaShop-performance: een hook die voor elk getoond product draait en één SQL-query per product doet. Op een categorie die 24 producten toont, zijn dat 24 extra queries per lading.
Detectie: PrestaShop profiler > Database. Ziet u dezelfde query N keer herhaald met verschillende parameters, dan is het een N+1.
Oplossing: de module aanpassen om de queries te batchen. In plaats van één query per product in de hook displayProductMiniature, moet de module alle product-IDs verzamelen via actionProductListBefore en één enkele query WHERE id_product IN (1, 2, 3, ...) doen die alle resultaten in één keer ophaalt.
PrestaShop-cache: Smarty + modulecache
Op PrestaShop 8 vullen twee cacheniveaus elkaar aan. De Smarty-cache (compileert de templates naar PHP) wordt in productie gebruikt: controleer SMARTY_CONSOLE_FORCE_COMPILE = 0 en SMARTY_CACHE = 1 in config/defines.inc.php. De modulecache (custom cache in de modules) is krachtiger: een goed gecodeerde module cachet zijn zware berekeningen en doet ze pas opnieuw wanneer de data verandert. Herberekent een module op elke pagina hetzelfde, dan is dat een te corrigeren bug.
Voeg op shops met veel verkeer ook een HTTP-cache toe (Varnish, of LiteSpeed-cache bij de hosting) die de vooraf gerenderde productpagina’s serveert zonder PrestaShop zelfs maar te bereiken. Dat deelt de TTFB door 10 op herhaalde requests en bevrijdt de server voor de echt dynamische requests.
De valkuil van de modules van derden
Op de shops die wij auditen komt 60 tot 80% van de CWV-problemen van slecht gecodeerde modules van derden. Het pattern is altijd hetzelfde: een module geïnstalleerd voor een nuttige functionaliteit (livechat, newsletterpopup, loyaltybadge, social proof) laadt zware JS op alle pagina’s, verzwaart de LCP en de INP, en niemand legt het verband.
De audit om regelmatig te doen:
- Schakel alle modules van derden uit en draai Lighthouse → dat is uw baseline “puur PrestaShop”.
- Heractiveer de modules één voor één en draai telkens opnieuw Lighthouse.
- Identificeer de modules die de score meer dan 5 punten laten kelderen → dat zijn uw schuldigen.
- Voor elke schuldige: ofwel vindt u een instelling die hem lichter maakt, ofwel vervangt u hem door een beter gecodeerd alternatief, ofwel beslist u dat de functionaliteit de degradatie niet waard is.
Keuzecriterium voor een nieuwe module in 2026: controleer vóór installatie of de module zijn assets alleen laadt op de pagina’s waar hij gebruikt wordt (niet op alle pagina’s), of hij gebatchte SQL doet (geen N+1), of hij een configureerbare cache biedt, en of hij een recente changelog heeft (een module die 18 maanden niet is onderhouden op PrestaShop 8 is verdacht).
Meerdere modules uit onze catalogus zijn ontwikkeld met deze beperkingen in het achterhoofd, zoals de module DataFirefly SideCart die zijn JS alleen laadt op de pagina’s waar hij wordt getoond, of de module DataFirefly Cross-Sell waarvan de analytics in AJAX buiten het kritieke pad vertrekken om de LCP niet te raken, onderwerp behandeld in ons artikel over cross-sell die bijdraagt aan de gemiddelde bestelwaarde.
Conclusie: continu werk, geen eenmalig project
Core Web Vitals optimalisatie op PrestaShop 8 is zelden werk van een paar dagen dat u één keer doet en vergeet. Het is continu werk: elke nieuw toegevoegde module kan de score breken, elke PrestaShop-update kan regressies introduceren, elke Google-evolutie (de komst van de INP in maart 2024 bijvoorbeeld) kan de prioriteiten herverdelen.
De juiste reflex is permanente monitoring opzetten (Search Console + RUM via web-vitals.js + GA4) en de metrics routinematig checken, niet alleen wanneer een probleem zichtbaar wordt. Een degradatie gedetecteerd in week 1 corrigeert u in enkele uren; dezelfde degradatie gedetecteerd in week 8, nadat u in de tussentijd drie andere modules heeft toegevoegd, wordt een complete audit van meerdere dagen.
Om verder te gaan: blader door onze categorieën Prestaties & Core Web Vitals en PrestaShop-tutorials voor de aanverwante technische onderwerpen. En identificeert u modules in uw huidige stack die de CWV slopen zonder overeenkomstige waarde te leveren: meerdere modules uit onze catalogus zijn performance-first by design. De SideCart, de Cross-Sell en het hele DataFirefly-gamma delen dezelfde belofte: geen JS op pagina’s waar de module niet wordt getoond, geen N+1, geen onnodige externe dependencies.
Lees ook: de complete Core Web Vitals gids en cache, Critical CSS en next-gen afbeeldingen.
Om in actie te komen: onze modulesselectie om uw PrestaShop-shop te versnellen.
