accessBlog

Aktuelles zum Thema Barrierefreies Webdesign.

Neben den in der letzten Folge behandelten CSS-Dateien gibt es selbstverständlich auch bei den verwendeten Grafiken erheblichen Optimierungsbedarf. Auch hier gilt: so viele und so groß wie nötig und so wenige und so klein wie möglich.

Aber flott, ey!

Dabei geht es nicht nur um die reinen Dateigrößen: eine übermäßige Anzahl von Grafikdateien in einer Seite wird den Aufbau schon alleine wegen des Overheads für Anfrage und Versand der Dateien merklich verlangsamen. Daher setzen wir seit dem Relaunch die sog. CSS-Sprite-Technik ein, bei der verschiedene Grafiken je nach Verwendungszweck gruppiert und zu einer Datei kombiniert werden, die dann immer nur in Ausschnitten angezeigt wird.

Ein Beispiel: in der Hauptnavigation unserer Seiten verwenden wir Ordnungszahlen in Form von Grafiken. Jeder dieser fünf Navigationspunkte hat drei Zustände – nach Altväter-Art wären dies 15 GIFs gewesen, jedes auf einen andersfarbigen Hintergrund geglättet. So hätte der Browser 15 Dateien anfordern müssen, der Server hätte diese 15 Dateien verschicken müssen, und alle hätten sich nacheinander durch die Leitung gedrängelt.

Da die Ziffern aber eigentlich halbtransparent sind und sich zwei der drei Zustände nur durch die (durchscheinende) Hintergrundfarbe unterscheiden, kann man sich die Arbeit sparen und die Grafiken gleich als 24 bit-PNGs mit Alphakanal ablegen. Wenn man diese dann zu einer Datei kombiniert, hat man die o.g. Sprites, die per CSS auf die Höhe der Zeilenbox beschnitten und verschoben werden (hier die Grafikdatei: oz.png). Resultat: 14 gesparte Anfragen an den Server und ein paar Zeilen mehr CSS-Code. Das ›mehr‹ an Dateigröße für die höhere Farbtiefe ist im Endeffekt eigentlich eine erhebliche Ersparnis.

Auch diese Technik hat ihre Grenzen: sämtliche Bilder müssen zur Darstellung entkomprimiert werden und hinterlassen unter Umständen einen ganz ordentlichen Fußabdruck im Arbeitsspeicher. Gerade bei mobilen Endgeräten ist Vorsicht geboten, da zu große Grafiken evtl. nicht in den spärlichen Cache des Geräts passen und immer wieder neu angefordert werden müssen.

Ähnlich verhält sich dies bei den Piktogrammen, mit denen Seitenbereiche gekennzeichnet werden – diese sind zwar ebenfalls 24 bit-PNGs mit 8 bit-Alphakanal und damit wesentlich größer als 8 bit-GIFs oder PNGs mit begrenzter Farbpalette, aber auf Grund ihrer Transparenz sind sie universell auf beliebigen farbigen Hintergründen verwendbar (z.B.: navicons.png).

Ganz anders beim EfA-Logo – dies ist zwar auch freigestellt auf transparentem Hintergrund mit einem leichten Schlagschatten zur rechten Seite, als 24bit-PNG würde es aber mit über 20 kb zu Buche schlagen (s. logo-efa-32bit-Photoshop.png) – eindeutig zu viel des Guten. Allerdings sollte das Logo für die Druckversion wiederverwendet werden – und zwar ohne eine neue Datei anzufordern, nur um diese auf weissem Hintergrund darstellen zu können. Hier kommt der Bildeditor Fireworks zur Hilfe, der im Gegensatz zu Photoshop auch 8 bit-PNGs mit Alphatransparenz exportieren kann. Mit einem gefühlten Aufwand von zwei Minuten konnte hier die Dateigröße auf knapp über 6 kb reduziert werden (bei nahezu identischer Qualität, vgl. logo-efa-8bit-Fireworks.png).

Ein weiterer Vorteil der Bearbeitung in Fireworks ist, dass selbst der IE 6 auf einmal die Transparenz im Rahmen seiner Möglichkeiten sauber darstellt, statt wie bei 24 bit-PNGs in einem grauen Kasten. Hier die Darstellung links im Safari, rechts im IE 6:

8 bit-PNG zum Vergleich in Safari mit Alphakanal und in Internet Explorer 6 ohne Schatten

Die in vielen Anleitungen zu findende Empfehlung, dem IE 6 über den AlphaImageLoader-Filter auf die Sprünge zu helfen hat zwei gravierende Nachteile: zum einen fuktioniert dieser Filter nach unserer Erfahrung nicht bei CSS-Sprites, und zum anderen geht dadurch die Performance der Seite in den Keller (mehr noch im IE 6 als im IE 5.x – ersterer hat die Angewohnheit, dieses Skript bei 20 Bildern auch 20× auszuführen, was einer Zeitstrafe von ca. 1/10 Sekunde pro Bild entspricht).

Zum Schluß werden die Grafiken noch durch einen Optimierer wie Pngcrush (DOS, Unix) oder PNGThing (Mac) geschickt, um überflüssige Metadaten zu entfernen und die Dateigröße noch weiter zu reduzieren. Aber das war noch nicht alles:

Bilder ins CSS schreiben? Geht doch gar nicht!

Doch, geht: ein Teil der Grafiken liegt hier nicht mehr als Grafikdatei auf dem Server, sondern ist per data: URI direkt in das Style Sheet ›eingebettet‹. Dies spart wieder eine Menge Datenverkehr, da die Bilder nicht mehr während der Verarbeitung des Style Sheets vom Server angefordert werden müssen, sondern bereits vorliegen. Im CSS sieht das wie folgt aus – hier ein Beispiel für das grafische Bullet bei List Items ():

  1. ul li {
  2. list-style-image: url(data:image/png;base64,iVBORw0KGgoAAA ANSUhEUgAAAAYAAAAHCAQAAACBmfRmAAAAKUlEQVQI12OYKDWxY eJVIGyYKMUAJP5DYQMDUAzGuYrGQVGGbMB%2FJAgAx7o1X3W50i UAAAAASUVORK5CYII%3D);
  3. }

(Tipp: Ian Hickson stellt unter The data: URI kitchen ein Browser-basiertes Tool zu Verfügung, das Grafikdateien entsprechend konvertiert; weitere Beispiele für diese Technik finden Sie in den kommentierten Style Sheets, die wir unter Downloads veröffentlicht haben.)

Einen Nachteil hat die Methode: die Internet Explorer bis einschließlich Version 7 versteht sie nicht (wer hätte das gedacht!). Da wir aber per Conditional Comment ein separates IE-Style Sheet eingebunden haben, um dessen zahllose Bugs zu umschiffen, kommen die Aufrufe nach herkömmlicher Art einfach dort hinein und alle sind zufrieden:

  1. ul li {
  2. list-style-image: url("/img/chrome/list-item.png");
  3. }

Wenn Sie mehr über den Trendsport Extrem-Optimizing wissen wollen haben wir hier noch ein paar lehrreiche Links aus dem Yahoo! User Interface Blog:

Nachtrag: Mehr zu Grafikformaten ganz aktuell im Atzventzkalender der Webkrautz: »Das richtige Grafikformat für den richtigen Zweck«.