Ich habe vor einigen Tagen die Serie Die großen Performance-Bremsen im Frontend gestartet. Im ersten Teil ging es um die Einbindung diverser externer Dienste und wie diese eine Website aufblähen können. In diesem Artikel widme ich mich den Bildern oder besser gesagt was man den Einsatz von Bildern falsch machen kann und wo Einsparungspotentiale stecken.
Allgemeines zu den Bildern
Ein Bild sagt mehr als 1.000 Worte … hört man sehr häufig. Das stimmt wohl. Ein Bild kann nicht nur zusätzliche Informationen liefern sondern einen Artikel erst verständlich machen und Bilder lockern einen Text auf. Daher wäre es blödsinnig, aus Gründen der Performance auf den Einsatz von Bildern und Grafiken zu verzichten … ich gehe bei dieser Aussage davon aus, dass man eine Flatrate und eine ordentliche Verbindung zur Verfügung hat. 🙂
Falsche Grafik-Formate
Ganz grob kann man folgendes sagen. Das Format JPG eignet sich für Fotos und Grafiken mit sehr vielen Farben (zum Beispiel sehr feine Verläufe) und/oder für Grafiken mit fotografischen Komponenten. Die Formate GIF und PNG eignen sich für den Rest und wenn Transparenzeffekte benötigt werden. GIF kann auch Animationen darstellen. So weit zu den drei Pixel-Grafik-Formaten, die im Web die weiteste Verbreitung haben
Weiter will ich hier in das Thema nicht einsteigen, weil man damit ganze Artikelserien füllen kann. Mir geht es darum zu zeigen, was passieren kann wenn man die falschen Grafikformate verwendet.
Fotografien
Folgendes Foto in den Maßen 490×327 Pixel habe ich in Photoshop CS2 unter den Qualitäts-Einstellungen Hoch (60%) gespeichert:
Die Dateigröße beträgt 32 KByte. Ohne nennenswerte Verluste in der Qualität könnte man die Dateigröße locker unter 30 KByte drücken. Würde ich das gleiche Bild in GIF abspeichern, dann bekäme ich 105 KByte und bei PNG (8 Bit) noch 91 KByte.
Also ist es hier klar: JPG hat eindeutig die Nase vorn, sowohl in der Qualität als auch in der Dateigröße.
Grafiken mit wenigen Farben und ohne fotografische Elemente
Nehmen wir uns jetzt eine Grafik vor, wo ich einen Teil der Tagwolke aus dem Fußbereich dieser Website abgebildet habe:
Die Ausmaße betragen 490×250 Pixel und die Grafik verursacht bei PNG gerade mal 8,6 KByte. Mit GIF komme ich schon auf 12,1 KByte, bei gleicher Bildqualität und mit JPG erreiche ich schon 23,7 KByte und da auch nur wenn ich die Qualität auf 30% runter drücke, was in einer sehr schlecht Bildqualität (Artefakte) resultiert. Hier das Ergebnis:
Möchte ich diese Artefakte nicht haben, dann muss ich bei derJPG-Qualität mindestens auf 60% gehen und ist das Bild schon fast 50 KByte groß.
Bei Grafiken solcher Art, wie im letzten Beispiel, ist JPG das falsche Format und hier patzen recht viele Webmaster und darunter befinden sich auch einige, die man das Prädikat Anfänger nicht unbedingt andichten würde.
Was wir aber hier auch gemerkt haben, ist die Tatsache das die Wahl von PNG (8 Bit) gegenüber GIF in den allermeisten Fällen, mal von ganz kleinen Grafiken abgesehen, in einer etwa 10-15% kleineren Dateigröße resultiert.
Kleine Bilder: Verkleinern vs. Ausschnitt
Ein häufiger Fall wo viel Optimierungspotential steckt ist folgender. Man schreibt einen Artikel und die Bilder die man einfügen möchte sind zu groß, zum Beispiel 980 Pixel breit. Das passt 1:1 nicht in den Inhaltsbereich. Also muss man die Bilder verkleinern, zumal die Mediathek von WordPress dies beim Einbinden automatisch macht. Aber ist das immer der richtige Weg?
Ich werde hier gleich eine verkleinerte Grafik einbinden, die auf das Original verweist:
Das Originalbild hat eine Dateigröße von 13,7 KByte und die Vorschaugrafik obwohl wesentlich kleiner hat eine Dateigröße von 14,45 KByte und ist somit “schwerer” als das Original. Je nach Fall kann das Vorschaubild noch wesentlich “dicker” sein als das Original. Verwende ich dagegen ein Ausschnitt in den gleichen Ausmaßen (490×189 Pixel) dann werde ich mit einer Dateigröße von 6,5 KByte belohnt:
Sicherlich das ganze ist natürlich eine Zeitfrage. Ein automatisch generiertes Vorschaubild spart Zeit und ist komfortabel, aber dennoch sollte man versuchen, zumindest bei umfangreichen und bebilderten Artikeln, die Vorschaubilder nicht durch die Verkleinerung der Originalbilder zu erreichen sondern auf Ausschnitte der relevanten Bereiche zu setzen.
Das hat nicht nur den Vorteil einer geringeren Dateigröße sondern dient auch dem Besucher der Website: auf einem zu Unkenntlichkeit, verkleinerten Vorschaubild ist häufig schwer zu erkennen, worum es im Original geht. Hier sind Ausschnitte des relevanten Bereiches doppelt im Vorteil.
Fazit
Beide oben genannten Aspekte – die Wahl des richtigen Formats und des richtigen Vorschaubildes – zeigen, dass die Optimierung einer Website kein Hexenwerk ist und das auch Webmaster mit vergleichsweise wenigen Kenntnissen viel erreichen können.
Wir arbeiten seit 20 Jahren mit WordPress und bieten diverse Dienstleistungen rund um das System an. Kontaktiere uns für weitere Informationen oder für ein Angebot.
Apropos Grafik: Standardmäßig wird ja ein Thumb erstellt, das mittlere und das große Bild zusätzlich zu dem hochgeladenen. Ich brauche bei meinen Blogs das mittlere nicht und möchte Platz auf dem Webspace sparen.
Kennst du eine Möglichkeit, wie das Bild in der Zwischengröße nach dem Hochladen via WordPressuploader unterdrückt werden kann?
Eigentlich bekannt, aber es kann nicht oft genug gesagt werden. Also Danke! 🙂
Ich hab die Qualität für die Vorschaudateien mittels functions.php auf 80% gesetzt. Allein das sorgt schon für bedeutend kleinere Bilder. WP selbst hat da wohl viel höhere Standards.
Wichtig ist auch, keine 10MP-Fotos direkt von der DigiCam hochzuladen und dann per CSS zu “skalieren”. 😯
@Micha: setz in den Einstellungen die entsprechenden Größe auf 0. Dann werden sie nicht mehr erstellt.
Danke, Tom. Funktioniert prima.
Ich mache bei JPG immer 50% Qualität, automatisch. Sofern mir JPG zu hoch bei der KB Zahl scheint, probiere ich PNG aus, was aber eher selten der Fall ist. Zudem nutze ich meistens auch immer nur Ausschnitte und sehr selten Gesamtbilder. 😉
Sehr gut erklärt- danke dafür!
Bei mir wird gar kein mittleres Vorschaubild erzeugt, liegt wohl am them – keine Ahnung. Brauch ich aber auch nicht 😉
[…] Tatsächlich ist alles, was Vladimir zeigte, einfach umzusetzen: Wahl der richtigen Plugins, Optimierung von Grafiken, Reduzierung von HTTP-Requests, Komprimierung und Caching. Nicht viel Neues, aber gut […]
[…] von CSS- und Javascript-Dateien, die Wahl der richtigen Plugins, ebenso wie die Verwendung verschiedener Grafik-Formate. Eine Verwendung von Tools und Diensten wie Firebug, YSlow oder Pingdom wurde zur […]
Danke für den Tipp bzgl. PNG und GIF. Mir war nicht bewusst, dass PNG so große Ersparnisse bringt.
Irgendwie war ich bislang immer der Ansicht, dass man auf PNG verzichten sollte, weil … keine Ahnung warum. 😉
[…] Session von Vladimir beruhte inhaltlich im Wesentlichen auf bereits von ihm zuvor veröffentlichte Blogbeiträge […]
[…] die Performance-Optimierung des Frontends habe ich recht viel geschrieben, zum Beispiel hier und hier. Bei dem Einsatz diverser Caching-Plugins bin ich vorsichtig und versuche im Vorfeld auf die Mittel […]