Was ist der Viewport?

Der Viewport ist die sichtbare Fläche, auf der ein Browser — oder der Crawler — eine Seite zeichnet, gemessen in den Einheiten, mit denen Stilvorlagen arbeiten. Er ist nicht dasselbe wie die körperliche Größe des Bildschirms, und diese Unterscheidung ist der Ursprung fast der ganzen Verwirrung.

Auf einem Rechner fallen beide fast zusammen, und niemand merkt es. Auf einem Telefon nicht: Der Bildschirm hat sehr viele Punkte auf sehr wenig Fläche, der Browser arbeitet also mit einem anderen Maß als das Gerät.

Die Angabe, eines der Meta-Tags im Kopfbereich, verbindet die beiden. Sie sagt dem Browser, mit der wirklichen Breite des Geräts zu rechnen statt mit einer angenommenen — und ohne sie erscheint auch die bestgebaute anpassungsfähige Gestaltung geschrumpft und winzig.

Eine Jahreszahl hilft, denn sie erklärt, warum es die Angabe gibt. Als Telefone anfingen zu surfen, war fast keine Website für sie gedacht; damit sie benutzbar blieben, entschieden ihre Browser, einen breiten Bildschirm vorzutäuschen und das Ergebnis zu schrumpfen. Die Angabe entstand, um zu sagen: „Diese Seite weiß, was sie tut, schrumpf sie nicht.“

Daraus folgt etwas Praktisches: Das Standardverhalten ist bis heute das alte. Eine neue HTML-Datei, heute geschrieben, ohne diese Zeile, verhält sich wie eine Seite von vor fünfzehn Jahren. Kein Fehler des Browsers, sondern Rücksicht auf Altbestand.

Und eine Wortklärung, die Streit erspart: Der Viewport ist kein Element der Seite und nichts, das sich gestalten ließe. Er ist das Fenster, durch das geschaut wird — und deshalb verhalten sich die auf ihn bezogenen Einheiten anders als die, die einen Container messen. Das merkt man in jeder anpassungsfähigen Gestaltung mit fließender Schriftgröße.

Wenn jemand „die Breite des Bildschirms“ sagt, kann er drei Dinge meinen, und die gehören auseinandergehalten, bevor man irgendetwas bespricht: was das Gerät misst, was die Seite verwendet, und was der Browser annimmt, wenn man ihm nichts sagt — und was am Ende im Index landet.

Dieser dritte Wert erklärt das bekannte Symptom. Mobile Browser rendern die Seite mit einer Schreibtischbreite, wenn sie keine Angabe finden, und schrumpfen das Ergebnis dann, damit es hineinpasst. web.dev beziffert das auf ungefähr 980 Pixel, mit der Vorsicht, „normalerweise“ zu sagen.

Deshalb ist das Mittel kein Neuentwurf, sondern die Angabe der richtigen Breite. Erst ab dieser Angabe greifen die Regeln, die für kleine Bildschirme geschrieben wurden — vorher nicht.

Eine vierte Breite taucht auf, sobald jemand die Tastatur benutzt, und überrascht alle, die Formulare untersuchen: Beim Öffnen der Bildschirmtastatur ändert sich die sichtbare Fläche, ohne dass sich die Breite ändert. Gestaltungen, die Höhen am Viewport festmachen, verrutschen genau dort — in dem Moment, in dem jemand tippt.

Und eine Prüfung, die die ersten drei in einer Minute trennt: Sieh nach, welche Breite die Seite angibt, und vergleiche sie mit der, die der Browser meldet. Stimmen sie nicht überein, fehlt die Angabe oder sagt etwas anderes als angenommen — und alles Folgende, auch die Messungen zur Ladegeschwindigkeit, misst dann etwas anderes.

Die übliche Angabe sagt zwei Dinge: dass die Breite des Geräts verwendet werden soll und dass der Anfangsmaßstab der natürliche ist. Damit kommt die überwiegende Mehrheit der Websites aus, und mehr hinzuzufügen nimmt meist weg, statt zu geben.

Was nicht angegeben gehört, ist eine Sperre des Zooms. Jemanden am Vergrößern zu hindern ist eine Barriere für die Nutzererfahrung und für die Zugänglichkeit für alle mit müden Augen und löst kein echtes Gestaltungsproblem; wenn die Schrift nicht lesbar ist, repariert man die Schrift.

Ebenso wenig ergibt es Sinn, eine Breite in Pixeln festzuschreiben, statt die anpassungsfähige Gestaltung entscheiden zu lassen. Sie einzufrieren erzwingt seitliches Schieben auf schmaleren Geräten und verschenkt Platz auf breiteren — genau das Gegenteil dessen, was gewollt war.

Eine Anmerkung verdient der Fall, dass die Angabe stimmt und man trotzdem seitlich schieben muss. Fast immer liegt es nicht am Viewport, sondern an einem Element, das breiter ist als er: ein Bild ohne ALT-Attribut und ohne Breitenbegrenzung, eine starre Tabelle, ein Codeblock ohne eigenen Container. Das Symptom sieht nach Konfiguration aus, die Ursache steckt im Inhalt.

Und ein Fall, der sich bei Migrationen wiederholt: die doppelte Angabe. Zwei verschiedene Deklarationen im selben Kopfbereich — eine aus der Vorlage, eine aus einem Modul — überlassen das Ergebnis dem Zufall, welche gewinnt, und das kann sich zwischen Versionen ändern, ohne dass jemand etwas anfasst. Genau die Art Detail, die ein technisches SEO im ausgelieferten HTML findet und nicht am Bildschirm.

Google arbeitet nach der Mobile-First-Indexierung mit der mobilen Fassung der Seiten; was ein Crawler sieht, ist also das, was auf einem schmalen Bildschirm erscheint. Eine Seite ohne Viewport-Angabe zeigt sich ihm geschrumpft, mit unlesbarer Schrift und gedrängten Elementen.

Die Wirkung reicht bis in die Messwerte. Eine Gestaltung, die sich bei dieser Breite schlecht verhält, erzeugt Sprünge, die der CLS misst, und lädt häufig das Hauptbild in falscher Größe, was den LCP verschlechtert.

Und eine mittelbare Wirkung wird unterschätzt: Sieht die Seite auf dem Handy schlecht aus, geht der Besucher wieder — und das zeigt sich in der Absprungrate früher als in irgendeinem technischen Bericht.

Eine weitere Wirkung wird selten besprochen und ist ziemlich teuer: die auf die Bilder. Glaubt der Browser, einen breiten Bildschirm vor sich zu haben, wählt er aus den vorhandenen Varianten die zu dieser Breite passende und lädt ein weit größeres Bild als nötig — was auch Lazy Loading nicht behebt. Bezahlt wird das in Daten und in Zeit, besonders auf langsamen Verbindungen.

Und der Blick in die andere Richtung lohnt: Die richtige Angabe genügt nicht, wenn der Inhalt für eine Maus gedacht ist. Winzige Berührungsziele, Menüs, die nur beim Darüberfahren aufgehen, und Schrift unter der lesbaren Größe bleiben Probleme, auch nachdem der Viewport erklärt ist — und sie zeigen sich im Engagement früher als in jeder Prüfung.

Der erste ist, sie gar nicht anzugeben. Das klingt elementar und kommt weiter vor, vor allem auf einzelnen Seiten außerhalb der üblichen Vorlage: Kampagnenseiten, Rechtstexte, Dankeseiten — also die, die kaum je in der Sitemap stehen.

Der zweite ist die Zoomsperre, oben schon genannt, und sie verdient die Wiederholung, weil sie weiter aus alten Beispielen abgeschrieben wird, die in Foren kursieren.

Und der dritte ist, es nur durch Verkleinern des Rechnerfensters zu prüfen. Das ändert die Breite, bildet aber das Verhalten eines mobilen Browsers nicht nach; es braucht ein echtes Gerät oder eine Nachbildung, die das berücksichtigt — was ebenso für die Mobile-First-Indexierung gilt.

Ein vierter Fehler, typisch für große Websites: anzunehmen, was in der Vorlage steht, stehe überall. Es genügt ein getrennt gebauter Bereich — eine Kampagnenseite, ein Konfigurator, eine aus einem anderen System geerbte Zone —, damit es genau dort fehlt, wo bezahlter Verkehr ankommt.

Und der letzte, der leiseste: nach einem Neuentwurf nicht erneut nachzusehen. Die Angabe überlebt fast alles, weil niemand sie absichtlich anfasst, doch sie verschwindet lautlos, wenn der Kopfbereich des Dokuments umgebaut wird — und das Symptom, eine geschrumpfte Seite, gehört zu den wenigen, die eine Logfile-Analyse nicht zeigen kann, denn der Server hat genau das ausgeliefert, was verlangt wurde.