Prestatie- en Core Web Vitals-audit

Fase P3 · Stage A — Begrijpen
Tijdsbox: 4–8 uur voor een representatieve audit; 2–5 werkdagen voor een sjabloonbreed onderzoek met engineeringtraces. De veldvalidatie van 28 dagen vindt plaats na oplossingen en verlengt de initiële audittijdsbox niet.
Eigenaar: de technisch SEO-lead is verantwoordelijk voor de scope en acceptatie. Een prestatie-engineer of senior front-end engineer is verantwoordelijk voor diagnose; platform-, CDN-, analyse-, ontwerp- en producteigenaren dragen bij waar hun systemen vertraging of instabiliteit veroorzaken.

Deze fase zet veldbewijs van echte gebruikers en herhaalbare labtests om in een herstelregister gekoppeld aan URL’s, sjablonen, metrics, eigenaren en gereed-wanneer-tests — niet in een generieke snelheidsscore.

Waarom deze fase, en waarom hier

Prestaties horen thuis in Stage A omdat een pagina die time-out geeft een crawlprobleem is voordat het een gebruikerservaringsprobleem is. Een crawler of retrieval-agent heeft een beperkt requestbudget. Als de origin hapert, herhaaldelijk doorverwijst of een onvolledig antwoord retourneert, kan de client de pagina verlaten voordat de inhoud kan worden geëvalueerd. Snellere koppen, betere copy en sterkere schema kunnen niet helpen bij content die niet betrouwbaar wordt opgehaald.

P3 gebruikt de canonieke hosts, beoogde indexeerbare sjablonen, prioriteitsreizen, statuscode-bewijs en onopgeloste infrastructuurbevindingen uit de technische baseline-audit . Die volgorde voorkomt valse diagnoses. Een “paginalading” van vijf seconden veroorzaakt door een redirect-lus is bijvoorbeeld geen taak voor beeldoptimalisatie, en een snelle test van een gecachte foutpagina is geen voldoende. P2 stelt vast dat de juiste URL kan worden opgevraagd en geselecteerd; P3 stelt vast dat deze binnen aanvaardbare tijd- en stabiliteitslimieten kan worden geleverd en gebruikt.

Het te laat uitvoeren van deze fase zorgt voor herbewerking. Een contentteam kan publiceren in een sjabloon waarvan de hero altijd het traagste element is, of een promotionele plek goedkeuren die elk productkaartje verschuift. Het defect vermenigvuldigt zich dan over nieuwe pagina’s.

Invoer en uitvoer

Invoer maakt de steekproef representatief. Uitvoer vormt het contract met de volgende fase: precies welke pagina’s betrouwbaar beschikbaar zijn, welke omstandigheden zwak blijven en welke prestatiebeperkingen latere metingen moeten kwalificeren.

Velddata en labdata zijn verschillend bewijs

Velddata beschrijft wat in aanmerking komende Chrome-gebruikers daadwerkelijk hebben ervaren. Het Chrome User Experience Report, meestal afgekort tot CrUX, aggregeert metingen van echte bezoeken en rapporteert het 75e percentiel: de waarde waar 75% van de geregistreerde ervaringen op of onder valt. Het omvat de rommeligheid van echte apparaten, netwerken, locaties, caches, toestemmingstools, sessies en interacties. Gebruik het om te beslissen of gebruikers de gepubliceerde drempels halen en of een geïmplementeerde wijziging de populatie uiteindelijk heeft verbeterd.

Labdata beschrijft één gecontroleerde paginalading of interactie onder vastgestelde omstandigheden. Lighthouse is een labtest die apparaat- en netwerksimulatie toepast, een trace vastlegt en waarschijnlijke oorzaken uitlegt. Gebruik het om een probleem te reproduceren, twee builds onder dezelfde opstelling te vergelijken, requestketens te inspecteren en werk te identificeren. Een labscore is nuttig bewijs, maar bewijst niet dat echte gebruikers slagen.

De twee bronnen kunnen van elkaar verschillen zonder dat een van beide fout is. Een snelle labrun kan een nabijgelegen locatie, warme CDN en geen noemenswaardige interactie gebruiken, terwijl veldbezoekers oudere telefoons en verre netwerken omvatten. Noteer het verschil en onderzoek de omstandigheden; middelde nooit de waarden en kies niet simpelweg de waarde die er gezonder uitziet.

De checklist

Voltooi deze controles in volgorde. Elk item vermeldt de actie, reden, methode, tool en acceptatievoorwaarde, zodat het kan worden toegewezen en opnieuw getest.

1. Vries de representatieve URL- en conditiematrix in

Wat: definieer de URL’s, sjablonen, apparaatprofielen, geografische gebieden, toestemmingsstatussen en cachemodi om te testen. Waarom: een alleen-homepage-audit kan slagen terwijl het product-, artikel- of afreken-sjabloon faalt. Hoe: combineer de P2-inventaris met verkeers- en bedrijfsprioriteitsdata; selecteer typische, zware en conversiekritieke voorbeelden. Tool: analyses, crawlinventaris, releaseregister en een gedeeld testblad. Gereed wanneer: elk prioritair sjabloon heeft een door de eigenaar goedgekeurd productievoorbeeld en elke test registreert apparaat, netwerk, locatie, login, toestemming en cache-aannames.

2. Leg de CrUX-veld-baseline vast

Wat: noteer beschikbare p75-veldmetrics op URL-niveau en afzonderlijk op origin-niveau. Waarom: de origin kan een zwak sjabloon verbergen, terwijl een individuele URL met weinig verkeer mogelijk geen publiceerbare data heeft. Hoe: gebruik dezelfde observatiedatum en hetzelfde venster van 28 dagen, label URL versus origin expliciet en noteer lege waarden als “onvoldoende data.” Tool: AmICited Web Vitals en CrUX. Gereed wanneer: elke bemonsterde URL heeft LCP-, INP-, CLS-, FCP- en TTFB-waarden of een gedocumenteerde onbekende status; bronsniveau en venster zijn ondubbelzinnig.

3. Verifieer de responsbetrouwbaarheid voordat je pixels scoort

Wat: herhaal verzoeken en noteer status, redirects, Time to First Byte (TTFB), time-outs en inconsistente antwoorden. TTFB is de interval van het begin van het verzoek tot het eerste byte van het antwoord aankomt. Waarom: een pagina kan niet schilderen voordat de HTML begint binnen te komen, en een intermitterende fout is ernstiger dan een cosmetische vertraging. Hoe: test koud en warm cachegedrag vanuit relevante regio’s, inspecteer servertiming en correleer afwijkingen met CDN- en origin-logboeken. Tool: request monitor, browser netwerkpaneel, CDN/origin-waarneembaarheid en Lighthouse-waterfall. Gereed wanneer: prioriteits-URL’s de beoogde 200-respons retourneren zonder onverwachte hops of time-outs, en elke langzame of mislukte respons heeft een gelogde bevinding met een eigenaar.

4. Diagnosticeer Largest Contentful Paint

Wat: identificeer het Largest Contentful Paint -element (LCP) en breek de tijd op in serververtraging, resource-ontdekking, resource-download en rendervertraging. LCP meet wanneer het grootste zichtbare beeld of tekstblok klaar is met renderen. Waarom: een afbeelding comprimeren heeft weinig zin als de browser deze laat ontdekt, en front-endwijzigingen kunnen een trage origin-wachttijd niet wegnemen. Hoe: inspecteer de trace en waterfall, vergelijk gecachte en niet-gecachte runs, controleer preload-prioriteit, responsieve afbeeldingsgroottes, render-blokkerende resources, lettergedrag en client-side rendering. Tool: Lighthouse, browserprestatietools, request-waterfall en beeldinspectie. Gereed wanneer: het werkelijke LCP-element en de dominante subcomponent zijn benoemd voor elk falend sjabloon, met een reproduceerbare vóór-meting en een specifieke oplossingshypothese.

5. Diagnosticeer Interaction to Next Paint

Wat: test het Interaction to Next Paint -pad (INP) voor echte acties zoals menu-openen, filteren, toevoegen aan winkelwagen, formulieren en het wegklikken van toestemming. INP meet de vertraging van een gebruikersinteractie totdat de browser de volgende visuele update toont, waarbij een interactie met hoge latentie uit het bezoek wordt gebruikt. Waarom: een pagina kan volledig lijken maar toch de gebruiker negeren terwijl JavaScript de hoofdthread bezet houdt. Hoe: reproduceer belangrijke acties, inspecteer lange taken en event-handlers, test third-party scripts en scheid invoervertraging, verwerkingstijd en presentatievertraging. Tool: CrUX, browserprestatietrace, interactieprofilering en een realistisch apparaat. Gereed wanneer: elke belangrijke interactie is uitgevoerd, de trage interactie en verantwoordelijke taak zijn geïdentificeerd voor falende sjablonen en de oplossing heeft een herhaalbare interactietest.

6. Diagnosticeer Cumulative Layout Shift

Wat: lokaliseer onverwachte beweging die bijdraagt aan Cumulative Layout Shift (CLS). CLS is een score zonder eenheid die onverwachte visuele beweging tijdens het leven van de pagina vertegenwoordigt. Waarom: een late banner, afbeelding zonder formaat, verwisseld lettertype, advertentie of gehydrateerd component kan de link verschuiven waarop een gebruiker op het punt staat te klikken en kan veranderen waar geautomatiseerde extractie inhoud vindt. Hoe: gebruik layout-shift-regio’s en een filmstrip, test vertraagde assets en toestemmingsstatussen en inspecteer elementen zonder gereserveerde afmetingen. Tool: CrUX, Lighthouse-trace, browser-renderdiagnostiek en visuele regressie-opname. Gereed wanneer: elke materiële verschuiving een bronelement, trigger en oplossing voor gereserveerde ruimte of rendering heeft; verwachte beweging onmiddellijk veroorzaakt door een gebruikersactie wordt afzonderlijk gedocumenteerd.

7. Gebruik FCP om blanco-schermvertraging te scheiden

Wat: meet First Contentful Paint (FCP), de tijd totdat de browser de eerste tekst, afbeelding, canvas of SVG-content rendert. Waarom: FCP onderscheidt een vroeg teken van vooruitgang van een pagina die leeg blijft, ook al bewijst het niet dat de hoofdinhoud gereed is. Hoe: vergelijk FCP met TTFB en LCP, inspecteer vervolgens blokkerende CSS, lettertypen, scripts, server-gerenderde markup en streaminggedrag. Tool: CrUX, Lighthouse en de netwerk-/prestatietrace. Gereed wanneer: elke trage FCP is toegewezen aan serververtraging, renderblokkering, alleen-client-rendering of een andere bewezen oorzaak, in plaats van slechts te worden beschreven als “de pagina voelt traag.”

8. Rangschik bevindingen op ernst, bereik en afhankelijkheid

Wat: orden de backlog op faalband, getroffen verkeer en sjablonen, bedrijfskritikaliteit en upstream-afhankelijkheid. Waarom: vijf gele scores oplossen kan de sprint verbruiken, terwijl één rode TTFB-fout elke pagina op de origin vertraagt. Hoe: plaats betrouwbaarheidsfouten eerst, daarna slechte metrics vóór metrics die verbetering behoeven; binnen dezelfde ernst, los gedeelde platformoorzaken en TTFB op vóór downstream LCP-werk. Tool: bevindingenregister, analyses, sjablooninventaris en engineeringschatting. Gereed wanneer: elke bevinding een ernst, geteld aantal getroffen URL’s of sjabloonscope, bewijs, eigenaar, inspanning, afhankelijkheid en expliciete prioriteit heeft.

9. Valideer implementatie in het lab

Wat: vergelijk de gewijzigde build met de vastgelegde baseline onder identieke omstandigheden. Waarom: velddata kan geen onmiddellijke releasefeedback geven en een niet-reproduceerbare “na”-run kan niet vaststellen dat de codewijziging het verschil veroorzaakte. Hoe: voer meerdere gecontroleerde steekproeven uit, vergelijk medianen in plaats van de enige beste run, inspecteer de trace op regressies en test kritieke interacties en layouts. Tool: Lighthouse, browserprestatietools, staging of gecontroleerde productierelease en request monitoring. Gereed wanneer: de beoogde oorzaak is verwijderd, de doelmetric het overeengekomen labbudget haalt over herhaalde runs, geen andere kritieke metric regresseert en bewijs is bijgevoegd bij de bevinding.

10. Annoteer de release en wacht op veldbevestiging

Wat: noteer implementatietijd, scope, verwachte metric en validatiedata. Waarom: CrUX is een voortschrijdend venster van 28 dagen, dus bezoeken van vóór de release blijven in het gerapporteerde percentiel nadat de oplossing is uitgerold. Hoe: monitor fouten onmiddellijk, controleer directionele veldbeweging naarmate nieuwe data binnenkomt en maak de definitieve vergelijking pas wanneer voldoende dagen na de release het venster vertegenwoordigen. Tool: implementatielogboek, AmICited Web Vitals, CrUX en monitoring. Gereed wanneer: onmiddellijke technische controles slagen, de release-aantekening zichtbaar is en een genoemde eigenaar en datum bestaan voor veldbevestiging; de bevinding wordt niet als “geverifieerd” gemarkeerd op basis van alleen labbewijs.

Tools in AmICited

Open https://app.amicited.com/audit/web-vitals om je domein te vergelijken met gevolgde concurrenten met behulp van echte CrUX-gebruikersdata. De audit plaatst LCP, INP, CLS, FCP en TTFB in één tabel, markeert je domein en maakt ontbrekende velddata zichtbaar in plaats van deze om te zetten in een misleidende nul. Gebruik de vergelijking om twee vragen te beantwoorden: of het domein de gepubliceerde drempels haalt en of een concurrent die hetzelfde publiek bedient een materieel beter veldresultaat heeft laten zien.

De Performance Impact -functie verbindt prestaties op paginaniveau met citatiepositie en -waarschijnlijkheid. Beschouw de relatie als prioriteringsbewijs, niet als bewijs dat snelheid alleen een citatieverandering veroorzaakte. Als een langzame geciteerde pagina en een snelle niet-geciteerde pagina verschillen in autoriteit, relevantie of inhoud, is prestatie slechts één variabele. Het nuttige signaal is dat een getroffen pagina waardevol genoeg is om op te lossen en te monitoren.

Volg voor productgebruik Hoe je je Core Web Vitals controleert in AmICited . Dit playbook definieert audit-scope, beslissingen en overdracht; de tutorial behandelt de klikken en metingen, dus dit hier dupliceren zou twee instructies opleveren die uit elkaar kunnen gaan lopen.

Beslisregels: hoe slecht eruitziet

Beoordeel Core Web Vitals op basis van velddata op het 75e percentiel. “Goed” betekent dat de p75-waarde op of onder de goede grens ligt. Een waarde op een grens behoort tot de betere band; bijvoorbeeld LCP van precies 2,5 seconden is goed. Ondersteunende FCP- en TTFB-drempels sturen diagnose en acceptatie, maar ze maken geen deel uit van de beoordeling van de drie Core Web Vitals-metrics.

Gebruik deze prioriteitsregels:

1. Mislukte verzoeken, time-outs en ongeldige antwoorden hebben voorrang op scores. Betrouwbaarheid is de leveringspoort.
2. Los slechte bands op vóór bands die verbetering behoeven. Rood is een aangetoonde slechte ervaring, geen poetskans.
3. Los TTFB op vóór LCP wanneer TTFB faalt. LCP kan niet plaatsvinden voordat de reactie begint, dus backend-vertraging verbruikt het LCP-budget voordat de browser iets kan renderen.
4. Geef de voorkeur aan gedeelde oorzaken boven geïsoleerde symptomen. Eén cache-beleidsreparatie over vier sjablonen weegt zwaarder dan vier afzonderlijke afbeeldingsaanpassingen met kleinere reikwijdte.
5. Gebruik verkeer en reiswaarde binnen dezelfde ernst. Een slechte INP bij afrekenen of LCP van een artikel met veel verkeer weegt zwaarder dan een archief met weinig verkeer in dezelfde band.
6. Noem een lege CrUX-waarde niet goed. Het is onbekend. Gebruik herhaalbaar labbewijs en een vergelijkbaar sjabloon tot er voldoende veldvolume is.
7. Beloof geen onmiddellijke veldbeweging. Valideer de implementatie nu, laat dan het voortschrijdende venster oudere ervaringen vervangen voordat je het veldresultaat accepteert of afwijst.

Oplevering: het prestatieherstelregister

Overhandig aan engineering één register plus de bijbehorende bewijsmap. Een spreadsheet, issue tracker of gestructureerde projecttabel is acceptabel als het deze velden behoudt en filtering op sjabloon, ernst, eigenaar en status mogelijk maakt:

ID en bevinding:
Getroffen URL's en sjablonen:
Prioriteitsreis en verkeerscontext:
Metric en veldband:
CrUX-niveau, p75-waarde en 28-dagenvenster:
Labconfiguratie en herhaalde baseline:
Waargenomen oorzaak en bewijsreferentie:
Verwachte conditie en doel:
Aanbevolen wijziging:
Ernst en prioriteitsmotivatie:
Eigenaar, afhankelijkheid en inspanning:
Releasedatum en aantekening:
Onmiddellijk lab-acceptatieresultaat:
Veldbevestigingsdatum en -resultaat:
Status: Open | Gepland | Lab geaccepteerd | Veld geverifieerd | Geaccepteerd risico

Voeg de URL-matrix, CrUX-export, labtraces, waterfalls, filmstrips, interactie-opnames, layout-shift-bewijs en release-aantekeningen bij. Dedupliceer op oorzaak: als dezelfde niet-gecachte origin-query een slechte TTFB veroorzaakt over drie sjablonen, maak dan één overkoepelende bevinding met drie getroffen scopes in plaats van drie concurrerende diagnoses.

“Geaccepteerd risico” heeft een genoemde goedkeurder, reden, getroffen scope, verval- of herzieningsdatum en monitoringsvoorwaarde nodig. Het is geen vervanging voor een eigenaar. De overdracht is compleet wanneer een engineer de fout kan reproduceren en de eigenaar van de volgende fase kan identificeren welke resultaten nog beperkt worden door prestaties.

Wat er misgaat

Lighthouse behandelen als het oordeel. Een score van 100 in één labrun vervangt geen slechte p75-velddata. Behoud Lighthouse als diagnostisch bewijs en CrUX als populatiebewijs.

Alleen de homepage testen. Bemonster elk hoogwaardig sjabloon plus een zwaar voorbeeld, anders ontsnappen sjabloondefecten aan de audit.

De LCP-afbeelding optimaliseren voordat TTFB wordt gecontroleerd. De asset kan klein zijn terwijl de origin twee seconden besteedt aan het genereren van HTML. Splits LCP op in componenten en los eerst de upstream-tijd op.

De enige snelste run gebruiken. Cache-warmte, achtergrondactiviteit en netwerkvariatie kunnen een flatteuze uitschieter creëren. Houd de configuratie vast en vergelijk medianen van herhaalde runs.

De dag na de release de overwinning uitroepen. Het lab kan bewijzen dat code en levering onmiddellijk zijn veranderd; het veldvenster van 28 dagen kan dat niet. Annoteer de release en plan veldacceptatie.

Ontbrekende CrUX-data als nul markeren. Geen data betekent dat de drempel voor geschiktheid of verkeer niet is gehaald. Het zegt niets over prestatiekwaliteit.

De samengestelde score najagen in plaats van de falende ervaring. Een samenvattende score kan verbeteren terwijl een afrekeninteractie nog steeds hapert of een held nog steeds verschuift. Accepteer genoemde metrics en reizen, geen cosmetische scorebeweging.

Nuttige functionaliteit verwijderen om een test te winnen. Het verwijderen van toestemming, personalisatie, analyses of toegankelijkheidsgedrag uit de labvariant produceert een resultaat dat gebruikers nooit ontvangen. Optimaliseer de productievereiste of neem een expliciet productbesluit.

Regressies buiten de doelmetric negeren. Het uitstellen van scripts kan LCP verbeteren maar een slechte INP creëren bij de eerste interactie; het reserveren van de verkeerde afmetingen kan een laadvertraging vervangen door CLS. Test alle vijf metrics en de kritieke reis opnieuw.

Volgende fase: AI-toegankelijkheid en agentgereedheid

De AI-toegankelijkheid en agentgereedheid -fase ontvangt de representatieve URL-matrix, responsbetrouwbaarheidsbewijs, TTFB-verdeling, onopgeloste prestatiebevindingen en een verklaring van welke inhoud aanwezig is in de eerste reactie. De eigenaar gebruikt dat bewijs om een toegangsbeleidsfout te onderscheiden van een leveringsfout en om de reële omstandigheden te reproduceren waaronder een agent de pagina ophaalt.

De volgende fase kan doorgaan wanneer kritieke URL’s betrouwbaar reageren en geen onopgelost prestatieprobleem het ophaalbewijs oninterpreteerbaar maakt. Het kan doorgaan met een schriftelijke beperking wanneer een metric die verbetering behoeft gebruikers treft maar stabiele toegang niet verhindert. Het moet pauzeren voor getroffen sjablonen wanneer verzoeken time-out geven, intermitterende fouten retourneren of de hoofdreactie regelmatig de afgesproken kritieke drempel overschrijdt.

De overdracht is compleet wanneer de volgende eigenaar weet welke URL’s elk sjabloon vertegenwoordigen, de testomstandigheden, de resterende leveringsfouten en of P3-bewijs al een trage agent-ophaaling verklaart.

FAQ

Veelgestelde vragen