Veröffentlicht: 4. April 2025
Wenn Sie Leistungsprobleme in der Praxis beheben möchten, müssen Sie die Lücke zwischen Ihrer Entwicklungsumgebung und den unterschiedlichen Leistungserfahrungen Ihrer Nutzer schließen. In diesem Beitrag sehen wir uns neue Funktionen in Chrome DevTools an, mit denen Sie Ihre Entscheidungen zur Fehlerbehebung bei der Leistung eher auf echte Daten als auf Vermutungen stützen können.
Erwartungen anpassen
Ab Chrome 134 enthält DevTools die Kalibrierung der CPU-Drosselung, ein neues Tool, mit dem die Unsicherheit bei der Auswahl des richtigen CPU-Drosselungsniveaus beseitigt wird. Führen Sie die Kalibrierung einmal aus. In DevTools werden dann Drosselungsvoreinstellungen für „Low-Tier-Mobilgeräte“ und „Mid-Tier-Mobilgeräte“ für Ihren Entwicklungscomputer generiert.
Ein häufiges Problem bei der Optimierung der Webleistung besteht darin, dass wir als Entwickler Websites oft auf schnellen Desktop-Geräten erstellen, während viele unserer Nutzer weniger leistungsstarke Mobilgeräte verwenden. Es kann schwierig sein, ein Leistungsproblem zu finden, wenn es nur auf einem Gerät mit einer viel langsameren CPU auftritt.
Der Goldstandard ist das Remote-Debugging auf einem echten Mobilgerät. Seit fast einem Jahrzehnt unterstützt Chrome jedoch auch die CPU-Drosselung für schnelle und einfache Iterationszyklen während der Entwicklung.
Aber welche CPU-Drosselungsstufe sollten Sie wählen? 4-fach? 20-fach? Woher wissen Sie, welche der Typen am besten zu den Geräten passt, von denen Sie wissen, dass sie Ihre Website besuchen? Und wie wirkt sich die Geschwindigkeit Ihres eigenen Geräts auf diese Entscheidung aus, unabhängig davon, ob Sie eine High-End-Workstation oder ein acht Jahre altes Chromebook unterwegs verwenden?
Kalibrierung der Drosselung
Wenn das Steuerfeld „Leistung“ geöffnet ist, gibt es in den Umgebungseinstellungen ein Drop-down-Menü, mit dem Sie die CPU-Drosselung festlegen können. Wenn Sie die Kalibrierung noch nicht durchgeführt haben, werden im Drop-down-Menü unter „Kalibrierte Voreinstellungen“ zwei deaktivierte Optionen und ganz unten die Option Kalibrieren… angezeigt.
Dadurch gelangen Sie zu den Voreinstellungen für die CPU-Drosselung in den Einstellungen. Sie können auch direkt dorthin gehen.
- Klicken Sie auf die Schaltfläche Kalibrieren.
- Klicken Sie auf Weiter, wenn Sie darauf hingewiesen werden, dass Sie die aktuelle Seite kurz verlassen.
- Es wird ein kurzer Benchmark ausgeführt, um die Geschwindigkeit Ihres aktuellen Computers zu messen. Die Kalibrierung ist abgeschlossen.
Die Drosselungsoptionen werden jetzt mit den kalibrierten Voreinstellungen für Low-Tier- und Mid-Tier-Geräte ausgefüllt.
Diese beiden Voreinstellungen sollten für die meisten Entwicklungsanwendungsfälle ausreichen. Wir empfehlen in der Regel die Voreinstellung „Mid-Tier“, da sie einem „typischen“ Mobilgerät entspricht, das im Web verwendet wird. Wenn Sie wissen, dass viele Ihrer Nutzer noch langsamere Geräte haben oder ein Leistungsproblem in der Regel nur bei diesen Nutzern auftritt, sollte die Option „Low-Tier“ langsam genug sein, um auch die Long Tail-Nutzung von Low-End-Geräten abzudecken.
Wenn Sie der Meinung sind, dass bei der Kalibrierung etwas schiefgelaufen ist oder sich Ihr lokaler Computer in irgendeiner Weise geändert hat, können Sie jederzeit über das Drop-down-Menü für die Drosselung oder in den Einstellungen eine Neukalibrierung vornehmen. Dadurch wird der Benchmark noch einmal ausgeführt und die Voreinstellungen aktualisiert.
Funktionsweise der CPU-Drosselung in DevTools
Wenn Sie sich schon einmal gefragt haben, wie die CPU-Drosselung in DevTools funktioniert, ist das Prinzip relativ einfach. Wenn Sie die Drosselung für einen Tab aktivieren, startet Chrome einen separaten Drosselungs-Thread, der den Haupt-Thread des Tabs unterbricht und für häufige kurze Bursts anhält. Ziel ist es, den Hauptthread insgesamt so lange zu pausieren, dass die Dauer einer bestimmten Aufgabe um den Drosselungsfaktor steigt.
Bei einer 4-fachen CPU-Drosselung wird der Hauptthread beispielsweise etwa 75% der Zeit angehalten, was die Ausführung von Aufgaben im Hauptthread um das Vierfache verlängert.
Der Vorteil dieses Ansatzes besteht darin, dass er für den Rest von Chrome weitgehend transparent ist. Es ist kein spezieller Code erforderlich, um JavaScript, das Layout oder eine der vielen anderen Arten von Arbeit zu verlangsamen, die ein Browser ausführen muss. Alle Arbeiten am Haupt-Thread dauern länger, da der Thread selbst nur für einen Bruchteil der Zeit ausgeführt werden darf.
Wenn die CPU-Drosselung wie ein echtes Mobilgerät funktioniert
Daher werden viele Arten von CPU-gebundenen Arbeiten auf Mobilgeräten durch CPU-Drosselung gut simuliert. Wenn eine Interaktion beispielsweise JavaScript und das Layout auslöst, wird sie mit hoher Wahrscheinlichkeit sehr ähnlich ausgeführt wie auf einem Mobilgerät.
Angenommen, eine Aufgabe wird durch das Klicken auf eine Schaltfläche ausgelöst und es wird JavaScript ausgeführt, um dem DOM neue Elemente hinzuzufügen. Der Browser muss dann Stil- und Layoutberechnungen ausführen, um die neuen Inhalte zu positionieren:
Mit der kalibrierten Voreinstellung für die CPU-Drosselung „Mid-Tier Mobile“ (3,7-fach auf diesem Entwicklungscomputer) sieht die Interaktion sehr ähnlich aus, die Dauer erhöht sich jedoch deutlich und die Aufgabe wird langwierig:
Wenn dieselbe Interaktion auf einem echten Mid-Tier-Gerät mit Remote-Debugging getestet wird, ergibt sich ein bemerkenswert ähnliches Ergebnis, sowohl in Bezug auf die Form als auch auf die Dauer des Protokolls der Interaktion. Da diese Aufgabe im Hauptthread hauptsächlich CPU-gebunden ist (Ausführung des JavaScript-Codes der Seite und des Stil- und Layoutcodes von Chrome), wird mit der kalibrierten Drosselung die tatsächliche Leistung auf Mobilgeräten genau nachgebildet:
Wann Sie trotzdem auf einem echten Mobilgerät testen sollten
Die CPU-Drosselung ist zwar sehr nützlich, kann aber nicht alle Aspekte der mobilen Hardware simulieren. Auf einem Smartphone ist die Festplattengeschwindigkeit langsamer, die Speicherbandbreite ist begrenzter und die thermische Drosselung kann jederzeit aktiviert werden, um die Ausführungsgeschwindigkeit zu verringern.
Eine häufige Drosselungsbeschränkung betrifft GPU-intensive Aufgaben. GPUs für Mobilgeräte und Computer unterscheiden sich architektonisch. Chrome führt GPU-Vorgänge in einem separaten Prozess aus, der vom Hauptthread der Seite getrennt ist. Daher wirkt sich die CPU-Drosselung in den DevTools nicht auf den GPU-Prozess aus. Das ist von Vorteil, da sich dies auf die Reaktionsfähigkeit der DevTools selbst und des restlichen Browsers auswirken würde.
Kompliziertes Malen, Compositing und effektreiches Styling sind häufige Leistungsprobleme, die auf einem Entwicklungscomputer in Ordnung erscheinen, auf Mobilgeräten aber unerwartet langsam sind. Außerdem kann es schwierig sein, festzustellen, ob überhaupt ein Problem vorliegt, wenn Sie versuchen, es auf Ihrem Entwicklungscomputer zu reproduzieren.
Stellen Sie sich dieselbe Interaktion wie zuvor vor (klicken und dem DOM viele Elemente hinzufügen), nur dass die neuen Elemente dieses Mal mit einer übermäßigen Anzahl von GPU-intensiven Schatten und Unkenntlichmachungsfiltern gestaltet sind.
Die Anfangsform und die Dauer der Interaktion sehen ähnlich aus, aber am Ende gibt es eine lange neue Malaktion im Haupt-Thread für die zusätzlichen Effekte:
Auf einem echten Mittelklasse-Smartphone sieht der Hauptthread-Teil der Interaktion sehr ähnlich aus wie der simulierte, einschließlich der zusätzlichen Paint-Operationen. Dann scheint ein wilder GPU-Prozess eine enorme Menge an Arbeit zu leisten, bevor das Ergebnis der Interaktion auf dem Bildschirm angezeigt werden kann:
Die GPU-Arbeit verlängert die Interaktion um weitere 300 Millisekunden. Diese Arbeit ist für die Laptop-GPU kaum vorhanden, selbst wenn die CPU-Drosselung (Hauptthread) aktiviert ist.
Es gibt noch einige andere Fälle, in denen die Emulation erhebliche Nachteile hat, z. B. das Laden von Seiten mit vielen Abhängigkeiten, bei dem es eine Wechselwirkung zwischen simulierter Netzwerkdrosselung, interprozessorischer Kommunikation und dem Zugriff auf Laufwerk- und Speichercaches gibt.
Sie sollten Ihre App aber auch auf echten Mobilgeräten testen. Wenn Sie ein Problem, das sich laut Ihren Felddaten auf Mobilgeräte auswirkt, im Lab auf Ihrem Computer nicht reproduzieren können, sollten Sie unbedingt das Remote-Debugging mit einem echten Gerät ausprobieren, um festzustellen, ob es einen Unterschied gibt, den Sie übersehen haben.
Weitere datengetriebene Verbesserungen bei der Fehlerbehebung
Vor Kurzem wurden auch einige weitere neue Funktionen eingeführt, mit denen sich Einstellungen und Entscheidungen für die Fehlerbehebung einfacher auf Ihre echten Nutzer stützen lassen.
Wenn Sie Felddaten aktiviert haben, erhalten Sie im Bereich Leistung Vorschläge zur Drosselung basierend auf den Nutzern im 75. Perzentil, gemessen im Chrome UX Report (CrUX). In der Echtzeitmessdatenansicht werden Sie benachrichtigt, wenn Ihre lokal gemessenen Messwerte von den Felddaten abweichen. In einem früheren Beitrag haben wir ausführlich beschrieben, wie Sie echte Core Web Vitals-Daten in die DevTools einbinden.
Neu ist, dass Sie in den Statistiken im Bereich „Leistung“ in der Seitenleiste jetzt auch benachrichtigt werden, wenn die in einem Trace gemessenen Messwerte nicht mit den tatsächlichen Erfahrungen Ihrer Nutzer übereinstimmen.
Wenn Felddaten aktiviert sind, können Sie auch die Core Web Vitals des 75. Perzentil verwenden, um die Reihenfolge der Informationen in der Seitenleiste zu bestimmen. Wenn Ihre Nutzer beispielsweise in der Regel einen guten Largest Contentful Paint (LCP), aber einen schlechten Interaction to Next Paint (INP) haben, werden Erkenntnisse zur Verbesserung des INP in der Regel ganz oben auf der Liste angezeigt.
Wenn Sie schon einmal zwischen mehreren Protokollen hin- und hergewechselt oder Protokolle von der Festplatte geladen haben, kann es schwierig sein, sich genau zu erinnern, welche Einstellungen für die mobile Emulation und Drosselung Sie in jedem Protokoll verwendet haben. Im Drop-down-Menü für die Auswahl der Traces oben im Bereich Leistung werden jetzt Emulationshinweise für jeden Trace angezeigt.
Stoppen, kalibrieren und zuhören
Letztendlich müssen wir unsere Entscheidungen zur Fehlerbehebung auf der Realität basieren: Beginnen Sie mit Felddaten aus Analysen und Nutzerberichten, um Probleme zu finden, und erstellen Sie diese Nutzererfahrungen dann zur Diagnose im Lab neu. Diese neuen DevTools-Erweiterungen sollten diesen Prozess ein wenig vereinfachen.
Die Kalibrierung der CPU-Drosselung und Benachrichtigungen bei abweichenden Ergebnissen in der Praxis und im Labor tragen dazu bei, die Unsicherheit zu verringern, ob Sie auf dem richtigen Weg sind, und ermöglichen eine konsistentere Annäherung an die tatsächliche Leistung. Da Sie mit DevTools nicht mehr raten müssen und potenzielle Abweichungen hervorgehoben werden, können Sie sich mehr auf die Behebung der tatsächlichen Leistungsprobleme konzentrieren, die sich auf Ihre Nutzer auswirken.
Hast du Ideen für weitere Verbesserungen oder Vorschläge für neue Funktionen? Geben Sie uns Feedback.