manche langen Namen.<\/li>\n<\/ul>\n\n\n\nDas verringert die Dateigr\u00f6\u00dfe.<\/p>\n\n\n\n
Das ist eine gute Praxis f\u00fcr Produktivsysteme, aber heute ist der Unterschied zwischen einer minifizierten und einer nicht minifizierten Datei, die zus\u00e4tzlich mit Brotli- oder GZIP-Kompression ausgeliefert wird, oft deutlich kleiner als noch vor einigen Jahren.<\/p>\n\n\n\n
Eine deutlich gr\u00f6\u00dfere Verbesserung kann es bringen, unn\u00f6tigen Code gar nicht erst auszuliefern<\/strong>.<\/p>\n\n\n\n<\/span>9. Behalten Sie die Zahl der Requests und den Gesamttransfer im Blick<\/span><\/h2>\n\n\n\nJede zus\u00e4tzliche Ressource bedeutet weitere Arbeit f\u00fcr den Browser.<\/p>\n\n\n\n
Das hei\u00dft nicht, dass Sie unbedingt alle Dateien zu einer einzigen zusammenfassen m\u00fcssen. Bei HTTP\/2 und HTTP\/3 ergibt diese Strategie oft keinen Sinn mehr.<\/p>\n\n\n\n
Dennoch lohnt es sich weiterhin, Ressourcen zu reduzieren, die nichts beitragen.<\/p>\n\n\n\n
Insbesondere:<\/p>\n\n\n\n
\n- JavaScript-Bibliotheken,<\/li>\n\n\n\n
- Schriften,<\/li>\n\n\n\n
- Tracker,<\/li>\n\n\n\n
- Social-Media-Widgets,<\/li>\n\n\n\n
- iframes,<\/li>\n\n\n\n
- Videos,<\/li>\n\n\n\n
- gro\u00dfe Bilder,<\/li>\n\n\n\n
- doppelt eingebundene Bibliotheken.<\/li>\n<\/ul>\n\n\n\n
Optimierung sollte darin bestehen, die Menge der geleisteten Arbeit<\/strong> zu verringern, und nicht nur die Zahl, die im Bericht steht.<\/p>\n\n\n\n<\/span>10. Bilder sind eine der gr\u00f6\u00dften Einsparquellen<\/span><\/h2>\n\n\n\nEin Foto, das auf der Seite in der Gr\u00f6\u00dfe 800 \u00d7 500 px angezeigt wird, sollte nicht als Datei mit 5000 \u00d7 3000 px geladen werden.<\/p>\n\n\n\n
Das ist einer der am einfachsten zu findenden Fehler.<\/p>\n\n\n\n
WordPress kann automatisch verschiedene Bildgr\u00f6\u00dfen erzeugen, und der Browser kann dank srcset<\/code> und sizes<\/code> die passende Version ausw\u00e4hlen.<\/p>\n\n\n\nEs lohnt sich au\u00dferdem, moderne Formate einzusetzen:<\/p>\n\n\n\n
\n- WebP,<\/li>\n\n\n\n
- AVIF.<\/li>\n<\/ul>\n\n\n\n
In vielen F\u00e4llen l\u00e4sst sich damit der Transfer deutlich senken, bei weiterhin guter Bildqualit\u00e4t.<\/p>\n\n\n\n
Sie sollten allerdings nicht mechanisch alles in ein einziges Format konvertieren. Das Ergebnis der Kompression muss an realem Material beurteilt werden.<\/p>\n\n\n\n
<\/span>11. Nutzen Sie Lazy Loading nicht f\u00fcr alles<\/span><\/h2>\n\n\n\nLazy Loading ist sehr n\u00fctzlich f\u00fcr Bilder, die weit unterhalb des ersten Bildschirms liegen.<\/p>\n\n\n\n
Ein Beispiel:<\/p>\n\n\n\n
<img\n src=\"photo.webp\"\n loading=\"lazy\"\n width=\"800\"\n height=\"600\"\n alt=\"Bildbeschreibung\"\n>\n<\/code><\/pre>\n\n\n\nHeutige Browser unterst\u00fctzen natives loading=\"lazy\"<\/code>, sodass in vielen F\u00e4llen keine zus\u00e4tzliche JavaScript-Bibliothek mehr n\u00f6tig ist.<\/p>\n\n\n\nEs gibt jedoch eine wichtige Ausnahme.<\/p>\n\n\n\n
Laden Sie das Hauptbild oberhalb der Falz nicht lazy<\/strong>, insbesondere dann nicht, wenn es das LCP-Element ist.<\/p>\n\n\n\nEin solches Bild sollte so fr\u00fch wie m\u00f6glich zu laden beginnen. Google empfiehlt ausdr\u00fccklich, Bilder im anf\u00e4nglichen Viewport, vor allem das LCP-Bild, nicht per Lazy Loading zu laden.<\/p>\n\n\n\n
<\/span>12. K\u00fcmmern Sie sich um das Bild, das f\u00fcr LCP verantwortlich ist<\/span><\/h2>\n\n\n\nWenn das gr\u00f6\u00dfte Element der Seite das Hauptproduktfoto oder ein Hero-Banner ist, sollte sein Download so fr\u00fch wie m\u00f6glich beginnen.<\/p>\n\n\n\n
Ein Problem entsteht, wenn das Bild:<\/p>\n\n\n\n
\n- nur als
background-image<\/code> im CSS gesetzt ist,<\/li>\n\n\n\n- erst durch JavaScript hinzugef\u00fcgt wird,<\/li>\n\n\n\n
- ein fehlerhaftes Lazy Loading hat,<\/li>\n\n\n\n
- vom Browser zu sp\u00e4t entdeckt wird.<\/li>\n<\/ul>\n\n\n\n
In bestimmten Situationen l\u00e4sst sich unter anderem einsetzen:<\/p>\n\n\n\n
fetchpriority=\"high\"\n<\/code><\/pre>\n\n\n\noder ein Preload der Ressource.<\/p>\n\n\n\n
Sie sollten allerdings nicht ein Dutzend Grafiken gleichzeitig preloaden. Wenn alles hohe Priorit\u00e4t erh\u00e4lt, erf\u00fcllen Priorit\u00e4ten praktisch keine Funktion mehr.<\/p>\n\n\n\n
<\/span>13. Legen Sie die Gr\u00f6\u00dfen von Bildern und anderen Elementen fest<\/span><\/h2>\n\n\n\nElemente sollten Abmessungen haben, die dem Browser bekannt sind.<\/p>\n\n\n\n
Bei Bildern k\u00f6nnen das sein:<\/p>\n\n\n\n
width=\"800\"\nheight=\"600\"\n<\/code><\/pre>\n\n\n\nDadurch kann der Browser den entsprechenden Platz reservieren, bevor die Datei selbst geladen ist.<\/p>\n\n\n\n
Das verringert das Risiko von Layoutverschiebungen, also eines schlechteren CLS.<\/p>\n\n\n\n
Ein \u00e4hnliches Problem tritt auf bei:<\/p>\n\n\n\n
\n- Anzeigen,<\/li>\n\n\n\n
- iframes,<\/li>\n\n\n\n
- Embeds,<\/li>\n\n\n\n
- dynamischen Bannern,<\/li>\n\n\n\n
- Elementen, die per JavaScript geladen werden.<\/li>\n<\/ul>\n\n\n\n
<\/span>14. Optimieren Sie Schriften<\/span><\/h2>\n\n\n\nAuch eine Webschrift ist eine Ressource, die heruntergeladen werden muss.<\/p>\n\n\n\n
Eine Seite, die Folgendes nutzt:<\/p>\n\n\n\n
\n- 4 Schriftfamilien,<\/li>\n\n\n\n
- 5 Schnitte je Familie,<\/li>\n\n\n\n
- Kursive,<\/li>\n\n\n\n
- zus\u00e4tzliche Zeichens\u00e4tze,<\/li>\n<\/ul>\n\n\n\n
kann deutlich mehr Daten laden, als n\u00f6tig ist.<\/p>\n\n\n\n
Es lohnt sich, die Zahl der Varianten zu begrenzen und WOFF2 zu nutzen.<\/p>\n\n\n\n
Eine gute Praxis ist au\u00dferdem:<\/p>\n\n\n\n
font-display: swap;\n<\/code><\/pre>\n\n\n\nDadurch kann der Nutzer den Text bereits in einer Ersatzschrift sehen, bevor die Zielschrift geladen ist.<\/p>\n\n\n\n
F\u00fcr die kritischsten Schriften ist ein Preload manchmal gerechtfertigt.<\/p>\n\n\n\n
<\/span>15. Begrenzen Sie externe Skripte<\/span><\/h2>\n\n\n\nEine Seite kann gut optimiert sein und trotzdem langsam laufen, weil Code von anderen Diensten stammt.<\/p>\n\n\n\n
Typische Beispiele:<\/p>\n\n\n\n
\n- Werbesysteme,<\/li>\n\n\n\n
- Analytics,<\/li>\n\n\n\n
- Chats,<\/li>\n\n\n\n
- Heatmaps,<\/li>\n\n\n\n
- Bewertungs-Widgets,<\/li>\n\n\n\n
- Social Media,<\/li>\n\n\n\n
- A\/B-Testing-Systeme,<\/li>\n\n\n\n
- YouTube-Videos,<\/li>\n\n\n\n
- Karten.<\/li>\n<\/ul>\n\n\n\n
Jedes dieser Elemente kann eigenes JavaScript laden, Event-Listener setzen und Code im Haupt-Thread ausf\u00fchren.<\/p>\n\n\n\n
Auf polnischen Firmenwebsites und in Online-Shops w\u00e4chst das Problem oft schrittweise: Zuerst kommt die Statistik dazu, sp\u00e4ter Meta Pixel, Google Ads, ein Chat, ein Marketing-Automation-Tool und weitere Widgets. Jedes f\u00fcr sich wirkt klein, zusammen k\u00f6nnen sie jedoch zu einer der Hauptquellen von Performance-Problemen werden.<\/p>\n\n\n\n
Eine L\u00f6sung kann sein:<\/p>\n\n\n\n
\n- unn\u00f6tige Dienste zu entfernen,<\/li>\n\n\n\n
- den Start zu verz\u00f6gern,<\/li>\n\n\n\n
- erst nach einer Interaktion zu laden,<\/li>\n\n\n\n
- leichte Platzhalter statt schwerer iframes einzusetzen.<\/li>\n<\/ul>\n\n\n\n
<\/span>16. Aktivieren Sie HTTP-Kompression<\/span><\/h2>\n\n\n\nHTML, CSS, JavaScript, JSON, XML und andere Textformate lassen sich sehr gut komprimieren.<\/p>\n\n\n\n
Der Server sollte sie daher zum Beispiel so ausliefern:<\/p>\n\n\n\n
\n- Brotli,<\/li>\n\n\n\n
- GZIP.<\/li>\n<\/ul>\n\n\n\n
Das verringert die Datenmenge, die zwischen Server und Browser \u00fcbertragen wird.<\/p>\n\n\n\n
Formate, die bereits \u00fcber eine eigene wirksame Kompression verf\u00fcgen, etwa die meisten Bilder oder Videos, sollten Sie dagegen nicht erneut komprimieren.<\/p>\n\n\n\n
<\/span>17. Stellen Sie einen passenden Browser-Cache ein<\/span><\/h2>\n\n\n\nStatische Dateien, die sich selten \u00e4ndern, sollten nicht bei jedem Besuch erneut geladen werden.<\/p>\n\n\n\n
Das betrifft unter anderem:<\/p>\n\n\n\n
\n- CSS,<\/li>\n\n\n\n
- JavaScript,<\/li>\n\n\n\n
- Bilder,<\/li>\n\n\n\n
- Schriften.<\/li>\n<\/ul>\n\n\n\n
Die passenden Header:<\/p>\n\n\n\n
Cache-Control\nExpires\nETag\n<\/code><\/pre>\n\n\n\nerlauben es dem Browser, bereits geladene Ressourcen erneut zu verwenden.<\/p>\n\n\n\n
Bei versionierten Dateien, zum Beispiel:<\/p>\n\n\n\n
app.a87c913.js\n<\/code><\/pre>\n\n\n\nl\u00e4sst sich eine sehr lange Cache-Zeit verwenden, denn eine \u00c4nderung des Inhalts f\u00fchrt zu einem neuen Dateinamen.<\/p>\n\n\n\n
<\/span>18. Vermeiden Sie unn\u00f6tige Weiterleitungen<\/span><\/h2>\n\n\n\nJeder Redirect bedeutet einen zus\u00e4tzlichen Request.<\/p>\n\n\n\n
Zum Beispiel:<\/p>\n\n\n\n
http://example.com\n\u2193\nhttps:\/\/example.com\n\u2193\nhttps:\/\/www.example.com\n\u2193\nhttps:\/\/www.example.com\/pl\/\n<\/code><\/pre>\n\n\n\nbedeutet mehrere Operationen, bevor der Nutzer beim eigentlichen Dokument ankommt.<\/p>\n\n\n\n
Bei einem einzelnen Seitenaufruf muss das keine Katastrophe sein, aber \u00e4hnliche Ketten innerhalb der Seite, in CSS, JavaScript oder Werbung k\u00f6nnen unn\u00f6tige Verz\u00f6gerungen erzeugen.<\/p>\n\n\n\n
Verlinken Sie direkt auf die Zieladressen.<\/p>\n\n\n\n
<\/span>19. Kontrollieren Sie die Gr\u00f6\u00dfe des DOM<\/span><\/h2>\n\n\n\nPage Builder erlauben es, komplizierte Layouts schnell zu erstellen, erzeugen aber oft sehr umfangreiches HTML.<\/p>\n\n\n\n
Ein optisch einfaches Element kann im Code so aussehen:<\/p>\n\n\n\n
<div>\n <div>\n <div>\n <div>\n <div>\n <span>Text<\/span>\n <\/div>\n <\/div>\n <\/div>\n <\/div>\n<\/div>\n<\/code><\/pre>\n\n\n\n