WordPress-Websites beschleunigen 2: Grafiken Optimieren

Peruns Weblog - Webwork und Internet

Weblog der perun.net webwork gmbh mit Artikeln zum Thema WordPress, Webwork, und Internet. Ältere Artikel findest du im Archiv.

WordPress-Websites beschleunigen 2: Grafiken Optimieren

Perun am 14. Mai 2009 um 16:08 Uhr

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

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.

Diesen Artikel weiterempfehlen:

14 Kommentare »»

1. – Sergej Müller

Kommentar vom 14. Mai 2009 um 16:16

Sehr schöner Hinweis, Vladimir.

Ich empfehle und nutze selbst das WordPress-Plugin für smush.it, welches mir meine Bilder direkt beim Upload in der Größe minimiert. Dazu hatte ich mal einen Erfahrungsbeitrag verfasst: http://playground.ebiene.de/752/wordpress-plugin-bilder-beim-upload-optimieren/
2. – micha149

Kommentar vom 14. Mai 2009 um 16:45

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
3. – Perun

Kommentar vom 14. Mai 2009 um 16:54

@Sergej,

danke für den Hinweis. Werde ich auf jeden Fall testen.
4. – Ralf

Kommentar vom 14. Mai 2009 um 21:26

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.
5. – martin

Kommentar vom 14. Mai 2009 um 22:25

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 …
6. – Perun

Kommentar vom 23. Mai 2009 um 14:29

@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.
7. – Sergej Müller

Kommentar vom 23. Mai 2009 um 16:05

Hast du das Plugin vielleicht unter WP 2.8 beta installiert? Mit WP 2.7.x läuft bei mir und vielen meiner Bekannten sauber.
8. – Perun

Kommentar vom 23. Mai 2009 um 20:28

@Sergej,

unter 2.7.1
9. – Sergej Müller

Kommentar vom 23. Mai 2009 um 21:29

Merkwürdig. Hier ist auch ein Erfahrungsbericht, der von einem scheinbar funktionierenden Plugin berichtet: http://ocean90.de/blog/2009/05/14/plugin-wp-smushit/

Bin sehr glücklich mit dem Plugin. Bevor es das Plugin gab, hatte ich die Bilder manuell durch den Online-Dienst gejagt und dann erst in WordPress hochgeladen. Jetzt passiert alles in einem Abwasch.
10. – Perun

Kommentar vom 23. Mai 2009 um 21:37

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.
11. – ocean90

Kommentar vom 24. Mai 2009 um 22:16

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ß
12. – ocean90

Kommentar vom 26. Mai 2009 um 11:41

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

Gruß
13. – Perun

Kommentar vom 27. Mai 2009 um 18:40

@ocean90,

darauf habe ich nicht geachtet … *überleg* das könnte einer der Ursachen sein. Das müsste ich mal testen.
14. – WordPress-Websites beschleuinigen 4: ein Zwischenergebnis » Peruns Weblog

Pingback vom 06. Juni 2009 um 22:34

[...] drei Artikeln vorher (hier, hier und hier) habe ich einiges beschrieben, wie man WordPress-Website beschleunigen kann. Das [...]

Einen Kommentar hinterlassen

Name (erforderlich)

Mail (wird nicht veröffentlicht) (erforderlich)

Website

XHTML (folgende Tags sind erlaubt): <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> . Kommentar-Vorschau ist aktiviert (Javascript wird benötigt).

Code-Beispiele: damit die Code-Beispiele richtig angezeigt werden müssen die Sonderzeichen maskiert werden (z. B. < zu <).

Live-Vorschau

1. – Sergej Müller

Kommentar vom 14. Mai 2009 um 16:16

Sehr schöner Hinweis, Vladimir.

Ich empfehle und nutze selbst das WordPress-Plugin für smush.it, welches mir meine Bilder direkt beim Upload in der Größe minimiert. Dazu hatte ich mal einen Erfahrungsbeitrag verfasst: http://playground.ebiene.de/752/wordpress-plugin-bilder-beim-upload-optimieren/

2. – micha149

Kommentar vom 14. Mai 2009 um 16:45

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

3. – Perun

Kommentar vom 14. Mai 2009 um 16:54

@Sergej,

danke für den Hinweis. Werde ich auf jeden Fall testen.

4. – Ralf

Kommentar vom 14. Mai 2009 um 21:26

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.

5. – martin

Kommentar vom 14. Mai 2009 um 22:25

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 …

6. – Perun

Kommentar vom 23. Mai 2009 um 14:29

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.

7. – Sergej Müller

Kommentar vom 23. Mai 2009 um 16:05

Hast du das Plugin vielleicht unter WP 2.8 beta installiert? Mit WP 2.7.x läuft bei mir und vielen meiner Bekannten sauber.

8. – Perun

Kommentar vom 23. Mai 2009 um 20:28

unter 2.7.1

9. – Sergej Müller

Kommentar vom 23. Mai 2009 um 21:29

Merkwürdig. Hier ist auch ein Erfahrungsbericht, der von einem scheinbar funktionierenden Plugin berichtet: http://ocean90.de/blog/2009/05/14/plugin-wp-smushit/

Bin sehr glücklich mit dem Plugin. Bevor es das Plugin gab, hatte ich die Bilder manuell durch den Online-Dienst gejagt und dann erst in WordPress hochgeladen. Jetzt passiert alles in einem Abwasch.

10. – Perun

Kommentar vom 23. Mai 2009 um 21:37

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.

11. – ocean90

Kommentar vom 24. Mai 2009 um 22:16

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ß

12. – ocean90

Kommentar vom 26. Mai 2009 um 11:41

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

13. – Perun

Kommentar vom 27. Mai 2009 um 18:40

@ocean90,

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

14. – WordPress-Websites beschleuinigen 4: ein Zwischenergebnis » Peruns Weblog

Pingback vom 06. Juni 2009 um 22:34

[...] drei Artikeln vorher (hier, hier und hier) habe ich einiges beschrieben, wie man WordPress-Website beschleunigen kann. Das [...]

Peruns Weblog - Webwork und Internet