90% van de WordPress-sites haalt een goede INP op mobiel. Hoor jij bij de rest, dan zit het meestal in scripts van derden, een page builder of een groot DOM.

Chris KettmannOprichter · Sales · Design · Development · AI

WebdesignPublicatie 10 november 20266 min lezen

INP verbeteren op WordPress: de grootste boosdoeners

Een slechte INP op WordPress komt zelden van WordPress zelf. 90% van de WordPress-sites haalt op mobiel een goede INP (HTTP Archive Tech Report, september 2026). Zit jij in de overige 10%, dan blokkeert JavaScript de browser op het moment van klikken. Meestal door scripts van derden, een zware page builder, een te groot DOM of plugins die overal laden.

Dit artikel gaat alleen over INP. Hoe WordPress zich op LCP en CLS verhoudt tot Wix, Shopify en Webflow, staat in Core Web Vitals in 2027.

Wat meet INP eigenlijk?

INP meet hoe lang het duurt tussen een klik, tap of toetsaanslag en het moment dat de browser het resultaat op het scherm zet. Google deelt die tijd op in drie delen: de input delay (wachten tot de browser vrij is), de processing duration (je eigen code die op de klik reageert) en de presentation delay (de browser die de nieuwe weergave tekent) (web.dev). Goed is 200 milliseconden of minder op het 75e percentiel van je bezoekers (web.dev).

Het belangrijkste begrip is de long task. De browser doet één taak tegelijk op de main thread, en elke taak die langer dan 50 milliseconden duurt, telt als long task (web.dev). Klikt een bezoeker terwijl zo’n taak loopt, dan wacht de klik. Op een goedkope telefoon duurt dezelfde JavaScript een veelvoud van wat je op je laptop ziet.

Hoe vind je de trage interactie?

Niet met Lighthouse. Een standaard labtest laadt alleen de pagina en klikt nergens op, dus er is geen INP om te rapporteren. Total Blocking Time is dan een bruikbare benadering, maar volgens Google geen vervanging (web.dev). Begin daarom met velddata:

Het Core Web Vitals-rapport in Search Console laat zien welke groepen URL’s op mobiel falen op INP.
PageSpeed Insights toont in het bovenste blok de INP van echte Chrome-bezoekers voor een URL of de hele site.
Daarna reproduceer je de interactie in Chrome DevTools, met de CPU-vertraging aan, en kijk je in het Performance-paneel welk script de lange taak veroorzaakt.

Let op welk paginatype faalt. Volgens de Web Almanac 2025 heeft op mobiel 80% van de homepages een goede INP, tegen 69% van de overige pagina’s. De auteurs wijzen op filters, carrousels, formuliervalidatie en widgets van derden, die vaker dieper in de site zitten (Web Almanac 2025). Is je homepage in orde maar je productoverzicht of contactpagina niet, dan weet je waar je moet zoeken.

Welke boosdoeners zien we het vaakst?

1. Scripts van derden

Chatwidgets, cookiebanners, heatmaps, advertentiepixels, reviewwidgets. Ze draaien op dezelfde main thread als je eigen code en voeren vaak werk uit op het moment dat iemand klikt of scrolt. Op sites waarop Google Tag Manager wordt herkend, heeft op mobiel 78% een goede INP, tegen 90% van alle WordPress-sites (HTTP Archive Tech Report, september 2026). Dat bewijst niet dat Tag Manager traag is. Het zegt wel dat sites die veel tracking laden, vaker problemen hebben.

Wat werkt: elk script langs de vraag “wie kijkt hier nog naar?”. Een heatmap van een project dat al een jaar klaar is, kan weg. Wat blijft, laad je pas na de eerste interactie of na een paar seconden, en dus niet in de <head>.

2. Page builders

Naar schatting 60% van de WordPress-sites gebruikt een page builder (Web Almanac 2025). De Almanac noemt builders een belangrijke oorzaak van de verschillen in snelheid tussen WordPress-sites, omdat ze de DOM complexer maken en bepalen welke bestanden en scripts er laden en draaien (Web Almanac 2025). Een animatie bij elke sectie, een tabwidget, een accordeon, een slider: elk element brengt eigen scripts mee.

Wat werkt: nieuwere builders laden bestanden voorwaardelijk, dus alleen voor widgets die op de pagina staan (Web Almanac 2025). Controleer of die optie in jouw builder aanstaat. Scrollanimaties en effecten schrappen waar ze niets toevoegen. En bij een nieuwe site de vraag stellen of de builder nodig is, of dat de blokeditor van WordPress volstaat.

3. Een te groot DOM

Hoe meer HTML-elementen op een pagina, hoe meer werk de browser heeft bij elke wijziging na een klik. Lighthouse waarschuwt vanaf 800 nodes en noemt een DOM boven de 1.400 nodes excessief (web.dev). Page builders stapelen containers in containers, en een megamenu met honderd links of een productoverzicht met alle varianten in de HTML doet de rest.

Wat werkt: geneste containers platslaan, lange lijsten pagineren en verborgen content (tabs, mobiele menu’s) pas opbouwen als iemand ze opent.

4. Plugins die overal laden

Een formulierplugin die zijn JavaScript op elke pagina zet, ook als het formulier alleen op de contactpagina staat. Een sliderplugin die laadt op pagina’s zonder slider. Dat werk telt bij elke klik mee als input delay. Sinds WordPress 6.3 kunnen scripts met een defer- of async-strategie worden geregistreerd (Make WordPress Core), maar een plugin moet daar zelf gebruik van maken.

Wat werkt: per pagina kijken welke scripts laden (het netwerktabblad in DevTools volstaat) en plugins die overal laden beperken tot de pagina’s waar ze nodig zijn, met een asset-manager of een paar regels in het thema.

5. Eigen code die in één keer alles doet

Een filter dat bij elke klik de hele productlijst opnieuw opbouwt, of een event handler die eerst analytics stuurt en dan pas de knop bijwerkt. Google’s advies: splits het werk op en geef de browser tussendoor ruimte om te tekenen, bijvoorbeeld met scheduler.yield() (web.dev). De bezoeker ziet dan direct dat zijn klik is aangekomen, en het zware werk volgt een fractie later.

Wat levert de meeste winst op?

Volgorde die we aanhouden:

Velddata lezen en het paginatype vinden dat faalt.
Scripts van derden opruimen of uitstellen. Dat kost geen ontwikkeltijd en levert vaak het meest op.
Plugin-scripts beperken tot de pagina’s waar ze horen.
Page builder-effecten en DOM-grootte terugbrengen op de falende pagina’s.
Pas daarna eigen JavaScript herschrijven.

INP is minder vaak het probleem dan LCP. Op WordPress heeft 55% van de sites op mobiel een goede LCP, tegen 90% voor INP (HTTP Archive Tech Report). Haal je INP wel en LCP niet, begin dan bij de server en je afbeeldingen. Daarvoor zijn hosting aan de edge en AVIF, WebP en srcset uitgelegd de logische vervolgstappen.

Wil je dat iemand dit structureel bijhoudt, met updates en monitoring, dan is dat website onderhoud. Voor een herbouw van een WordPress-site die tegen zijn grenzen aanloopt, kijk bij WordPress.

Veelgestelde vragen

Helpt een cacheplugin tegen een slechte INP?

Nauwelijks. Een cacheplugin maakt de server sneller en helpt dus LCP en TTFB. INP gaat over JavaScript in de browser na het laden. Sommige optimalisatieplugins kunnen scripts uitstellen, wat wel helpt, maar test daarna of formulieren en menu’s nog werken.

Is Elementor slecht voor INP?

Niet per definitie. Op sites met Elementor heeft 88% op mobiel een goede INP, tegen 90% van alle WordPress-sites (HTTP Archive Tech Report). Het grotere probleem van Elementor-sites zit in LCP. Wat INP raakt, zijn vooral zware widgets en animaties op specifieke pagina’s.

Waarom is mijn INP op desktop goed en op mobiel slecht?

Telefoons hebben tragere processors, dus dezelfde JavaScript duurt langer en blokkeert de browser vaker langer dan 50 milliseconden. Over het hele web haalt 97% van de sites op desktop een goede INP, tegen 77% op mobiel (Web Almanac 2025).