Gepubliceerd: 4 april 2025
Het oplossen van prestatieproblemen in de echte wereld betekent het overbruggen van de kloof tussen uw ontwikkelomgeving en de diverse prestatie-ervaringen van uw gebruikers. In dit bericht bekijken we nieuwe functies in Chrome DevTools waarmee u uw beslissingen over prestatiefoutopsporing meer kunt baseren op echte gegevens in plaats van op giswerk.
Het kalibreren van verwachtingen
Vanaf Chrome 134 bevat DevTools CPU-throttling-kalibratie , een nieuwe tool om de onzekerheid bij het kiezen van het juiste CPU-throttling-niveau weg te nemen. Voer de kalibratie één keer uit en DevTools genereert voorinstellingen voor de beperking van 'low-tier mobile' en 'mid-tier mobile', specifiek voor uw ontwikkelmachine.
Een veelvoorkomend verschil in webprestaties is dat we als ontwikkelaars vaak sites bouwen op snelle desktopapparaten, terwijl veel van onze gebruikers zich op bescheidener mobiele apparaten bevinden. Het opsporen van een prestatieprobleem kan lastig zijn als het alleen gebeurt op een apparaat met een veel langzamere CPU.
De gouden standaard is foutopsporing op afstand op een echt mobiel apparaat , maar Chrome ondersteunt al bijna tien jaar ook CPU-throttling voor snelle en lichtgewicht iteratiecycli tijdens de ontwikkeling.
Maar welk CPU-throttling-niveau moet u kiezen? 4x? 20x ? Hoe weet u welke het beste overeenkomt met het type apparaat dat u kent en uw site bezoekt? En hoe verandert de snelheid van uw eigen machine die beslissing, of u nu op een high-end werkstation zit of onderweg een 8 jaar oude Chromebook gebruikt?
Het throttling-kalibratieproces
Wanneer het paneel Prestaties wordt geopend, hebben de Omgevingsinstellingen een vervolgkeuzelijst waarin u het CPU-beperkingsniveau kunt instellen. Als u de kalibratie nog niet eerder hebt uitgevoerd, ziet u twee uitgeschakelde opties onder 'Gekalibreerde voorinstellingen' in de vervolgkeuzelijst en een optie Kalibreren... helemaal onderaan.
Als u dit selecteert, gaat u naar de voorinstellingen voor CPU-beperking in Instellingen (u kunt daar ook rechtstreeks naartoe gaan).
- Klik op de knop Kalibreren
- Klik op Doorgaan wanneer u wordt gewaarschuwd dat de huidige pagina even wordt verlaten
- Er wordt een snelle benchmark uitgevoerd om de snelheid van uw huidige machine te meten en de kalibratie is voltooid
De beperkingsopties worden nu gevuld met de gekalibreerde voorinstellingen voor apparaten uit het lagere en middelste niveau.
Deze twee voorinstellingen zouden voldoende moeten zijn voor de meeste ontwikkelingsgebruiksscenario's, en over het algemeen raden we de 'middenklasse'-voorinstelling aan, omdat deze overeenkomt met een 'typisch' mobiel apparaat dat op internet te zien is. Als u weet dat veel van uw gebruikers nog langzamere apparaten hebben of dat een prestatieprobleem zich doorgaans alleen bij deze gebruikers voordoet, zou de 'low-tier'-optie langzaam genoeg moeten zijn om zelfs de lange staart van low-end apparaten te kunnen opvangen.
Als u ten slotte denkt dat er iets mis is gegaan met de kalibratie of dat uw lokale machine op de een of andere manier is veranderd, kunt u altijd opnieuw kalibreren via de vervolgkeuzelijst of via de instellingen, waardoor de benchmark opnieuw wordt uitgevoerd en de presets worden bijgewerkt.
Hoe CPU-throttling werkt in DevTools
Als je ooit nieuwsgierig bent geweest naar hoe CPU-beperking werkt in DevTools, is het idee relatief eenvoudig. Wanneer u beperking voor een tabblad inschakelt, start Chrome een afzonderlijke beperkingsthread die de hoofdthread van het tabblad onderbreekt en opschort voor frequente korte uitbarstingen. Het doel is om de rode draad in totaal zo lang op te schorten dat de duur van een bepaalde taak met de smorende factor toeneemt.
Bij 4x CPU-throttling zal de hoofdthread bijvoorbeeld ongeveer 75% van de tijd worden opgeschort, waardoor het voltooien van de hoofdthread vier keer zo lang duurt.
Het voordeel van deze aanpak is dat deze grotendeels transparant is voor de rest van Chrome; er is geen gespecialiseerde code nodig om JavaScript, of de lay-out, of elk van de vele andere soorten werk die een browser moet doen, te vertragen. Al het werk aan de hoofdthread duurt langer omdat de thread zelf slechts een fractie van de tijd mag worden uitgevoerd.
Wanneer CPU-throttling werkt als een echt mobiel apparaat
Als gevolg hiervan worden veel soorten mobiel CPU-gebonden werk goed gesimuleerd door CPU-throttling. Als een interactie bijvoorbeeld javascript en lay-out activeert, is de kans groot dat deze op dezelfde manier wordt uitgevoerd als op een mobiel apparaat.
Overweeg een taak die wordt geactiveerd door een klik op een knop, waarbij Javascript wordt uitgevoerd om nieuwe elementen aan de DOM toe te voegen, waarvoor de browser vervolgens stijl- en lay-outberekeningen moet uitvoeren om de nieuwe inhoud te positioneren:
Met de gekalibreerde "mid-tier mobile" CPU-throttling-voorinstelling (3,7x op deze ontwikkelmachine) lijkt de interactie erg op elkaar, maar de duur neemt aanzienlijk toe, waardoor het een lange taak wordt:
Het testen van dezelfde interactie op een echt middenapparaat met behulp van foutopsporing op afstand levert een opmerkelijk vergelijkbaar resultaat op, zowel wat betreft de vorm als de duur van het spoor van de interactie. Omdat deze taak grotendeels CPU-gebonden is in de hoofdthread (het uitvoeren van de JavaScript-code van de pagina en de stijl- en lay-outcode van Chrome), bootst de gekalibreerde beperking nauwkeurig de echte mobiele prestaties na:
Wanneer je misschien toch wilt testen op een echt mobiel apparaat
Hoewel zeer nuttig, kan CPU-throttling niet alle aspecten van mobiele hardware simuleren. Op een telefoon is de schijfsnelheid lager, is de geheugenbandbreedte beperkter en kan thermische beperking op elk moment in werking treden om de uitvoeringssnelheid te verlagen.
Een veel voorkomende beperking van de beperking is GPU-intensief werk. Mobiele en desktop-GPU's verschillen architectonisch, en Chrome voert GPU-bewerkingen uit in een afzonderlijk proces dat losstaat van de hoofdthread van de pagina. Als gevolg hiervan heeft de CPU-beperking van DevTools geen invloed op het GPU-proces (wat het beste is, omdat dit de reactiesnelheid van DevTools zelf en de rest van de browser zou beïnvloeden).
Gecompliceerd schilderen, composities maken en styling met veel effecten zijn veelvoorkomende prestatieproblemen die prima lijken op een ontwikkelmachine, maar onverwacht traag op mobiel. En het kan lastig zijn om te beseffen dat er überhaupt een probleem is wanneer u probeert het probleem opnieuw te creëren op uw ontwikkelmachine.
Overweeg dezelfde interactie als voorheen (klik en voeg veel elementen toe aan de DOM), alleen deze keer zijn de nieuwe elementen opgemaakt met een buitensporig aantal GPU-zware box-shadows en vervagingsfilters .
De beginvorm en duur van de interactie lijken op elkaar, maar aan het einde is er een lange nieuwe rode draad voor de extra effecten:
Op een echte middentelefoon lijkt het hoofdgedeelte van de interactie erg op het gesimuleerde, inclusief de extra verf, maar dan lijkt een wild GPU-proces enorm veel werk te verzetten voordat het resultaat van de interactie op het scherm kan verschijnen:
Het GPU-werk verlengt de interactie met nog eens 300 milliseconden, en is werk dat nauwelijks bestaat voor de GPU van de laptop, zelfs als (main-thread) CPU-throttling ingeschakeld is.
Er zijn nog een paar andere gevallen die ook aanzienlijke nadelen hebben aan de emulatie, zoals het laden van pagina's met grote afhankelijkheid, waarbij er een wisselwerking is tussen gesimuleerde netwerkbeperking, communicatie tussen processen en toegang tot schijf- en geheugencaches.
Zorg er altijd voor dat u op een gegeven moment op echte mobiele apparaten test. En als u in het laboratorium op uw desktopcomputer een probleem niet kunt nabootsen waarvan uit uw veldgegevens blijkt dat dit van invloed is op mobiele gebruikers, probeer dan zeker foutopsporing op afstand met een echt apparaat om te zien of u een verschil mist.
Meer datagestuurde foutopsporingsverbeteringen
Er zijn onlangs enkele andere nieuwe functies geïntroduceerd om het gemakkelijker te maken om foutopsporingsinstellingen en beslissingen op uw echte gebruikers te baseren.
Als u veldgegevens heeft ingeschakeld , geeft het prestatiepaneel suggesties over beperking op basis van uw 75e percentielgebruikers zoals gemeten door het Chrome User Experience Report (CrUX) . De realtime metrische weergave waarschuwt u als uw lokaal gemeten statistieken afwijken van de veldgegevens. Dit werd gedetailleerd besproken in een eerder bericht over het inbrengen van echte Core Web Vitals-gegevens in DevTools .
Een nieuwe toevoeging is dat de inzichten van het prestatiepaneel in de zijbalk u nu ook waarschuwen als de statistieken die in een trace worden gemeten niet overeenkomen met wat uw gebruikers in de echte wereld ervaren.
Als veldgegevens zijn ingeschakeld, wordt ook gebruik gemaakt van uw 75e percentiel Core Web Vitals om te helpen bij het rangschikken van de volgorde waarin inzichten in de zijbalk worden weergegeven. Als uw gebruikers bijvoorbeeld doorgaans geweldige Largest Contentful Paint (LCP) hebben, maar een slechte Interaction to Next Paint (INP) , zullen inzichten die helpen bij het verbeteren van INP meestal bovenaan de lijst terechtkomen.
En ten slotte: als u ooit tussen meerdere traces heen en weer hebt gebladerd, of traces van schijf hebt geladen, kan het moeilijk zijn om precies te onthouden welke mobiele emulatie- en throttling-instellingen u in elke trace hebt gebruikt. De vervolgkeuzelijst tracering boven aan het prestatiepaneel toont nu emulatie-informatie voor elke trace.
Stop, kalibreer en luister
Uiteindelijk moeten we onze debugging-beslissingen baseren op de echte wereld: beginnend met veldgegevens uit analyses en gebruikersrapporten om problemen te vinden, en vervolgens die gebruikerservaringen in het laboratorium opnieuw creëren voor diagnose. Deze nieuwe DevTools-toevoegingen zouden dat proces een beetje eenvoudiger moeten maken.
Kalibratie van CPU-throttling en waarschuwingen over uiteenlopende veld- en laboratoriumervaringen helpen de onzekerheid te verminderen of u wel of niet op de goede weg bent, en maken een consistentere benadering van de prestaties in de echte wereld mogelijk. Door giswerk uit de configuratie te halen en potentiële discrepanties te benadrukken, wil DevTools u helpen meer tijd te besteden aan het oplossen van de daadwerkelijke prestatieproblemen waarmee uw gebruikers te maken hebben.
Heeft u ideeën voor meer verbeteringen of suggesties voor nieuwe functies? Laat het ons weten!