PRPL ist ein Akronym, das ein Muster beschreibt, mit dem Webseiten schneller geladen und interaktiv werden:
- Laden Sie die später gefundenen Ressourcen vorab.
- Rendern Sie die ursprüngliche Route so schnell wie möglich.
- Verbleibende Assets im Cache speichern.
- Lazy load andere Routes und nicht kritische Assets.
In diesem Leitfaden erfahren Sie, wie diese Techniken zusammenpassen, aber dennoch unabhängig voneinander verwendet werden können, um Leistungsergebnisse zu erzielen.
Seite mit Lighthouse prüfen
Führen Sie Lighthouse aus, um Verbesserungsmöglichkeiten im Einklang mit den PRPL-Methoden zu identifizieren:
- Drücken Sie Strg + Umschalttaste + J (oder Befehlstaste + Optionstaste + J auf einem Mac), um die Entwicklertools zu öffnen.
- Klicken Sie auf den Tab Lighthouse.
- Klicken Sie die Kästchen Leistung und Progressive Web-App an.
- Klicken Sie auf Audits ausführen, um einen Bericht zu erstellen.
Weitere Informationen finden Sie unter Mit Lighthouse Leistungspotenziale erkennen.
Wichtige Ressourcen vorab laden
Lighthouse zeigt die folgende fehlgeschlagene Prüfung an, wenn eine bestimmte Ressource spät geparst und abgerufen wird:
Preload ist eine deklarative Abrufanfrage, die den Browser auffordert, eine Ressource anzufordern, die sonst vom Preload-Scanner des Browsers nicht gefunden werden kann, z. B. ein Bild, auf das in der background-image-Property verwiesen wird. Laden Sie spät entdeckte Ressourcen vorab, indem Sie ein <link>-Tag mit rel="preload" in die Kopfzeile Ihres HTML-Dokuments einfügen:
<link rel="preload" as="image" href="hero-image.jpg">
Wenn Sie eine <link rel="preload">-Anweisung hinzufügen, wird eine Anfrage für diese Ressource gestartet und im Cache gespeichert. Der Browser kann sie dann bei Bedarf abrufen.
Weitere Informationen zum Vorladen wichtiger Ressourcen finden Sie im Leitfaden Wichtige Assets vorab laden.
Erste Route so schnell wie möglich rendern
Lighthouse gibt eine Warnung aus, wenn es Ressourcen gibt, die den First Paint verzögern, also den Moment, in dem Ihre Website Pixel auf dem Bildschirm darstellt:
Um den First Paint zu verbessern, empfiehlt Lighthouse, kritisches JavaScript einzubetten und den Rest mit async zu verschieben. Außerdem sollte kritisches CSS, das im sichtbaren Bereich verwendet wird, inline eingefügt werden. Dadurch wird die Leistung verbessert, da keine zusätzlichen Zugriffe auf den Server erforderlich sind, um renderblockierende Assets abzurufen.
Inline-Code ist jedoch aus Entwicklungssicht schwieriger zu pflegen und kann nicht separat vom Browser im Cache gespeichert werden.
Eine weitere Möglichkeit, den First Paint zu verbessern, besteht darin, das ursprüngliche HTML Ihrer Seite serverseitig zu rendern. So werden dem Nutzer Inhalte sofort angezeigt, während Scripts noch abgerufen, geparst und ausgeführt werden. Allerdings kann dadurch die Nutzlast der HTML-Datei erheblich erhöht werden, was sich negativ auf Time to Interactive auswirken kann. Außerdem kann die Zeit, die Ihre Anwendung benötigt, um interaktiv zu werden und auf Nutzereingaben reagieren, beeinträchtigt werden.
Es gibt keine einzige richtige Lösung, um die First Paint-Zeit in Ihrer Anwendung zu reduzieren. Sie sollten das Einbetten von Stilen und das serverseitige Rendering nur in Betracht ziehen, wenn die Vorteile die Nachteile für Ihre Anwendung überwiegen. In den folgenden Ressourcen finden Sie weitere Informationen zu diesen beiden Konzepten.
Assets vorab im Cache speichern
Da Dienstworker als Proxy fungieren, können sie bei wiederholten Besuchen Assets direkt aus dem Cache statt vom Server abrufen. So können Nutzer Ihre App nicht nur offline verwenden, sondern auch bei wiederholten Besuchen schneller auf Seiten zugreifen.
Sie können eine Bibliothek eines Drittanbieters verwenden, um das Generieren eines Service Workers zu vereinfachen, es sei denn, Sie haben komplexere Caching-Anforderungen als eine Bibliothek. Workbox bietet beispielsweise eine Reihe von Tools, mit denen Sie einen Service Worker zum Caching von Assets erstellen und verwalten können. Weitere Informationen zu Dienstmitarbeitern und Offlinezuverlässigkeit finden Sie im Leitfaden zu Dienstmitarbeitern im Lernpfad zur Zuverlässigkeit.
Lazy Loading
Lighthouse zeigt eine fehlgeschlagene Prüfung an, wenn Sie zu viele Daten über das Netzwerk senden.
Das gilt für alle Asset-Typen, aber große JavaScript-Nutzlasten sind besonders kostspielig, da der Browser viel Zeit für das Parsen und Kompilieren benötigt. In Lighthouse wird bei Bedarf auch eine Warnung angezeigt.
Wenn Sie eine kleinere JavaScript-Nutzlast senden möchten, die nur den Code enthält, der beim ersten Laden Ihrer Anwendung benötigt wird, teilen Sie das gesamte Bundle und laden Sie die einzelnen Teile bei Bedarf.
Nachdem Sie das Bundle aufgeteilt haben, laden Sie die wichtigsten Teile vorab. Weitere Informationen dazu finden Sie unter Wichtige Assets vorab laden. Durch das Vorabladen werden wichtigere Ressourcen früher vom Browser abgerufen und heruntergeladen.
Neben dem Aufteilen und Laden verschiedener JavaScript-Chunks auf Anfrage bietet Lighthouse auch eine Prüfung für das Lazy-Loading nicht kritischer Bilder.
Wenn Sie viele Bilder auf Ihrer Webseite laden, sollten Sie alle Bilder, die sich „below the fold“ oder außerhalb des Darstellungsbereichs des Geräts befinden, beim Laden der Seite verschieben (siehe Lazysizes zum Lazy-Loaden von Bildern verwenden).
Nächste Schritte
Nachdem Sie nun einige der grundlegenden Konzepte des PRPL-Musters kennen, können Sie mit dem nächsten Leitfaden in diesem Abschnitt fortfahren, um mehr zu erfahren. Denken Sie daran, dass nicht alle Techniken gleichzeitig angewendet werden müssen. Mit den folgenden Maßnahmen lassen sich deutliche Leistungsverbesserungen erzielen.
- Wichtige Ressourcen vorab laden
- Rendern Sie die ursprüngliche Route so schnell wie möglich.
- Verbleibende Assets im Cache speichern.
- Lazy load andere Routes und nicht kritische Assets.
Hier finden Sie weitere Informationen zu PRPL-Mustern.