perun.net – WordPress & Webwork



Die großen Performance-Bremsen im Frontend 2

Von am 30. 06. 2010 um 15:33 – Aktualisiert am 18. 02. 2013 um 22:24

Der falsche Einsatz von Bildern kann eine große Performance-Bremse sein: falsches Format, nicht-optimiertes oder nicht skaliertes Bild etc. Die Lösungen sind einfach und entfalten schnell Ihre Wirkung.

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:

Gerade mal 32 KByte

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:

Gerade mal 8,6 KByte

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:

JPG und Artefakte

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:

Klicken um auf das Orignal zu kommen

Vergleiche die Dateigrößen des Originals und des Vorschaubildes

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:

Ausschnitt des großen Bildes

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.

Diesen Artikel weiterempfehlen:

Premium WordPress Themes

Verwandte Artikel:

 — 


11 Kommentare

  1. 1.Micha

    Kommentar vom 30.06.2010 um 15:47

    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?

  2. 2.Tom

    Kommentar vom 30.06.2010 um 15:58

    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". 8-O

  3. 3.Tom

    Kommentar vom 30.06.2010 um 15:59

    @Micha: setz in den Einstellungen die entsprechenden Größe auf 0. Dann werden sie nicht mehr erstellt.

  4. 4.Micha

    Kommentar vom 30.06.2010 um 16:36

    Danke, Tom. Funktioniert prima.

  5. 5.LexX Noel

    Kommentar vom 30.06.2010 um 18:05

    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. ;)

  6. 6. – Luigi

    Kommentar vom 30.06.2010 um 20:54

    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 ;)

  7. 7.Rückblick auf das WordCamp 2010 in Berlin - Weblog - Michael Jendryschik

    Pingback vom 04.07.2010 um 19:43

    [...] 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 [...]

  8. 8.Das WordCamp 2010 in Berlin – ein Rückblick » sebastian-gerth.com

    Pingback vom 06.07.2010 um 16:22

    [...] von CSS- und Javascript-Dateien, die Wahl der rich­ti­gen Plugins, ebenso wie die Ver­wen­dung ver­schie­de­ner Grafik-Formate. Eine Ver­wen­dung von Tools und Diens­ten wie Fire­bug, YSlow oder Ping­dom wurde zur [...]

  9. 9.Benni

    Kommentar vom 08.07.2010 um 10:41

    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. ;)

  10. 10.Rückblick: WordCamp 2010 | Webseiten-Infos.de

    Pingback vom 11.07.2010 um 17:18

    [...] Session von Vladimir beruhte inhaltlich im Wesentlichen auf bereits von ihm zuvor veröffentlichte Blogbeiträge [...]

  11. 11.WordPress: Plugins die ich einsetze | WordPress & Webwork

    Pingback vom 11.06.2011 um 20:46

    [...] 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 [...]

Tut mir Leid, aber die Kommentar-Funktion ist momentan deaktiviert.



Weblog der perun.net webwork gmbh mit Artikeln zum Thema WordPress, Webwork, und Internet.