Er is één plek waar u ziet hoe snel uw site is voor mensen die er echt op komen, en dat is niet een testtool. Het paginasnelheid rapport search console noemt Google zelf het rapport Core Web Vitals, en het staat in het linkermenu onder Ervaring. Het werkt anders dan u gewend bent, en juist daarom wordt het vaak verkeerd gelezen.
Hieronder loop ik het rapport met u door: wat u ziet, waarom de aantallen niet kloppen met uw sitemap, en in welke volgorde u de meldingen oppakt.
Het paginasnelheid-rapport (Search Console) van dichtbij
De cijfers komen uit metingen bij echte Chrome-gebruikers die uw site bezochten en die het delen van gebruiksstatistieken aan hebben staan. Het gaat om een voortschrijdend gemiddelde over achtentwintig dagen, en Google kijkt daarbij naar de waarde die 75 procent van uw bezoekers haalt of beter.
Dat verklaart twee dingen die mensen in verwarring brengen. Ten eerste: aanpassingen zijn hier pas na weken zichtbaar, omdat het venster van achtentwintig dagen langzaam meeschuift. Ten tweede: pagina’s met weinig bezoek staan er niet in, want zonder voldoende metingen laat Google geen cijfer zien.
Er zijn drie meetwaarden. Het moment waarop het grootste element in beeld staat, de reactiesnelheid op de eerste interactie, en de mate waarin de indeling verspringt tijdens het laden. Wat die drie inhouden en welke grenswaarden gelden, staat uitgewerkt in de toelichting op de drie meetwaarden van Google.
Groepen in plaats van losse pagina’s
Het meest verwarrende onderdeel: Google toont geen lijst met pagina’s, maar groepen van vergelijkbare URLs. Alle blogartikelen worden bijvoorbeeld als één groep behandeld, met daaronder een handvol voorbeeld-URLs.
Dat is eigenlijk goed nieuws. Het betekent dat u niet honderd pagina’s hoeft te repareren, maar één sjabloon. Vindt u de oorzaak op één blogartikel, dan lost u hem voor alle artikelen tegelijk op.
Het betekent ook dat de aantallen misleidend groot ogen. “1.240 URLs slecht” klinkt dramatisch, maar het gaat vaak om één productsjabloon met een zware afbeelding erin. Kijk dus altijd eerst naar het aantal groepen, niet naar het aantal URLs.
Het rapport stap voor stap doorlopen
- Kies eerst het tabblad Mobiel. Daar zit het probleem bijna altijd, en Google beoordeelt vooral de mobiele ervaring.
- Kijk naar de grafiek in de tijd. Een plotselinge knik verraadt een wijziging: een nieuwe plugin, een nieuw script, een grote afbeelding op een sjabloon. Leg die datum naast uw eigen wijzigingslogboek.
- Open de tabel met problemen. Elke regel noemt de meetwaarde en het aantal URLs. Begin bij de regel met het meeste bezoek, niet met de meeste URLs.
- Klik door naar de voorbeeld-URLs en open er twee of drie in PageSpeed Insights. Daar staat pas wat er concreet aan de hand is.
- Los het op in het sjabloon, niet op de losse pagina.
- Klik op Validatie starten zodra u klaar bent. Google gaat dan opnieuw kijken en meldt binnen enkele weken of het probleem is verholpen.
Die laatste stap wordt vaak vergeten. Zonder validatie duurt het langer voordat het rapport bijtrekt, en u mist de bevestiging dat uw reparatie ook werkelijk hielp.
Twee praktische opmerkingen bij die validatie. Ten eerste duurt hij lang: reken op twee tot vier weken voordat u uitsluitsel krijgt, omdat Google opnieuw achtentwintig dagen aan bezoekgegevens nodig heeft. Ten tweede kan hij mislukken terwijl uw reparatie klopt, bijvoorbeeld doordat er een tweede oorzaak in hetzelfde sjabloon zit. Start hem in dat geval gewoon opnieuw nadat u ook die heeft aangepakt; er zit geen limiet op het aantal pogingen.
De drie meest voorkomende bevindingen
Het grootste element laadt te traag. Negen van de tien keer is dat een sfeerfoto boven aan de pagina die te zwaar is of die te laat wordt opgehaald omdat hij als achtergrond is geplaatst. Dit is de meest lonende reparatie in het hele rapport.
De indeling verspringt. Meestal veroorzaakt door afbeeldingen zonder opgegeven afmetingen, door een cookiemelding die na een seconde inschuift, of door lettertypen die omwisselen. Afmetingen meegeven is vaak een kwestie van een vinkje in uw thema.
De pagina reageert traag op de eerste klik. Dit wijst op te veel JavaScript dat tegelijk wil starten, vaak van trackingscripts of van een paginabouwer. Uitstellen tot na het laden lost het meestal op, maar test dan wel of formulieren en filters nog werken.
Wanneer u dit rapport mag negeren
Staat alles in het groen, dan is er niets te winnen, hoe vaak een verkoper u ook belt over uw score. En heeft u weinig verkeer, dan blijft het rapport leeg of instabiel; dan is meten met een testtool zinniger. Meet in dat geval bewust met een mobiel profiel, zoals beschreven in het stappenplan voor testen op een trage verbinding.
Verwar dit rapport ook niet met uw posities. Snelheid is één signaal tussen vele, en een tragere pagina met een beter antwoord wint het nog altijd van een snelle pagina met een dun verhaal.
Een laatste valkuil: dit rapport gaat over pagina’s zoals Google ze kent, dus inclusief adressen met parameters van campagnes of filters. Ziet u groepen met vreemde adressen, dan komen die vaak uit uw eigen advertenties of uit een filterfunctie in een webshop. Dat is op zichzelf geen fout, maar het kan uw cijfers vertroebelen omdat zulke pagina’s zwaarder laden dan de gewone variant.
Maak er een maandelijkse gewoonte van
Vijf minuten per maand is genoeg: open het rapport, kijk of de lijn de goede kant op loopt en of er nieuwe groepen bij zijn gekomen. Zo ontdekt u een nieuw script of een zware afbeelding binnen weken in plaats van bij de volgende klacht.
Bij WebMaintor zetten we dit getal in de maandrapportage naast het aantal updates, juist omdat het de enige snelheidsmeting is die van echte bezoekers komt. Dat past bij hoe wij snelheidswerk aan echte bezoekcijfers koppelen in plaats van aan een momentopname.
Concrete volgende stap: open Search Console, ga naar het rapport onder Ervaring en kijk hoeveel groepen er in het rood staan op mobiel. Dat aantal is uw werkvoorraad, en die is bijna altijd kleiner dan u vreesde.
