Webleistung, Behalten des Leuchtturmwerts 100 bei.

Die Qualität des Erlebnisses von Websites ist entscheidend, um die Geschäftsziele Ihrer Website und die Zufriedenheit Ihrer Besucherinnen und Besucher zu erreichen.

Adobe Experience Manager (AEM) wurde optimiert, um hervorragende Erlebnisse und eine optimale Webleistung zu liefern. Mit dem Überwachung der tatsächlichen Verwendung (RUM) betriebliche Datenerfassung, werden Informationen kontinuierlich aus der Feldverwendung erfasst und bieten eine Möglichkeit, Messungen der tatsächlichen Nutzungsleistung zu durchlaufen, ohne auf die CRuX-Daten warten zu müssen, um Auswirkungen von Code- und Bereitstellungsänderungen anzuzeigen. Es ist üblich, dass in RUM erfasste Felddaten von den Laborergebnissen abweichen, da Netzwerk, Geolokation und Verarbeitungsleistung für echte Geräte viel vielfältiger sind als die simulierten Bedingungen in einem Labor.

Die Google PageSpeed Insight-Dienst ist nachweislich ein großartiges Labormesswerkzeug. Sie kann verwendet werden, um die langsame Verschlechterung des Leistungs- und Erlebniswerts Ihrer Website zu vermeiden.

Wenn Sie Ihr Projekt mit der Vorlage wie im Abschnitt Entwickler-Tutorial, erhalten Sie einen sehr stabilen Lighthouse-Wert auf PageSpeed Insight für sowohl Mobile als auch Desktop unter 100. Bei jeder Komponente des Leuchtturmwerts gibt es einen Puffer, den der Projektcode verbrauchen kann und sich dennoch innerhalb der Grenzen eines perfekten 100 Leuchtturm.

Testen von Pull-Anforderungen

Es stellt sich heraus, dass es schwierig ist, den Lighthouse-Wert nach dem Tiefststand zu verbessern, aber es ist nicht schwer, ihn bei 100 wenn Sie kontinuierlich testen.

Wenn Sie eine Pull-Anforderung (PA) für ein Projekt öffnen, werden die Test-URLs in der Beschreibung Ihres Projekts verwendet, um den PageSpeed Insights-Dienst für auszuführen. Der AEM GitHub-Bot schlägt automatisch Ihren PR-Wert fehl, wenn der Wert unter 100 mit ein wenig Puffer, um eine gewisse Volatilität der Ergebnisse zu berücksichtigen.

Die Ergebnisse beziehen sich auf das mobile Leuchtturm-Ergebnis, da es im Vergleich zum Desktop schwieriger ist, diese zu erreichen.

Warum Google PageSpeed Insights?

Viele Teams und Einzelpersonen verwenden ihre eigenen Konfigurationen zur Messung von Lighthouse-Werten. Verschiedene Teams haben ihre eigenen Testfunktionen entwickelt und ihre eigenen Testwerkzeuge mit Konfigurationen verwendet, die im Rahmen ihrer kontinuierlichen Überwachungs- und Leistungsberichtspraktiken eingerichtet wurden.

Die Leistung einer Website wirkt sich auf ihren Rang in den Suchergebnissen aus, was sich in den Core Web Vitals im crUX-Bericht widerspiegelt. Google verfügt über einen großen Griff auf die relevanten durchschnittlichen Kombinationen von Geräteinformationen (z. B. Bildschirmgröße) sowie die Netzwerkleistung dieser Geräte. Aber am Ende ist SEO der ultimative Vermittler dessen, was gute oder schlechte Web-Performance ist. Da es sich bei der spezifischen Konfiguration um ein sich bewegendes Ziel handelt, sollten die Leistungspraktiken global an die aktuellen durchschnittlichen Geräte und Netzwerkmerkmale angepasst werden.

Anstatt also eine projektspezifische Konfiguration für Lighthouse-Tests zu verwenden, verwenden wir die kontinuierlich aktualisierten Konfigurationen, die als Teil der Mobil- und Desktop-Strategien angesehen werden, auf die in den neuesten Versionen von Google verwiesen wird PageSpeed Insights-API.

Auch wenn es zusätzliche Einblicke geben kann, die einige Entwickler aus anderen Methoden zur Messung von Lighthouse-Werten ziehen, um eine aussagekräftige und vergleichbare Leistungsgespräche über Projekte hinweg führen zu können, muss es eine Möglichkeit geben, die Leistung universell zu messen. Der standardmäßige PageSpeed Insight-Dienst ist der autoritativste und am weitesten verbreitete Labortest zur Leistungsmessung.

Beachten Sie jedoch, dass die Empfehlungen, die Sie von PageSpeed Insights erhalten, nicht unbedingt zu besseren Ergebnissen führen, insbesondere wenn Sie näher an einen Leuchtturm von 100.

Die von der integrierten RUM-Datenerfassung erfassten Core Web Vitals (CWV) spielen bei der Validierung der Ergebnisse eine wichtige Rolle. Bei geringfügigen Änderungen ist es jedoch aufgrund der Abweichungen der Ergebnisse und des Fehlens ausreichender Datenpunkte (Traffic) über einen kurzen Zeitraum unmöglich, in den meisten Fällen statistisch relevante Ergebnisse zu erhalten.

Dreistufige Ladevorgänge (E-L-D)

Wenn Sie die Payload auf einer Webseite in drei Phasen unterteilen, ist es relativ einfach, einen sauberen Leuchtturm zu erzielen und somit eine Grundlage für ein großartiges Kundenerlebnis zu schaffen.

Der dreistufige Ladeansatz unterteilt die Payload und Ausführung der Seite in drei Phasen

Phase E: Einsatz

Im eager Phase, alles, was geladen werden muss, damit die true LCP angezeigt werden, wird geladen. In einem Projekt besteht dies normalerweise aus dem Markup, den CSS-Stilen und JavaScript-Dateien.

In vielen Fällen LCP -Element in einem Block enthalten ist (der häufig durch die automatische Blockierung erstellt wird), wobei der Block .js und .css auch geladen werden.

Die Blocklader blendet Abschnitte progressiv aus, was bedeutet, dass alle Blöcke des ersten Abschnitts für die LCP angezeigt werden. Aus diesem Grund kann es sinnvoll sein, einen kleineren Abschnitt zu verwenden, der so wenig wie nötig am Anfang einer Seite enthält.

Es ist eine gute Faustregel, die aggregierte Payload vor der LCP wird unter 100 KB angezeigt, was normalerweise zu einer LCP Ereignis schneller als 1560 ms (LCP Bewertung bei 100 PSI). Insbesondere auf Mobilgeräten ist das Netzwerk tendenziell von der Bandbreite abhängig, sodass die Ladesequenz vor LCP hat minimale bis keine Auswirkungen.

Laden von oder Verbinden mit einer zweiten Herkunft vor der LCP ist dringend davon abgeraten, eine zweite Verbindung herzustellen (TLS, DNS usw.) erhöht die LCP.

Phase L: Lazy

Im faul -Phase wird der Teil der Payload geladen, der sich nicht auf die gesamte Blockierungszeit auswirkt (TBT) und schließlich die erste Eingangsverzögerung (FID).

Dazu gehören beispielsweise das Laden von Bausteinen (JavaScript und CSS) sowie das Laden aller verbleibenden Bilder entsprechend ihrer loading="lazy" -Attribut und anderen JavaScript-Bibliotheken, die nicht blockieren. Die "Lazy"-Phase ist im Allgemeinen alles, was in den verschiedenen blocks Sie erstellen , um die Projektanforderungen abzudecken.

In dieser Phase wäre es nach wie vor ratsam, dass der Großteil der Payload aus demselben Ursprung stammt und von der Erstanbieter kontrolliert wird, sodass bei Bedarf Änderungen vorgenommen werden können, um negative Auswirkungen auf TBT, TTI und FID.

Phase D: Verzögert

Im Verzögerung -Phase werden die Teile der Payload geladen, die keine unmittelbaren Auswirkungen auf das Erlebnis haben und/oder nicht vom Projekt kontrolliert werden und von Dritten stammen. Denken Sie an Marketing-Tools, Einverständnisverwaltung, erweiterte Analysen, Chat-/Interaktionsmodule usw. die häufig über Tag-Management-Lösungen bereitgestellt werden.

Es ist wichtig zu verstehen, dass der Beginn dieser Phase erheblich verzögert werden muss, damit die Auswirkungen auf das Kundenerlebnis insgesamt minimiert werden. Die verzögerte Phase sollte mindestens drei Sekunden nach dem LCP-Ereignis betragen, damit genügend Zeit bleibt, um den Rest des Erlebnisses abzuwickeln.

Die verzögerte Phase wird normalerweise in delayed.js , der als erster Auffangbehälter für Skripte dient, die TBT. Idealerweise sollte die TBT -Probleme werden aus den betreffenden Skripten entfernt, indem sie entweder außerhalb des Haupt-Threads (in einem Webworker) geladen werden oder indem die tatsächliche Sperrzeit einfach aus dem Code entfernt wird. Sobald die Probleme behoben sind, können diese Bibliotheken einfach zur Lazy-Phase hinzugefügt und früher geladen werden.

Idealerweise gibt es keine Blockierungszeit in Ihren Skripten, was manchmal schwer zu erreichen ist, da häufig verwendete Technologien wie Tag-Manager oder Build-Tools große JavaScript-Dateien erstellen, die blockieren, während der Browser sie analysiert. Aus Leistungssicht ist es ratsam, diese Techniken zu entfernen, sicherzustellen, dass Ihre einzelnen Skripte nicht blockieren und sie einzeln als separate kleinere Dateien laden.

Kopf- und Fußzeile

Die Kopfzeile und insbesondere die Fußzeile der Seite befinden sich nicht im kritischen Pfad zum LCP, weshalb sie asynchron in ihren jeweiligen Blöcken geladen werden. Im Allgemeinen sollten Ressourcen, die nicht denselben Lebenszyklus aufweisen (d. h. sie werden zu unterschiedlichen Zeitpunkten mit Bearbeitungsänderungen aktualisiert) in separaten Dokumenten aufbewahrt werden, um die Zwischenspeicherungskette zwischen dem Ursprung und dem Browser zu vereinfachen und effizienter zu gestalten. Die Trennung dieser Ressourcen erhöht das Cache-Trefferverhältnis und verringert die Cache-Invalidierung und die Komplexität der Cacheverwaltung.

Schriften

Da Webfonts häufig eine Belastung für die Bandbreite darstellen und von einer anderen Quelle über einen Schriftartdienst wie https://fonts.adobe.com oder https://fonts.google.com, ist es größtenteils unmöglich, Schriftarten vor der LCP, weshalb sie in der Regel zum lazy-styles.css und werden nach der LCP angezeigt.

LCP-Blöcke

Es gibt Situationen, in denen die tatsächlichen LCP -Element nicht im Markup enthalten ist, das an den Client übertragen wird. Dies geschieht, wenn eine Indirektion oder Suche erfolgt (z. B. ein Dienst, der aufgerufen wird, ein Fragment, das geladen wird, oder eine Suche, die in einem .json) für die LCP -Element.
In diesen Situationen ist es wichtig, dass das Laden der Seite mit dem Prädikat LCP Kandidaten (derzeit das erste Bild auf der Seite), bis der erste Block die erforderlichen Änderungen am DOM vorgenommen hat.
So identifizieren Sie, auf welche Blöcke gewartet wird, bevor sie auf die LCP laden, können Sie die Blöcke hinzufügen, die die LCP -Element zu LCP_BLOCKS Array in scripts.js.

Bonus: Geschwindigkeit ist grün

Der Aufbau von schnell, klein und schnell gerenderten Websites ist nicht nur eine gute Idee, außergewöhnliche Erlebnisse bereitzustellen, die eine bessere Konversion ermöglichen, sondern auch eine gute Möglichkeit, die CO2-Emissionen zu reduzieren.