Monitor Core Web Vitals van belangrijke websitepagina’s

Volg LCP, CLS en laadgegevens van geselecteerde openbare pagina’s op je projectdomein. Bekijk vijf metrics per URL en een aparte homepagesamenvatting met Speed Index; beoordeel een gerichte verbetering met een later labresultaat. Dit zijn gecontroleerde tests, geen veldgegevens van echte gebruikers.

Core Web Vitals monitoren Plannen vergelijken

Core Web Vitals-controles

LCP

Vind geselecteerde URL's waar de hoofdinhoud laat verschijnt.

CLS

Bekijk onverwachte verschuivingen in de opmaak op geselecteerde URL's.

Dagelijkse laboratoriummetingen

Noteer huidige waarden en bekijk na een gerichte verbetering een later labresultaat.

Screpy Core Web Vitals-dashboard met labprestaties voor gemonitorde URL’s
Logo van Uber in de klantvertrouwenssectie van het Screpy SEO-platform
Logo van Philips in de klantvertrouwenssectie van het Screpy SEO-platform
Logo van FedEx Express in de klantvertrouwenssectie van het Screpy SEO-platform
Logo van Bosch in de klantvertrouwenssectie van het Screpy SEO-platform
Logo van Champion in de klantvertrouwenssectie van het Screpy SEO-platform
Logo van Iconfinder in de klantvertrouwenssectie van het Screpy SEO-platform
Logo van T-Mobile in de klantvertrouwenssectie van het Screpy SEO-platform
Logo van Carrefour in de klantvertrouwenssectie van het Screpy SEO-platform
Logo van Stanley in de klantvertrouwenssectie van het Screpy SEO-platform
Logo van Skoda in de klantvertrouwenssectie van het Screpy SEO-platform

Monitor Largest Contentful Paint

Largest Contentful Paint meet wanneer de grootste geschikte afbeelding, het tekstblok of de video in het zichtbare testgebied verschijnt. Gebruik de LCP-waarde van iedere gemonitorde URL om te kiezen welke pagina een nader laadonderzoek verdient.

  • Screpy toont LCP in seconden: tot en met 2,5 s is goed, boven 2,5 s tot en met 4 s is verbetering nodig, en boven 4 s is slecht.
  • Een snelle FCP gevolgd door een langzame LCP betekent dat er al inhoud zichtbaar was vóór het hoofdelement. Onderzoek de levering en weergave daarvan in plaats van te veronderstellen dat de hele pagina leeg bleef.
  • Bevestig de betrokken afbeelding, het lettertype of de vertraagde weergave met een prestatieonderzoek door een ontwikkelaar. Het getal alleen identificeert geen element en schrijft geen oplossing voor.

Meet Cumulative Layout Shift

Een pagina kan snel laden en toch onverwacht een knop of alinea verplaatsen. Cumulative Layout Shift geeft iedere gemonitorde URL een stabiliteitsscore in het lab, zodat je beweging los van laadsnelheid kunt onderzoeken.

  • CLS heeft geen tijdseenheid: tot en met 0,1 is goed in Screpy, boven 0,1 tot en met 0,25 is verbetering nodig, en boven 0,25 is slecht.
  • Controleer gereserveerde ruimte voor afbeeldingen, advertenties en ingesloten inhoud, plus wijzigingen van lettertypen. Dit zijn mogelijke oorzaken; de Screpy-score identificeert niet welk element verschoof.
  • Een lage CLS tijdens laden sluit latere verschuivingen tijdens een bezoek niet uit. Controleer de daadwerkelijke interactie en veldgegevens als het probleem na het laden verschijnt.

Controleer Total Blocking Time

Total Blocking Time helpt werk op de hoofdthread herkennen dat invoerreacties tijdens laden kan vertragen. Lees TBT samen met LCP en FCP: snel zichtbare inhoud betekent niet noodzakelijk dat de pagina snel reageert.

  • TBT wordt getoond in milliseconden: tot en met 200 ms is goed, boven 200 ms tot en met 600 ms is verbetering nodig, en boven 600 ms is slecht.
  • Blokkeertijd telt de delen van lange taken boven 50 ms binnen de meetperiode op. Het is niet de totale JavaScript-uitvoeringstijd.
  • Analyseer bij hoge TBT lange taken en onnodige scripts met ontwikkelaarstools voordat je code wijzigt. De dashboardwaarde koppelt de vertraging niet aan een specifiek script.
  • TBT is geen INP. INP meet interacties en kan in het lab worden getest door die interacties uit te voeren; deze Screpy-functie rapporteert geen INP-meting.

Vergelijk FCP en TTFB

First Contentful Paint markeert de eerste zichtbare inhoud; Time to First Byte markeert het begin van de respons. Door beide voor dezelfde URL te lezen onderscheid je een vroege responsvertraging van de tijd om inhoud op het scherm te krijgen.

  • FCP wordt getoond in seconden: tot en met 1,8 s is goed, boven 1,8 s tot en met 3 s is verbetering nodig, en boven 3 s is slecht.
  • TTFB wordt getoond in milliseconden: tot en met 800 ms is goed, boven 800 ms tot en met 1.800 ms is verbetering nodig, en boven 1.800 ms is slecht. Verbindingen, redirects en responsgedrag kunnen de waarde beïnvloeden.
  • Bij lage TTFB en langzame FCP onderzoek je wat de eerste weergave ophoudt. Bij een langzame respons onderzoek je eerst de levering; geen afzonderlijke waarde bewijst een backend- of weergaveoorzaak.

Monitor belangrijke websitepagina’s

Volg een behapbare selectie openbare projectpagina’s in plaats van één homepageresultaat als de hele website te beschouwen. Gebruik de projectruimte van je abonnement voor pagina’s waar laad- of lay-outproblemen het meest tellen.

  • De homepage wordt toegevoegd bij het aanmaken van het project. Voeg andere openbare URL’s op het projectdomein of subdomeinen toe wanneer je abonnement monitoring toestaat.
  • Kies representatieve product-, categorie-, artikel- en conversie-ingangspagina’s. Een terugkerend templateprobleem kan nader onderzoek rechtvaardigen, maar één URL-test meet niet iedere pagina met dat template.
  • URL-invoer normaliseert het protocol en de host, voegt ontbrekende HTTPS toe en verwijdert fragmenten. Paden en queryparameters blijven belangrijk; dezelfde genormaliseerde URL wordt niet dubbel geaccepteerd.
  • Een toegevoegde pagina wacht op de eerste geplande controle voordat ze in de resultatentabel verschijnt. Een URL toevoegen start geen onmiddellijke test.
  • Bevestig verwijderen om de pagina niet meer te volgen en ruimte binnen je limiet vrij te maken. Dit verwijdert de gemonitorde registratie, niet de pagina van je website of Google.

Bekijk homepageprestaties

De samenvatting boven de URL-tabel gebruikt de gecontroleerde projecthomepage. Ze bundelt actuele labmetingen, inclusief Speed Index; de tabel eronder houdt haar vijf getoonde metrics aan iedere gemonitorde URL gekoppeld.

  • Lees FCP, LCP, CLS, TTFB, TBT en Speed Index in de homepagesamenvatting. Dit zijn homepagewaarden, geen gemiddelde van alle gevolgde pagina’s.
  • Speed Index beschrijft hoe snel zichtbare inhoud tijdens het laden wordt opgebouwd. Screpy toont seconden: tot en met 3,4 s is goed, boven 3,4 s tot en met 5,8 s is verbetering nodig, en boven 5,8 s is slecht.
  • Iedere balk vertegenwoordigt de huidige meting. Het is geen opgeslagen trend, bezoekerspercentage of Googles 75e percentiel uit veldgegevens.
  • Zonder gecontroleerd homepageresultaat is de samenvatting niet beschikbaar. Een resultaat van een andere gemonitorde URL wordt niet als vervanging gebruikt.

Volg dagelijkse labcontroles

Actieve geschikte pagina’s komen na een dag in aanmerking voor een nieuwe geplande controle. Bekijk na een gerichte wijziging het huidige resultaat en houd rekening met abonnementsvoorwaarden en beschikbaarheid van de controle, zonder een exact tijdstip te verwachten.

  • Sorteer resultaten op pagina-URL of CWV-status om je beoordeling te ordenen. FCP, LCP, CLS, TTFB en TBT blijven zichtbaar voor iedere geteste URL.
  • De CWV-badge gebruikt de slechtste beschikbare classificatie van LCP, CLS en TBT. PASS betekent dat die beschikbare waarden goed zijn; FAIL omvat zowel verbetering nodig als slecht.
  • Controleer ontbrekende waarden ook als de rij PASS toont. Een ontbrekende metric telt niet als gezonde meting; de badge bevestigt geen Google-beoordeling met LCP, INP en CLS uit het veld.
  • Geen gegevens betekent dat het laboordeel niet beschikbaar is. Een ontbrekende waarde is geen nul en een mislukte controle bewijst geen gezonde pagina.
  • Noteer huidige waarden voordat je een verbetering publiceert en vergelijk later dezelfde URL. De tabel toont actuele resultaten in plaats van een opgeslagen voor-en-na-geschiedenis.

Lees prestatiegegevens met SEO MCP

Neem de opgeslagen laboverzichtsgegevens van de homepage mee naar een AI-gesprek of REST-integratie. Vraag om uitleg van beschikbare metingen en gericht onderzoek, met het bewijs gescheiden van een voorgestelde oplossing.

  • Authenticeer en kies een project waartoe je toegang hebt. REST-toegang vereist ook dat Core Web Vitals in het projectabonnement beschikbaar is.
  • Het antwoord bevat de homepage-URL, opgeslagen controletijd en beschikbare FCP-, LCP-, CLS-, TTFB-, TBT- en Speed Index-waarden. Dit is homepagebewijs, geen lijst van alle gemonitorde pagina’s.
  • Zonder gecontroleerde homepage is er geen overzicht; individuele ontbrekende metingen blijven niet beschikbaar. Vraag de assistent om datagaten te benoemen voordat hij conclusies trekt.
  • De Core Web Vitals-MCP-tool leest opgeslagen gegevens. Ze start geen nieuwe test, voegt geen pagina’s toe, identificeert geen verantwoordelijk element en zet TBT niet om in INP.

Praat over Core Web Vitals. Met SEO MCP.

Lees het opgeslagen laboverzicht van de projecthomepage via SEO MCP. Laat beschikbare metrics uitleggen met URL en controletijd en kies je onderzoek zonder een rapport van alle pagina’s of een nieuwe test te veronderstellen.

  1. Screpy: Hallo! Laten we Core Web Vitals voor example.com bekijken. Wat wil je weten?
  2. Jij: Leg de opgeslagen labresultaten van de homepage van example.com uit en benoem wat onbekend blijft.
  3. Screpy: In dit homepagevoorbeeld is LCP 3,2 s en is verbetering nodig; CLS is 0,04 en goed. Controleer de opgeslagen URL en tijd voordat je de waarden gebruikt. Deze twee getallen tonen niet iedere metric, meten geen INP en identificeren geen verantwoordelijk element. Ik kan onderzoek voorstellen, geen nieuwe test uitvoeren. Voorbeeldwaarden van de homepage in het lab: LCP: 3,2 s. CLS: 0,04.
  4. Jij: Maak daar een kort actieplan van.
  5. Screpy: Ik houd bevindingen en aanbevelingen apart. Bekijk het bewijs, kies één wijziging en controleer daarna de resultaten. Je volgende stappen: Bekijk: Controleer bron en datum van elke bevinding.. Beslis: Kies de eerste wijziging.. Verifieer: Vergelijk de resultaten na de wijziging..
  6. Jij: Kun je het bewijs in gewone taal uitleggen?
  7. Screpy: Ja. Vraag naar een ondersteund resultaat en ik leg uit wat het toont, waar het vandaan komt en wat onzeker blijft. Ontbrekende gegevens blijven onbeschikbaar; aanbevelingen zijn geen automatische oplossingen.

Maak van een trage URL een testbare prestatieverbetering.

Houd URL en meetmethode stabiel, gebruik de zwakste metriek om het onderzoek te richten en valideer één wijziging met een latere controle.

  1. Kies een representatieve openbare URL

    Kies openbare URL’s op het projectdomein of de subdomeinen. Begin binnen je projectlimiet met de homepage, een conversie-ingang en een representatieve URL van een belangrijk template.

  2. Laat de geplande labcontrole een basislijn maken

    Geschikte actieve URL’s krijgen terugkerende geplande labcontroles. Bekijk na de eerste poging de beschikbare FCP-, LCP-, CLS-, TTFB- en TBT-waarden van de geteste URL; de aparte homepagesamenvatting bevat ook Speed Index.

  3. Volg de zwakke metriek naar een gerichte hypothese

    Kies op basis van de zwakke metric een gericht onderzoek: LCP voor hoofdinhoud, CLS voor onverwachte beweging, TBT voor blokkerend werk en FCP met TTFB voor het vroege laden. Homepage-Speed Index geeft context over zichtbare voortgang, geen bewezen oorzaak.

  4. Wijzig één oorzaak en meet opnieuw

    Noteer de waarden vóór een gerichte wijziging, houd de URL stabiel en vergelijk een later gepland resultaat. Het dashboard toont huidige metingen: bewaar je eerdere basislijn apart en onderzoek herhaalde veranderingen in plaats van één schommeling als bewijs te behandelen.

Monitor de pagina’s waar een regressie het meeste zou betekenen.

Een kleine representatieve URL-set is eenvoudiger te onderzoeken dan een dashboard vol pagina’s met lage waarde. Begin met bedrijfskritische routes en herbruikbare templates.

Belangrijkste landingspagina’s

Monitor pagina’s die het product, de dienst of campagne introduceren, omdat een trage eerste ervaring ontdekking en conversie kan beïnvloeden.

Gedeelde paginatemplates

Kies één representatieve product-, categorie-, artikel- of documentatie-URL om problemen te vinden die in hetzelfde template kunnen terugkeren.

Conversiepaden

Houd prijs-, registratie-, lead- en checkoutpagina’s zichtbaar wanneer scripts, embeds, experimenten of tags van derden de prestaties wijzigen.

Releasegevoelige pagina’s

Volg URL’s die worden geraakt door redesigns, frameworkwijzigingen, nieuwe media, tagmanagerupdates of wijzigingen in levering voordat je het patroon breder uitrolt.

Interpreteer labresultaten zonder ze te overschatten.

Screpy maakt terugkerende prestatiecontroles uitvoerbaar. Deze grenzen houden het resultaat juist wanneer velddata, oorzaakanalyse of rankingimpact de echte vraag is.

Labdata, geen velddata

Screpy voert gecontroleerde paginatests uit. Het resultaat vertegenwoordigt niet de echte gebruikersdataset van Chrome UX Report of Google Search Console.

TBT is geen INP

TBT beschrijft blokkerend werk in de gemeten laadperiode. INP vereist interactiemetingen en kan in het lab worden getest door interacties uit te voeren; deze Screpy-functie rapporteert geen INP en vervangt geen bewijs van echte gebruikersresponsiviteit.

Een beoordeling is geen oorzaak

Een slechte metriek toont waar je moet kijken. Bevestig element, verzoek, script, template of servergedrag voordat je iets wijzigt.

Prestaties zijn geen rankinggarantie

Een goede pagina-ervaring helpt gebruikers en zoeken, maar vervangt geen relevante content, crawlbaarheid, indexering, links of andere signalen.

Kies de prestatie-workflow die bij de vraag past.

Monitor geselecteerde URL’s voor terugkerende labresultaten, audit de bredere website op technische patronen of lees de meetmethode voordat je Screpy met velddata vergelijkt.

Screpy-documentatie

Leer labprestatiecontroles interpreteren

Gebruik de gids om URL’s te kiezen, labmetrics te lezen en ze van veldgegevens te onderscheiden. Bewaar een basislijn apart voordat je een gerichte verbetering met een later resultaat vergelijkt.

Core Web Vitals-gids lezen

Antwoorden op vragen over Core Web Vitals-monitoring.

Begrijp lab- versus velddata, LCP, CLS, TBT, aanvullende snelheidsmetrics, dagelijkse controles, URL-keuze, beoordelingen en de grenzen van claims over pagina-ervaring.

Welke pagina’s moet ik eerst monitoren?

Begin met de homepage, belangrijke openbare landingspagina’s, conversie-ingangen en een representatieve URL per belangrijk template. Toegevoegde URL’s moeten bij het projectdomein of subdomeinen horen en binnen de abonnementsruimte passen. Een templatevoorbeeld test niet alle pagina’s van dat template.

Wat meet Screpy Core Web Vitals Monitoring?

Screpy’s URL-tabel toont lab-FCP, LCP, CLS, TTFB en TBT. De gecontroleerde homepagesamenvatting voegt Speed Index toe. De tabel gebruikt PASS/FAIL; geauthenticeerde API- en MCP-antwoorden bevatten ook de homepage-URL en opgeslagen controletijd. Dit zijn geen metingen van echte gebruikers.

Hoe vaak worden gemonitorde URL’s gecontroleerd?

Actieve geschikte URL’s komen na een dag in aanmerking voor een nieuwe geplande controle. Het projectabonnement en de beschikbaarheid beïnvloeden de afronding; een resultaat op dagelijks hetzelfde tijdstip is niet gegarandeerd. Een nieuwe URL verschijnt na de eerste controlepoging in de tabel.

Zijn Screpy Core Web Vitals gebaseerd op echte gebruikers?

Nee. Screpy rapporteert gecontroleerde labmetingen voor de geteste URL. Velddata van Chrome UX Report of Google Search Console weerspiegelt echte bezoeken over een voortschrijdende periode en kan verschillen door apparaten, netwerken, regio en gedrag.

Waarom toont Screpy TBT in plaats van INP?

Deze functie meet laden en levert TBT als blokkeerdiagnose; ze meet niet de interacties die voor INP nodig zijn. INP kan in het lab worden getest door interacties uit te voeren, maar TBT is geen INP en beschrijft niet alle interacties na laden.

Welke metrics zijn de officiële Core Web Vitals?

Google definieert momenteel Largest Contentful Paint, Interaction to Next Paint en Cumulative Layout Shift als Core Web Vitals. Screpy meet LCP en CLS in het lab en rapporteert TBT als diagnose naast FCP, TTFB en Speed Index; TBT wordt niet als INP gepresenteerd.

Garandeert betere Core Web Vitals hogere rankings?

Nee. Google raadt goede Core Web Vitals aan voor gebruikers en zoeken, maar pagina-ervaring is slechts één onderdeel van veel signalen. Relevante content kan ook met een zwakkere ervaring ranken en een snelle pagina is geen garantie.

Betekent PASS in Screpy dat de URL Googles Core Web Vitals haalt?

Nee. Het tabeloordeel gebruikt de slechtste beschikbare labclassificatie van LCP, CLS en TBT en kan ontbrekende waarden hebben. Google beoordeelt echte gebruikersgegevens, inclusief INP, met eigen regels voor dekking en percentielen. Bekijk de beschikbare metrics en het relevante veldrapport voordat je die conclusie trekt.