Page Speed & Core Web Vitals: Definition, Analyse und Optimierung

In diesem Artikel erkläre ich dir deshalb, wie du Ladezeiten dank Page-Speed-Optimierung so gering wie möglich hältst.

18 Tipps für die Sofortoptimierung

Du willst jetzt gleich mehr Page Speed?

Zuerst ein Hinweis an alle Entwickler:innen: Page-Speed-Optimierung ist kein Projekt – sie ist ein Prozess. Jede neue Erweiterung, jedes neue Script und jede Änderung am Server erfordert eine erneute Prüfung der Website-Performance. Es ist sehr wichtig, vorab auf einem Testserver zu prüfen, welche Auswirkungen diese Änderungen später auf der Live-Website haben werden.

Bist du Marketer:in, denke daran, dass jeder Wunsch, den du gegenüber Entwickler:innen äußerst, Auswirkungen auf die Geschwindigkeit deiner Website haben kann. Selbst dann, wenn Mark Zuckerberg persönlich den Code für dein Projekt schreibt.

1. Page-Speed-Optimierung per Server-Caching

Mit Caching kannst du deinen Webserver und deine Datenbank schonen, da so weniger Daten aus der Datenbank angefragt und vom Server berechnet werden müssen.

Du kannst durch diese Methode Ressourcen einsparen, da das Ergebnis der Aufrufe nach der ersten Anfrage im Serverspeicher verbleibt.

Wird eine Seite aufgerufen, die sich bereits im Servercache befindet, greift der Browser auf den Servercache zu und umgeht damit die komplexe und ressourcenfressende Abfrage der Seite im Hintergrund.

Der Server-Cache sollte aber nicht mit dem Browser-Cache verwechselt werden. Die gecachten Daten werden nicht auf dem Gerät gespeichert, auf dem sich der Browser befindet, wie es beim Browsercaching der Fall ist, sondern, wie gesagt, auf dem Server.

Achtung: Wenn Daten auf deiner Website geändert werden, muss auch der Server-Cache gelöscht und neu aufgebaut werden. Bitte cache auch nicht deine Check-out-Formulare, das kann im Konversionsprozess durchaus zu Schwierigkeiten führen.

Wenn du WordPress nutzt, kannst du das Plug-In WP Rocket verwenden, um dein Caching recht einfach und fix einzurichten.

2. Page-Speed-Optimierung durch Browser-Caching

Diese Methode des Cachings wirkt sich besonders dann positiv auf die Ladezeit deiner Website aus, wenn Besucher:innen wiederkehren.

Beim Browser-Caching werden Elemente der Website, die sich nicht verändern – üblicherweise Bilder, JavaScript und CSS – im Speicher des Browsers auf dem Gerät der Besucher:innen abgelegt. Sie müssen dann beim erneuten Besuch der Website nicht erneut geladen werden. Schon ist die Wartezeit um einiges kürzer.

Du kannst das Browser-Caching aktivieren, indem du für dein CMS eine Erweiterung verwendest oder indem du es manuell über deine .htaccess-Datei aktivierst.

Nutzt du WordPress, helfen dir dabei diese Plugins:

• WP Rocket
• W3 Total Cache
• WP Fastest Cache

Manuell ist die Einrichtung des Browser-Cachings etwas komplexer.

Zuerst musst du sicherstellen, dass entweder mod_headers oder mod_expires auf deinem Server ihre Arbeit tun, also aktiviert sind.

Browser-Caching per mod_headers

Im Falle von mod_headers sieht der korrekte Eintrag in der .htaccess so aus:

In runden Klammern werden hier die Dateitypen festgelegt, die gecached werden sollen.

Mit age=2592000 wird die Dauer des Cachings in Sekunden festgelegt. In diesem Fall 30 Tage.

Browser-Caching per mod_expires

Bei dieser Variante fügst du deiner .htaccess-Datei diesen Code hinzu:

Wie du am Code erkennen kannst, ist es möglich, für jeden Dateitypen die Dauer des Cachings zu bestimmen. So kannst du hier mit solchen Werten arbeiten wie:

• 1 month
• 2 weeks
• 3600 seconds

Browser-Caching und Änderungen an deiner Website

Was aber, wenn du etwas an deiner Website änderst, das aber im Browser deiner Besucher:innen noch für mehrere Wochen gecached sein wird?

Du kannst den MD5-Hash einsetzen, um das Problem zu umgehen. Dabei wird allen Dateien, die einem Typen angehören, der gecached wird, eine einzigartige Zeichenkette angehängt. Ändert sich eine solche Datei, wird ein neuer Hash angehängt. Dadurch wird diese Datei als neu erkannt und erneut vom Server angefragt.

3. Page-Speed-Optimierung durch die Minimierung von HTTP-Requests

Wenn einer oder eine deiner Besucher:innen eine deiner Webpages besucht, wird eine Anfrage an den Server gestellt. Als Antwort liefert der Server das HTML deiner Webpage. Darin wird wiederum auf einzelne Dateien verwiesen. Stylesheet (CSS), JavaScript (JS), Bilder – alle werden mit dem Hypertext Transfer Protocol (HTTP) aufgerufen.

Browser können zwischen 2 und 8 Anfragen gleichzeitig und pro Domain ausführen. So kann zum Beispiel der Google Chrome Browser maximal 6 Verbindungen parallel zu einem Host herstellen. Mehr dazu kannst du direkt bei Google nachlesen. Es gibt also eine Obergrenze. Wird diese überschritten, müssen die übrig gebliebenen Aufrufe warten, bis die anderen erledigt sind. Je länger das dauert, desto länger dauert es also, die Webpage komplett anzuzeigen. Ich möchte dir noch ein paar Informationen zum Hintergrund von Requests geben. Ein komplett unterschätztes Thema in der Optimierung der Seitenladegeschwindigkeit ist dabei die Reduktion der sogenannten Roundtrips. Um das zu verstehen, muss man tiefer in die Kommunikation zwischen Browser (Client) und dem Server einsteigen und wissen, welche Limitierungen eine Rolle spielen.

Key Learnings – Was bedeutet das für die Optimierung der Ladezeit

• http-Requests (LKW) können nur mit einer bestimmten maximalen Geschwindigkeit (Lichtgeschwindigkeit) zwischen Browser und Server verkehren. Auf diese Geschwindigkeit hast du keinen Einfluss. Ein Request von Deutschland auf einen Server in Los Angeles braucht sogar in Lichtgeschwindigkeit 100ms.
• Die Informationen in den http-Requests sind während der Fahrt zwischen Browser und Server nicht wirklich sicher. Deswegen gibt es als sicheres Verbindungsprotokoll „https“ – der LKW fährt dabei durch einen Tunnel. Um den Tunnel (die sichere Verbindung) herzustellen, wird deutlich mehr Zeit benötigt, als wenn der LKW einfach auf einer normalen Straße unterwegs wäre.
• Je kürzer die Strecken, die ein http- oder https-Request zurücklegen muss, desto schneller lädt die Website. Eine Möglichkeit um die „Strecken zu verkürzen“, ist der Einsatz von Content Delivery Networks (CDNs) – ein Netz regional verteilter Server, die aufgrund ihrer geografischen Nähe die Distanz des Requests und damit die Seitenladegeschwindigkeit reduzieren.
• Mithilfe von speziellen Browser-Anweisungen wie Preload (der Browser lädt eine Ressource, z.B. ein Bild, bereits bevor es überhaupt angefordert wurde, damit es hinterher ohne Verzögerung zur Verfügung steht) und Preconnect (der Browser stellt eine Verbindung zu Linkzielen her, bevor ein Nutzer auf den Link geklickt hat), ist es möglich, die Wartezeit der Requests zu verringern. So bildet sich kein langer Stau mehr und http(s)-Requests können schneller ausgeführt werden.
• Je größer eine Ressource (HTML, JavaScript, CSS etc.), desto länger dauert es, bis diese geladen ist. Um die Seitenladegeschwindigkeit zu optimieren, lohnt es sich also, die Ressourcen zu komprimieren.
• Deine Website lädt schneller, wenn die Requests seltener zwischen Browser und Server hin- und herfahren müssen.

Reduziere die Anzahl und die Entfernung der Requests

• Reduziere die Anzahl der Requests
• Reduziere die Entfernung, die die einzelnen Requests zurücklegen müssen

Wie kannst du die Requests analsyieren?

Du willst die Requests für deine wichtigen Seite analysieren? Dann überprüfe mal diese Seiten in den Chrome Entwickler-Tools. Du gehst in die Chrome Entwicklerconsole und öffnest den Reiter Netzwerk. Anschließend lässt du deine Seite durchlaufen. Unten links siehts du dann die Anzahl der Requests, wie hier bei uns 78 Requests für die Startseite.

Aufgabe: Spare deine Server-Anfragen pro Domain. Stelle deinem HTML also nicht mehrere kleine CSS-Dateien zur Verfügung, sondern fasse zusammen, was zusammenzufassen ist. Das gilt auch für JavaScript-Dateien.

Das Zusammenfassen hat aber auch Nachteile. Wenn du CSS zusammenfasst, brauchst du dafür einen genauen Plan. Gilt es also, nur eine einzige CSS-Datei zu laden, müssen unter Umständen viele Dateien zu einer zusammengefasst werden. Das heißt aber auch, dass du dann das CSS der FAQ-Seite auch auf der Teamseite lädst. Am Ende hast du so vielleicht nur eine Datei, dafür aber eine mit vielen redundanten Informationen.

Natürlich gibt es hier konzeptionelle Workarounds. So könntest du CSS-Dateien erstellen, die Seitentypen repräsentieren, die recht ähnlich sind und auf diese Weise Redundanzen vermeiden.

Das Thema „Request-Obergrenze“ ist allerdings schon bald obsolet, denn HTTP/2 steht in den Startlöchern. Damit ist das Zusammenfassen von CSS- und JavaScript-Dateien nicht mehr nötig, weil die Abfragenobergrenze hier nicht mehr relevant ist. Dadurch wird der oben skizzierte Optimierungsansatz ins Gegenteil verkehrt. Nun sollte dein Server im besten Fall kleinteiligere Dateien zur Verfügung stellen, weil diese natürlich viel weniger redundante Infos enthalten. Also nur CSS, das auch wirklich auf dieser Webpage verwendet wird.

Dafür müssen dein Server und der Browser deines Website-Besuchers aber HTTP/2 verstehen. Moderne Browser können das in den neuesten Versionen. Auf Serverseite ist das momentan in Deutschland aber nur bei wenigen Hostern möglich. Das liegt auch daran, dass die endgültige Spezifizierung für HTTP/2 bis dato nicht vorliegt. Hier heißt es vielerorts noch: abwarten.

Glücklicherweise versteht Google bereits HTTP/2. Und für ältere Browser ist HTTP/2 komplett abwärtskompatibel.

4. Vermeide unnötig viele Weiterleitungen

Wir sprechen hier über Zeitersparnis im Bereich von Milli- und Nanosekunden. Aber erstens wollen wir so schnell wie möglich sein und zweitens können sich viele verkettete Weiterleitungen zu einem hübschen Sümmchen addieren, welches unseren Website-Besuchern das Surfen vergällt.

Hier ein Beispiel:

Der 121WATT-Blog lief zu Beginn unter http://121watt.de/blog, wurde dann auf http://blog.121watt.de umgezogen, um dann nach einigen Jahren wieder auf http://121watt.de/blog zu laufen. Irgendwann haben wir dann https eingeführt, was unsere URLs im Protokoll um den Buchstaben „s“ erweiterte.

Schon haben wir für einen alten, aber noch existierenden Blog-Post drei Weiterleitungen zusammen, die Serverzeit in Anspruch nehmen.

Das Gegenmittel heißt „Dokumentation“. Lückenlose, gewissenhafte und gut nachvollziehbare Dokumentation. Was beim Betrieb einer Website generell eine gute Idee ist, wird bei der Page-Speed-Optimierung hinsichtlich der Weiterleitungen unverzichtbar.

Und wie beseitigst du eine solche Link-Bremse? Das ist am Ende gar nicht schwer. Eine verkettete Weiterleitung kannst du technisch dadurch umgehen, dass du eine Abkürzung nimmst. Vom ursprünglichen Link zum aktuellen Link. Um unsere Backlinks von jeder vorangegangenen URL zu behalten, sollte allerdings jede dieser URLs direkt auf den aktuellen Link zeigen.

 

5. Lade Inhalte per AJAX nach

Wenn eine lange Website aufgerufen wird, werden viele Daten geladen. Es wird eine Anfrage zur Auslieferung der Seite an den Server geschickt und der Server antwortet brav mit der gesamten Seite, also allen Daten, die sie ausmachen. Das kann schon mal eine ganze Menge Code sein, der da zurückkommt.

Nun gibt es Menschen, die sich deine Website nicht bis ganz zum Schluss anschauen. Vielleicht, weil sie die Information, die sie gesucht haben, schon zu Beginn gefunden haben, weil sie schon recht früh eine Entscheidung zum Kauf treffen oder sogar, weil sie nicht das gefunden haben, was sie suchen.

Im Sinne der Page Speed-Optimierung könntest du nun also per AJAX je nach Scrollposition immer nur die Inhalte nachladen, die als nächstes angezeigt werden sollen.

Das bekannteste Beispiel und ein Pionier auf diesem Gebiet war Pinterest. Hier war es quasi unmöglich, alle Posts zu einem Thema auf einmal zu laden. Also wurden die jeweils nachfolgenden Punkte nachgeladen, wenn der oder die Betrachter:in einer Seite bis ganz ans Ende gescrollt hat. Buzzwort: Infinite Scrolling.

Die Ladeanimation war damals quasi Teil des Erlebnisses. Heute würde man sie sich sparen, indem man bereits Teile der Seite nachlädt, die sich noch nicht im Sichtbereich des Nutzers befinden.

Auf Smartphones lohnt sich das Nachladen per AJAX übrigens ganz besonders. Auch bei normal langen Seiten. Denn die Displays sind so schmal, dass auch kurze Seiten schnell zu sehr langen Seiten werden können.

6. Komprimiere CSS und JavaScript

Jede CSS-, HTML- oder JS-Datei, die aufgerufen wird, muss geladen werden. Je kleiner sie ist, desto schneller geht das. Durch Komprimierung kannst du die Datenmenge verringern.

Das geht am besten, indem du Zeichen sparst. Kurzer Code nimmt weniger Speicherplatz ein als langer Code. Deshalb werden in minifiziertem Code alle Kommentare, alle Zeilenumbrüche und die meisten Leerzeichen entfernt.

Natürlich macht das kein Mensch per Hand. Der oder die findige Frontend-Entwickler:in überlässt das einem Taskrunner. Diese Toolsets wie zum Beispiel Grunt, Gulp oder Webpack bieten viele Möglichkeiten, um wiederkehrende Aufgaben bei der Entwicklung zu automatisieren. Unter anderem eben die Komprimierung von JavaScript und CSS.

Hier siehst du, welchen Einfluss die Komprimierung auf eine JS-Datei hat.

In diesem Beispiel konnte die Dateigröße unserer JavaScript-Datei um 25 % gekürzt werden. Bei größeren Dateien kann die prozentuale Einsparung sogar noch höher sein. Während ich diesen Artikel schreibe, hat unser Entwickler Robert eine 238 kb große JS-Datei auf 35 kb minifiziert. Das entspricht einer Reduzierung um mehr als 85 %.

Im JavaScript kannst du darüber hinaus Variablennamen kürzen. Der kürzeste Name ist natürlich einstellig. Aber damit kann man schlecht programmieren. Sprechende Variablen sind immer die bessere Wahl.

Durch die oben genannten Taskrunner werden die Variablen deshalb nach der Programmierung maximal gekürzt. Hierdurch werden zusätzlich Daten gespart.

7. Verwende Gzip-Komprimierung

Mit Gzip werden Dateien komprimiert. Ihre Dateigröße wird also verringert. Dadurch können diese Dateien auch schneller übermittelt werden.

Die Aktivierung von Gzip auf Webservern ist eigentlich Standard. Dennoch ist es eine gute Idee, zu prüfen, ob die Komprimierungsmethode wirklich aktiviert ist und so zur Page-Speed-Optimierung beiträgt.

Hier erfährst du mehr zur Aktivierung von GZip.

8. Page-Speed-Optimierung durch asynchrones Laden

Eine Webpage wird beim Laden immer in der Reihenfolge geladen, in der die zu ladenden Elemente im Code auftauchen. Ist ein Element in dieser Abfolge noch nicht vollständig verarbeitet, kann das folgende Element nicht verarbeitet und somit auch noch nicht angezeigt werden.

Die Positionierung von CSS und JS-Dateien im HTML war deshalb auch lange durch die Eigenheiten des synchronen Ladens bestimmt: CSS im <head>, JS am Ende des <body>.

• CSS wird dabei zu Beginn geladen, damit der Browser gleich weiß, wie er deine Website darstellen soll. Würdest du deine CSS-Dateien im unteren Teil deines HTML verlinken, würde das HTML erst mal ohne Styles, also hässlich wie die Nacht dunkel, geladen und dann erst gestylt werden.
• Bei JavaScript ist das anders. Es unterstützt das Verhalten deiner Website und nicht das Aussehen. Da Besucher:innen im Zweifelsfall erst einmal die Informationen auf der Website brauchen, wird das JavaScript und damit die Funktionalitäten der Website beim synchronen Laden am Ende geladen.

Javascript und CSS kannst du allerdings auch asynchron laden. Bevor wir aber in die Tiefen des Critical Rendering Path absteigen, erkläre ich dir kurz, wieso du vor allem JavaScript asynchron laden solltest.

Asynchrones Laden von JavaScript

Beim asynchronen Laden von JavaScript macht es keinen Unterschied, ob deine JS-Dateien oben oder unten im HTML zu finden sind.

Warum?

Beim asynchronen Laden wird der Code von oben nach unten durchgegangen und die Bestandteile werden wie üblich in der Reihenfolge geladen, wie sie in der HTML-Datei zu finden sind. Der Unterschied besteht nun darin, dass eine Datei, die geladen wird, nicht fertig geladen sein muss, bevor der Rest geladen werden kann. Sie beginnt mit dem Ladevorgang und lädt im Hintergrund weiter, während die nächsten Zeilen Code Stück für Stück abgearbeitet werden.

Der Vorteil: manche Skripte – zum Beispiel für das Tracking deiner Website – sollten zur besseren Funktion bereits zu Beginn geladen werden. Durch asynchrones Laden kannst du verhindern, dass sie die Anzeige deiner Website verhindern.

 

 

9. Verwende Subdomains, um mehr HTTP-Requests zu erhalten

Erinnerst du dich, dass ein Browser nur bis zu 8 Requests gleichzeitig bearbeiten kann? Das Problem kannst du mit einem kleinen Trick umgehen. Denn diese Restriktion gilt nur auf Domainebene. Wenn du also Skripte und Dateien zusätzlich von anderen Domains laden kannst, kannst du pro Domain 8 zusätzliche Dateien laden.

Du könntest deine CSS- und JS-Dateien deshalb von einer oder mehreren Subdomains laden lassen. Warum?

Nehmen wir an, deine Website besteht aus 28 Dateien. HTML, CSS, JS und diverse Bilder. Nehmen wir der Einfachheit halber weiterhin an, diese Dateien seien alle gleich groß. Zum Beispiel 15 kb.

Würden alle 28 Dateien auf deiner Hauptdomain liegen, dann könnte der Browser deines Besuchers diese in 4 Schritten laden: 8, 8, 8, 4.

Würde das Laden einer Datei insgesamt 50 Millisekunden dauern, dann wären die Dateien theoretisch innerhalb von 200 Millisekunden geladen.

Wären alle Dateien auf deine Hauptdomain und 3 Subdomains verteilt, könnte der Browser deines Besuchers die 28 Requests gleichzeitig abrufen. Die theoretische Ladezeit für alle 28 Dateien nun: 50 Millisekunden.

Dieses Beispiel soll natürlich nur illustrieren, welche Zusammenhänge zwischen Browser, Dateien und Domains bestehen. Eine Website mit 100 zu ladenden Dateien auf mehr als 12 Subdomains zu verteilen, um möglichst kurze Ladezeiten zu erreichen, ist nicht nur umständlich, sondern auch viel zu aufwändig zu administrieren.

Manchmal hilft es schon, alle Bilder auf die Domain bilder.deinedomain.de zu legen. JavaScript und CSS sollten in den meisten Fällen nur als eine Datei vorliegen.

All das entfällt bei HTTP/2. Denn hier sind die Requests pro Domain nicht mehr begrenzt.

10. Optimiere deinen Page Speed durch die Nutzung eines Content-Delivery-Networks (CDN)

Über ein CDN kannst du Elemente deiner Website laden, ohne deinen eigenen Server zu belasten. Das geht mit Skripten, Bildern, CSS und allen anderen Elementen, die per HTTP-Request geladen werden müssen.

Der Vorteil liegt zum einen in der Einsparung von HTTP-Requests an deinem eigenen Server. Zum anderen arbeiten CDNs regional. Wenn also ein Client in Deutschland Elemente lädt, werden sie von einem Standort in Deutschland geladen und nicht etwa in den USA oder auf den Philippinen. So erhöht sich die Geschwindigkeit durch kürzere Übertragungswege nochmals.

Es gibt viele CDN-Anbieter. Für kleine und für riesige Projekte. Sie sind dann entsprechend günstig oder teuer.

• Google bietet sein Google Cloud CDN an.
• Nutzt du WordPress, kannst du mit WP-Rocket deine statischen Dateien zu deinem CDN-Anbieter verlinken.
• Auch Amazon bietet ein CDN. Es heißt CloudFront ist Bestandteil der Amazon Web Services (AWS).
• Geht es um eine richtig große Website mit vielen Inhalten und massig Traffic, dann ist Akamai vielleicht das Richtige für dich.

 

Hast du Lust auf mehr SEO bekommen? Dann findest du hier unsere nächsten Termine für unser Page-Speed- oder SEO-Aufbau-Seminar:

11. Verbessere die Antwortzeit deines Servers

Wird deine Website aufgerufen, muss dein Webserver mit Daten antworten. Je schneller die einzelnen Anfragen beantwortet sind, desto schneller ist deine Website vollständig geladen.

Dieser Punkt ist sehr wichtig. Denn egal, wie vorbildlich du die anderen Punkte dieses Artikels umgesetzt hast: Antwortet dein Server nicht schnell, bleibt deine Seite langsam. Du kannst die Antwortzeit deines Servers grundsätzlich durch die Administration deines Servers optimieren oder du kannst deinem Hoster mehr Geld zahlen, damit er das für dich tut.

Mach es dir hier einfach und wähle die zweite Variante, wenn du kannst.
Mehr Infos zur „Average Response Time“, erhältst du direkt bei Google oder, wenn du mehr zur Serverantwortzeit wissen möchtest, dann erklärt dir der Artikel von Enterspeed alles darüber wie schnell deine Seite sein sollte.

12. Vermeide Bad Requests

Wenn deine Website aufgerufen wird und dein Webserver so die Anfrage zur Auslieferung einer Datei erhält, sollte er auch liefern. Werden einzelne Elemente wie Bilder, JavaScript oder CSS nicht gefunden, wird die vorher reibungslose Kommunikation zwischen Client und Server zu einer hitzigen Diskussion um fehlende Inhalte. Das bindet Ressourcen, indem zum Beispiel unnötige DNS-Aufrufe ausgelöst werden.

Du kannst das Fehlen von angefragten Dateien ganz einfach beheben, in dem du:

1. Die fehlende Datei wieder dort zur Verfügung stellst, wo sie sich ursprünglich befand
2. Auf den neuen Dateinamen oder den Ort weiterleitest, an dem die Datei nun gefunden werden kann

Dazu musst du die Bad Requests aber erst einmal aufdecken. Dazu kannst du wieder Screaming Frog verwenden.

13. Nutze CSS3 anstelle von Grafiken für Buttons, Icons und Hintergründe

Ja – dieser Tipp ist alt. Aber du glaubst nicht, wie oft er immer noch ignoriert wird.

Vor einigen Jahren mussten Grafiken noch als Bilder, also PNG oder JPG, in Websites eingebunden werden. Abgesehen davon, dass man auf grauenvolle Techniken wie Sliding Doors zurückgreifen musste, um Buttons zu erzeugen, die eine dynamische Breite hatten, mussten dabei immer Bilder geladen werden.

Auch ein noch so kleines Bild hat viele Zeilen Code. Um dir das zu veranschaulichen, musst du nur einmal ein kleines Bild mit einem Text-Editor öffnen.

Schneller und eleganter ist es, alle grafischen Elemente, die keine Fotos sind, per CSS zu erzeugen. Der Klassiker sind Buttons. Werden sie in CSS3 erzeugt, bestehen sie nur aus sehr wenigen Zeilen Code.

Neben der gesparten Ladezeit sind Grafiken, die per CSS erzeugt wurden, natürlich überall knackscharf. Ob auf einem normalen Monitor, der 72 dpi darstellt, oder auf einem Retina-Display mit 220 dpi.

14. Verwende Bilder mit den richtigen Abmessungen

Die Maße des Bildes sollten immer an der größten Darstellung des jeweiligen Screens auf deiner Seite gemessen werden. Reden wir also von einem responsive Design, bei dem das Bild auf dem Desktop mit 1000px x 1000px dargestellt wird, auf einem Telefon aber deutlich kleiner, so muss das Bild trotzdem in 1000px x 1000px vorliegen.

Einen Nachteil hat diese Vorgehensweise aber: Das Bild wird immer in voller Größe geladen. Responsive hin oder her. Einen Workaround bieten Tools wie imgix. Hier werden deine Bilder gehostet und jeweils anhand der Viewport-Größe gerendert und ausgegeben. Schaut sich also jemand deine Website auf dem Smartphone an, wird das Bild auch nur in der entsprechenden Größe ausgeliefert. Das spart Platz.

Du kannst aber auch das <picture>-Element verwenden. Dieses HTML5-Element ermöglicht es dir, für ein Bild verschiedene Versionen anzubieten. Diese Versionen orientieren sich an verschiedenen Viewport-Größen, die du selbst bestimmen kannst:

15. Verwende für Bilder das richtige Dateiformat

Im Prinzip sind für Bilder auf Websites nur drei Dateiformate relevant: .jpg, .png und .gif. Doch wofür solltest du welches verwenden?

Als Faustregel gilt:

• .jpg für Fotos und Hintergrundgrafiken
• .png, .gif oder .svg für Layoutgrafiken

Aber PNG ist nicht gleich PNG. In den meisten Fällen ist PNG-8 eine gute Wahl, da dieses Format eine sehr geringe Dateigröße mit einem zumeist ausreichenden Farbspektrum verbindet.

Für Grafiken – ausdrücklich nicht für Fotos – ist die Verwendung des Vektorformats SVG sehr sinnvoll. Diese Dateien sind sehr klein, aber unendlich skalierbar. So können sie auch auf Retina-Displays ohne Qualitätsverlust dargestellt werden.

16. Reduziere die Bildinformationen bei Fotos

Ja, du hast richtig gelesen. Auch wenn es unser Ziel ist, die Besucher:innen unserer Websites durch optische Leckerbissen in Ekstase zu versetzen, sollten wir unsere Bilder um nicht wahrnehmbare Bildinformationen bereinigen.

Eine Grafik kann so zum Beispiel in Photoshop auf ein vertretbares Maß komprimiert werden, um anschließend nochmals durch ein Tool wie kraken.io oder PNGGauntlet von weiteren redundanten Elementen befreit zu werden.

17. Entferne EXIF-Daten und Meta-Tags

Die meisten Fotos enthalten Meta-Informationen wie EXIF und Meta-Tags. Diese Infos nehmen Platz weg und bieten auf einer Website keinen Mehrwert. Also wohin damit? Richtig: in den Müll. Dabei hilft uns zum Beispiel der Webservice tinypng.

18. Denke zuerst an deine mobilen Nutzer:innen

Die Herrschaft der Desktop-Rechner ist vorbei. Eine neue Website muss das mobile Publikum zufriedenstellen. Wenn du also eine Website entwickelst, solltest du an die denken, die mit schlechter Verbindung und wenig Geduld in einem Straßencafé sitzen und deine Seite aufrufen möchten.

Diese Personen haben einen kleineren Screen vor sich, bedienen ihr Telefon mit dem Finger anstatt mit der Maus, und haben gerade vielleicht nur eine EDGE-Verbindung zur Verfügung.

Wenn du an diese Personen denkst wird dir klar, dass Geschwindigkeit dein vorrangiges Ziel sein muss. Denn bist du langsam, ist deine Website nicht mobile-friendly. Ist sie nicht mobile-friendly, betrachtet Google sie in der mobilen(!) Suche nicht als indexierungswürdig. Und damit gehen dir – je nach Branche – vielleicht mehr als 50 % deiner Kunden ganz einfach verloren.

Zünde die nächste Stufe

Page-Speed-Optimierung ist trotz dieser Überschrift keine Raketenwissenschaft. Am Ende geht es fast immer darum, Daten so schnell wie möglich auf das Endgerät deiner Website-Besucher:innen zu bringen.

Du kennst nun die Zusammenhänge und die meisten wirksamen Möglichkeiten, um deine Seite schneller zu machen und so Nutzer:innen und Maschine das zu liefern, was sie sich wünschen: Speed!

Habe ich etwas vergessen? Hast du Fragen? Siehst du etwas anders? Nutze unsere Kommentarfunktion, um mit mir in Kontakt zu treten.