kulturbanause Blog

Responsive Design, WordPress, Konzeption, HTML, CSS, JS & UX/UI …

Performance-Optimierung für Websites – Fortgeschrittene Tipps zur Optimierung der Lighthouse-Werte

Die Performance-Optimierung einer Website ist zum Standard geworden. Zu einem Zeitpunkt, an dem wir neben einer besseren User Experience durch verkürzte Ladezeiten auch die Reduzierung von CO2-Emissionen im Blick haben, ist das Thema nicht mehr wegzudenken. Wir zeigen euch, wie ihr die wichtigsten Punkte angeht, die direkt am Code der Website optimiert werden können.

Workshops & Schulungen von kulturbanause

Intensive Trainings mit hohem Praxisbezug.

Online-Schulungen (remote per Video)

Inhouse-Schulungen

Vorraussetzungen

Ein guter Server, der die Website ausliefert, ist Voraussetzung, dass die aufgeführten Optimierungen auch ein spürbares Ergebnis liefern. Eine Website kann noch so gut optimiert sein, wenn der Server die Website zu langsam ausliefert, werden wir nie eine gute Performance erreichen.

Wir beziehen uns bei den aufgeführten Punkten vornehmlich auf die Informationen, die uns der Lighthouse-Performance-Test aus den Google Chrome DevTools liefert.

Neben der Erklärung, was die jeweilige Fehlermeldung bedeutet, zeigen wir in einem Code-Snippet das HTML-Markup zur Fehlerbehebung.

Standards, wie das Minifizieren, Komprimieren und Cachen von Dateien setzen wir voraus und gehen an dieser Stelle nicht weiter darauf ein.

Preload key requests

Via preload kann dem Browser mitgeteilt werden, dass eine bestimmte Ressource früher abgerufen werden soll, als der Browser sie entdecken würde. Außerdem speichert der Browser vorgeladene Ressourcen im Cache, so dass sie bei Bedarf sofort verfügbar sind. Oft betrifft das die verwendeten Fonts:

<link rel="preload" href="...fonts/LatoRegular.woff2" as="font" type="font/woff2" crossorigin="anonymous">

Ensure text remains visible during webfont load

Schriften sind oft große Dateien, die eine Weile zum Laden benötigen. Einige Browser verbergen Text, bis die Schrift geladen ist, was zum flash of invisible text (FOIT) führt.

Die einfachste Möglichkeit zu vermeiden, dass kein Text angezeigt wird, während benutzerdefinierte Schriften geladen werden, besteht darin, vorübergehend eine Systemschriftart anzuzeigen. Durch Hinzufügen der CSS-Eigenschaft font-display: swap; innerhalb von @font-face kann dies in den meisten modernen Browsern vermieden werden.

<style>
  @font-face {
    font-family: 'Lato';
    src: url('.../fonts/LatoRegular.woff2') format('woff2');
    font-style: normal;
    font-weight: normal;
    font-display: swap;
  }
</style>

Eliminate render-blocking resources

Ziel ist es, Rendering-blockierende URLs zu reduzieren, indem kritische Ressourcen eingefügt, nicht-kritische Ressourcen zurückgestellt und unbenutzte Ressourcen entfernt werden.

Critical CSS

Ein Lösungsansatz ist, Critical CSS einzusetzen. Die Idee von Critical CSS ist, das Styling aller Elemente, die beim ersten Laden einer Unterseite im sichtbaren Bereich – »Above the Fold« – liegen, zu separieren und inline im HTML-<head> zu laden.

Außerdem sollte die CSS-Datei nach Medien-Typ (Screen, Print, etc.) aufgeteilt werden, sodass ein nicht benötigter Medien-Typ vom Browser ignoriert und nicht geladen werden muss.

<!DOCTYPE html>
<html> 
  <head>
    ... 
    <style> /* critical */ </style>
  </head>
  <body>
    <link rel="stylesheet" href="/assets/css/kb-style.css" media="screen" />
    <link rel="stylesheet" href="/assets/css/kb-style-print.css" media="print" />
  </body>
</html>

JavaScript zusammenfassen und reduzieren

Häufig wird auf Websites eine Vielzahl von JavaScripten für verschiedenste Funktionen geladen. Z. B. bringt so gut wie jedes WordPress-Plugin, das die Funktionalität via JavaScript erweitert, eine oder sogar mehrere JavaScript-Dateien mit. Diese erzeugen einzelne Requests. Durch Zusammenfassen der Scripte zu einer einzelnen Datei können diese vermieden, oder durch Priorisieren und dynamisches Nachladen verzögert werden.

Seit der Verfügbarkeit von HTTP/2, womit mehrere Requests parallel vom Server verarbeitet werden können, ist das Zusammenfassen aller Scripte zu einer einzelnen großen Datei nicht unbedingt der effizienteste Ansatz. Stattdessen kann es sinnvoller sein zu prüfen, welche Scripte auf der aktuellen Unterseite benötigt werden, und nur diese zu laden. Dadurch muss effektiv eine geringere Datenmenge geladen werden. An dieser Stelle nur der kurze Hinweis, dass dadurch unter Umständen das Thema Caching erschwert wird.

JavaScript asynchron oder verzögert laden

async

Ein weiterer Lösungsansatz besteht darin, möglichst kein JavaScript im Header zu laden, sondern asynchron im Footer.

Mit dem async-Attribut im <script>-Tag lädt der Browser das Script parallel zu anderen Ressourcen und beginnt parallel mit dem Aufbau der Seite. Sobald das Script geladen ist, entsteht eine Pause, weil der Browser das Script erst interpretieren muss.

Für Third Party-Scripte ist async ein Muss. Wenn der externe Server, von dem ein Script bereitgestellt wird, langsam ist, beeinflusst das Script die Performance der eigenen Seite sehr stark negativ.

Asynchrones Laden kann allerdings auch zu Schwierigkeiten führen, da es nicht vorhersehbar ist, wann das Script tatsächlich geladen und ausführbar ist. Einzelne Funktionen müssen gegebenenfalls umgeschrieben werden und mit entsprechenden Callbacks arbeiten.

<!DOCTYPE html>
<html>
  <head>
    ...
  </head>
  <body>
    <script async src="/assets/js/kb_async-script.min.js"></script>
  </body>
</html>

defer

Das defer-Attribut im <script>-Tag verspricht dem Browser, dass die Webseite nicht durch Anweisungen wie document.write geändert wird. document.write sollte sowieso vermieden werden! Der Browser verschiebt das Laden und Ausführen des Scripts, bis alle anderen Komponenten geladen und das DOM Processing abgeschlossen ist.

<!DOCTYPE html>
<html>
  <head>
    <script defer src="/assets/js/kb_defer-script.min.js"></script>
  </head>
  <body>
    ...
  </body>
</html>

Defer offscreen images

Bilder, die nicht im Viewport – im sichtbaren Bereich der Website – liegen, müssen nicht geladen werden. Sowohl der Request als auch die Datenmenge kann initial eingespart werden. Erst, wenn sie durch Scrollen oder ein vergleichbares Event in den Viewport  kommen, müssen sie nachgeladen werden. Das wird als »Lazy Loading« bezeichnet.

Moderne Browser unterstützen Lazy Loading nativ. Über die Ergänzung  <loading="lazy"> im <img>-Tag wird dem Browser mitgeteilt, dass er mit dem Laden des jeweiligen Bildes warten soll, bis es in den Viewport kommt – oder in die Nähe des Viewports, damit das Nachladen nicht sichtbar ist und es kein »Springen« im Layout gibt – auch als Layout Shift bezeichnet. Der Cumulative Layout Shift (CLS) wird ebenfalls im Lighthouse-Test und Performance mit geprüft.

<img 
 loading="lazy" 
 width="750" 
 height="750" 
 alt="" 
 src="/assets/img/img-750.webp"
>

Serve images in next-gen formats

Bilder sollten in einem web-optimierten Format, etwa WebP oder AVIF, ausgespielt werden. Diese neueren Formate bieten den Vorteil einer wesentlich stärkeren Komprimierung bei geringerem Qualitätsverlust. In WordPress kann dies relativ einfach und zuverlässig mit einem Plugin wie EWWW Image Optimizer automatisiert werden. Hier könnt ihr nachlesen, wie und in welchen Programmen WebP-Grafiken exportiert werden können.

Properly size images

Bilder sollten möglichst genau in der Größe ausgespielt werden, in der sie auch angezeigt werden. Bei einem Bildschirm mit einer Auflösung von 1920px mal 1080px und einem DPR-Wert von 1 (kein Retina, o. Ä.) brauchen Bilder, die in einer effektiven Größe von 320px mal 320px angezeigt werden, auch nur genau in dieser Größe geladen zu werden.

Um gleichzeitig Bilder für Geräte mit einem höheren DPR-Wert zur Verfügung zu stellen, kann das srcset-Attribut in <img>-Tags verwendet werden.

<img 
 loading="lazy" 
 width="750" 
 height="750" 
 alt=""
 src="/assets/img/img-750.webp"
 srcset="/assets/img/img-750.webp 750w, 
         /assets/img/img-325.webp 325w" 
 sizes="(max-width: 1023px) 100vw, 
        (min-width: 768px) 50vw, 
        (min-width: 1024px) 33vw"
>

Hier erfahrt ihr mehr über Responsive Images im Web.

Jetzt bist du gefragt!

Hast du Anregungen, Ergänzungen, einen Fehler gefunden oder ist dieser Beitrag nicht mehr aktuell? Dann freuen wir uns auf deinen Kommentar.

Du kannst diesen Beitrag natürlich auch weiterempfehlen. Wir sind dir für jede Unterstützung dankbar!

Das könnte dich auch interessieren

Kommentar verfassen

Dieser Blog lebt vom Feedback der Besucher! Also los, mach mit!
Bitte habe Verständnis dafür, dass Kommentare die mit dem Inhalt dieses Beitrags nichts zu tun haben, gelöscht werden.