Een WordPress-website is vaak snel op desktop maar traag op mobiel doordat Google PageSpeed Insights de mobiele pagina onder zwaardere omstandigheden test. De desktoptest kan vertraging door JavaScript, animaties en grote afbeeldingen nog maskeren, terwijl dezelfde vertraging op mobiel direct zichtbaar wordt. Kijk daarom niet alleen naar de score, maar vooral naar het Largest Contentful Paint-element en de bijbehorende Lighthouse-trace.
Een desktopscore van 100 bewijst niet dat je website snel is voor mobiele bezoekers. Dat zagen we op onze eigen WordPress-website, die na een eerdere optimalisatieronde op 98 stond: desktop bleef op 100, maar een latere mobiele controle kwam uit op 74. De grootste winst zat niet in nog een cachingplugin, maar in een onzichtbare H1, een opacity-animatie en te zware afbeeldingen. Na twee gerichte fixrondes stond mobiel op 99.
Waarom is de mobiele PageSpeed-score lager dan desktop?
Google PageSpeed Insights gebruikt verschillende testomstandigheden voor mobiel en desktop. De mobiele test simuleert een apparaat met minder rekenkracht en een tragere verbinding. Daardoor duurt het langer om JavaScript uit te voeren, CSS te verwerken, afbeeldingen te downloaden en onderdelen op het scherm te tekenen.
Dat verschil is op zichzelf niet vreemd. Het probleem begint wanneer desktop soepel lijkt, maar mobiel secondenlang wacht op de belangrijkste inhoud. Een snelle server of volle cache lost dat niet automatisch op. Alles wat de browser na het ontvangen van de pagina nog moet uitvoeren, blijft meetellen.
Largest Contentful Paint, afgekort LCP, meet wanneer het grootste zichtbare tekst- of beeldelement in het eerste scherm is weergegeven. Op een dienstenpagina is dat vaak de hoofdkop of hero-afbeelding. Als dat element verborgen is, geanimeerd binnenkomt of op een zwaar bestand wacht, loopt de LCP op.
Onze H1 was geladen, maar nog niet zichtbaar
Tijdens een controlerun op LaunchYourSite zagen we een mobiele prestatiescore van 74 en een LCP van 6,7 seconden. Desktop stond op 100. De Lighthouse-trace wees de H1 aan als LCP-element en liet een render delay van 2.990 milliseconden zien.
De tekst stond al in de HTML. Toch zette ons script iedere sectie eerst in een verborgen status. Een CSS-regel gaf de inhoud van de hero opacity: 0 totdat uitgesteld JavaScript de sectie zichtbaar maakte. Op een snelle desktop viel die constructie nauwelijks op. In de mobiele test bleef de belangrijkste kop bijna drie seconden onzichtbaar.
Nadat we de hero uit dat JavaScript-gestuurde reveal-systeem haalden, bleef nog 567 milliseconden vertraging over. Dat was exact de duur van de opacity-animatie op de H1. Chrome telde de kop pas als weergegeven nadat die animatie was afgelopen.
De les is simpel: inhoud boven de vouw mag niet afhankelijk zijn van JavaScript om zichtbaar te worden. Een animatie op je belangrijkste kop lijkt klein, maar kan rechtstreeks in je LCP terechtkomen.
Zware afbeeldingen maken het mobiele verschil groter
De trace liet ook zien dat niet alle vertraging uit animaties kwam. Eén PNG in een projectkaart woog 1.573 kB. Die werd vervangen door een WebP van 87 kB. Ook laadde een favicon-fallback van 212 kB met hoge prioriteit mee, terwijl bezoekers daar niets aan hadden.
Een responsive ontwerp maakt een afbeelding alleen kleiner op het scherm. Het garandeert niet dat de browser ook een kleiner bestand downloadt. Controleer daarom of WordPress daadwerkelijk srcset en sizes meegeeft. Daarmee kan de browser een beeldformaat kiezen dat bij het scherm past.
Op desktop kan een snelle verbinding een verkeerd gekozen afbeelding verbergen. Op mobiel wordt hetzelfde bestand een rem op de eerste weergave. Dat is precies waarom alleen naar de desktopscore kijken een verkeerd gevoel van zekerheid geeft.
Zo vind je de echte oorzaak
- Meet mobiel en desktop op exact dezelfde URL. Noteer de prestatiescore, LCP, Speed Index, Total Blocking Time en het paginagewicht. Vergelijk niet alleen de twee grote scores.
- Open het LCP-element in PageSpeed Insights. Controleer of het een afbeelding, kop of ander tekstblok is. Zonder dat element te kennen, optimaliseer je op goed geluk.
- Bekijk waar de LCP-tijd wordt besteed. Een lange downloadtijd wijst eerder naar een bestand of netwerkverzoek. Een lange render delay wijst eerder naar CSS, JavaScript, fonts, animaties of verborgen inhoud.
- Controleer de zichtbaarheid van de hero zonder JavaScript. Schakel JavaScript tijdelijk uit of inspecteer de beginstijl. De H1 en kernboodschap moeten direct zichtbaar zijn, ook voordat een observer of animatiescript draait.
- Controleer de werkelijk gedownloade afbeeldingen. Kijk niet alleen naar de afmetingen in WordPress. Controleer in het netwerkoverzicht welk bestand op mobiel wordt opgehaald, hoeveel kB het weegt en of
srcsetwordt gebruikt. - Pas één oorzaak per ronde aan. Meet opnieuw na iedere gerichte wijziging. Zo weet je welke ingreep effect had en voorkom je dat een toevallige scoreschommeling als oplossing wordt gezien.
- Test de pagina na het legen van de cache. Controleer daarna ook de publieke versie in een privévenster. Een oude cachelaag kan anders doen alsof je wijziging niets heeft opgeleverd.
Wat leverde deze aanpak op?
We veranderden niet blind tien instellingen tegelijk. Eerst haalden we de hero uit het reveal-systeem. Daarna verwijderden we de H1 uit de opacity-animatie, voorkwamen we onnodige layoutmetingen en leverden we kleinere, passende afbeeldingen.
| Mobiele meting | Voor | Na |
|---|---|---|
| PageSpeed-prestatiescore | 74 | 99 |
| LCP | 6,7 sec. | 2,2 sec. |
| Speed Index | 4,5 sec. | 1,2 sec. |
| Total Blocking Time | 30 ms | 0 ms |
| Paginagewicht | circa 2,0 MB | 355 kB |
Desktop bleef in dezelfde controlerun op 100. Dat maakte de kern van het probleem zichtbaar: de desktopscore was geen bewijs dat de mobiele ervaring goed was.
Deze controlerun volgde op een eerdere snelheidsoptimalisatie van dezelfde WordPress-website. Die ronde bracht mobiel van 64 naar 98. Weken later, vlak voordat we dat resultaat wilden gebruiken, mat een controle 74. Niet omdat die eerste meting onjuist was, maar omdat er sindsdien nieuwe secties, animaties en afbeeldingen bij waren gekomen. Na deze tweede ronde staat mobiel op 99, dus hoger dan na de eerste. Dat is precies waarom snelheid geen eenmalig vinkje is: elke nieuwe upload, animatie of sectie kan het eerste scherm opnieuw vertragen, en dat merk je alleen als je blijft meten.
Veelgestelde vragen
Waarom geeft PageSpeed mobiel een lagere score dan desktop?
De mobiele test gebruikt zwaardere gesimuleerde omstandigheden en minder rekenkracht. Daardoor worden JavaScript, zware beelden en rendervertraging duidelijker zichtbaar. Een verschil is normaal, maar een trage LCP verdient onderzoek.
Moet ik een cachingplugin installeren om mobiel sneller te maken?
Niet automatisch. Cache helpt vooral om bestanden en HTML sneller aan te leveren, maar maakt een verborgen H1 of zware opacity-animatie niet zichtbaar. Zoek eerst in de Lighthouse-trace waar de tijd werkelijk verloren gaat.
Kan een tekstkop het LCP-element zijn?
Ja. Largest Contentful Paint kan een groot tekstblok zijn, zoals de H1 in je hero. Als CSS die kop verbergt of animeert, kan dat de LCP rechtstreeks vertragen.
Is een score van 100 op desktop genoeg?
Nee. Een desktopscore van 100 zegt alleen iets over die desktopmeting. Meet mobiel apart en controleer vooral de LCP, Speed Index en het grootste zichtbare element.
Hoe vaak moet ik mijn WordPress-snelheid meten?
Meet in ieder geval na wijzigingen aan het thema, scripts, plugins, fonts en afbeeldingen. Controleer daarnaast periodiek de belangrijkste pagina’s, omdat een nieuwe upload of ontwerpaanpassing een eerdere optimalisatie kan terugdraaien.
Kijk verder dan de groene desktopscore
Een groot verschil tussen desktop en mobiel los je niet op door willekeurig meer optimalisatie aan te zetten. Vind eerst het LCP-element, bepaal waar de vertraging ontstaat en pas daarna één oorzaak tegelijk aan.
Wil je weten wat jouw mobiele eerste scherm vertraagt? Stuur de pagina door via het contactformulier. Dan kijken we naar de meting en niet alleen naar het groene cijfer op desktop.