Lighthouse: Websitegeschwindigkeit optimieren

Sofia Emelianova
Sofia Emelianova

Ziel des Tutorials

In dieser Anleitung erfahren Sie, wie Sie mit den Chrome-Entwicklertools dafür sorgen, dass Ihre Websites schneller geladen werden.

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

Voraussetzungen

Sie sollten grundlegende Kenntnisse in der Webentwicklung haben, ähnlich wie im Kurs Einführung in die Webentwicklung.

Sie müssen nichts über die Ladeleistung wissen.

Einleitung

Das ist Tony. Tony ist in der Katzengesellschaft sehr bekannt. Er hat eine Website erstellt, auf der seine Fans seine Lieblingsspeisen kennenlernen können. Die Website ist bei seinen Fans sehr beliebt, aber Tony beschwert sich immer wieder, dass die Website langsam geladen wird. Tony hat Sie gebeten, ihm zu helfen, die Website zu beschleunigen.

Tony die Katze.

Schritt 1: Website prüfen

Wenn Sie die Ladeleistung einer Website verbessern möchten, beginnen Sie immer mit einem Audit. Die Prüfung hat zwei wichtige Funktionen:

  • Es wird eine Referenz erstellt, anhand derer Sie spätere Änderungen messen können.
  • Sie erhalten umsetzbare Tipps dazu, welche Änderungen die größten Auswirkungen haben.

Einrichten

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

  1. Erstellen Sie einen Remix des Projekts der Website auf Glitch. Das neue Projekt wird in einem Tab geöffnet. Dieser Tab wird als Editor-Tab bezeichnet.

    Die Originalquelle und der Editor-Tab, nachdem Sie auf „Remix“ geklickt haben.

    Der Name des Projekts wird von tony in einen zufällig generierten Namen geändert. Sie haben jetzt eine eigene bearbeitbare Kopie des Codes. Später werden Sie diesen Code ändern.

  2. Klicken Sie unten auf dem Tab „Editor“ auf Vorschau > Vorschau in einem neuen Fenster. Die Demo wird in einem neuen Tab geöffnet. Dieser Tab wird als Tab „Demo“ bezeichnet. Das Laden der Website kann eine Weile dauern.

    Tab „Demo“

  3. Öffne die Entwicklertools neben der Demo.

    die Entwicklertools und die Demo.

Baseline festlegen

Die Baseline ist eine Aufzeichnung der Leistung der Website vor jeder Leistungssteigerung.

  1. Öffnen Sie den Bereich Lighthouse. Es ist möglicherweise hinter mehr Bereichen verborgen.

    Der Lighthouse-Bereich.

  2. Gleichen Sie die Konfigurationseinstellungen des Lighthouse-Berichts mit denen im Screenshot ab. Die verschiedenen Optionen werden folgendermaßen erklärt:

    • check_box Speicherinhalt löschen. Wenn Sie dieses Kästchen aktivieren, wird vor jeder Prüfung der gesamte mit der Seite verknüpfte Speicher gelöscht. Lassen Sie diese Einstellung aktiviert, wenn Sie prüfen möchten, wie Erstbesucher Ihre Website erleben. 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-Aufrufstacks hinzugefügt. Die Berichterstellung kann jedoch verlangsamt werden. Nachdem der Lighthouse-Bericht erstellt wurde, ist der Trace unter more_vert im Menü Tools > Ungedrosselten Trace anzeigen verfügbar. Leistungs-Trace ohne (links) und mit (rechts) JS-Sampling.
    • Simulierte Drosselung (Standardeinstellung) . Diese Option simuliert die typischen Bedingungen beim Surfen auf einem Mobilgerät. Sie heißt „simuliert“, weil Lighthouse während der Prüfung nicht drosselt. Stattdessen wird lediglich extrapoliert, wie lange es dauern würde, bis die Seite unter mobilen Bedingungen geladen wird. Die Einstellung DevTools-Drosselung (erweitert) hingegen drosselt Ihre CPU und Ihr Netzwerk, was zu einem längeren Prüfungsprozess führt.
    • Modus > Navigation (Standard). In diesem Modus wird ein einzelner Seitenaufbau analysiert, den wir in dieser Anleitung benötigen. Weitere Informationen finden Sie unter Die drei Modi.
    • Gerät > Mobilgerät. Die Option für Mobilgeräte ändert den User-Agent-String und simuliert einen mobilen Darstellungsbereich. Bei der Desktop-Option werden die Änderungen auf Mobilgeräten praktisch nur deaktiviert.
    • Kategorien > check_box Leistung: Wenn nur eine aktivierte Kategorie aktiviert ist, erstellt Lighthouse nur einen Bericht mit den entsprechenden Prüfungen. Sie können die anderen Kategorien aktiviert lassen, wenn Sie sehen möchten, welche Arten von Empfehlungen sie geben. Durch das Deaktivieren irrelevanter Kategorien wird die Prüfung etwas beschleunigt.
  3. Klicken Sie auf Seitenaufbau analysieren. Nach 10 bis 30 Sekunden wird im Bereich Lighthouse ein Bericht zur Leistung der Website angezeigt.

    Einen Lighthouse-Bericht zur Websiteleistung

Umgang mit Berichtsfehlern

Wenn in Ihrem Lighthouse-Bericht ein Fehler auftritt, versuchen Sie, den Tab „Demo“ in einem Inkognitofenster auszuführen und keine anderen Tabs geöffnet zu haben. Dadurch wird sichergestellt, dass Chrome in einem sauberen Zustand ausgeführt wird. Insbesondere Chrome-Erweiterungen können den Prüfungsprozess beeinträchtigen.

Ein Bericht mit einem Fehler.

Bericht auswerten

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

Die Gesamtleistung.

Messwerte

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

Bereich „Messwerte“

Dieser Abschnitt enthält quantitative Messungen der Website-Leistung. Jeder Messwert gibt Aufschluss über einen anderen Aspekt der Leistung. First Contentful Paint informiert Sie beispielsweise darüber, wann Inhalte zum ersten Mal auf den Bildschirm gezeichnet werden. Dies ist ein wichtiger Meilenstein in der Wahrnehmung des Seitenaufbaus durch den Nutzer. Mit Time To Interactive hingegen wird der Punkt markiert, an dem die Seite für Nutzerinteraktionen bereit genug erscheint.

Screenshots

Als Nächstes sehen Sie eine Sammlung von Screenshots, die Ihnen zeigen, wie die Seite beim Laden aussah.

Screenshots, die zeigen, wie die Seite während des Ladevorgangs ausgesehen hat.

Möglichkeiten

Als Nächstes finden Sie den Abschnitt Empfehlungen mit konkreten Tipps, wie Sie die Ladeleistung dieser Seite verbessern können.

Bereich „Empfehlungen“

Klicken Sie auf eine Empfehlung, um mehr darüber zu erfahren.

Weitere Informationen zu Textkomprimierung.

Klicken Sie auf Weitere Informationen, um zu erfahren, warum eine Empfehlung wichtig ist, und um spezifische Empfehlungen zu ihrer Behebung zu erhalten.

Diagnose

Im Abschnitt Diagnose finden Sie weitere Informationen zu Faktoren, die die Ladezeit einer Seite beeinflussen.

Im Bereich „Diagnose“

Bestandene Prüfungen

Im Bereich Bestandene Prüfungen sehen Sie, was die Website korrekt macht. Klicken Sie, um den Bereich zu maximieren.

Im Bereich „Bestandene Prüfungen“

Schritt 2: Experimentieren

Im Abschnitt Empfehlungen Ihres Lighthouse-Berichts finden Sie Tipps dazu, wie Sie die Leistung der Seite verbessern können. In diesem Abschnitt implementieren Sie die empfohlenen Änderungen an der Codebasis und prüfen die Website nach jeder Änderung, um zu messen, wie sie sich auf die Websitegeschwindigkeit auswirkt.

Textkomprimierung aktivieren

Laut Ihrem Bericht ist die Aktivierung der Textkomprimierung eine der wichtigsten Möglichkeiten zur Verbesserung der Seitenleistung.

Bei der Textkomprimierung wird die Größe einer Textdatei reduziert oder komprimiert, bevor sie über das Netzwerk gesendet wird. So könnten Sie einen Ordner vor dem E-Mail-Versand komprimieren, um seine Größe zu reduzieren.

Bevor Sie die Komprimierung aktivieren, haben Sie mehrere Möglichkeiten, manuell zu prüfen, ob Textressourcen komprimiert sind.

Öffnen Sie den Bereich Netzwerk und klicken Sie auf Einstellungen > Große Anfragezeilen verwenden.

In der Spalte „Größe“ im Bereich „Netzwerk“ werden große Anfragezeilen angezeigt.

In jeder Zelle Größe werden zwei Werte angezeigt. Der oberste 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 beim Senden über das Netzwerk nicht komprimiert. In diesem Beispiel sind der obere und der untere Wert für bundle.js beide 1.4 MB.

Sie können die Komprimierung auch überprüfen, indem Sie die HTTP-Header einer Ressource überprüfen:

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

    Tab „Headers“

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

Das war genug mit den Erklärungen. Zeit für ein paar Ä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 zwei (hervorgehobenen) Zeilen hinzu:

    ...
    const fs = require('fs');
    const compression = require('compression');
    
    app.use(compression());
    app.use(express.static('build'));
    ...
    
  2. app.use(compression()) muss vor app.use(express.static('build')) gesetzt werden.

    server.js bearbeiten.

  3. Warten Sie, bis der neue Build der Website über Glitch bereitgestellt wurde. Ein glückliches Emoji in der unteren linken Ecke zeigt an, dass die Bereitstellung erfolgreich war.

Überprüfen Sie anhand der bereits bekannten Workflows manuell, ob die Komprimierung funktioniert:

  1. Kehren Sie zum Tab „Demo“ zurück und aktualisieren Sie die Seite.

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

    In der Spalte „Größe“ werden jetzt zwei verschiedene Werte für Textressourcen angezeigt.

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

    Der Abschnitt „Response Headers“ (Antwortheader) enthält jetzt einen Header zur Inhaltscodierung.

Führen Sie den Lighthouse-Bericht noch einmal auf der Seite aus, um zu messen, wie sich die Textkomprimierung auf die Ladeleistung der Seite auswirkt:

  1. Öffnen Sie den Lighthouse-Bereich und klicken Sie oben in der Aktionsleiste auf Hinzufügen Prüfung durchführen....

    Die Schaltfläche „Durchführen eine Prüfung“.

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

    Ein Lighthouse-Bericht nach der Aktivierung der Textkomprimierung

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

Textkomprimierung in der realen Welt

Bei den meisten Servern gibt es einfache Lösungen wie diese, um die Komprimierung zu aktivieren. Suchen Sie einfach nach der Konfiguration des Servers, der zum Komprimieren von Text verwendet werden soll.

Bildgröße anpassen

Laut Ihrem neuen Bericht ist die richtige Größe von Bildern eine weitere große Chance.

Durch die Reduzierung der Dateigröße von Bildern lässt sich die Ladezeit der Bilder verkürzen. Wenn sich der Nutzer Ihre Bilder auf einem 500 Pixel breiten Bildschirm eines Mobilgeräts ansieht, ist es eigentlich sinnlos, ein Bild mit einer Breite von 1.500 Pixeln zu senden. Im Idealfall senden Sie ein Bild mit einer Breite von höchstens 500 Pixeln.

  1. Klicken Sie im Bericht auf Bilder richtig groß, um zu sehen, an welchen Bildern die Größe angepasst werden muss. Es sieht so aus, als wären alle 4 Bilder größer als nötig.

    Details zur Empfehlung für Bilder mit der richtigen Größe

  2. Öffnen Sie auf dem Tab „Editor“ src/model.js.

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

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

    Ein Lighthouse-Bericht nach der Größenanpassung von Bildern

Die Änderung hat anscheinend nur einen geringen Einfluss auf die Gesamtleistung. Anhand des Werts lässt sich jedoch nicht eindeutig erkennen, wie viele Netzwerkdaten Sie Ihren Nutzern einsparen. Die Gesamtgröße der alten Fotos betrug rund 6,1 MB, jetzt sind es nur noch etwa 633 KB. Sie können dies in der Statusleiste unten im Bereich Netzwerk prüfen.

Menge der übertragenen Daten vor und nach der Größenänderung von Bildern.

Größe von Bildern in der realen Umgebung anpassen

Bei einer kleinen App kann eine einmalige Größenänderung wie diese ausreichen. Bei einer großen App ist das offensichtlich nicht skalierbar. Hier sind einige Strategien für die Verwaltung von Bildern in großen Apps:

  • Passen Sie die Größe der Images während des Erstellungsprozesses an.
  • Erstellen Sie während des Build-Prozesses mehrere Größen jedes Images und verwenden Sie dann srcset in Ihrem Code. Zur Laufzeit wählt der Browser die beste Größe für das Gerät aus, auf dem er ausgeführt wird. Siehe Bilder in relativer Größe.
  • Verwenden Sie ein CDN für Bilder, mit dem Sie die Größe eines Bildes bei Anfrage dynamisch anpassen können.
  • Optimieren Sie zumindest jedes Bild. Das führt häufig zu enormen Einsparungen. Bei der Optimierung wird ein Bild über ein spezielles Programm ausgeführt, das die Größe der Bilddatei reduziert. Weitere Tipps finden Sie unter Wichtige Bildoptimierung.

Ressourcen eliminieren, die das Rendering blockieren

Laut Ihrem aktuellen Bericht ist die Eliminierung von Ressourcen, die das Rendering blockieren, jetzt die größte Chance.

Eine Ressource, die das Rendering blockiert, ist eine externe JavaScript- oder CSS-Datei, die der Browser herunterladen, parsen und ausführen muss, bevor die Seite angezeigt werden kann. Ziel ist es, nur den grundlegenden CSS- und JavaScript-Code auszuführen, der für die korrekte Darstellung der Seite erforderlich ist.

Die erste Aufgabe besteht darin, Code zu finden, der beim Laden der Seite nicht ausgeführt werden muss.

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

    Weitere Informationen zur Empfehlung „Ressourcen reduzieren, die das Rendering blockieren“.

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

    • Auf einem Mac: Befehlstaste + Umschalt + P
    • Unter Windows, Linux oder ChromeOS: Strg + Umschalttaste + P
  3. Geben Sie die ersten Buchstaben von Coverage ein und wählen Sie Abdeckung anzeigen aus.

    Das Befehlsmenü im Lighthouse-Steuerfeld öffnen.

    Der Tab Abdeckung wird in der Leiste geöffnet.

    Tab „Abdeckung“

  4. Klicken Sie auf Aktualisieren Aktualisieren. Auf dem Tab Abdeckung erhalten Sie einen Überblick darüber, welcher Anteil des Codes in bundle.js, jquery.js und lodash.js beim Laden der Seite ausgeführt wird.

    Bericht zur Abdeckung

    Dieser Screenshot zeigt, dass etwa 74% bzw. 30% der jQuery- und Lodash-Dateien nicht verwendet werden.

  5. Klicken Sie auf die Zeile jquery.js. Die Entwicklertools öffnen die Datei im Bereich Quellen. Eine Codezeile wurde ausgeführt, wenn daneben ein grüner Balken zu sehen ist. Ein roter Balken neben einer Codezeile bedeutet, dass der Code nicht ausgeführt wurde und beim Seitenaufbau auch nicht benötigt wird.

    Anzeigen der jQuery-Datei im Bereich "Quellen"

  6. Scrollen Sie ein bisschen durch den jQuery-Code. Einige der Zeilen, die „ausgeführt“ werden, sind in Wirklichkeit nur Kommentare. Eine weitere Möglichkeit, die Größe dieser Datei zu reduzieren, besteht darin, diesen Code über einen Komprimierer auszuführen, der Kommentare entfernt.

Wenn Sie mit Ihrem eigenen Code arbeiten, können Sie auf dem Tab Abdeckung den Code Zeile für Zeile analysieren und nur den Code senden, der für den Seitenaufbau erforderlich ist.

Sind die Dateien jquery.js und lodash.js überhaupt erforderlich, um die Seite zu laden? Auf dem Tab Request Blocking (Anfrageblockierung) sehen Sie, was passiert, wenn keine Ressourcen verfügbar sind.

  1. Klicken Sie auf den Tab Netzwerk und öffnen Sie noch einmal das Befehlsmenü.
  2. Beginnen Sie mit der Eingabe von blocking und wählen Sie dann Anfrageblockierung anzeigen aus. Der Tab Anfrageblockierung wird geöffnet.

    Tab „Anfrageblockierung“

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

    Hinzufügen eines Musters, um jede Anfrage an das Verzeichnis "libs" zu blockieren.

  4. Lade die Seite neu. Die jQuery- und Lodash-Anfragen sind rot, was bedeutet, dass sie blockiert wurden. Die Seite wird immer noch geladen und ist interaktiv, sodass diese Ressourcen offenbar nicht benötigt werden.

    Im Bereich „Netzwerk“ wird angezeigt, dass die Anfragen blockiert wurden.

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

Im Allgemeinen ist der Tab Anfrageblockierung nützlich, um das Verhalten Ihrer Seite zu simulieren, 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 Tab „Editor“ 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 im Bereich Lighthouse noch einmal. Ihre Gesamtpunktzahl sollte sich wieder verbessert haben.

    Einen Lighthouse-Bericht, nachdem die Ressourcen entfernt wurden, die das Rendering blockieren

Den kritischen Rendering-Pfad in der realen Welt optimieren

Der kritische Rendering-Pfad bezieht sich auf den Code, den Sie zum Laden einer Seite benötigen. Im Allgemeinen können Sie den Seitenaufbau beschleunigen, indem Sie während des Seitenaufbaus nur wichtigen Code senden und dann alles andere per Lazy Loading laden.

  • Es ist unwahrscheinlich, dass Sie Skripts finden, die Sie sofort entfernen können. Viele Skripts müssen jedoch nicht beim Seitenaufbau angefordert werden und können stattdessen asynchron angefordert werden. Weitere Informationen finden Sie unter Asynchron oder verzögert verwenden.
  • Wenn Sie ein Framework verwenden, prüfen Sie, ob es einen Produktionsmodus hat. In diesem Modus kann eine Funktion wie Baumbewegung verwendet werden, um unnötigen Code zu entfernen, der das kritische Rendering blockiert.

Weniger Arbeit mit dem Hauptthread

Ihr aktueller Bericht enthält im Bereich Empfehlungen einige kleinere potenzielle Einsparungen. Wenn Sie jedoch zum Abschnitt Diagnose scrollen, scheint der größte Engpass in einer zu großen Hauptthread-Aktivität zu sein.

Der Hauptthread ist der Ort, an dem der Browser die meiste Arbeit für die Anzeige einer Seite ausführt, z. B. das Parsen und Ausführen von HTML, CSS und JavaScript.

Das Ziel besteht darin, im Bereich Leistung zu analysieren, welche Arbeit der Hauptthread während des Ladens der Seite ausführt, und Möglichkeiten finden, unnötige Arbeit aufzuschieben oder zu entfernen.

  1. Öffnen Sie Leistung > Einstellungen. Erfassungseinstellungen und setzen Sie Netzwerk auf Langsames 3G und CPU auf 6-fache Verzögerung.

    Einstellungen für CPU- und Netzwerkdrosselung im Bereich „Leistung“

    Für Mobilgeräte gelten in der Regel mehr Hardwarebeschränkungen als für Laptops oder Desktop-Computer. Mit diesen Einstellungen können Sie den Seitenaufbau also so erleben, als würden Sie ein weniger leistungsstarkes Gerät verwenden.

  2. Klicken Sie auf Aktualisieren Aktualisieren. Die Entwicklertools laden die Seite neu und erstellen dann eine Visualisierung dessen, was zum Laden der Seite erforderlich war. Diese Visualisierung wird als trace bezeichnet.

    Trace des Seitenaufbaus im Steuerfeld „Leistung“.

Im Trace wird die Aktivität chronologisch von links nach rechts angezeigt. Die oben angezeigten Diagramme für fps, CPU und NET bieten einen Überblick über Bilder pro Sekunde, CPU-Aktivität und Netzwerkaktivität.

Der Abschnitt „Übersicht“ des Trace.

Die gelben Bereiche im Bereich Übersicht zeigen an, dass die CPU mit der Skriptaktivität ausgelastet war. Dies ist ein Hinweis darauf, dass Sie den Seitenaufbau beschleunigen können, indem Sie weniger JavaScript-Aufwand benötigen.

Untersuchen Sie den Trace, um Möglichkeiten zu finden, weniger JavaScript auszuführen:

  1. Klicken Sie auf den Bereich Timings, um ihn zu maximieren.

    Im Bereich „Timings“

    Es gibt eine Reihe von Messwerten für das Nutzertiming von React. Anscheinend nutzt Tony den Entwicklungsmodus von React. Der Wechsel in den Produktionsmodus von React wird wahrscheinlich zu leichten Leistungssteigerungen führen.

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

  3. Gehen Sie den Hauptbereich durch. Dieser Abschnitt enthält ein chronologisches Log der Aktivitäten des Hauptthreads, von links nach rechts. Die Y-Achse (oben nach unten) zeigt, warum Ereignisse aufgetreten sind.

    Hauptbereich

    In diesem Beispiel wurde durch das Evaluate Script-Ereignis die (anonymous)-Funktion ausgeführt, wodurch __webpack__require__, ./src/index.jsx usw. ausgeführt wurde.

  4. Scrollen Sie im Main-Bereich ganz nach unten. Wenn Sie ein Framework verwenden, wird der Großteil der Hauptaktivität durch das Framework verursacht, das normalerweise außerhalb Ihrer Kontrolle liegt. Die durch Ihre App verursachte Aktivität befindet sich normalerweise unten.

    Die mineBitcoin-Aktivität.

    In dieser App scheint es so, als ob eine Funktion namens App viele Aufrufe einer mineBitcoin-Funktion verursacht. Es scheint so, als ob Tony die Geräte seiner Fans zum Mining von Kryptowährungen nutzt...

  5. Öffnen Sie unten den Tab Bottom-Up. Auf diesem Tab wird aufgeschlüsselt, welche Aktivitäten am meisten Zeit beansprucht haben. Wenn Sie unter Bottom-up (Unten) nichts sehen, klicken Sie auf das Label für Main (Hauptbereich).

    Tab „Bottom-up“

    Im Abschnitt Bottom-Up werden nur Informationen für die Aktivität oder Gruppe von Aktivitäten angezeigt, die Sie derzeit ausgewählt haben. Wenn Sie beispielsweise auf eine der mineBitcoin-Aktivitäten geklickt haben, werden im Abschnitt Bottom-Up nur Informationen zu dieser einen Aktivität angezeigt.

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

Zeit, um festzustellen, ob der Produktionsmodus und die Reduzierung von JavaScript-Aktivitäten den Seitenaufbau beschleunigen. Mit dem Produktionsmodus beginnen:

  1. Öffnen Sie im Tab „Editor“ webpack.config.js.
  2. Ändern Sie "mode":"development" zu "mode":"production".
  3. Warten Sie, bis der neue Build bereitgestellt wurde.
  4. Prüfen Sie die Seite noch einmal.

    Einen Lighthouse-Bericht, nachdem Sie Webpack für die Verwendung des Produktionsmodus konfiguriert haben

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

  1. Öffnen Sie im Tab „Editor“ src/App.jsx.
  2. Kommentieren Sie den Anruf an this.mineBitcoin(1500) in der constructor aus.
  3. Warten Sie, bis der neue Build bereitgestellt wurde.
  4. Prüfen Sie die Seite noch einmal.

Einen Lighthouse-Bericht, nachdem unnötige JavaScript-Änderungen entfernt wurden

Wie immer gibt es noch etwas zu tun, zum Beispiel die Messwerte Largest Contentful Paint und Cumulative Layout Shift.

Weniger Hauptthreads in der realen Welt

Im Bereich Leistung sehen Sie am häufigsten, welche Aktivitäten Ihre Website beim Laden ausführt. Außerdem finden Sie dort Möglichkeiten, unnötige Aktivitäten zu entfernen.

Wenn Sie einen Ansatz bevorzugen, der dem console.log() ähnelt, können Sie mit der User Timing API bestimmte Phasen Ihres App-Lebenszyklus beliebig auszeichnen, um zu verfolgen, wie lange jede dieser Phasen dauert.

Zusammenfassung

  • Wenn Sie die Ladeleistung einer Website optimieren möchten, beginnen Sie immer mit einem Audit. Die Prüfung legt eine Grundlage fest und gibt Ihnen Verbesserungsvorschläge.
  • Nehmen Sie jeweils nur eine Änderung vor und prüfen Sie die Seite nach jeder Änderung, um festzustellen, wie sich diese isolierte Änderung auf die Leistung auswirkt.

Nächste Schritte

Führen Sie Audits auf Ihrer eigenen Website durch! Wenn du Hilfe beim Interpretieren deines Berichts oder bei der Verbesserung der Ladeleistung benötigst, sieh dir die verschiedenen Möglichkeiten an, wie du Hilfe von der Entwicklertools-Community erhalten kannst:

  • In diesem Dokument können Sie Fehler im Repository developer.chrome.com melden.
  • Du kannst Fehlerberichte in den Entwicklertools unter Chromium Bugs einreichen.
  • Besprechen Sie Funktionen und Änderungen in der Mailingliste. Verwenden Sie die Mailingliste nicht für Support-Fragen. Verwenden Sie stattdessen Stack Overflow.
  • Allgemeine Hilfe zur Verwendung der Entwicklertools auf Stack Overflow erhalten. Wenn du Anfragen zu Fehlern einreichen möchtest, verwende immer Chromium-Programmfehler.
  • Twittern Sie uns unter @ChromeDevTools.