Wie und warum wir Performance Insights erstellt haben

Jack Franklin

In Chrome 102 sehen Sie in den Entwicklertools den neuen experimentellen Bereich Leistungsstatistiken. In diesem Beitrag erläutern wir nicht nur, warum wir an einem neuen Panel gearbeitet haben, sondern auch, welche technischen Herausforderungen wir dabei gemeistert haben und welche Entscheidungen wir getroffen haben.

ALT_TEXT_HERE

Warum ein weiteres Steuerfeld erstellen?

Falls Sie es noch nicht gesehen haben: Wir haben ein Video veröffentlicht, in dem wir erklären, warum wir den Bereich „Leistungsstatistiken“ entwickelt haben und wie Sie damit umsetzbare Informationen zur Leistung Ihrer Website erhalten.

Das vorhandene Leistungspanel ist eine gute Ressource, wenn Sie alle Daten für Ihre Website an einem Ort sehen möchten. Wir haben jedoch festgestellt, dass es etwas überwältigend sein kann. Wenn du kein Experte für die Leistung bist, ist es schwierig zu wissen, worauf du genau achten musst und welche Teile der Aufnahme relevant sind.

Im Bereich „Statistiken“ können Sie sich weiterhin eine Zeitachse Ihres Tracings ansehen und die Daten prüfen. Außerdem erhalten Sie eine praktische Liste der wichtigsten „Statistiken“, die sich in den DevTools ansehen sollten. So lassen sich unter anderem Probleme wie renderblockierende Anfragen, Layoutänderungen und lange Aufgaben erkennen, die sich negativ auf die Seitenladeleistung Ihrer Website und insbesondere auf die Core Web Vitals (CWV)-Werte Ihrer Website auswirken können. Neben der Kennzeichnung von Problemen erhalten Sie in den Leistungsdaten umsetzbare Vorschläge zur Verbesserung Ihrer CWV-Werte sowie Links zu weiteren Ressourcen und Dokumentationen.

Feedbacklink im Steuerfeld

Dieser Bereich ist experimentell und wir würden gerne dein Feedback dazu erhalten. Bitte teilen Sie uns mit, wenn Sie Fehler feststellen oder Funktionen anfordern möchten, die Ihnen bei der Optimierung der Leistung Ihrer Website helfen könnten.

So haben wir Leistungsstatistiken entwickelt

Wie der Rest von DevTools wurde Performance Insights in TypeScript erstellt. Für die Benutzeroberfläche wurden Webkomponenten mit lit-html verwendet. Der Unterschied zu Performance Insights besteht darin, dass die primäre Benutzeroberfläche ein HTML-canvas-Element ist und die Zeitachse auf diesem Canvas gezeichnet wird. Die größte Komplexität entsteht durch die Verwaltung dieses Canvas: Es geht nicht nur darum, die richtigen Details an der richtigen Stelle zu zeichnen, sondern auch um die Verwaltung von Mausereignissen (z. B.: Wo hat der Nutzer auf dem Canvas geklickt? Haben sie auf ein von uns gezeichnetes Ereignis geklickt?) und sichergestellt, dass wir den Canvas effektiv neu rendern.

Mehrere Tracks auf einem einzigen Canvas

Für eine bestimmte Website gibt es mehrere „Tracks“, die wir rendern möchten. Jeder Track steht für eine andere Datenkategorie. Im Bereich „Statistiken“ werden beispielsweise standardmäßig drei Tracks angezeigt:

Wir werden das Panel kontinuierlich um weitere Funktionen ergänzen und voraussichtlich auch weitere Tracks hinzufügen.

Ursprünglich sollte für jeden dieser Tracks ein eigenes <canvas> gerendert werden, sodass die Hauptansicht aus mehreren vertikal gestapelten Canvas-Elementen besteht. Das würde das Rendern auf Spurebene vereinfachen, da jeder Track separat gerendert werden könnte und es keine Gefahr gäbe, dass ein Track außerhalb seiner Grenzen gerendert wird. Leider hat dieser Ansatz zwei Hauptprobleme:

Das (Wieder-)Rendern von canvas-Elementen ist sehr aufwendig. Mehrere Canvasse sind aufwendiger als ein einzelner Canvas, auch wenn dieser größer ist. Das Rendern von Overlays, die über mehrere Tracks verlaufen (z. B. vertikale Linien zum Markieren von Ereignissen wie die FCP-Zeit), wird komplex: Wir müssen auf mehreren Canvases rendern und sicherstellen, dass sie alle zusammen gerendert und korrekt ausgerichtet werden.

Da wir nur eine canvas für die gesamte Benutzeroberfläche verwenden, mussten wir herausfinden, wie wir dafür sorgen können, dass jeder Track an den richtigen Koordinaten gerendert wird und nicht in einen anderen Track überläuft. Wenn ein bestimmter Track beispielsweise 100 Pixel hoch ist, können wir nicht zulassen, dass etwas mit einer Höhe von 120 Pixeln gerendert wird und in den darunter liegenden Track überläuft. Zur Behebung dieses Problems können wir clip verwenden. Bevor wir jeden Titel rendern, zeichnen wir ein Rechteck, das das sichtbare Titelfenster darstellt. Dadurch wird sichergestellt, dass alle Pfade, die außerhalb dieser Grenzen gezeichnet werden, vom Canvas abgeschnitten werden.

canvasContext.beginPath();
canvasContext.rect(
    trackVisibleWindow.x, trackVisibleWindow.y, trackVisibleWindow.width, trackVisibleWindow.height);
canvasContext.clip();

Außerdem sollte jeder Track seine vertikale Position nicht kennen müssen: Jeder Track sollte sich so rendern, als würde er bei (0, 0) gerendert. Wir haben eine Komponente auf höherer Ebene (die wir TrackManager nennen), um die Gesamtposition des Tracks zu verwalten. Dazu wird translate verwendet, bei dem der Canvas um eine gegebene Position (x, y) übersetzt wird. Beispiel:

canvasContext.translate(0, 10); // Translate by 10px in the y direction
canvasContext.rect(0, 0, 10, 10); // draw a rectangle at (0, 0) that’s 10px high and wide

Obwohl im rect-Code 0, 0 als Position festgelegt ist, wird das Rechteck durch die angewendete Gesamttranslation an 0, 10 gerendert. So können wir auf Spurebene arbeiten, als würden wir bei (0, 0) rendern, und unseren Spurmanager so übersetzen lassen, dass jeder Track korrekt unter dem vorherigen gerendert wird.

Off-Screen-Canvasse für Titel und Highlights

Das Canvas-Rendering ist relativ teuer. Wir möchten, dass der Bereich „Statistiken“ reibungslos und responsiv bleibt, während Sie damit arbeiten. Manchmal ist es unvermeidlich, den gesamten Canvas noch einmal zu rendern. Wenn Sie beispielsweise die Zoomstufe ändern, müssen wir von vorn beginnen und alles noch einmal rendern. Das erneute Rendern des Canvas ist besonders aufwendig, da Sie nicht nur einen kleinen Teil davon neu rendern können, sondern den gesamten Canvas löschen und neu zeichnen müssen. Das ist anders als beim DOM-Neu-Rendering, bei dem Tools die minimal erforderlichen Änderungen berechnen können, anstatt alles zu entfernen und noch einmal von vorn anzufangen.

Ein Bereich, in dem wir visuelle Probleme festgestellt haben, war das Hervorheben. Wenn Sie den Mauszeiger auf Messwerte im Bereich bewegen, werden sie auf der Zeitachse hervorgehoben. Wenn Sie den Mauszeiger auf eine Statistik für ein bestimmtes Ereignis bewegen, wird dieses Ereignis blau umrandet.

Diese Funktion wurde zuerst implementiert, indem die Mausbewegung über ein Element erkannt und dann direkt auf dem Haupt-Canvas ein Highlight gezeichnet wurde. Das Problem tritt auf, wenn wir die Markierung entfernen müssen: Die einzige Option ist, alles neu zu zeichnen. Es ist nicht möglich, den Bereich, in dem sich der Akzent befand, einfach neu zu zeichnen (nicht ohne große architektonische Änderungen). Aber den gesamten Canvas neu zu zeichnen, nur weil wir einen blauen Rahmen um ein Element entfernen möchten, erschien uns übertrieben. Außerdem kam es zu Verzögerungen, wenn Sie die Maus schnell über verschiedene Elemente bewegen, um nacheinander mehrere Markierungen einzublenden.

Um das zu beheben, haben wir unsere Benutzeroberfläche in zwei off-screen-Canvasse unterteilt: den „Haupt-Canvas“, auf dem die Titel gerendert werden, und den „Highlights-Canvas“, auf dem die Highlights gezeichnet werden. Anschließend kopieren wir diese Canvases in das Canvas, das für den Nutzer auf dem Bildschirm sichtbar ist. Wir können die Methode drawImage auf einen Canvas-Kontext anwenden, der einen anderen Canvas als Quelle haben kann.

Wenn Sie das tun, wird das Haupt-Canvas nicht neu gezeichnet, wenn Sie ein Highlight entfernen. Stattdessen können Sie das Canvas auf dem Bildschirm löschen und dann das Haupt-Canvas in das sichtbare Canvas kopieren. Das Kopieren eines Canvas ist kostengünstig, das Zeichnen ist dagegen teuer. Wenn wir Highlights auf ein separates Canvas verschieben, vermeiden wir diese Kosten, wenn wir Highlights ein- und ausschalten.

Umfassend getestetes Trace-Parsing

Einer der Vorteile der kompletten Neuentwicklung einer Funktion besteht darin, dass Sie die zuvor getroffenen technischen Entscheidungen reflektieren und Verbesserungen vornehmen können. Unter anderem wollten wir unseren Code explizit in zwei fast vollständig getrennte Teile aufteilen:

Parsen Sie die Tracedatei und ziehen Sie die erforderlichen Daten heraus. Tracks rendern

Durch die Trennung des Parsings (Teil 1) von der UI-Arbeit (Teil 2) konnten wir ein solides Parsing-System entwickeln. Jeder Trace wird durch eine Reihe von Handlern geführt, die für unterschiedliche Aufgaben verantwortlich sind: Ein LayoutShiftHandler berechnet alle Informationen, die wir für Layoutänderungen benötigen, und ein NetworkRequestsHandler kümmert sich ausschließlich um das Abrufen von Netzwerkanfragen. Der explizite Parseschritt, bei dem verschiedene Handler für verschiedene Teile des Logs verantwortlich sind, war ebenfalls von Vorteil: Das Parsen von Protokollen kann sehr kompliziert werden und es ist hilfreich, sich jeweils auf ein Problem konzentrieren zu können.

Außerdem konnten wir unsere Trace-Analyse umfassend testen, indem wir Aufzeichnungen in DevTools erstellt, gespeichert und dann als Teil unserer Testsuite geladen haben. Das ist großartig, weil wir mit echten Traces testen können und nicht riesige Mengen an gefälschten Trace-Daten ansammeln müssen, die möglicherweise veraltet sind.

Screenshot-Tests für Canvas-UI

Bleiben wir beim Thema Tests: Normalerweise testen wir unsere Frontend-Komponenten, indem wir sie im Browser rendern und dafür sorgen, dass sie sich wie erwartet verhalten. Wir können Klickereignisse senden, um Aktualisierungen auszulösen, und prüfen, ob das von den Komponenten generierte DOM korrekt ist. Dieser Ansatz funktioniert für uns gut, aber nicht beim Rendern in ein Canvas. Es gibt keine Möglichkeit, ein Canvas zu prüfen und festzustellen, was dort gezeichnet wird. Daher ist unser üblicher Ansatz, zuerst zu rendern und dann abzufragen, nicht geeignet.

Für eine gewisse Testabdeckung haben wir Screenshot-Tests durchgeführt. Bei jedem Test wird ein Canvas gestartet, der zu testende Track gerendert und dann ein Screenshot des Canvas-Elements aufgenommen. Dieser Screenshot wird dann in unserer Codebasis gespeichert. Bei zukünftigen Tests wird der gespeicherte Screenshot mit dem generierten Screenshot verglichen. Wenn die Screenshots unterschiedlich sind, schlägt der Test fehl. Wir stellen auch ein Flag bereit, mit dem der Test ausgeführt und ein Screenshot-Update erzwungen werden kann, wenn wir das Rendering absichtlich geändert haben und der Test aktualisiert werden muss.

Screenshot-Tests sind nicht perfekt und etwas ungenau. Sie können nur testen, ob die gesamte Komponente wie erwartet gerendert wird, und nicht spezifischere Behauptungen. Anfangs haben wir sie zu oft verwendet, um sicherzustellen, dass jede einzelne Komponente (HTML oder Canvas) korrekt gerendert wird. Das hat unsere Testsuite drastisch verlangsamt und zu Problemen geführt, bei denen kleine, fast irrelevante Änderungen an der Benutzeroberfläche (z. B. subtile Farbänderungen oder das Hinzufügen von Rändern zwischen Elementen) dazu geführt haben, dass mehrere Screenshots fehlgeschlagen sind und aktualisiert werden mussten. Wir haben die Verwendung von Screenshots jetzt reduziert und verwenden sie nur noch für Canvas-basierte Komponenten. Dieses Gleichgewicht hat sich bisher bewährt.

Fazit

Die Entwicklung des neuen Bereichs „Leistungsstatistiken“ war für das Team eine sehr angenehme und lehrreiche Erfahrung. Wir haben viel über Trace-Dateien, die Arbeit mit Canvas und vieles mehr gelernt. Wir wünschen dir viel Spaß mit dem neuen Bereich und sind gespannt auf dein Feedback.

Weitere Informationen zum Bereich „Leistungsstatistiken“ finden Sie unter Leistungsstatistiken: Umsetzbare Informationen zur Leistung Ihrer Website.

Vorschaukanäle herunterladen

Sie können Canary, Dev oder Beta als Standardbrowser für die Entwicklung verwenden. Diese Vorabversionen bieten Zugriff auf die neuesten DevTools-Funktionen, ermöglichen den Test moderner Webplattform-APIs und helfen Ihnen, Probleme auf Ihrer Website zu finden, bevor Ihre Nutzer sie bemerken.

Chrome-Entwicklertools-Team kontaktieren

Verwende die folgenden Optionen, um die neuen Funktionen, Updates oder andere Aspekte der Entwicklertools zu besprechen.