Begin met reizen, niet met een site-brede gemiddelde
Noem drie tot vijf reizen waarbij vertraging duidelijke klant- of operationele kosten heeft: landen op een campagnepagina, een product vinden, een leadformulier indienen, inloggen of een supportverzoek afronden. Schrijf voor elke reis het begin, het nuttige resultaat, de belangrijkste apparaatsklasse en welke pagina of interactie goed moet werken.
Geef elke reis zijn eigen budgetregel. Een dashboard mag meer code bevatten dan een publiek artikel, maar de filteractie heeft een responsiviteitsdoel nodig. Een mediaryke productpagina kan grotere afbeeldingen accepteren, maar heeft een limiet nodig voor de hoofdzichtbare afbeelding. Dit voorkomt dat een zwak kritisch pad wegvalt in een origin-breed gemiddelde.
Omschrijf wat de bezoeker kan zien of doen, zoals het aanbod lezen, een resultaat zien of een formulierbevestiging ontvangen.
Caching kan de assetkosten wezenlijk veranderen, dus noteer of het budget een eerste bezoek, een herhaalbezoek of beide dekt.
Kies uitkomsten en beheersbare inputs
Gebruik zowel uitkomststatistieken als inputlimieten. Google beschrijft Largest Contentful Paint (LCP) als laadtoelatingsprestatie; Interaction to Next Paint (INP) als interactieresponsiviteit; en Cumulative Layout Shift (CLS) als visuele stabiliteit. De aanbevolen goede drempels zijn LCP op of onder 2,5 seconden, INP op of onder 200 milliseconden en CLS op of onder 0,1 op het 75e percentiel, afzonderlijk beschouwd voor mobiel en desktop.
Voeg limieten toe die vroeg een oorzaak blootleggen: initiële JavaScript, afbeeldingen die nodig zijn vóór de hoofdinhoud, totale transfer voor de route, third-party verzoeken en een bekend duur widget. Houd gecomprimeerde transfers consistent bij. Een diagnostiek zoals Time to First Byte kan helpen bij het onderzoeken van traag laden, maar het is op zich geen klantuitkomst.
Gebruik LCP wanneer de reis afhankelijk is van het zichtbaar worden van de hoofdinhoud.
Gebruik veld-INP voor zoeken, filteren, menu’s en checkout; gebruik een labproxy alleen vóórdat velddata beschikbaar is.
Beperk de initiële route en grootste bijdragers zodat eigenaren weten wat aangepast moet worden na een overschrijding.
Stel cijfers op basis van je basislijn
Leg een basislijn vast voor elke reis. Onderscheid in PageSpeed Insights Chrome User Experience Report velddata, die echte Chrome-gebruikerservaringen aggregeert, van Lighthouse-labdata, wat een gecontroleerde test is. Velddata controleert de ervaring die gebruikers bereiken; labtests maken een wijziging reproduceerbaar vóór release.
Segmenteer minstens op mobiel en desktop en, waar mogelijk, per kritisch template of URL. PageSpeed Insights kan terugvallen van URL-data naar origin-data, en sommige pagina’s hebben geen CrUX-data. Label die gevallen als een labbasislijn en voeg real-user meting toe voor belangrijke reizen. Bewaar de test-URL, apparaat- en netwerkprofiel, cache-status, datum en toolversie bij elke basislijn.
Kies een doel dat de basislijn in een geplande stap verbetert en test het vervolgens onder representatieve omstandigheden. Een budget dat normale releases blokkeert, wordt omzeild; een budget boven de huidige ervaring beschermt niemand.
Het 75e percentiel is de waarde waarop 75% van de waargenomen ervaringen op of onder valt; het is geen gemiddelde.
Maak het budget tot een releaseregel
Houd het budget in een versioneerde, reviewbare plaats naast de code of release-checklist. Elke regel heeft de reis, metric, testprofiel of populatie, waarschuwingsdrempel, foutdrempel, eigenaar, meetmethode en uitzonderingstraject nodig. MDN raadt waarschuwings- en foutniveaus aan: de waarschuwing ondersteunt proactieve planning, terwijl de fout een bovengrens is met merkbaar negatief effect.
Automatiseer betrouwbare checks. Een bundler kan een te groot asset of initiële entry-point weigeren; webpack ondersteunt maximum asset- en entry-pointlimieten en productie-fouthints. Voer reproduceerbare labtests uit voor de betreffende reis in pull requests of releasekandidaten. Houd veldstatistieken voor post-release verificatie en prioritering in plaats van een onbetrouwbare build-gate.
Wanneer een limiet faalt, verklein een asset, stel niet-essentiële code uit, wijzig de ervaring, splits de release of keur een uitzondering goed. Verhoog de drempel niet stilzwijgend om de build te laten passeren.
Leg een product- en technische eigenaar vast, klantimpact, vervaldatum en remedietaak vóór release.
Blokkeer een reproduceerbaar foutdrempel op een beschermd pad; waarschuw en onderzoek waarschuwingsdrempels.
Verifieer en herstel na lancering
Paginagewicht voorspelt niet de volledige ervaring. Verzoekvolgorde, render-blokkerend werk, apparaatcapabiliteit, netwerkcondities, caching en third parties spelen ook een rol. Houd inputlimieten om groei te detecteren en uitkomstmetingen om te testen of het pad bruikbaar is. De W3C Resource Timing-interface geeft resource-timings en transfer-, gecodeerde en gedecomprimeerde groottes voor diepere diagnose. Cross-origin timingdetail kan beperkt zijn door timing-permissies, dus een onvolledige waterfall bewijst niet dat er geen third-party kosten zijn.
Bekijk veldresultaten na belangrijke template-, platform-, marketing-tag- of verkeerswijzigingen. Als LCP verslechtert, inspecteer serverrespons, de LCP-resource en render-blokkerend werk. Als INP verslechtert, inspecteer echte interacties; Lighthouse kan INP niet meten omdat er geen gebruikersinput is, hoewel Total Blocking Time een labproxy is. Gebruik SIU’s proactieve optimalisatieworkflow om een overschrijding te triëren, het kritieke pad te stabiliseren en de fix in dezelfde meetcontext te verifiëren.
Verlopen uitzonderingen tonen snel tijdelijke prestatieschuld die permanent werd.