Optimierung für Bildschirmauflösungen

»Optimiert für …«

800 × 600 Pixel gilt seit etlichen Jahren als Auflösung, für die eine Website »optimiert« wird. Das heißt in der Regel: Das Layout wird ungefähr auf eine Breite von 780 Pixeln festgezurrt, darunter werden horizontale Bildlaufleisten angezeigt. Das Ganze wird dann zentriert oder links angeordnet. Der möglicherweise entstehende freie Platz bleibt entweder frei oder wird vereinzelt durch auftauchende Werbebanner aufgefüllt. Zunehmend wird auch für 1024 × 768 Pixel »optimiert«, die magische Grenze liegt dann etwa bei 990 Pixeln.

Liquid, fluid, elastic, jello!

Nun gibt es verstärkt fließende und elastische Layouts oder auch Götterspeisen-Layouts als Alternativen zu festen Layouts. Mithilfe von JavaScript sind noch mehr anpassbare Alternativen denkbar. Björn Seibert nennt einige prominente Beispiele.

Wir optimieren uns zu Tode

Trotz dieser Möglichkeiten, ein Layout in verschiedener Hinsicht anpassungsfähig zu gestalten, ist die Mehrheit aller Websites nach wie vor für eine Auflösung »optimiert«. Das liegt in den seltensten Fällen daran, dass das Design stark mit Pixelgrafiken arbeitet, die eine Flexibilität einschränken. Anwender mit höheren Bildschirmauflösungen bekommen daher oft winzige Sites zu Gesicht, die nur einen Teil des Bildschirms ausfüllen. Die Schriftgröße passt sich selbstverständlich auch nicht der größeren Auflösung an. Im Endeffekt haben wir also ein auf 800 × 600 Pixel »optimiertes« Web. Dieser (vermeintliche) kleinste gemeinsame Nenner hemmt die Vielfalt der Layouts. Der Wechsel auf 1024 × 768 ändert dabei nichts grundlegendes, sondern läutet nur die nächste Phase des Optimierungswahns ein.

Viewport statt Bildschirmauflösung

Zunächst einmal muss festgestellt werden, dass die Bildschirmauflösung nicht entscheidend ist. Auch die Browserfenstergröße ist für die Website nachrangig. Vielmehr ist die Breite des Bereiches wichtig, die der Website tatsächlich zur Verfügung steht. Der Fachbegriff für diesen Bereich ist Viewport. Thomas Lahn hat diese grundsätzlichen Erkenntnisse einmal auf die Formel gebracht:

Auflösung != Desktopgrösse != Browserfenstergrösse != Anzeigebereich. [psf 3.7]

PointedEars‘ Standard-Floskeln

Viewport-Breite untersuchen

Zahlreiche Counter und Tracker fragen mittels JavaScript die Bildschirmauflösung ab, sodass der Webautor eine schöne, bunte Statistik über die verwendeten Auflösungen bekommt. Diese Statistiken dienen dann als Killerargumente dafür, dass man eine bestimmte Auflösung nicht mehr berücksichtigen muss und dass man getrost für eine bestimmte Auflösung »optimieren« kann.

Interessant für Design-Entscheidungen ist hingegen eher die Viewport-Breite sowie ihr Verhältnis zur Auflösung. Die wenigsten Statistik-Scripte vermessen den Viewport. Unter diesen wenigen ist Mint, siehe Beispielstatistiken.

Hier im SELFHTML-Weblog habe ich eine ähnliche Statistik installiert, die mit JavaScript die Viewport-Breite sowie die Bildschirmauflösung untersucht und im Hintergrund zum Server übertragt, wo sie in einer Datenbank gespeichert wird. Dazu benutze ich diesen einfachen Scriptschnipsel von Peter-Paul Koch. Das komplette Script »spioniert« zudem noch einige andere Javascript-Eigenschaften aus, vor allem zu Studienzwecken.

Sicher ist dieses Weblog in keinster Weise repräsentativ, wird es doch vornehmlich von Technik-affinen Webbastlern frequentiert. Da ich hier sowieso als Alternative zur wenig aussagekräftigen Webalizer-Statistik eine JavaScript-Statistik etabliere wollte, bot sich erst einmal dieses Studienobjekt an. Zuerst begann ich damit, die Viewport-Größe aufzuzeichnen, später auch die Auflösung. Da das Layout dieses Weblogs im Allgemeinen bei verschiedenen Viewport-Breiten passabel aussieht, gehe ich davon aus, dass die Ergebnisse nicht durch an unsere Site angepasste Viewport-Breiten verfälscht wird.

Statistik über die Auflösungsbreite

Vorab, welche Auflösungen sind verbreitet, wenn wir der Eigenschaft screen.width Glauben schenken?


Zeitraum: 2006-04-01 bis 2006-10-30. Gezählte »Besucher«: 87155. Ein »Besucher« ist definiert als eine eindeutige Kombination aus IP-Adresse und HTTP-User-Agent.

Eine Auflösungsbreite von 800 Pixeln scheint hier demnach nahezu überhaupt nicht mehr verbreitet.

Statistik über die Viewport-Breite

Interessant wird nun die Viewport-Statistik. Anstatt ein Verteilungsdiagramm zu zeichnen, bin ich folgendermaßen vorgegangen: Ich habe eine kumulative Statistik erstellt, in der zu einer bestimmten Breite zu sehen ist, wieviel Prozent aller »Besucher« einen Viewport haben, in den diese Breite hineinpasst. Auf diese Weise sieht man, wieviel Prozent der »Besucher« bei einer bestimmten Breite noch mithalten können beziehungsweise bei wieviel Prozent eine geringere Viewport-Breite gemessen wurde.


Zeitraum: 2006-02-25 bis 2006-10-30. Gezählte »Besucher«: 69375

In einem weiteren Diagramm habe ich den interessanten Ausschnitt vergrößert dargestellt:

Diese Diagramme sind so zu lesen: 80,6 Prozent aller »Besucher« haben eine Viewport-Breite größer als 1000 Pixel, hingegen nur 50,1 Prozent einen Viewport größer als 1040 Pixel.

Diese Statistik ist für mich erstaunlich, denn sie bestätigt viele Vermutungen. Obwohl eine Auflösungsbreite von 1024 und höher klar dominiert, gehen auf dem Weg von 780 Pixel bis 1000 Pixel Viewport-Breite 16 Prozent der »Besucher« verloren. Dann kommt der starke Abfall, der durch die Auflösungsbreite bedingt ist (ca. 30 Prozent). Diese Kurve legt die Vermutung nahe, dass viele Browserfenster nicht maximiert sind bzw. innerhalb des Browserfensters noch andere Elemente in der Horizontalen Raum einnehmen. Vermutlich sind ICQ, Skype und ähnliche Programme, die ständig als Leiste links oder rechts sichtbar sind, für eingeengte Browserfenster verantwortlich. Und einige Anwender ziehen das Browserfenster absichtlich nicht größer. Was die angenommene Differenz von Browserfensterbreite und Viewport-Breite angeht, so sind vermutlich geöffnete Sidebars verantwortlich, über die fast alle Browser verfügen. Insbesondere Opera stellt darin alle möglichen Browserfunktionen dar.

Statistik über die Viewport-Breite bei bestimmten Auflösungen

Während die beiden vorigen Diagramme die Viewport-Breite bei allen Auflösungen berücksichtigten, habe ich weitere Diagramme erstellt, die die Viewport-Breite bei den verbreitesten Auflösungen zeigen, jeweils gleichsam kumulativ. Dieser Vergleich ist etwas heikel, da ich wie gesagt nur von einer recht kleinen Messbasis hinsichtlich der Auflösungsbreite ausgehen kann.

800 Pixel:
1024 Pixel:
1280 Pixel:

Zeitraum jeweils 2006-02-25 bis 2006-10-30. Messbasis: 1169 »Besucher« bei 800 Pixel, 29042 »Besucher« bei 1024 Pixel und 39894 »Besucher« bei 1280 Pixel.

In diesen Diagrammen zeigt sich, dass von der Auflösung keinesfalls auf eine Standard-Viewport-Breite geschlossen werden kann. Wenn man für die Auflösungsbreite 1024 Pixel »optimiert« und von einer Viewport-Breite von 980 Pixeln ausgeht, so »erreicht« man tatsächlich weniger als 80 Prozent aller Besucher mit dieser Auflösung. Noch eklatanter ist es bei der Auflösungsbreite von 1280 Pixeln. Hier gelten die oben geäußerten Vermutungen ganz besonders: Das Browserfenster füllt den Bildschirm nicht aus, zudem füllt der Viewport nicht das Browserfenster aus. Mit größerer Auflösung steht Websites also keinesfalls mehr Raum zur Verfügung. Für 1280 Pixel »optimieren« wäre widersinnig, denn würde man die hinzu gewonnene Breite nutzen, so würde man die Besucher dazu zwingen, den Viewport zu vergrößern.

Disclaimer

In meinen Messungen und Auswertungen sind viele Faktoren nicht berücksichtigt. Nicht zuletzt schließe ich methodische Fehler meinerseits nicht aus.

Der Schluss, dass eine bestimmte feste Layout-Breite einen gewissen Prozentsatz der Besucher »ausschließt«, ist sicher nicht möglich. Die gemessenen Viewport-Breiten lassen nur Hypothesen darüber zu, was für die Differenz zwischen Auflösung und Viewport verantwortlich ist. Browser-Sidebars können problemlos eingeklappt werden und Browserfenster meist auch maximiert werden, wenn die Website dies erfordert und der Besuche die Site in ihrer Gänze betrachten will. Er wird lediglich dazu gezwungen, den Viewport anzupassen. Mein SELFHTML-Kollege Roland Skop schlägt daher vor, zu messen, ob viele Leute die Fenstergröße nach dem Laden der Website ändern. Interessant wären dann die Ausgangs- und die Endbreite. Dies wäre mit einigem Aufwand messbar, wenngleich auch nicht sehr zuverlässig.

Dieser Bericht ist bewusst voreilig, denn ich habe nur Daten in diesem wenig relevanten fachlichen Weblog gesammelt. Ich werde meine Untersuchungen fortführen und ausweiten. Dieser Artikel wird entsprechend aktualisiert. Daher bitte ich darum, Fehlerkorrekturen per E-Mail einzureichen und dazu nicht die Kommentarfunktion zu nutzen.

Download

Alle obigen Diagramme liegen samt Werte-Tabellen als OpenOffice-Calc-Dateien vor:

Die PHP-Scripte, mit denen ich die Auswertung vorgenommen habe, stelle ich gerne auf Wunsch zur Verfügung. Leider bin ich bisher noch nicht dazu gekommen, ein einfaches Download-Zip mit Scripten für PHP/MySQL zusammenzustellen.

51 Kommentare » Schreibe einen Kommentar

  1. Danke an alle für die Kommentare, die wichtige Aspekte in die Diskussion eingebracht haben!

    Nach der riesigen Textmenge von 50 Kommentaren, die zum Teil separate Diskussionen starteten und zum Teil weit vom Thema des Artikels abschweiften, möchte ich die Kommentare nun schließen.

    Die Kommentarfunktion ist für solchen allgemeinen Austausch sowie für Grundsatzdiskussionen eher ungeeignet, dafür steht weiterhin unser Forum offen. Siehe auch unser erster Blogeintrag mit Anmerkungen zum Zweck der hiesigen Kommentarfunktion.

    Ich muss auch gestehen, dass ich den Eindruck habe, dass manche Kommentatoren den Artikel anscheinend missverstanden haben oder sich nicht mit den kritischen Kernaussagen des Artikels auseinandergesetzt haben. Roland hatte das in seinem Kommentar ganz gut auf den Punkt gebracht.

    Meine Absicht war gerade nicht, die »Optimierung« für irgendwelche Auflösungen oder vermeintlich ideale Layout-Breiten zu empfehlen oder die Entwicklung von »Auflösungsweichen« voranzutreiben. Gerade diese Praxis galt es mir mit stichhaltigen Argumenten grundsätzlich zu hinterfragen, ohne dabei eine Lösung vorzustellen, die von sich behauptet, das Nonplusultra zu sein.