Hebt u gezocht op ‘Core Web Vitals-beoordeling mislukt’ nadat u een groene snelheidsscore zag? Controleer dan eerst welke gegevens elk resultaat beschrijft. PageSpeed Insights (PSI) combineert gegevens van echte bezoeken met een aparte gecontroleerde test. Leg het adres, het apparaat, het gegevensbereik en de metriek die niet voldoet vast voordat u een tool koopt of iemand vraagt de website opnieuw te bouwen.
Wij beginnen met die gegevens omdat ‘maak de score groen’ te veel openlaat. Een ontwikkelaar moet weten welke gebruikservaring aandacht vraagt en welk bewijs een zinvolle verbetering aantoont.
Core Web Vitals-beoordeling mislukt: wat heeft het rapport gemeten?
De beoordeling beschrijft vastgelegde bezoekerservaringen, terwijl het Lighthouse-gedeelte een diagnostische test uitvoert. De documentatie van Google over PageSpeed Insights legt uit dat de veldgegevens afkomstig zijn uit het Chrome User Experience Report, of CrUX, over een voortschrijdende verzamelperiode van 28 dagen. Een nieuwe diagnostische test en die historische gegevens kunnen daardoor verschillende resultaten laten zien.
De testomstandigheden verschillen. Eén gecontroleerde test kan niet alle apparaten, verbindingen en handelingen uit echte bezoeken omvatten. Gebruik de test om een mogelijke oorzaak te onderzoeken en houd de bezoekersgegevens erbij wanneer u bepaalt wat nog niet is opgelost.
Het resultaat kan een groter bereik hebben. Als er te weinig gegevens zijn voor de precieze pagina, kan PSI terugvallen op de oorsprong, de zogeheten origin. Dat is grofweg hetzelfde websiteadres inclusief protocol en hostnaam. Een resultaat voor de oorsprong bundelt bezoeken aan verschillende pagina’s. Lees het getoonde bereik voordat u het resultaat als bewijs voor een specifieke product- of dienstenpagina gebruikt.
De periode bevat oudere bezoeken. Een wijziging van vandaag herschrijft de waarnemingen van gisteren niet. Bewaar de datum waarop de wijziging live ging, zodat u een directe controle van de aanpassing kunt onderscheiden van latere bezoekersgegevens.
Door deze verschillen hebben de rapporten elk hun eigen taak: bezoekersgegevens wijzen een ervaring aan die onderzoek vraagt; een gecontroleerde test helpt die ervaring te reproduceren en te onderzoeken.
Welke metriek vraagt aandacht?
Bekijk LCP, INP en CLS afzonderlijk voordat u een oplossing kiest. De Web Vitals-richtlijnen van Google onderscheiden laden, reactiesnelheid en visuele stabiliteit. De onderstaande tabel geeft de grenswaarden voor ‘goed’ uit die richtlijnen, beoordeeld op het 75e percentiel voor de relevante groep apparaten. Googles uitleg van de grenswaarden licht dat percentiel toe: minstens 75% van de gemeten paginaweergaven moet voor die metriek aan de grenswaarde ‘goed’ voldoen. Dat is iets anders dan een gemiddelde of de totale Lighthouse-score.
| Metriek | Wat die beschrijft | Grenswaarde ‘goed’ | Vraag aan de beheerder |
|---|---|---|---|
| LCP, Largest Contentful Paint | Wanneer het grootste zichtbare inhoudselement verschijnt | Hoogstens 2,5 seconden | Welk element is vertraagd en waar in de laadvolgorde ontstaat dat? |
| INP, Interaction to Next Paint | Hoe snel de pagina op interacties reageert | Hoogstens 200 milliseconden | Welke tik, klik of toetsaanslag is traag onder de betreffende omstandigheden? |
| CLS, Cumulative Layout Shift | Onverwachte verschuivingen van de lay-out | Hoogstens 0,1 | Welk element verschuift en op welk moment tijdens het bezoek? |
Wanneer er voor al deze metrieken voldoende gegevens zijn, vereist PSI voor een geslaagde beoordeling dat hun waarden op het 75e percentiel goed zijn. Bij onvoldoende INP-gegevens kunnen goede LCP- en CLS-waarden nog steeds tot een geslaagde beoordeling leiden. Zijn er onvoldoende LCP- of CLS-gegevens, dan kan PSI die pagina of oorsprong niet beoordelen.
Behandel ontbrekende gegevens als onzekerheid. De CrUX-methodologie van Google vereist bezoeken die aan de meetvoorwaarden voldoen en voldoende populariteit; Google publiceert geen universeel minimumaantal bezoekers. Een ontbrekend resultaat vertelt u niet dat niemand de pagina bezoekt, dat de ervaring goed is of dat een aanpassing is mislukt.
Wat kunt u controleren voordat u voor werk betaalt?
Bewaar een uitgangsrapport en doorloop dezelfde klantreis op een telefoon voordat u een tool kiest. U hebt een duidelijke probleembeschrijving nodig: de pagina, de gegevens achter de waarschuwing en het gedrag dat u kunt reproduceren. Lukt reproduceren niet, leg die beperking dan vast in plaats van het gat met een vermoeden op te vullen.
- Open de precieze zakelijke pagina in PSI. Bewaar het adres en de rapportdatum. Neem de landingspagina of het paginasjabloon mee dat van belang is voor de aanvraag of aankoop die u onderzoekt.
- Noteer mobiel of desktop en het gegevensbereik. Leg vast of het veldgedeelte de URL, de oorsprong of onvoldoende gegevens weergeeft. Gebruik dezelfde selectie voor latere vergelijkingen.
- Benoem de metriek die aandacht vraagt. Gebruik de afzonderlijke Core Web Vitals-resultaten en lees daarna het diagnostische gedeelte voor aanwijzingen. Houd ontbrekende meetgegevens zichtbaar.
- Voer een echte taak uit op een telefoon. Open het menu, gebruik het relevante filter of vul het betreffende formulier in. Noteer wat laat laadt, traag reageert of onverwacht verschuift.
- Koppel een aanwijzing aan een test. Vraag de beheerder de betreffende handeling of laadvertraging te reproduceren en uit te leggen wat de test kan vaststellen.
Voor bredere controles van afbeeldingen, widgets, cache en hosting kunt u onze uitleg over veelvoorkomende oorzaken van een trage website gebruiken. Houd de huidige taak gericht op de mislukte beoordeling en op het bewijs waarmee u een aanpassing kunt beoordelen.
Wat moet de aanpassing omvatten?
Kies de kleinste wijziging die de diagnose ondersteunt en spreek vervolgens af hoe u die controleert. Begin met de rapporten en functies die u al hebt. Technisch werk wordt makkelijker te beoordelen als de beheerder de betreffende pagina of het sjabloon benoemt, het knelpunt uitlegt en de omstandigheden voor en na de wijziging vergelijkbaar houdt.
- Koppel het voorstel aan de metriek. De LCP-handleiding van web.dev onderscheidt vertraging bij de respons, ontdekking, het laden en de weergave van het grootste element. De INP-handleiding richt het onderzoek op trage interacties. De CLS-handleiding omvat ook verschuivingen na het eerste laden. Vraag om het relevante bewijs in plaats van een algemene belofte om de snelheid te verbeteren.
- Pas de vastgestelde oorzaak aan en test het gedrag opnieuw. Een gerichte aanpassing aan een bron of sjabloon kan onderdeel zijn van websiteontwikkeling en onderhoud. Leg vast wat er wanneer is veranderd en noteer waar mogelijk hoe u de wijziging terugdraait.
- Controleer of de klanttaak nog werkt. Test de navigatie, formulieren en aankoopstappen die relevant zijn voor de pagina. Houd toestemmingsfuncties werkend; onderzoek hun gedrag en lay-out met behoud van rechtsgeldige toestemming.
- Bepaal of er meer bewijs nodig is. Als de beschikbare rapporten de betreffende interactie of pagina niet kunnen aanwijzen, kunnen aanvullende metingen helpen. Vraag welke vraag de voorgestelde monitoring beantwoordt voordat u een betaalde dienst toevoegt.
Als de technische prioriteit onduidelijk is, kan technische SEO beginnen met een diagnose en een controleerbare werklijst. Een nieuw ontwerp of optimalisatiepakket heeft een eigen onderbouwing nodig.
U kunt deze taakkaart kopiëren en onbekende velden leeg laten:
Pagina en zakelijke taak:
Apparaat en bereik van de veldgegevens:
Metriek die aandacht vraagt:
Waargenomen gedrag en testomstandigheden:
Voorgestelde oorzaak en wijziging:
Datum waarop de wijziging live ging:
Vergelijkbare controle na de wijziging:
Latere veldwaarneming en resterende onzekerheid:Hoe controleert u of het werk heeft geholpen?
Beoordeel eerst het gewijzigde gedrag en vergelijk daarna latere veldgegevens binnen hetzelfde bereik. Volgens de documentatie werkt PSI zijn veldgegevens dagelijks bij, met behoud van een voortschrijdend verzamelvenster. Bewaar de datum waarop de wijziging live ging bij uw gegevens. Dat venster is geen gegarandeerde aftelperiode tot een geslaagde beoordeling.
Vergelijk de beoogde metriek en de klanttaak onder vergelijkbare testomstandigheden. Blijft het symptoom bestaan, pak de diagnose dan opnieuw op. Verbetert de test maar ondersteunen latere veldgegevens het effect van de wijziging niet, onderzoek dan opnieuw de betreffende pagina’s en de omstandigheden van bezoekers. Ontbrekende veldgegevens moeten een expliciete beperking blijven.
Onze rol
Wij beginnen met het rapport, de belangrijke pagina’s en een taak die we kunnen reproduceren. We onderscheiden de voorgestelde aanpassing, de controle daarvan en later bewijs van bezoekers, zodat elke beslissing een basis heeft die u kunt beoordelen. Een briefing voor websiteprestaties kan beginnen met de taakkaart hierboven; houd onbekende velden zichtbaar.
