Schnellere Websites leicht gemacht: Neue Technologien und Werkzeuge für Entwickler

Kürzlich hielt ich auf dem Pilsner Meetup unserer Community Frontendisti.cz einen Vortrag mit zehn Tipps zu den neuesten Entwicklungen in Sachen Webgeschwindigkeit, maßgeschneidert für Entwickler.

Lassen Sie uns diese frischen, noch warmen Technologien und Werkzeuge auch in schriftlicher Form durchgehen. Entwicklerinnen und Entwickler können den folgenden Text als Wegweiser nutzen, um zu lernen, was sie in den Sommerferien studieren sollten, damit sie ab September schnellere Websites erstellen können.

Ich werde es nicht unnötig in die Länge ziehen, also kommen wir direkt zu den Tipps.

1) WebP, AVIF, die noch wenig genutzten Bildersparer#

Vereinfacht gesagt, haben traditionelle Bildformate ihre primären Anwendungsbereiche:

• Gif dient für Animationen
• JPEG beherrscht verlustbehaftete Kompression
• PNG kann Halbdurchsichtigkeit
• SVG ist das einzige Format, das Vektoren unterstützt

Die neuen Bildformate WebP und AVIF bieten sowohl verlustbehaftete als auch verlustfreie Kompression, Animationen und Halbdurchsichtigkeit. Beide sind jedoch deutlich datenärmer.

SVG wird weiterhin für Vektoren benötigt, aber alle anderen älteren Formate werden von den neuen in den Schatten gestellt.

Sie verwenden WebP oder AVIF noch nicht? Das sollten Sie:

• WebP hat praktisch volle Unterstützung in allen modernen Browsern.
• Beim AVIF-Format warten wir auf Microsoft und seinen Edge-Browser. Dank des picture-Elements müssen wir jedoch nicht allzu lange warten.

Bilder auf Websites sollten Sie immer im WebP Format bereitstellen und, wenn möglich, auch AVIF in Betracht ziehen.

2) Priority Hints, beschleunigen Sie LCP im Handumdrehen#

Priority Hints sind das Gewürz für die Optimierung der Metrik LCP (Largest Contentful Paint).

Preload kann manchmal sehr nützlich sein, um die Ladepriorität eines bestimmten Elements, wie zum Beispiel Schriften, zu erhöhen:

<link rel="preload" href="font-1.woff2" as="font" type="font/woff2" crossorigin />

Das neue fetchpriority-Attribut ermöglicht es, eine höhere Priorität für das Laden eines HTML-Elements festzulegen. Aber auch, die Priorität zu senken.

Nehmen wir zum Beispiel zwei Bilder in einem Karussell. Ich erhöhe die Priorität des ersten und senke die des zweiten. Dadurch lädt und zeigt das erste Bild deutlich schneller an und verbessert meine LCP-Metrik:

<img fetchpriority="high" src="image-1.webp" /> <img fetchpriority="low" src="image-2.webp" />

Sehr interessant ist die Möglichkeit, die Priorität des Downloads einer Datei mittels Fetch in JS zu senken:

<script>
  fetch('https://example.com/', { priority: 'low' }).then((data) => {
    // Starten Sie den Fetch mit höherer Priorität
  });
</script>

Im Vortrag (siehe oben) erwähne ich die Möglichkeit, die Fetch-Priorität zu erhöhen, aber das ist Unsinn. Im Falle der Prioritätszuweisung zu einem Fetch kann diese nur gesenkt werden. Die höhere Priorität ist ihr Standardzustand.

Preload wird von allen Browsern unterstützt, fetchpriority bisher nur von denen mit Chromium-Kern, aber Safari plant dies ebenfalls.

Das Fehlen der Unterstützung in Firefox (und derzeit auch in Safari) muss nicht allzu sehr stören. Betrachten wir es aus der Perspektive der progressiven Verbesserung – einige Benutzer profitieren von einer schnelleren Ladezeit, aber fehlende Unterstützung bei anderen bricht nichts.

Vorsicht, mit Gewürzen sollte man sparsam umgehen. Nutzen Sie die Änderung der Priorisierung nur, wenn Sie wirklich wissen, was Sie tun, und die Auswirkungen direkt im Browser messen können.

3) aspect-ratio, alles Asynchrone muss ein Seitenverhältnis haben#

Dieses Bild ist hübsch, aber traurig:

<img src="image.webp" alt="Image" />

Wissen Sie warum? Der Browser muss den darunter liegenden Inhalt wahrscheinlich neu rendern, nachdem das Bild geladen wurde. So ist es besser:

<img src="image.webp" width="500" height="500" alt="Image" />

Bildern sollten Sie immer width- und height-Attribute definieren. Diese dienen dazu, den reservierten Raum festzulegen. Auf diese Weise tritt kein Layout-Shift auf und die Metrik CLS (Cumulative Layout Shift) wird nicht verschlechtert.

Sie haben kein Bild, sondern vielleicht eine JavaScript-Komponente? Verwenden Sie dann aspect-ratio:

<p style="aspect-ratio: 4/3"></p>

Die CSS-Eigenschaft aspect-ratio legt das Seitenverhältnis für Elemente fest, die keine Bilder sind. Sie beseitigt die Notwendigkeit, den „Padding-Trick“ zu verwenden.

Die Unterstützung ist in allen modernen Browsern vollständig, siehe width/height und aspect-ratio. Verwenden Sie dies für alle asynchronen Elemente, einschließlich Werbung.

4) size-adjust, verhindern Sie Layout-Sprünge durch Schriftarten#

Das Problem können Sie auf dem folgenden Bild einer Optimierung bei unserem Kunden Sazka.cz sehen:

Ein häufiges Problem im Bereich des Layout-Shifts, das von der Metrik CLS gemessen wird, ist die unterschiedliche Größe von System- und benutzerdefinierten Schriftarten.

Das size-adjust-Attribut löst dieses Problem:

@font-face {
  font-family: 'Montserrat-fallback';
  size-adjust: 113.56999999999995%;
  src: local('Arial Bold'), local('Arial');
}

Dieser Eintrag passt die Größe des Systemfonts an den benutzerdefinierten Font an und minimiert Layout-Verschiebungen und somit die Verschlechterung von CLS aufgrund benutzerdefinierter Fonts.

Unterstützt wird das von allen Browsern mit Ausnahme von Safari. Aber auch hier ist das nicht weiter schlimm.

5) BFcache, oder wie Chrome endlich aufgewacht ist#

BFcache steht für „back & forward cache“. Es handelt sich um einen Cache im Browser, der Seiten speichert, die im Browser-Verlauf durchgeblättert wurden. Nichts Neues, aber Sie könnten überrascht sein, dass Chrome diese Funktion erst jetzt richtig gelernt hat.

Die Beschleunigung der Website durch die Back/Forward-Cache ist auf den ersten Blick sichtbar:

BFcache richtig einzusetzen (und dabei zum Beispiel nicht das Messen oder andere Dinge zu zerstören) ist ziemlich kompliziert. Lesen Sie lieber mehr darüber, zum Beispiel auf dem oben angegebenen Link.

Wesentlich ist, dass Sie als Entwickler unter anderem die folgenden Eigenschaften nicht verwenden sollten:

• Ereignisse unload, beforeunload.
• Header Cache-Control: no-store.
• Referenzen auf window.opener.

Das Testen der BFcache-Unterstützung auf Ihren Websites ist in den DevTools von Chrome möglich. Entweder im Reiter Application oder über Lighthouse.

Die BFcache-Unterstützung ist, nachdem sich Chrome endlich bewegt hat, vollständig. Es gibt Fallstudien, die sagen, dass dies wirklich helfen kann. Bei unseren Kunden haben wir jedoch bisher keine sprunghafte Verbesserung der Geschwindigkeit festgestellt, wir betrachten BFcache eher als einen der potenziell einfachen Schritte für einen kleinen Fortschritt in Richtung besserer Geschwindigkeit. Es ist ähnlich wie bei der Implementierung von Brotli-Kompression.

6) Prerender, die neue Version des Seiten-Preloads#

Mit Prerender-Anweisungen können Sie während des Besuchs eines Benutzers auf einer Seite angeben, dass Sie eine andere Seite herunterladen und zur Anzeige vorbereiten möchten.

Dies ist besonders nützlich bei geradlinigen Navigationen wie dem Durchlaufen eines Kaufprozesses.

Auch das Prerendering kann einen großen Einfluss auf das Benutzererlebnis haben. Einst gab es in der Entwickler-Community einen ziemlichen „Hype“ um das Prerendering von Seiten:

<link rel="prerender" href="/next-page/" />

Diese alte Methode wird jedoch aus Chrome entfernt. Sie ist hauptsächlich aufgrund ihrer übermäßigen Einfachheit ungeeignet.

Neu wird die Prerender-Anweisung seit Chrome 108 so definiert:

<script type="speculationrules">
  {
    "prerender": [
      {
        "source": "list",
        "urls": ["next.html", "next2.html"]
      }
    ]
  }
</script>

Beachten Sie den Eintrag speculationrules. Ja, es handelt sich buchstäblich um „spekulative Regeln“. Damit drücken wir die Wahrscheinlichkeit aus, dass der Benutzer auf bestimmte Seiten weitergeht. In der nächsten Version der Implementierung in Chrome sollte auch ein numerischer Ausdruck dieser Wahrscheinlichkeit nicht fehlen.

Mit der Unterstützung können Sie derzeit wieder nur in auf Chromium basierenden Browsern rechnen. Und wir? Bei unseren Kunden warten wir noch ab, wie es sich entwickelt.

7) INP, eine völlig neue Interaktivitätsmetrik#

In meinem Vortrag sagte ich, dass die INP-Metrik (Interaction to Next Paint) die Metrik FID wahrscheinlich im Jahr 2024 ersetzen wird. Jetzt kennen wir den Termin der Änderung in den Core Web Vitals, es ist März 2024.

Die neue Metrik befasst sich erneut mit der Reaktionsgeschwindigkeit der Benutzeroberfläche auf Klicks (oder andere Eingaben) des Benutzers. Ihre Feinde sind also langsam ausgeführte „Ajax“-Anfragen oder lange Aufgaben in JS, die den Rendering-Kern blockieren.

Ich habe berechnet, dass von den 100 meistbesuchten tschechischen E-Shops nur 17 % diese Metrik erfüllen.

FID wird weltweit von 95 % der Websites erfüllt ⨉ INP nur von 66 %. Ich befürchte, dass die Entwickler-Community im nächsten Jahr ein wenig darunter leiden wird, insbesondere bei Websites, die auf JavaScript-Frameworks basieren.

Was sind die Hauptunterschiede zwischen den Metriken INP und FID?

• FID = erste Interaktion × INP = gesamte Zeit auf der Seite. Es reicht also nicht, nur auf den ersten Klick schnell zu reagieren. Es zählt der schlechteste von allen.
• FID = erster Teil der Reaktion × INP = gesamte Reaktion. FID misst nur die Zeit, bis der Klick von JavaScript verarbeitet wird. INP wartet ausdrücklich auf das Neuzeichnen der Seite in den neuen Zustand.

Die Optimierung der INP-Metrik auf Ihrer Website kann einige Zeit in Anspruch nehmen, daher empfehlen wir, sich bald mit diesem Thema zu beschäftigen. Wir zeigen INP auch neu in unserem Geschwindigkeitstester an, einschließlich deren Überwachung. Wir können Ihnen natürlich auch bei der Optimierung dieser Metrik helfen.

In den nächsten Tipps werden wir uns von Technologien und Metriken zu Werkzeugen bewegen.

8) Web Vitals overlay, ein unauffälliger, aber großartiger Helfer#

Um als Entwickler die richtigen Probleme zu beheben, müssen Sie in der Lage sein, die Metriken korrekt zu messen.

Die Web Vitals Overlay-Leiste ist für lokale Tests deutlich besser als Lighthouse. Sie zeigt die richtigen Metriken an und sie sind auch korrekt berechnet.

Man muss sich bewusst sein, dass Lighthouse ohne spezielle Einstellungen synthetisch misst und daher nicht in der Lage ist, die Metriken korrekt zu messen, die während der gesamten Zeit des Aufenthalts des Benutzers auf der Seite gesammelt werden.

Wie kommen Sie zum Web Vitals Overlay?

• Öffnen Sie die Chrome Dev Tools (F12).
• Cmd + Shift + P auf dem Mac oder Ctrl + Shift + P auf Windows.
• Beginnen Sie mit der Eingabe von „Web Vitals Overlay“.

Bei Metriken wie CLS oder neu INP erhalten Sie nicht die gleichen Zahlen, die Sie dann in den Google-Daten sehen.

Eine vernünftige Alternative zum Web Vitals Overlay ist die Web Vitals Extension.

9) Perf. Insights, ein neues Werkzeug zur Geschwindigkeitsoptimierung#

Performance Insights ist so etwas wie der Performance-Tab, aber für Menschen.

In Insights zeigt Chrome spezifische Informationen zur Optimierung einer bestimmten Metrik, zum Beispiel bei CLS:

• Konkrete unerwünschte Verschiebungen bei CLS (1).
• CLS-Score (2).
• Potenzielle Ursachen des Problems (3).

Wenn Sie Details zur Geschwindigkeitsoptimierung benötigen und der Performance-Tab für Sie zu komplex ist, ziehen Sie Performance Insights in Betracht.

10) Trace.Cafe, teilen Sie die Ergebnisse detaillierter Geschwindigkeitsmessungen#

Ein sehr kurzer Tipp zum Schluss. Trace.cafe ermöglicht es Ihnen, die Ausgabe von Trace (Performance-Tab) unter einer bestimmten URL zu teilen.

Laden Sie die Daten im JSON-Format herunter, ziehen Sie sie in Trace.cafe und teilen Sie die resultierende URL mit Kollegen. Paul Irish, der Autor dieser großartigen App, sagt, dass Ihre Trace unter der gegebenen URL drei Monate lang bestehen bleibt:

Und damit sind wir am Ende dieses kurzen Leitfadens zu den Neuigkeiten rund um Geschwindigkeit für Entwickler.

Möchten Sie weitere Tipps erhalten? Jeden Monat veröffentlichen wir einen Newsletter, aber wir veröffentlichen auch auf LinkedIn, Twitter oder Facebook.

Tags:PageSpeed.ONEWeb Performance