PRPL ist ein Akronym, das ein Muster beschreibt, mit dem Webseiten geladen und schneller interaktiv werden:
- Laden Sie die spät entdeckten Ressourcen vorab.
- Rendern Sie die ursprüngliche Route so schnell wie möglich.
- Verbleibende Assets im Cache speichern.
- Lazy Loading für andere Routen und nicht kritische Assets
In diesem Leitfaden erfahren Sie, wie die einzelnen Techniken zusammenpassen, aber dennoch unabhängig voneinander eingesetzt werden, um Leistungsergebnisse zu erzielen.
Seite mit Lighthouse prüfen
Lighthouse ausführen, um Verbesserungsmöglichkeiten in Übereinstimmung mit der PRPL zu ermitteln Techniken:
- Drücken Sie „Strg + Umschalttaste + J“ (oder „Befehlstaste + Option + 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 generieren.
Kritische Ressourcen vorab laden
Lighthouse zeigt die folgende fehlgeschlagene Prüfung an, wenn eine bestimmte Ressource geparst und spät abgerufen:
Vorab laden
ist eine deklarative Abrufanfrage, die den Browser anweist, eine Ressource anzufordern, die ansonsten vom Preload Scanner des Browsers nicht sichtbar ist, z. B. ein Bild, auf das von der background-image-Eigenschaft 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 initiiert und im Cache gespeichert. Der Browser kann sie dann bei Bedarf abrufen.
Weitere Informationen zum Vorabladen wichtiger Ressourcen finden Sie in der Leitfaden zum Vorabladen wichtiger Assets
<ph type="x-smartling-placeholder">Erste Route so schnell wie möglich rendern
Lighthouse gibt eine Warnung aus, wenn es Ressourcen gibt, die First Paint verzögern. der Moment, in dem Ihre Website Pixel auf dem Bildschirm rendert:
Zur Verbesserung von First Paint empfiehlt Lighthouse das Einfügen kritischer JavaScript- und
und der Rest mit der Funktion
async,
und wichtige CSS-Elemente „above the fold“ einfügen. Dadurch wird die Leistung verbessert.
da Roundtrips an den Server vermieden werden, um Assets abzurufen, die das Rendering blockieren.
Die Pflege von Inline-Code ist jedoch aus Entwicklungsperspektive schwieriger.
kann vom Browser nicht separat im Cache gespeichert werden.
Ein weiterer Ansatz zur Verbesserung von First Paint besteht darin, den ersten Paint serverseitig zu rendern. HTML-Code Ihrer Seite. Inhalte werden dem Nutzer während der Skripterstellung sofort angezeigt. abgerufen, geparst und ausgeführt werden. Dadurch kann jedoch die Anzahl der der HTML-Datei erheblich beeinträchtigt, was Time to Interactive, oder wie lange es dauert, bis Ihre Anwendung interaktiv wird auf Nutzereingaben.
Es gibt nicht nur eine richtige Lösung, um den First Paint und Sie sollten nur Stile und serverseitige wenn die Vorteile die Vor- und Nachteile der Anwendung überwiegen. Sie können finden Sie in den folgenden Ressourcen weitere Informationen zu diesen beiden Konzepten.
Assets vorab im Cache speichern
Durch die Rolle eines Proxy können Service Worker Assets direkt aus dem Cache abrufen. statt auf den Server bei wiederholten Besuchen. So können Nutzer nicht nur Ihre wenn sie offline sind. Außerdem führt dies zu kürzeren Seitenladezeiten auf wiederholte Besuche.
Bibliothek eines Drittanbieters verwenden, um das Generieren eines Service Workers zu vereinfachen es sei denn, Sie haben komplexere Caching-Anforderungen als eine Bibliothek bereitstellen. Beispiel: Workbox bietet eine Sammlung von Tools, mit denen Sie einen Service Worker erstellen und verwalten können, Assets im Cache speichern. Weitere Informationen zu Service Workern und zur Offlinezuverlässigkeit Weitere Informationen finden Sie im Service Worker Guide des Lernpfads zur Zuverlässigkeit.
Lazy Loading
Wenn Sie zu viele Daten über das Netzwerk senden, zeigt Lighthouse eine fehlgeschlagene Prüfung an.
Dies schließt alle Asset-Typen ein. Große JavaScript-Nutzlasten sind jedoch besonders aufgrund der Zeit, die der Browser zum Parsen und Kompilieren benötigt. In diesem Fall gibt Lighthouse gegebenenfalls auch eine Warnung aus.
Um eine kleinere JavaScript-Nutzlast zu senden, die nur den Code enthält, der erforderlich ist, wenn ein Nutzer zuerst Ihre Anwendung lädt, teilen Sie das gesamte Bundle und Lazy Loading-Blöcke nach Bedarf auf.
Nachdem Sie Ihr Bundle aufgeteilt haben, laden Sie vorab die Blöcke, die mehr (siehe Leitfaden zum Vorabladen wichtiger Assets). Durch Vorabladen werden wichtige Ressourcen schneller abgerufen und heruntergeladen durch den Browser.
Neben dem Aufteilen und Laden verschiedener JavaScript-Blöcke bei Bedarf Lighthouse bietet auch eine Prüfung für Lazy Loading von nicht kritischen Bildern.
Wenn Sie viele Bilder auf Ihrer Webseite laden, verschieben Sie alle Bilder, die „below the fold“ (mit Scrollen sichtbar) sind, oder außerhalb des Darstellungsbereichs des Geräts, wenn eine Seite geladen wird. Weitere Informationen finden Sie unter Lazysize für das Lazy Loading von Bildern verwenden.
Nächste Schritte
Jetzt, da Sie einige der grundlegenden Konzepte des PRPL-Musters kennen, Weitere Informationen finden Sie im nächsten Leitfaden in diesem Abschnitt. Denken Sie daran, dass nicht alle Techniken angewendet. Alle Bemühungen, die mit einem der folgenden Punkte durchgeführt werden, spürbare Leistungsverbesserungen.
- Kritische Ressourcen vorab laden.
- Rendern Sie die ursprüngliche Route so schnell wie möglich.
- Verbleibende Assets im Cache speichern.
- Lazy Loading für andere Routen und nicht kritische Assets
Hier finden Sie weitere Informationen zu PRPL-Mustern.