Da die User wie auch Google immer mehr Wert auf die Lade-Geschwindigkeit einer Seite wert legen sollte man als Webenwickler, wie auch als Webdesigner seine Seiten möglichst so gestalten, dass sie schnell vom Server an den Client ausgeliefert werden können. Die zwei Grundlegenden Dinge hierfür sind:

  1. So wenig Content wie möglich
  2. So wenig HTTP-Requests wie möglich.

Für den ersten Punkt gibt es diverse Ansätze. Als erstes solle natürlich der generierte HTML-, CSS- und JavaScript-Code so gering und komprimiert wie möglich gestaltet werden. Zu diesem Thema und gerade zum Punkt Komprimierung von JavaScript und CSS mit Hilfe des Closure Compilers von Google habe ich heute ja schon einen kleinen Artikel verfasst.

Ich möchte hier eine kleine Hilfestellung zu Punkt 2. geben. Eine Möglichkeit, den die Anzahl der HTTP-Requests zu minimieren ist es Hintergrundgrafiken in einer Datei zusammenzufassen. So wird bei der Kommunikation zwischen Client und Server nur ein einziger HTTP-Requests benötigt um diese Datei bereitzustellen. Das zerschneiden der Bilder und somit die Zuordnung auf die einzelnen Dom-Elemente wird dann per CSS background-image und background-position erledigt. Dieses Verfahren bezeichnet man als CSS Sprites.

div.bg_image1,
div.bg_image2
{
   background-image: url(sprite.gif);
   width: 120px;
   width: 60px;
}

div.bg_image1
{
   background-position: 0 -120px;
}

div.bg_image2
{
   background-position: 0 -240px;
}

Aber wieso überhaupt die HTTP-Requests minimieren? …


Das Problem der HTTP-Requests:

Der Grund darin, dass die Ladezeit von Websites oft recht langsam ist, ist eingentlich im HTTP-Protokoll verankert. Dieses ist nämlich ein sogenanntes zustandsloses Protokoll. Soll heißen, dass alle Anfragen, selbst die von ein und dem Selben Client,  immer als voneinander unabhängige Transaktionen behandelt werden. Leider ist es nun auch so, dass jeder Browser auch nur eine begrenzte Anzahl von parallelen HTTP-Requests aufbauen kann.

Nehmen wir mal an, dass in eurem Browser nur eine maximale Anzahl von 4 Requests konfiguriert ist. Sollen nun aber 5 Ressourcen (Bilder, CSS, JavaScript, Flash etc.) vom Server abgerufen werden muss der fünfte Request warten bis einer der ersten vier beendet ist. Hier könnt Ihr euch vorstellen, dass es zu ganz schön langen Warteschlangen kommen kann umso mehr Bilder oder sonstige externe Ressourcen nachgeladen werden müssen.

Da man nun die Konfigurationen und Limitierungen der Client-Browser nicht beeinflussen kann, kann man nur versuchen die Anzahl der HTTP Request dadurch zu verringern, indem man möglichst wenig externe Ressourcen benötigt.


CSS-Sprites und das Problem mit background-repeat:

Kommen wir also zurück zu den CSS-Sprites. Wie schon erwähnt können wir also mehrere Hintergrund-Bilder in einer Datei zusammenfassen und dann diese einzeln über background-position im CSS ansprechen. Leider, und dass war mein Problem funktioniert diese Methode nur in Verbindung mit den CSS-Angaben width und height. Diese bestimmen zusammen mit der x- und y-Pixel-Koordinate in der Angabe background-position die Größe des Bildes welches letztendlich als Hintergrundbild für das entsprechende HTML-Element benutzt werden soll. Möchte man nun also auch für die Hintergrundbilder Sprites verwenden weche sich per background-repeat wiederholen sollen, so muss man einen kleinen aber einfachen Trick anwenden.


Die Lösung

Ich musste auch erst überlegen, habe mir dann aber einfach zwei weitere Sprite-Image-Dateien gebastelt. Die erste hat eine Breite von genau einem Pixel und ich nenne sie mal sprite_y.gif und die zweite hat eine Höhe von einem Pixel (sprite_x.gif). In die sprite_y.gif kommen nun alle sich auf der x-Achse wiederholenden (background-repeat: repeat-x;)  Bilder untereinander und in die sprite_x.gif-Datei kommen alle sich auf der y-Achse wiederholenden (background-repeat: repeat-y;)  Bilder nebeneinander. Wenn wir jetzt die jeweilige x- oder y-Sprite-Datei im CSS angeben können wir getrost background-repeat benutzen und das Hintergrundbild wiederholt sich wie gewünscht.

Ähnliche Artikel: