Meet een klanttraject voordat u code wijzigt
Kies één belangrijk pad en interactie, zoals het openen van navigatie, filteren van resultaten of het indienen van een formulier. Neem dit op in het Performance-paneel van Chrome DevTools in een schone browsertoestand. Herhaal de actie en leg zowel een run met CPU-throttling als een run op een ontwikkelmachine vast; desktoptraces kunnen werk verbergen dat op een minder krachtige telefoon storend is.
Gebruik de trace om een smalle hypothese te testen, niet om een component de schuld te geven op basis van een bundelrapport. In de Main flame chart nemen bredere balken meer tijd in beslag en gestapelde balken tonen de call stack. Een rood driehoekje op een Task identificeert een potentiële long task; selecteer het en volg de link naar de initierende code. Sla before-and-after traces op voor betekenisvolle veranderingen.
Neem op net voor de actie en stop na het zichtbare resultaat.
Houd route, accountstatus en actiesequentie consistent.
Ken elke grootste kostenpost toe aan het team of de leverancier die deze kan veranderen.
Lees de trace als een wachtrij van werk
Een long task is een drempel voor onderzoek, geen volledige diagnose. De W3C Long Tasks-specificatie rapporteert taken van 50 milliseconden of langer. Kijk onder een taak voor JavaScript-evaluatie, een event handler, stijlherberekening, layout of paint. De call stack geeft aan waar te beginnen; timing toont of het probleem code, rendering of een third-party frame is.
Prioriteer kosten die terugkeren tijdens een waardevolle interactie. Een korte handler kan nog steeds traag aanvoelen als deze layout triggert of achter eerder werk wacht. De trace is een labmeting, bevestig de oplossing op representatieve apparaten en, waar beschikbaar, met privacybewuste veldtelemetrie.
Startup-parsing vereist een andere remedie dan een post-tap handler.
Vind herhaalde stijl-write en layout-read patronen vóór refactoring.
Voeg de trace, scenario en topkosten toe aan het werkitem.
Lever minder code op het moment dat het ertoe doet
Maak een inventaris van scripts per route en doel. Verwijder ongebruikte packages, duplicaten, gepensioneerde experimenten en code voor afgesloten features. Split vervolgens route-specifieke of zelden gebruikte features zodat ze laden wanneer ze nodig zijn in plaats van in het initiële pad. Dynamisch laden kan startup-werk verminderen, maar kan zichtbare vertraging creëren wanneer een gebruiker de feature direct nodig heeft.
Vraag je af of een component een volledig client-side framework nodig heeft, of een utility bestaande mogelijkheden dupliceert en of statische HTML plus een kleine uitbreiding volstaat. Test de fallbacktoestand van een uitgestelde module. De pagina moet optionele functionaliteit probleemloos kunnen uitstellen in plaats van een niet-werkend bedieningselement te tonen.
Documenteer welke scripts op een route zijn toegestaan en waarom.
Overweeg dit voor optionele editors, kaarten, spelers of rapportageweergaven.
Test authenticatie, toegankelijkheid, betalingen en formulierafhandeling; zoek gekwalificeerde review waar bedieningselementen beïnvloed worden.
Verdeel werk zodat de browser kan reageren
Het opdelen van code in kleinere functies creëert geen aparte browsertaken als die functies synchroon worden uitgevoerd. Deel bij een lange lus het werk op in batches, werk de direct zichtbare gebruikersstatus bij en geef daarna de CPU vrij voordat je doorgaat. Zo kan de browser tussen batches invoer en rendering verwerken.
Waar ondersteund, geeft `scheduler.yield()` de main thread vrij en gaat het werk later verder; controleer met feature detection of de functie beschikbaar is en gebruik een fallback voor niet-ondersteunde browsers. Geef de uitvoering niet na elke piepkleine bewerking vrij: dat heeft overhead en kan de voltooiingstijd verhogen. Kies grenzen op basis van metingen, behoud de mogelijkheid tot annuleren en voorkom dat verouderde resultaten nieuwere status overschrijven.
Toon acceptatie of voortgang vóór niet-zichtbare opvolgacties.
Yield voordat gemeten werk lang wordt, in plaats van eenmaal per item.
De huidige web.dev-richtlijn raadt geen nieuwe strategie gebaseerd op `isInputPending()` aan.
Verplaats berekening, niet de interface, naar een worker
Een Web Worker voert een script uit op een achtergrondthread, apart van de main thread waarop de pagina wordt uitgevoerd. Hij is geschikt voor kostbaar parsen, datatransformatie, zoekindexering en andere berekeningen die geen directe toegang tot de gebruikersinterface nodig hebben. Stuur een duidelijk afgebakende invoer, ontvang een duidelijk afgebakend resultaat en houd rendering en zichtbare statuswijzigingen op de main thread.
Workers zijn niet universeel. Ze kunnen de DOM niet rechtstreeks manipuleren of Window gebruiken, en bij de gewone berichtuitwisseling worden gegevens gekopieerd. Het opstarten van een worker, gegevensoverdracht en foutcoördinatie kunnen zwaarder wegen dan een kleine berekening. Meet de volledige interactie, beëindig overbodige workers en ontwerp een fallback als werk in een worker mislukt.
Begin met een berekening waarvan input en output serialiseerbaar en testbaar zijn.
Verwerp resultaten die voor een oudere filter, route of actie zijn gemaakt.
Communiceer zinvolle voortgang via de normale interface.
Beheer JavaScript van derden als productieafhankelijkheid
Analytics, advertising, experimenten, social embeds, videospelers en support-widgets kunnen requests, JavaScript-evaluatie, iframes en afhankelijkheden toevoegen. Een vendor-script kan noodzakelijk zijn, maar valt buiten de directe controle van het applicatieteam en kan prestatie, privacy, beveiliging en continuïteit beïnvloeden. Breng doel, routes, laadconditie, goedkeurder, consentvereiste en verwijder-eigenaar in kaart.
Waar voorwaarden en contracten het toelaten, vergelijk een representatieve pagina met en zonder één third-party origin. Prestatietools kunnen kostbare evaluatie, payloads en long-task-attributie blootleggen. Houd een lichte of vertraagde integratie alleen wanneer de gedocumenteerde waarde de gemeten kosten rechtvaardigt. Bevestig kerncontent en de primaire transactie wanneer een optionele afhankelijkheid traag of afwezig is.
Laad een tag alleen op routes en onder condities die het nodig hebben.
Neem tag-manager-wijzigingen op in performance-, privacy-, security- en rollback-review.
Documenteer en test hoe een niet-kritische integratie uit te schakelen is.
Maak responsiviteit tot een waarborg voor releases
Maak van de winnende trace een kleine regressiecheck voor het belangrijke traject. Definieer gedekte interacties, apparaat- of CPU-beperking, verwachte respons en reviewer. Koppel dit aan bundle- en third-party-inventarisreview zodat een nieuw package of tag niet stilletjes main-thread-werk kan herintroduceren.
Status Is UP gebruikt dit bewijs voor proactieve optimalisatie en veilige remediatie, niet ter vervanging van live beschikbaarheidsmonitoring. Bereid vóór een risicovolle wijziging rollback voor en verifieer het kritieke pad na release. Resultaten variëren per apparaat, netwerk, browser, content en accountstatus; beschouw drempels als regels, niet als garanties.
Eis before-and-after traces voor gedeelde navigatie, checkout, zoekopdrachten of grote bundles.
Ken de feature-flag, tag-instelling of deployment-versie die bekend-goed gedrag herstelt.
Profiel opnieuw na grote releases, vendor-wijzigingen of verschuivingen in device-mix.