WordPress-Websites beschleunigen 2: Grafiken Optimieren

Ich habe vor gut drei Wochen den ersten Artikel zum Thema “WordPress-Websites beschleunigen” geschrieben. Damals war das Thema gzip und andere Maßnahmen die man in der .htaccess-Datei machen kann.

Doch es gibt sehr wirksame Maßnahmen, die nicht so techniklastig sind: Optimierung von Grafiken. Das man die Grafiken des eigenen Layouts optimieren kann ist hinlänglich bekannt. In der Regel kommt für Grafiken mit fotografischen Elementen .jpg zum Einsatz und sonst .gif oder .png, hier muss man einfach austesten was die beste Kombination aus Dateigröße und Qualität ergibt, vielen ist das hinlänglich bekannt, deswegen gehe ich da jetzt nicht tiefer rein.

.png statt .gif

Aus Erfahrung weiß ich das in den allermeisten Fällen die Entscheidung für .png anstatt .gif darin resultiert, dass man bei gleicher Qualität eine kleinere Dateigröße erreichen kann, speziell bei größeren Dateien. Je nach Größe und Art der Grafik kann das bis zu 20% betragen.

Leider ist es so, dass Photoshop – zumindest bis einschl. CS2 – für die .png-Grafiken den falschen Gamma-Wert übergibt. Daraus resultiert, dass IE und Safari die Grafiken einen Tick dunkler darstellen. Bei einfachen Screenshots im Artikel ist das kein Problem, aber bei Layoutelementen kann das unangenehm auffallen. Der folgende englischsprachige Artikel erklärt was da passiert und stellt auch einige Lösungsmöglichkeiten vor: The PNG Gamma Dilemma.

Matthias Schütz stellt mit TweakPNG eine recht einfache Möglichkeit, die das Problem lösen kann.

CSS-Sprites: ein statt mehrer Hintergrundbildern

Durch den Einsatz von CSS-Sprites (es werden mehrere Hintergrundbilder zu einer Grafik verschmelzt) kann nicht nur an der Dateigröße speichern sondern auch HTTP-Anfragen minimieren, was zusätzlich zur Optimierung der Website beiträgt. Hier ein interessanter Artikel dazu.

Bilder im Inhalt: hohes Optimierungspotential

So, nun aber zum Aspekt worum es mir eigentlich geht 🙂 und zwar zu den Bildern in den Artikeln selbst. WordPress bietet die Möglichkeit, dass man über die Anwendung selbst, Bilder hochlädt und sie im Inhalt in verschiedenen Größen einbinden kann. Dabei ist mir aufgefallen dass die kleineren Grafiken, die von WordPress automatisch erzeugt werden, sehr häufig aufgebläht werden und zum Teil von der Dateigröße her größer sind, als die die Originale die zum Teil von den Ausmaßen doppelt so groß sind.

Ich kenne mich mit den Tiefen von PHP und seinen verschiedenen Bibliotheken nicht aus, aber ich vermute mal das die PHP-Bibliothek GD-Lib hier die verkleinerten Bildern nicht in der optimalen Dateigröße ausgibt. Wenn ich Blödsinn erzähle, dann korrigiert mich bitte. Auf jeden Fall habe ich, die automatisch generierten Vorschaubilder durch Photoshop geschickt und hier kann man die vergleichen:

Aufgeblähte Grafiken
Aufgeblähte Grafiken

Auf der rechten Seite sieht man die originalen Grafiken auf dem Server und die dazugehörigen automatisch generierten Vorschaubilder. Links befinden sich ebenfalls die originalen Grafiekn und die Vorschaubilder welche ich kurz durch Photoshop geschickt habe. Das Ergebnis ist eindeutig. Links haben die 11 Dateien zusammen 400kb und rechts 857kb.

Speziell die Vorschaubilder bergen viel Einsparpotential – z. B. die Datei expression-web-2-500×353.png kommt von 122kb auf 43kb runter – und hier lohnt es sich auch mal nachzujustieren. Gut das ist immer auch eine Zeitfrage, aber wenn es viele Bilder sind kann man hier mit den Automatismen (Skripte, Aktionen etc.) der Grafikprogramme schnell vorankommen.

Ob es auch eine vernünftige serverseitige Lösung gibt, würde mich auch interessieren.

Wir arbeiten seit 20 Jahren mit WordPress und bieten diverse Dienst­leistungen rund um das System an. Kontaktiere uns für weitere Informationen oder für ein Angebot.

Verwandte Beiträge:

14 Kommentare

  1. Hey Perun!

    Ich benutze für serverseitige Bildoperationen auch die GD-Library. Der Vorteil ist, das diese bei den meisten Webservern direkt installiert ist. Bei Image-Magic oder gar der Cairo-Library ist das nicht unbedingt der Fall. Und einen Rootserver, auf dem man sich austoben kann, hat nicht jeder.
    Probleme mit den Dateigrößen kann ich bei meiner Anwendung aber nicht bestätigen. Man müsste man in den WordPress-Code rein schauen um zu gucken was WP dort treibt. Größere Dateien sind ja nicht unbedingt der gewünschte Effekt. Dann kann ich ja gleich das original laden und einfach kleiner darstellen. 😀

    Viele Grüße, micha149

  2. Nicht unbedingt WP-Spezifisch, jedoch vielleicht für den einen oder anderen “Foto-Blogger” interessant: XAT Image Optimizer

    Mit dem Programm kann man Bilder (jpg, gif, png) verlustfrei komprimieren. Neben Stapelverarbeitung beherrscht es auch rudimentäre Bildbearbeitung (Größe anpassen, Zuschneiden, Wasserzeichen, usw).

    Nicht nur interessant um die Ladezeiten zu verkürzen, auch wenn man sein Blog auf einem Shared Host hat und mit dem Speicherplatz etwas haushalten muss eine ganz interessante Sache.

  3. Hi, bei PNG Grafiken muss man manchmal auf alte IEs achten. Es kam bei mir schon vor, dass er wegen einigen PNG-Grafiken mit Alphakanal abgestürzt ist. 😳 Klingt irre, aber als ich das Bild durch ein einfaches GIF ersetzte blieb der IE6 stabil …

  4. @Sergej,

    ich habe das smush.it-Plugin getestet, aber bei mir funktioniert es nicht “Cannot use object of type WP_Error as array … in /wp-includes/http.php” und blockiert zum Teil die Mediathek von WordPress.

    1. Folgendes habe ich auf der Plugin-Website gesehen:

      fopen Errors

      WP Smush.it currently requires that your PHP setup allows accessing remote URLs using fopen. See the PHP documentation for information, or hang tight… we’ll be updating the plugin soon.

      Ich weiß jetzt nicht ob das was mit meiner Fehlermeldung zu tun hat.

  5. fopen() und allow_url_fopen() sollten aktiviert sein.
    Habe den Fehler bisher auch nur zweimal bekommen, Bilder waren jedoch in der Mediathek trotzdem vorhanden.

    Gruß

  6. Nachtrag: Ich bekomme den Fehler wenn ich einen Unterstrich im Dateinamen habe, ist das bei dir auch der Fall?

    Gruß

  7. @ocean90,

    darauf habe ich nicht geachtet … *überleg* das könnte einer der Ursachen sein. Das müsste ich mal testen.

Kommentare sind geschlossen.