Hauptmenü:
Für den Webmaster:
Zu große Datenmenge auf der Webseite
Zu große Bilder
Nicht aktivierte Komprimierung
Langsame Datenbanken
Zu langsamer Server
Zu große Bilder
In einer Studie wurde festgestellt, dass Bilder zu den Elementen zählen, die den größten Teil einer Webseite ausmachen. Bilddateien machen häufig über 60% der Dateigröße einer Webseite aus. Dies zeigt auch, dass hier eine Optimierung große Auswirkung haben wird.
Quelle: httparchive, 2014
Bilder auf einer Webseite müssen nicht hochauflösend sein. Deshalb sollten Bilddateien vor dem Einbinden auf einer Webseite auf ihre Dateiengröße überprüft werden. Oft findet man Bilder mit 2 Megabyte und mehr. Dies verschwendet Ladezeit und erzeugt unnötigen Traffic und somit auch Kosten für Sie.
Schon bei der Bearbeitung mit Photoshop oder der kostenlosen Software Gimp können Sie so durchschnittlich bis zu 80% der Datengröße für die Bilder einsparen.
Sie brauchen nur das Originalbild in die Software hochladen und dann auf Exportoptimierung bzw. für das Web speichern. Vor dem Abspeichern haben Sie in der Regel die Möglichkeit sich die Vorschau anzeigen zu lassen, so können Sie Qualitätseinbußen ausschließen.
Für das Dateiformat gilt:
• BMP und TIFF vermeiden.
• GIF nur für kleine und einfache Grafiken (z.B. Favicon und für Animationen) benutzen.
• JPEG für naturgetreue Bilder.
• PNG-Dateien werden sogar ausdrücklich von Yahoo empfohlen.
Optimal ist es, wenn im Code die richtige Größe vom gespeicherten Originalbild vorhanden ist. Somit muss der Browser die Maße eines Bildes nicht erst berechnen. Dieses Anpassen bzw. Skalieren kostet unnötig Zeit.
Wenn eine Seite viele Bilder im Content aufweist, kann deren Ladezeit zudem durch den Einsatz eines Content Delivery Networks (CDN) reduziert werden. Das heißt die Bilder werden auf einen externen Server ausgelagert und so schneller verfügbar gemacht.
Zu langsamer Server
Browser-Caching nutzen
Diese Regel gilt, wenn HKC - Herbert Keilhack Consulting feststellt, dass die Antwort von Ihrem Server keine expliziten Caching-Header enthält, oder wenn die Ressourcen den Angaben gemäß nur für kurze Zeit zwischengespeichert werden sollen.
Übersicht
Durch Browser-Caching für statische Ressourcen können Nutzer Zeit sparen, wenn sie Ihre Website mehr als einmal besuchen. Caching-Header sollten für sämtliche zwischenspeicherbaren statischen Ressourcen gelten, nicht nur für eine kleine Teilmenge davon, wie z. B. für Bilder. Zu den zwischenspeicherbaren Ressourcen gehören unter anderem JavaScript- und CSS-Dateien, Bilddateien und andere binäre Objektdateien wie z. B. Mediendateien und PDFs. HTML ist im Allgemeinen nicht statisch und sollte standardmäßig nicht als zwischenspeicherbar betrachtet werden. Überlegen Sie, welche Caching-Richtlinien für den HTML-Code Ihrer Website geeignet sind.
Empfehlungen
Aktivieren Sie das Browser-Caching für Ihren Server. Statische Ressourcen sollten eine Cache-Lebensdauer von mindestens einer Woche haben. Bei Drittanbieter-Ressourcen wie Werbeanzeigen oder Widgets sollte die Cache-Lebensdauer mindestens einen Tag betragen. Google empfiehlt für alle zwischenspeicherbaren Ressourcen die folgenden Einstellungen:
Legen Sie für Expires mindestens eine Woche fest, vorzugsweise bis zu ein Jahr. Google bevorzugt Expires gegenüber Cache-Control: max-age, weil es breiter unterstützt wird. Legen Sie aber nicht mehr als ein Jahr fest, da dies gegen die RFC-Richtlinien verstößt.
Wenn Sie genau wissen, wann eine Ressource geändert wird, können Sie auch eine kürzere Ablauffrist angeben. Wenn Sie vermuten, dass eine Ressource bald geändert werden könnte, aber nicht den genauen Zeitpunkt wissen, sollten Sie eine lange Ablauffrist festlegen und URL-Fingerprinting verwenden. Letzteres wird weiter unten beschrieben.
Header der Typen "Expires" und "Cache-Control: max-age"
Diese Header geben den Zeitraum an, während dessen der Browser die zwischengespeicherte Ressource verwenden kann, ohne zu prüfen, ob auf dem Webserver eine neue Version verfügbar ist. Bei ihnen handelt es sich um starke Caching-Header, die ohne Bedingungen gelten. Nach ihrer Festlegung und dem Herunterladen der Ressource sendet der Browser erst dann wieder GET-Anforderungen für die Ressource, wenn das Ablaufdatum oder der maximale Zeitraum erreicht ist oder wenn der Cache vom Nutzer gelöscht wurde.
Header der Typen "Last-Modified" und "ETag"
Diese Header geben an, wie der Browser zum Zweck des Cachings prüfen soll, ob die Dateien identisch sind. Beim Last-Modified-Header ist es das Datum. Beim ETag-Header kann es ein beliebiger Wert sein, der eine Ressource eindeutig identifiziert. Hierfür werden oft Dateiversionen oder Inhalts-Hashes verwendet. Last-Modified ist insofern ein schwacher Caching-Header. Der Browser bestimmt anhand einer Heuristik, ob das Element aus dem Cache abgerufen wird oder nicht.
Diese Header ermöglichen dem Browser ein effizientes Aktualisieren seiner zwischengespeicherten Ressourcen. Dabei werden beim expliziten Neuladen der Seite durch den Nutzer bedingte GET-Anforderungen gesendet. Bedingte GET-Anforderungen erhalten nur dann eine vollständige Antwort, wenn die Ressource auf dem Server geändert wurde. Daher ist die Latenz geringer als bei vollständigen GET-Anforderungen.
Welche Caching-Header sollte ich verwenden?
Es ist wichtig, für alle zwischenspeicherbaren Ressourcen entweder Expires oder Cache-Control max-age und entweder Last-Modified oder ETag anzugeben. Es bringt nichts, sowohl Expires als auch Cache-Control: max-age oder sowohl Last-Modified als auch ETag anzugeben.
URL-Fingerprinting
Bei Ressourcen, die gelegentlich geändert werden, kann man den Browser die Ressource zwischenspeichern lassen, bis sie auf dem Server geändert wird. Im Fall einer Änderung teilt der Server dem Browser mit, dass eine neue Version verfügbar ist. Dazu wird jeder Version der Ressource eine eindeutige URL zugewiesen. Hat man z. B. eine Ressource namens "my_stylesheet.css", kann man die Datei in "my_stylesheet_fingerprint.css" umbenennen. Wenn die Ressource geändert wird, wird auch ihre ID und damit ihre URL geändert. Bei einer Änderung der URL ist der Browser gezwungen, die Ressource erneut abzurufen.
Oft wird für die IDs eine 128-Bit-Hexadezimalzahl verwendet, die den Hash des Dateiinhalts codiert.
Eine weitere Möglichkeit besteht darin, für jede neue Version der Anwendung ein neues Veröffentlichungsverzeichnis zu erstellen und die Assets jeder Version im mit der Version gekennzeichneten Verzeichnis zu platzieren. Dies hat folgenden Nachteil: Wenn ein Asset bei einem Versionswechsel unverändert bleibt, ändert sich trotzdem seine URL und es wird ein erneuter Download erzwungen. Bei der Verwendung von Inhalts-Hashes besteht dieses Problem nicht. Dafür ist das Verfahren aber ein wenig komplexer.
Texte wurden zum Teil von Google Inc. freundlicherweise unter Creative Commons – Namensnennung 3.0-Lizenz zur Verfügung gestellt. Die Texte wurden soweit notwendig übersetzt und überarbeitet.