PRPL ist ein Akronym, das ein Muster beschreibt, mit dem Webseiten schneller geladen und interaktiv werden:
- Laden Sie die spät erkannten Ressourcen vorab.
- Rendern Sie die ursprüngliche Route so schnell wie möglich.
- Speichere die verbleibenden Assets vorab.
- Andere Routen und nicht kritische Assets per Lazy Loading laden
In diesem Leitfaden erfahren Sie, wie die einzelnen Methoden 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 zu ermitteln, die auf die PRPL-Techniken abgestimmt sind:
- Drücken Sie Strg + Umschalttaste + J (oder Befehlstaste + Option + J auf dem 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 Leistungsmöglichkeiten ermitteln.
Kritische Ressourcen vorab laden
Lighthouse zeigt die folgende fehlgeschlagene Prüfung an, wenn eine bestimmte Ressource geparst und spät abgerufen wird:
Vorabladen ist eine deklarative Abrufanfrage, die den Browser anfordert, eine Ressource anzufordern, die vom Preload-Scanner des Browsers nicht erkannt wird, zum Beispiel ein Bild, auf das vom Attribut background-image verwiesen wird. Wenn Sie spät erkannte Ressourcen vorab laden möchten, fügen Sie in den Header des HTML-Dokuments das <link>-Tag mit rel="preload" ein:
<link rel="preload" as="image" href="hero-image.jpg">
Durch das Hinzufügen einer <link rel="preload">-Anweisung wird eine Anfrage für diese Ressource initiiert und im Cache gespeichert. Der Browser kann sie dann bei Bedarf abrufen.
Weitere Informationen zum Vorabladen kritischer Ressourcen finden Sie unter Kritische Assets vorab laden.
Ursprüngliche Route so schnell wie möglich rendern
Lighthouse gibt eine Warnung aus, wenn Ressourcen First Paint verzögern, also den Moment, in dem Ihre Website Pixel auf dem Bildschirm rendert:
Zur Verbesserung von First Paint empfiehlt Lighthouse, wichtiges JavaScript inline einzubinden, den Rest mithilfe von async aufzuschieben und wichtige CSS-Elemente, die „above the fold“ verwendet werden, „above the fold“ zu platzieren. Dies verbessert die Leistung, da Umlaufanfragen zum Server vermieden werden, um Assets abzurufen, die das Rendering blockieren.
Inline-Code ist jedoch aus Entwicklungssicht schwieriger zu verwalten und kann nicht separat vom Browser im Cache gespeichert werden.
Ein weiterer Ansatz zur Verbesserung von First Paint besteht im serverseitigen Rendering des ersten HTML-Codes Ihrer Seite. Dadurch werden dem Nutzer Inhalte sofort angezeigt, während die Skripts noch abgerufen, geparst und ausgeführt werden. Dies kann jedoch die Nutzlast der HTML-Datei erheblich erhöhen, was die Zeit bis Interaktivität beeinträchtigen kann oder dazu führen kann, dass die Anwendung interaktiv wird und auf Nutzereingaben reagieren kann.
Es gibt nicht nur eine richtige Lösung für die Reduzierung von First Paint in Ihrer Anwendung. Sie sollten Stile und serverseitiges Rendering nur dann Inline-Styles und serverseitiges Rendering in Betracht ziehen, wenn die Vorteile die Vor- und Nachteile für Ihre Anwendung überwiegen. Weitere Informationen zu diesen beiden Konzepten finden Sie in den folgenden Ressourcen.
Assets vorab im Cache speichern
Als Proxy können Service Worker Assets bei wiederholten Besuchen direkt aus dem Cache und nicht vom Server abrufen. So können Nutzer Ihre Anwendung nicht nur offline verwenden, sondern auch die Seitenladezeiten bei wiederholten Besuchen verkürzen.
Verwenden Sie eine Bibliothek eines Drittanbieters, um das Generieren eines Service Workers zu vereinfachen, es sei denn, Sie haben komplexere Caching-Anforderungen, als eine Bibliothek bereitstellen kann. Workbox bietet beispielsweise eine Reihe von Tools, mit denen Sie einen Service Worker erstellen und verwalten können, um Assets im Cache zu speichern. Weitere Informationen zu Service Workern und Offlinezuverlässigkeit finden Sie im Service Worker-Leitfaden im Lernpfad zur Zuverlässigkeit.
Lazy Load
Lighthouse zeigt eine fehlgeschlagene Prüfung an, wenn zu viele Daten über das Netzwerk gesendet werden.
Dazu gehören alle Asset-Typen. Große JavaScript-Nutzlasten sind jedoch besonders kostspielig, da der Browser viel Zeit zum Parsen und Kompilieren benötigt. In Lighthouse wird gegebenenfalls auch eine Warnung ausgegeben.
Wenn Sie eine kleinere JavaScript-Nutzlast senden möchten, die nur den Code enthält, der beim ersten Laden Ihrer Anwendung durch einen Nutzer erforderlich ist, müssen Sie das gesamte Bundle und Lazy-Load-Chunks nach Bedarf aufteilen.
Nachdem Sie das Bundle aufgeteilt haben, laden Sie die wichtigeren Blöcke vorab. Weitere Informationen finden Sie unter Wichtige Assets vorab laden. Durch das Vorabladen werden wichtigere Ressourcen vom Browser schneller abgerufen und heruntergeladen.
Neben dem Aufteilen und Laden verschiedener JavaScript-Chunks bei Bedarf bietet Lighthouse auch eine Prüfung für das Lazy Loading von nicht kritischen Bildern.
Wenn Sie viele Bilder auf Ihrer Webseite laden, verschieben Sie beim Laden einer Seite alle Elemente, die sich „below the fold“ (mit Scrollen sichtbar) oder außerhalb des Darstellungsbereichs des Geräts befinden. Weitere Informationen finden Sie unter Lazysizes zum Lazyload von Bildern verwenden.
Nächste Schritte
Sie kennen nun einige der grundlegenden Konzepte hinter dem PRPL-Muster. Fahren Sie nun mit der nächsten Anleitung in diesem Abschnitt fort, um weitere Informationen zu erhalten. Beachten Sie, dass nicht alle Techniken zusammen angewendet werden müssen. Wenn Sie eines der folgenden Ziele umsetzen, wird die Leistung spürbar verbessert.
- Kritische Ressourcen vorab laden
- Rendern Sie die ursprüngliche Route so schnell wie möglich.
- Speichere die verbleibenden Assets vorab.
- Andere Routen und nicht kritische Assets per Lazy Loading laden
Hier findest du weitere Informationen zu PRPL-Mustern.