Interaction to Next Paint (INP) — wat e-commerce owners moeten weten

Interaction to Next Paint (INP) — wat e-commerce owners moeten weten

Sinds maart 2024 is First Input Delay (FID) dood. Google heeft hem vervangen door Interaction to Next Paint (INP) als officiële Core Web Vital. Voor e-commerce is dit een ingrijpende wissel — en de meeste webshops zijn er nog niet klaar voor.

FID mat alleen de eerste interactie op een pagina. INP meet elke klik, tik en toetsaanslag gedurende de volledige paginasessie. Een trage filterknop op je categoriepagina die bij FID onzichtbaar bleef? Die herkent INP feilloos.

Wat je leert in dit artikel

• Wat INP precies meet en hoe het verschilt van FID
• Waarom e-commerce pagina's extra gevoelig zijn voor INP-problemen
• De drie fases van een interactie en waar tijd verloren gaat
• Concrete optimalisatiestrategieën per fase
• Hoe INP je ranking beïnvloedt

Wat meet INP?

INP meet de responstijd van een interactie: de tijd tussen het moment dat een gebruiker klikt (of tapt, of een toets indrukt) en het moment dat de browser de volgende frame heeft geschilderd als reactie op die interactie.

Die responstijd bestaat uit drie onderdelen:

1. Input delay — wachttijd voordat de browser de event handler start
2. Processing time — tijd die de JavaScript event handler nodig heeft
3. Presentation delay — tijd die de browser nodig heeft om de DOM-wijziging te renderen

• Goed: onder 200 milliseconden
• Verbetering nodig: 200 tot 500 milliseconden
• Slecht: boven 500 milliseconden

De uiteindelijke INP-score is het 98e percentiel van alle interacties op een pagina. Bijna alle interacties moeten snel zijn. Één trage outlier kan de score domineren.

Waarom e-commerce extra gevoelig is

E-commerce pagina's zijn interactie-intensief. Denk aan wat een bezoeker doet op een categoriepagina:

• Filtert op merk, maat, kleur, prijs
• Sorteert producten
• Voegt producten toe aan de wishlist
• Klikt op "Meer laden" of pagineert
• Zoekt via de zoekbalk

Elke van die acties is een interactie die INP meet. Als je filtercomponent 600ms nodig heeft om te reageren na een klik, is je INP slecht — ook als de rest van je pagina snel is.

Vergelijk dit met FID: FID mat alleen de allereerste klik op een pagina. Gebruikers klikten vaak als eerste op een groot, snel reagerend element. De trage filterknop bleef buiten beeld.

De drie fases van een interactie

Fase 1: Input delay

Input delay treedt op als de browser bezig is met iets anders op het moment van de klik. De main thread is geblokkeerd door een Long Task.

• JavaScript-bundels die bij paginalading verwerkt worden
• Third-party scripts (analytics, chat, tracking pixels)
• Zware initialisatie van framework-componenten

// Slechte aanpak: zware berekening op de main thread bij paginastart
window.addEventListener('load', () => {
    // Dit blokkeert de main thread voor 800ms
    const result = zwareBerekening(productData);
    renderCategorie(result);
});

// Betere aanpak: defer naar idle time
window.addEventListener('load', () => {
    requestIdleCallback(() => {
        const result = zwareBerekening(productData);
        renderCategorie(result);
    });
});

Fase 2: Processing time

Processing time is de tijd die je event handler nodig heeft. Dit is waar de meeste optimalisaties plaatsvinden.

Een filtercomponent die bij elke klik de volledige productlijst opnieuw opbouwt in de DOM, heeft een hoge processing time. Een component die alleen de gewijzigde elementen bijwerkt, is aanzienlijk sneller.

// Trage aanpak: volledige DOM herbouwen bij filter
filterButton.addEventListener('click', () => {
    const producten = filterProducten(alleProducten, actieveFilters);
    productGrid.innerHTML = ''; // Alles weggooien
    producten.forEach(product => {
        productGrid.appendChild(maakProductCard(product)); // Alles herbouwen
    });
});

// Snellere aanpak: alleen wijzigingen doorvoeren
filterButton.addEventListener('click', () => {
    const producten = filterProducten(alleProducten, actieveFilters);
    updateProductGrid(productGrid, producten); // Diffing: alleen wijzigingen
});

Fase 3: Presentation delay

Presentation delay is de tijd die de browser nodig heeft om de gewijzigde DOM te schilderen. Dit is moeilijker te beïnvloeden maar niet onmogelijk.

/* Traag: triggert layout recalculation */
.product-card:hover {
    margin-top: -5px; /* Wijzigt layout */
}

/* Snel: alleen composite layer animatie */
.product-card:hover {
    transform: translateY(-5px); /* Alleen GPU-laag */
}

INP optimaliseren voor e-commerce: praktische aanpak

1. Identificeer de trage interacties

Gebruik Chrome DevTools Performance Insights tab. Neem een sessie op terwijl je door de webshop navigeert en filters gebruikt. DevTools markeert Long Tasks en toont welke interacties boven de 200ms-drempel komen.

Google Search Console toont ook INP field data onder Core Web Vitals. Als je INP "slecht" of "verbetering nodig" toont, geeft Search Console aan op welke pagina-types het probleem speelt.

2. Verklein en defer JavaScript

Elke kilobyte JavaScript die bij paginalading verwerkt wordt, vergroot de kans op Long Tasks en daarmee op input delay.

// Laad zware componenten pas als ze nodig zijn
const laadFilterComponent = async () => {
    const { FilterComponent } = await import('./components/FilterComponent.js');
    new FilterComponent(document.getElementById('filter-sidebar'));
};

// Laad pas bij eerste interactie met de filter
document.getElementById('filter-toggle').addEventListener('click', laadFilterComponent, { once: true });

3. Verplaats zware berekeningen naar Web Workers

Web Workers draaien op een aparte thread. Ze blokkeren de main thread niet.

// main.js: stuur filterwerk naar Web Worker
const filterWorker = new Worker('/js/filter-worker.js');

filterButton.addEventListener('click', () => {
    filterWorker.postMessage({
        producten: alleProducten,
        filters: actieveFilters
    });
});

filterWorker.onmessage = (event) => {
    updateProductGrid(event.data.gefilterdeProgramma);
};

// filter-worker.js: draait op aparte thread
self.onmessage = (event) => {
    const gefilterd = event.data.producten.filter(product => {
        return voldoetAanFilters(product, event.data.filters);
    });
    self.postMessage({ gefilterd });
};

4. Optimaliseer third-party scripts

Third-party scripts zijn een van de grootste bronnen van Long Tasks. Analytics, chat-widgets, recensie-platforms, social media pixels — ze draaien allemaal op dezelfde main thread.

Laad third-party scripts zo laat mogelijk:

<!-- Defer alle third-party scripts -->
<script defer src="https://analytics.example.com/script.js"></script>

<!-- Of laad pas na user interaction -->
<script>
window.addEventListener('scroll', function() {
    // Laad chat widget pas als gebruiker scrollt
    const script = document.createElement('script');
    script.src = 'https://chat.example.com/widget.js';
    document.head.appendChild(script);
}, { once: true });
</script>

5. Gebruik scheduler.yield() voor lange taken

Moderne browsers ondersteunen scheduler.yield() om lange taken op te splitsen. Dit geeft de browser de kans om gebruikersinteracties te verwerken tussen bewerkingen door.

async function verwerkGroteProductenlijst(producten) {
    for (let i = 0; i < producten.length; i++) {
        verwerkProduct(producten[i]);

        // Geef de browser elke 50 producten de kans om interacties te verwerken
        if (i % 50 === 0) {
            await scheduler.yield();
        }
    }
}

INP en je Google ranking

Google gebruikt INP als onderdeel van de Page Experience ranking-factor. Een slechte INP-score heeft een negatieve invloed op je organische positie voor mobiele zoekopdrachten.

Hoe groot die invloed is, is moeilijk te isoleren. Google combineert meerdere Page Experience-signalen. Maar in competitieve niches — mode, elektronica, woonaccessoires — kan een betere INP de doorslag geven boven een concurrent met vergelijkbare content.

De relatie tussen INP en andere Core Web Vitals leggen we uit in onze gids over Core Web Vitals 2026. Voor LCP-optimalisatie, dat ook meetelt, zie ons artikel over Largest Contentful Paint optimaliseren.

Benchmarks

In onze e-commerce projecten zien we typische INP-waarden vóór optimalisatie:

Conclusie

INP is strenger dan FID en raakt e-commerce harder. Een trage filtercomponent, een trage "Toevoegen aan winkelwagen" knop, een trage zoekbalk — ze tellen allemaal mee voor je INP-score.

De oplossingen zijn concreet: JavaScript deferred laden, zware berekeningen naar Web Workers, third-party scripts later laden, DOM-updates minimaliseren. Geen van die optimalisaties is raket wetenschap maar ze vergen technische aandacht.

Veelgestelde vragen

FID was goed, INP is slecht. Hoe kan dat?

FID mat alleen de input delay van de eerste interactie. INP meet de volledige interactie (inclusief processing en painting) van alle interacties. Een pagina met een snelle eerste klik maar trage filterinteracties scoorde goed op FID en slecht op INP.

Welke interacties tellen mee voor INP?

Klikken met de muis, tikken op een touchscreen en toetsaanslagen. Scrollen en hoveren tellen niet mee. Elke interactie die JavaScript uitlokt, telt.

Kan ik INP verbeteren zonder de pagina te herbouwen?

Ja. De meeste INP-verbeteringen zijn incrementeel: scripts deferred laden, third-party scripts later laden, event handlers optimaliseren. Je hoeft de pagina niet te herbouwen om significante winst te behalen.

Hyva en Alpine.js: is INP daar beter dan in Magento luma?

Ja, significant. Hyva's Alpine.js-gebaseerde frontend laadt veel minder JavaScript dan de Knockout.js-stack in standaard Magento. We meten op vergelijkbare pages 40-60% lagere INP-waarden met Hyva. Dat is een van de concrete performance-argumenten voor Hyva-migratie. Lees ook ons artikel over JavaScript bundel verkleinen voor concrete optimalisatietechnieken.