Lighthouse: Websitegeschwindigkeit optimieren

Übersicht

Mit dem Lighthouse-Bereich können Sie ein umfassendes Audit Ihrer Website durchführen. Im Bereich Lighthouse wird ein Bericht generiert, der Ihnen Aufschluss über Folgendes gibt:

• Leistung
• Bedienungshilfen
• Best Practices
• SEO

… und viele andere Messwerte.

Das folgende Tutorial hilft Ihnen beim Einstieg in Lighthouse in den Chrome-Entwicklertools.

Weitere Informationen dazu, wie Lighthouse die Qualität Ihrer Website verbessern kann, finden Sie in unserer Lighthouse-Dokumentation.

Ziel der Anleitung

In diesem Tutorial erfahren Sie, wie Sie mit den Chrome-Entwicklertools Möglichkeiten finden, die Ladezeit Ihrer Websites zu verkürzen.

Lesen Sie weiter oder sehen Sie sich die Videoversion dieser Anleitung an:

Vorbereitung

Sie sollten über grundlegende Kenntnisse in der Webentwicklung verfügen, wie sie in diesem Kurs zur Einführung in die Webentwicklung vermittelt werden.

Sie müssen sich nicht mit der Ladeleistung auskennen.

Einführung

Das ist Tony. Tony ist in der Katzenwelt sehr berühmt. Er hat eine Website erstellt, auf der seine Fans erfahren können, was seine Lieblingsgerichte sind. Seine Fans lieben die Website, aber Tony erhält immer wieder Beschwerden, dass die Website langsam geladen wird. Tony hat Sie gebeten, ihm dabei zu helfen, die Website zu beschleunigen.

Schritt 1: Website prüfen

Wenn Sie die Ladeleistung einer Website verbessern möchten, sollten Sie immer mit einem Audit beginnen. Das Audit hat zwei wichtige Funktionen:

• So wird eine Grundlage geschaffen, anhand derer Sie spätere Änderungen messen können.
• Sie erhalten praktische Tipps dazu, welche Änderungen sich am stärksten auswirken.

Einrichten

Zuerst müssen Sie eine neue Arbeitsumgebung für Tonys Website einrichten, damit Sie später Änderungen daran vornehmen können:

1. Remixe das Projekt der Website auf Glitch. Ihr neues Projekt wird in einem Tab geöffnet. Dieser Tab wird als Editor-Tab bezeichnet.

   

   Der Name des Projekts ändert sich von tony zu einem zufällig generierten Namen. Sie haben jetzt eine eigene bearbeitbare Kopie des Codes. Später nehmen Sie Änderungen an diesem Code vor.

2. Klicken Sie unten auf dem Editor-Tab auf Vorschau > Vorschau in neuem Fenster. Die Demo wird in einem neuen Tab geöffnet. Diese Registerkarte wird als Demotab bezeichnet. Es kann eine Weile dauern, bis die Website geladen ist.

   

3. Öffnen Sie die Entwicklertools neben der Demo.

   

Baseline festlegen

Die Baseline ist ein Datensatz, der zeigt, wie die Website funktioniert hat, bevor Sie Leistungsverbesserungen vorgenommen haben.

1. Öffnen Sie den Bereich Lighthouse. Möglicherweise ist sie hinter double_arrow Weitere Felder verborgen.

   

2. Die Konfigurationseinstellungen Ihres Lighthouse-Berichts müssen mit denen auf dem Screenshot übereinstimmen. Hier finden Sie eine Erklärung der verschiedenen Optionen:

   • check_box Speicherinhalt löschen Wenn Sie dieses Kästchen aktivieren, werden vor jeder Prüfung alle mit der Seite verknüpften Speicherinhalte gelöscht. Lassen Sie diese Einstellung aktiviert, wenn Sie prüfen möchten, wie Nutzer, die Ihre Website zum ersten Mal besuchen, sie wahrnehmen. Deaktivieren Sie diese Einstellung, wenn Sie die Funktion für wiederholte Besuche nutzen möchten.
   • check_box JS-Sampling aktivieren Diese Option ist standardmäßig deaktiviert. Wenn diese Option aktiviert ist, werden dem Leistungs-Trace detaillierte JavaScript-Callstacks hinzugefügt. Dies kann jedoch die Berichterstellung verlangsamen. Der Trace ist nach der Generierung des Lighthouse-Berichts unter Tools-Menü > Unthrottled Trace ansehen verfügbar.
   • Simulierte Drosselung (Standard) arrow_drop_down Mit dieser Option werden die typischen Bedingungen für das Surfen auf einem Mobilgerät simuliert. Die Werte werden als „simuliert“ bezeichnet, weil Lighthouse während der Prüfung nicht tatsächlich drosselt. Stattdessen wird nur extrapoliert, wie lange das Laden der Seite unter mobilen Bedingungen dauern würde. Die Einstellung Drosselung über die Entwicklertools (erweitert) drosselt hingegen tatsächlich Ihre CPU und Ihr Netzwerk, was jedoch zu einem längeren Auditprozess führt.
   • Modus > radio_button_checked Navigation (Standard). In diesem Modus wird ein einzelner Seitenaufbau analysiert. Das ist genau das, was wir in dieser Anleitung benötigen. Weitere Informationen finden Sie unter Die drei Modi.
   • Gerät > radio_button_checked Mobil. Bei der mobilen Option wird der User-Agent-String geändert und ein mobiler Viewport simuliert. Mit der Desktop-Option werden die Änderungen für Mobilgeräte im Grunde nur deaktiviert.
   • Kategorien > check_box Leistung. Wenn nur eine Kategorie aktiviert ist, enthält der Lighthouse-Bericht nur die entsprechenden Prüfungen. Sie können die anderen Kategorien aktiviert lassen, wenn Sie die darin enthaltenen Empfehlungen sehen möchten. Wenn Sie irrelevante Kategorien deaktivieren, wird der Überprüfungsprozess etwas beschleunigt.

3. Klicken Sie auf Seitenaufbau analysieren. Nach 10 bis 30 Sekunden wird im Bereich Lighthouse ein Bericht zur Leistung der Website angezeigt.

   

Berichtsfehler beheben

Wenn in Ihrem Lighthouse-Bericht ein Fehler auftritt, versuchen Sie, den Demotab in einem Inkognitofenster ohne andere geöffnete Tabs auszuführen. So wird sichergestellt, dass Sie Chrome in einem sauberen Zustand ausführen. Insbesondere Chrome-Erweiterungen können den Überprüfungsprozess beeinträchtigen.

Bericht auswerten

Die Zahl oben im Bericht ist der Gesamtleistungsindex für die Website. Wenn Sie später Änderungen am Code vornehmen, sollte diese Zahl steigen. Ein höherer Wert bedeutet eine bessere Leistung.

Messwerte

Scrollen Sie nach unten zum Bereich Messwerte und klicken Sie auf Ansicht maximieren. Wenn Sie die Dokumentation zu einem Messwert aufrufen möchten, klicken Sie auf Weitere Informationen.

In diesem Abschnitt finden Sie quantitative Messwerte zur Leistung der Website. Jeder Messwert gibt Aufschluss über einen anderen Aspekt der Leistung. Der Messwert First Contentful Paint gibt beispielsweise an, wann Inhalte zum ersten Mal auf dem Bildschirm gerendert werden. Das ist ein wichtiger Meilenstein für die Nutzer, da sie dann den Seitenaufbau wahrnehmen. Time To Interactive gibt dagegen an, wann die Seite so weit geladen ist, dass Nutzerinteraktionen möglich sind.

Screenshots

Im Folgenden sehen Sie eine Reihe von Screenshots, die zeigen, wie die Seite beim Laden aussah.

Verkaufschancen

Als Nächstes folgt der Bereich Empfehlungen, in dem Sie konkrete Tipps zur Verbesserung der Ladeleistung dieser Seite finden.

Klicken Sie auf eine Empfehlung, um weitere Informationen zu erhalten.

Klicken Sie auf Weitere Informationen…, um die Dokumentation dazu aufzurufen, warum eine Optimierungsmöglichkeit wichtig ist, und um spezifische Empfehlungen zur Behebung des Problems zu erhalten.

Diagnose

Im Bereich Diagnose finden Sie weitere Informationen zu Faktoren, die zur Ladezeit der Seite beitragen.

Bestandene Prüfungen

Im Bereich Bestandene Prüfungen sehen Sie, was auf der Website richtig gemacht wird. Klicken Sie, um den Abschnitt zu maximieren.

Schritt 2: Test

Im Bereich Empfehlungen Ihres Lighthouse-Berichts finden Sie Tipps zur Verbesserung der Seitenleistung. In diesem Abschnitt implementieren Sie die empfohlenen Änderungen an der Codebasis und prüfen die Website nach jeder Änderung, um zu sehen, wie sich das auf die Websitegeschwindigkeit auswirkt.

Textkomprimierung aktivieren

In Ihrem Bericht wird angegeben, dass die Aktivierung der Textkomprimierung eine der wichtigsten Möglichkeiten zur Verbesserung der Seitenleistung ist.

Bei der Textkomprimierung wird die Größe einer Textdatei reduziert oder komprimiert, bevor sie über das Netzwerk gesendet wird. Das ist ähnlich wie beim Komprimieren eines Ordners in einer ZIP-Datei, bevor Sie ihn per E-Mail senden, um seine Größe zu verringern.

Bevor Sie die Komprimierung aktivieren, können Sie auf folgende Weise manuell prüfen, ob Textressourcen komprimiert sind.

Öffnen Sie den Bereich Netzwerk und prüfen Sie, ob settings Einstellungen > check_box Große Anforderungszeilen verwenden ausgewählt ist.

In jeder Zelle für Größe werden zwei Werte angezeigt. Der obere Wert ist die Größe der heruntergeladenen Ressource. Der untere Wert ist die Größe der unkomprimierten Ressource. Wenn die beiden Werte identisch sind, wird die Ressource nicht komprimiert, wenn sie über das Netzwerk gesendet wird. In diesem Beispiel sind die oberen und unteren Werte für bundle.js beide 1.4 MB.

Sie können auch die HTTP-Header einer Ressource prüfen, um festzustellen, ob sie komprimiert ist:

1. Klicken Sie auf bundle.js und öffnen Sie den Tab Headers (Header).

   

2. Suchen Sie im Abschnitt Response Headers nach einem content-encoding-Header. Sie sollten keine sehen. Das bedeutet, dass bundle.js nicht komprimiert wurde. Wenn eine Ressource komprimiert ist, wird dieser Header in der Regel auf gzip, deflate oder br gesetzt. Eine Erläuterung dieser Werte finden Sie unter Anweisungen.

Genug der Erklärungen. Zeit für einige Änderungen! Aktivieren Sie die Textkomprimierung, indem Sie einige Codezeilen hinzufügen:

1. Öffnen Sie im Editor-Tab server.js und fügen Sie die folgenden beiden (hervorgehobenen) Zeilen hinzu:

   ...
   const fs = require('fs');
   const compression = require('compression');
   
   app.use(compression());
   app.use(express.static('build'));
   ...
   

2. Achten Sie darauf, app.use(compression()) vor app.use(express.static('build')) zu platzieren.

   

3. Warten Sie, bis Glitch den neuen Build der Website bereitgestellt hat. Ein fröhliches Emoji unten links zeigt an, dass die Bereitstellung erfolgreich war.

Verwenden Sie die Workflows, die Sie zuvor kennengelernt haben, um manuell zu prüfen, ob die Komprimierung funktioniert:

1. Kehren Sie zum Demotab zurück und laden Sie die Seite neu.

   In der Spalte Größe sollten jetzt zwei verschiedene Werte für Textressourcen wie bundle.js angezeigt werden. Der obere Wert 269 KB für bundle.js ist die Größe der Datei, die über das Netzwerk gesendet wurde, und der untere Wert 1.4 MB ist die unkomprimierte Dateigröße.

   

2. Der Abschnitt Antwortheader für bundle.js sollte jetzt einen content-encoding: gzip-Header enthalten.

   

Führen Sie den Lighthouse-Bericht noch einmal für die Seite aus, um die Auswirkungen der Textkomprimierung auf die Ladeleistung der Seite zu messen:

1. Öffnen Sie den Bereich Lighthouse und klicken Sie oben in der Aktionsleiste auf  Audit durchführen....

   

2. Lassen Sie die Einstellungen unverändert und klicken Sie auf Seitenaufbau analysieren.

   

Endlich! Das sieht nach Fortschritt aus. Ihr Gesamtleistungsfaktor sollte gestiegen sein, was bedeutet, dass die Website schneller wird.

Textkomprimierung in der Praxis

Bei den meisten Servern gibt es wirklich so einfache Lösungen, um die Komprimierung zu aktivieren. Suchen Sie einfach nach Informationen zur Konfiguration des Servers, den Sie zum Komprimieren von Text verwenden.

Bildgröße anpassen

In Ihrem neuen Bericht heißt es, dass die richtige Größe von Bildern eine weitere große Chance bietet.

Wenn Sie die Größe von Bildern ändern, wird die Dateigröße verringert und die Ladezeit verkürzt. Wenn sich ein Nutzer Ihre Bilder auf einem 500 Pixel breiten Display eines Mobilgeräts ansieht, ist es nicht sinnvoll, ein 1.500 Pixel breites Bild zu senden. Idealerweise senden Sie ein Bild mit einer Breite von höchstens 500 Pixeln.

1. Klicken Sie in Ihrem Bericht auf Bilder richtig dimensionieren, um zu sehen, welche Bilder angepasst werden sollten. Offenbar sind alle vier Bilder größer als nötig.

   

2. Öffnen Sie auf dem Editor-Tab die Datei src/model.js.

3. Ersetzen Sie const dir = 'big' durch const dir = 'small'. Dieses Verzeichnis enthält Kopien derselben Bilder, die in der Größe angepasst wurden.

4. Prüfen Sie die Seite noch einmal, um zu sehen, wie sich diese Änderung auf die Ladeleistung auswirkt.

   

Die Änderung scheint sich nur geringfügig auf die Gesamtleistung auszuwirken. Eine Sache, die im Score jedoch nicht deutlich wird, ist, wie viele Netzwerkdaten Sie für Ihre Nutzer einsparen. Die Gesamtgröße der alten Fotos betrug etwa 6,1 MB, jetzt sind es nur noch etwa 633 KB. Sie können dies in der Statusleiste unten im Bereich Network (Netzwerk) prüfen.

Bilder in der realen Welt anpassen

Für eine kleine App kann eine einmalige Größenänderung wie diese ausreichend sein. Bei einer großen App ist das natürlich nicht skalierbar. Hier sind einige Strategien für die Verwaltung von Bildern in großen Apps:

• Größe von Bildern während des Build-Prozesses anpassen
• Erstellen Sie während des Build-Prozesses mehrere Größen jedes Bildes und verwenden Sie dann srcset in Ihrem Code. Zur Laufzeit wählt der Browser die Größe aus, die für das Gerät, auf dem er ausgeführt wird, am besten geeignet ist. Weitere Informationen finden Sie unter Bilder mit relativer Größe.
• Verwenden Sie ein Bild-CDN, mit dem Sie die Größe eines Bildes dynamisch anpassen können, wenn Sie es anfordern.
• Optimieren Sie zumindest jedes Bild. Das kann oft zu erheblichen Einsparungen führen. Bei der Optimierung wird ein Bild durch ein spezielles Programm geleitet, das die Größe der Bilddatei reduziert. Weitere Tipps finden Sie unter Wichtige Bildoptimierung.

Ressourcen entfernen, die das Rendering blockieren

Laut Ihrem letzten Bericht ist das Entfernen von Ressourcen, die das Rendering blockieren, die größte Optimierungsmöglichkeit.

Eine rendern-blockierende Ressource ist eine externe JavaScript- oder CSS-Datei, die der Browser herunterladen, parsen und ausführen muss, bevor er die Seite anzeigen kann. Ziel ist es, nur den CSS- und JavaScript-Kerncode auszuführen, der für die korrekte Darstellung der Seite erforderlich ist.

Der erste Schritt besteht also darin, Code zu finden, der nicht beim Laden der Seite ausgeführt werden muss.

1. Klicken Sie auf Ressourcen entfernen, die das Rendering blockieren, um die blockierenden Ressourcen zu sehen: lodash.js und jquery.js.

   

2. Drücken Sie je nach Betriebssystem Folgendes, um das Befehlsmenü zu öffnen:

   • Auf dem Mac: Befehlstaste + Umschalt + P
   • Unter Windows, Linux oder ChromeOS: Strg + Umschalttaste + P

3. Geben Sie Coverage ein und wählen Sie Abdeckung anzeigen aus.

   

   Der Tab Abdeckung wird in der Schublade geöffnet.

   

4. Klicken Sie auf Aktualisieren Neu laden. Auf dem Tab Abdeckung sehen Sie eine Übersicht darüber, wie viel Code in bundle.js, jquery.js und lodash.js beim Laden der Seite ausgeführt wird.

   

   Auf diesem Screenshot ist zu sehen, dass etwa 74% der jQuery-Dateien und 30% der Lodash-Dateien nicht verwendet werden.

5. Klicken Sie auf die Zeile jquery.js. DevTools öffnet die Datei im Bereich Quellen. Eine Codezeile wurde ausgeführt, wenn daneben ein grüner Balken angezeigt wird. Ein roter Balken neben einer Codezeile bedeutet, dass sie nicht ausgeführt wurde und beim Laden der Seite definitiv nicht benötigt wird.

   

6. Scrollen Sie ein wenig durch den jQuery-Code. Einige der Zeilen, die „ausgeführt“ werden, sind tatsächlich nur Kommentare. Wenn Sie diesen Code durch ein Tool zur Minimierung von Code ausführen, das Kommentare entfernt, können Sie die Größe dieser Datei ebenfalls reduzieren.

Kurz gesagt: Wenn Sie mit Ihrem eigenen Code arbeiten, können Sie auf dem Tab Coverage (Abdeckung) Ihren Code zeilenweise analysieren und nur den Code bereitstellen, der für das Laden der Seite erforderlich ist.

Werden die Dateien jquery.js und lodash.js überhaupt zum Laden der Seite benötigt? Auf dem Tab Anfrage blockieren sehen Sie, was passiert, wenn Ressourcen nicht verfügbar sind.

1. Klicken Sie auf den Tab Netzwerk und öffnen Sie das Befehlsmenü noch einmal.

2. Geben Sie blocking ein und wählen Sie Anfrageblockierung anzeigen aus. Der Tab Blockierung anfordern wird geöffnet.

   

3. Klicken Sie auf  Muster hinzufügen, geben Sie /libs/* in das Textfeld ein und drücken Sie zur Bestätigung die Eingabetaste.

   

4. Lade die Seite neu. Die jQuery- und Lodash-Anfragen sind rot, was bedeutet, dass sie blockiert wurden. Die Seite wird weiterhin geladen und ist interaktiv. Anscheinend sind diese Ressourcen also überhaupt nicht erforderlich.

   

5. Klicken Sie auf  Alle Muster entfernen, um das Blockierungsmuster /libs/* zu löschen.

Im Allgemeinen ist der Tab Anfrage blockieren nützlich, um zu simulieren, wie sich Ihre Seite verhält, wenn eine bestimmte Ressource nicht verfügbar ist.

Entfernen Sie nun die Verweise auf diese Dateien aus dem Code und prüfen Sie die Seite noch einmal:

1. Öffnen Sie auf dem Editor-Tab die Datei template.html.

2. Löschen Sie die entsprechenden <script>-Tags:

   <head>
       ...
       <meta name="viewport" content="width=device-width, initial-scale=1">
       <script src="/libs/lodash.js"></script>
       <script src="/libs/jquery.js"></script>
       <title>Tony's Favorite Foods</title>
   </head>
   

3. Warten Sie, bis die Website neu erstellt und bereitgestellt wurde.

4. Prüfen Sie die Seite noch einmal über das Lighthouse-Panel. Ihr Gesamtfaktor sollte sich noch einmal verbessert haben.

   

Wichtige Rendering-Pfade in der Praxis optimieren

Der kritische Rendering-Pfad bezieht sich auf den Code, der zum Laden einer Seite erforderlich ist. Im Allgemeinen können Sie die Seitenladezeit verkürzen, indem Sie nur wichtigen Code während des Seitenladens übertragen und alles andere verzögert laden.

• Es ist unwahrscheinlich, dass Sie Skripts finden, die Sie einfach entfernen können. Oft ist es jedoch so, dass viele Skripts nicht während des Seitenaufbaus angefordert werden müssen, sondern stattdessen asynchron angefordert werden können. Weitere Informationen finden Sie unter async- oder defer-Attribute verwenden.
• Wenn Sie ein Framework verwenden, prüfen Sie, ob es einen Produktionsmodus hat. In diesem Modus wird möglicherweise eine Funktion wie Tree Shaking verwendet, um unnötigen Code zu entfernen, der das kritische Rendern blockiert.

Weniger Aufwand im Hauptthread

In Ihrem letzten Bericht sind im Bereich Optimierungsvorschläge einige geringfügige potenzielle Einsparungen zu sehen. Wenn Sie jedoch zum Bereich Diagnose scrollen, scheint der größte Engpass eine zu hohe Aktivität im Hauptthread zu sein.

Im Hauptthread führt der Browser die meisten Aufgaben aus, die zum Anzeigen einer Seite erforderlich sind, z. B. das Parsen und Ausführen von HTML, CSS und JavaScript.

Ziel ist es, mit dem Bereich Leistung zu analysieren, welche Aufgaben der Hauptthread während des Seitenaufbaus ausführt, und Möglichkeiten zu finden, unnötige Aufgaben zu verzögern oder zu entfernen.

1. Öffnen Sie Leistung >  Aufnahmeeinstellungen und legen Sie Netzwerk auf Langsames 3G und CPU auf 6-fache Verlangsamung fest.

   

   Mobilgeräte haben in der Regel mehr Hardwareeinschränkungen als Laptops oder Desktopcomputer. Mit diesen Einstellungen können Sie das Laden der Seite so erleben, als würden Sie ein weniger leistungsstarkes Gerät verwenden.

2. Klicken Sie auf Aktualisieren Neu laden. Die Entwicklertools laden die Seite neu und erstellen dann eine Visualisierung aller Schritte, die zum Laden der Seite erforderlich waren. Diese Visualisierung wird als Trace bezeichnet.

   

Der Trace zeigt die Aktivitäten chronologisch von links nach rechts. Die Diagramme für FPS, CPU und NET oben bieten einen Überblick über die Frames pro Sekunde, die CPU-Aktivität und die Netzwerkaktivität.

Die gelbe Wand im Bereich Übersicht bedeutet, dass die CPU vollständig mit Scripting-Aktivitäten beschäftigt war. Das ist ein Hinweis darauf, dass Sie die Seitenladezeit möglicherweise verkürzen können, indem Sie weniger JavaScript-Arbeit erledigen.

Untersuchen Sie den Trace, um Möglichkeiten zu finden, weniger JavaScript-Arbeit zu leisten:

1. Klicken Sie auf den Abschnitt Zeitangaben, um ihn zu maximieren.

   

   Es gibt eine Reihe von User Timing-Messungen von React. Offenbar wird in Tonys App der Entwicklermodus von React verwendet. Wenn Sie zum Produktionsmodus von React wechseln, können Sie wahrscheinlich ganz einfach die Leistung verbessern.

2. Klicken Sie noch einmal auf Zeitangaben, um den Bereich zu minimieren.

3. Sehen Sie sich den Bereich Haupt an. In diesem Bereich sehen Sie ein chronologisches Protokoll der Hauptthreadaktivität von links nach rechts. Auf der Y-Achse (von oben nach unten) wird angezeigt, warum Ereignisse aufgetreten sind.

   

   In diesem Beispiel hat das Ereignis Evaluate Script die Ausführung der Funktion (anonymous) ausgelöst, was zur Ausführung von __webpack__require__, ./src/index.jsx usw. geführt hat.

4. Scrollen Sie zum unteren Bereich des Abschnitts Haupt. Wenn Sie ein Framework verwenden, wird der Großteil der oberen Aktivität durch das Framework verursacht, was in der Regel außerhalb Ihrer Kontrolle liegt. Die durch Ihre App verursachten Aktivitäten werden normalerweise unten angezeigt.

   

   In dieser App scheint eine Funktion namens App viele Aufrufe einer mineBitcoin-Funktion zu verursachen. Es sieht so aus, als würde Tony die Geräte seiner Fans zum Mining von Kryptowährungen verwenden…

5. Öffnen Sie unten den Tab Bottom-Up. Auf diesem Tab sehen Sie, welche Aktivitäten am meisten Zeit in Anspruch genommen haben. Wenn im Bereich Bottom-Up nichts angezeigt wird, klicken Sie auf das Label für den Bereich Main.

   

   Im Bereich Bottom-up werden nur Informationen für die Aktivität oder Aktivitätsgruppe angezeigt, die Sie gerade ausgewählt haben. Wenn Sie beispielsweise auf eine der mineBitcoin-Aktivitäten geklickt haben, werden im Bereich Bottom-up nur Informationen zu dieser einen Aktivität angezeigt.

   In der Spalte Eigenzeit sehen Sie, wie viel Zeit direkt für die einzelnen Aktivitäten aufgewendet wurde. In diesem Fall wurden etwa 82% der Hauptthreadzeit für die Funktion mineBitcoin aufgewendet.

Es ist an der Zeit, zu prüfen, ob sich die Ladezeit der Seite verkürzt, wenn Sie den Produktionsmodus verwenden und die JavaScript-Aktivität reduzieren. So starten Sie im Produktionsmodus:

1. Öffnen Sie auf dem Tab „Editor“ die Datei webpack.config.js.
2. Ändern Sie "mode":"development" zu "mode":"production".
3. Warten Sie, bis der neue Build bereitgestellt wurde.

4. Überprüfen Sie die Seite noch einmal.

   

Reduzieren Sie die JavaScript-Aktivität, indem Sie den Aufruf von mineBitcoin entfernen:

1. Öffnen Sie auf dem Tab „Editor“ die Datei src/App.jsx.
2. Kommentieren Sie den Aufruf von this.mineBitcoin(1500) in constructor aus.
3. Warten Sie, bis der neue Build bereitgestellt wurde.
4. Überprüfen Sie die Seite noch einmal.

Wie immer gibt es noch einiges zu tun, z. B. die Messwerte Largest Contentful Paint und Cumulative Layout Shift zu verbessern.

Weniger Arbeit im Haupt-Thread in der Praxis

Im Allgemeinen ist der Bereich Leistung die gängigste Methode, um zu verstehen, welche Aktivitäten auf Ihrer Website beim Laden ausgeführt werden, und um Möglichkeiten zu finden, unnötige Aktivitäten zu entfernen.

Wenn Sie einen Ansatz bevorzugen, der sich eher wie console.log() anfühlt, können Sie mit der User Timing API bestimmte Phasen des App-Lebenszyklus beliebig markieren, um die Dauer der einzelnen Phasen zu erfassen.

Zusammenfassung

• Wenn Sie die Ladeleistung einer Website optimieren möchten, sollten Sie immer mit einer Analyse beginnen. Im Audit wird eine Baseline erstellt und Sie erhalten Tipps zur Verbesserung.
• Nehmen Sie jeweils nur eine Änderung vor und prüfen Sie die Seite danach, um zu sehen, wie sich diese einzelne Änderung auf die Leistung auswirkt.

Nächste Schritte

Audits auf Ihrer eigenen Website durchführen Wenn Sie Hilfe bei der Interpretation Ihres Berichts oder bei der Suche nach Möglichkeiten zur Verbesserung der Ladeleistung benötigen, finden Sie hier alle Möglichkeiten, Hilfe von der DevTools-Community zu erhalten:

• Fehler in diesem Dokument können Sie im Repository developer.chrome.com melden.
• Fehlerberichte zu den Entwicklertools können Sie unter Chromium Bugs einreichen.
• Funktionen und Änderungen können auf der Mailingliste diskutiert werden. Bitte verwenden Sie die Mailingliste nicht für Supportanfragen. Verwenden Sie stattdessen Stack Overflow.
• Allgemeine Hilfe zur Verwendung der Entwicklertools finden Sie auf Stack Overflow. Verwenden Sie zum Melden von Fehlern immer Chromium Bugs.
• Senden Sie uns einen Tweet an @ChromeDevTools.