Viewport-Meta-Tag prüfen
Das Viewport-Meta-Tag sagt einem mobilen Browser, welche Breite er für die Seite annehmen soll. Es ist eine einzige Zeile, bestimmt aber das gesamte mobile Erlebnis: Fehlt es, wird die Seite als Desktop-Breite angenommen und passend verkleinert; ist es falsch konfiguriert, entsteht waagerechtes Scrollen; ist es zu stark eingeschränkt, können Menschen mit eingeschränktem Sehvermögen die Seite überhaupt nicht vergrößern. Dieses Werkzeug betrachtet das Tag nicht nur als Ganzes, es zerlegt es Direktive für Direktive und sagt Ihnen, was jede davon bedeutet.
Was passiert ohne Viewport-Tag?
Um mit älteren Desktop-Websites verträglich zu bleiben, nehmen mobile Browser für eine Seite ohne Viewport-Tag rund 980 Pixel Breite an und verkleinern sie dann auf die Bildschirmgröße. Die Besucherin sieht eine herausgezoomte Desktop-Seite: Der Text ist zu klein zum Lesen, die Links sind zu klein, um sie mit dem Finger zu treffen. Google wertet eine solche Seite als nicht mobilfreundlich, und da der Großteil des Suchtraffics mobil ist, bedeutet das unmittelbaren Verlust bei Platzierung wie Abschlüssen.
Warum ist width=device-width unverzichtbar?
Diese Direktive weist die Seite an, sich an der tatsächlichen Breite des Geräts auszurichten, auf dem sie betrachtet wird. Jede CSS-Media-Query eines responsiven Entwurfs arbeitet mit dieser Breite; ohne die Direktive werden Media-Queries gegen 980 Pixel geprüft, und Ihr mobiles Layout greift nie. Einen festen Wert zu schreiben (etwa width=1024) ist noch schlechter: Jedes Gerät nimmt dann diese Breite an, schmale Bildschirme bekommen eine waagerechte Bildlaufleiste, und Inhalte laufen über.
Zoom blockieren: der häufigste Fehler bei der Barrierefreiheit
user-scalable=no oder maximum-scale=1 hinzuzufügen hindert Nutzer daran, mit zwei Fingern zu zoomen. Die Einstellung wird meist in guter Absicht gesetzt, damit der Entwurf nicht zerbricht oder der Bildschirm beim Antippen eines Formularfelds nicht springt. Der Preis ist jedoch hoch: Menschen mit eingeschränktem Sehvermögen müssen zoomen, um Text lesen zu können, und diese Einstellung schließt sie vollständig von der Seite aus. WCAG 2.1 SC 1.4.4 verlangt mindestens zweifache Vergrößerung; gute Praxis erlaubt bis zum Fünffachen. In einem responsiven Entwurf mit ausreichender Schriftgröße erübrigt sich diese Einschränkung ohnehin. Sie gehört zu den Punkten, die Prüfungen der Barrierefreiheit unmittelbar als Fehler melden und die sich am leichtesten beheben lassen.
initial-scale, minimum-scale und maximum-scale
initial-scale legt fest, mit welcher Zoomstufe die Seite öffnet; der Standardwert ist 1 und bedeutet, dass die Seite unverändert und ohne Skalierung gezeigt wird. minimum-scale und maximum-scale setzen die Grenzen, bis zu denen eine Nutzerin heraus- und hineinzoomen darf. An diesen beiden zu drehen ist selten nötig, und maximum-scale auf einen niedrigen Wert festzunageln erzeugt das oben beschriebene Problem der Barrierefreiheit. Der praktische Rat: Schreiben Sie initial-scale=1 und lassen Sie die anderen beiden undefiniert.
Bildschirme mit Notch: viewport-fit=cover
Auf Bildschirmen mit Notch oder abgerundeten Ecken hält der Browser Inhalte standardmäßig innerhalb des sicheren Bereichs und lässt an den Rändern Abstand. viewport-fit=cover hebt diese Grenze auf und lässt den Entwurf sich über den ganzen Bildschirm ausbreiten. Es allein hinzuzufügen ist allerdings riskant: Inhalte können unter der Notch oder der Home-Leiste verschwinden. Richtig eingesetzt wird cover zusammen mit den Safe-Area-Variablen im CSS, etwa env(safe-area-inset-top), um wichtige Elemente zu schützen.
Die Bildschirmtastatur und interactive-widget
Wird auf dem Handy ein Formularfeld angetippt, kann die aufklappende Bildschirmtastatur fast die Hälfte des sichtbaren Bereichs verdecken. Die Direktive interactive-widget bestimmt, wie sich diese Verengung in CSS und JavaScript niederschlägt: ob der sichtbare Bereich oder der Inhaltsbereich neu berechnet wird oder ob die Tastatur den Inhalt schlicht überlagert. Auf formularlastigen Seiten hilft sie, das Verrutschen fest positionierter Schaltflächen beim Öffnen der Tastatur zu verhindern. Sie nicht zu definieren ist kein Fehler; das Standardverhalten reicht für die meisten Seiten.
Ihre Fragen
Häufig gestellte Fragen
Wie lautet das richtige Viewport-Tag?
Für die meisten Websites gibt es genau eine richtige Zeile: <meta name="viewport" content="width=device-width, initial-scale=1">. Alles darüber hinaus dient Sonderfällen und sollte nur hinzugefügt werden, wenn Sie es wirklich brauchen.
Schadet user-scalable=no der SEO?
Es gibt keine Aussage, dass damit eine unmittelbare Abwertung der Platzierung einhergeht, doch Prüfungen zur Barrierefreiheit melden es als Fehler, und Ihr Lighthouse-Wert für Barrierefreiheit sinkt. Das eigentliche Problem liegt auf der Nutzerseite: Besucher mit eingeschränktem Sehvermögen können die Seite nicht vergrößern, also nicht lesen, und gehen wieder. Ein responsiver Entwurf braucht diese Einstellung nicht.
Ich habe ein Viewport-Tag, die Website sieht auf dem Handy trotzdem kaputt aus. Warum?
Das Viewport-Tag ist nur die Ausgangsbedingung der Skalierung; das Layout selbst entsteht im CSS. Auch bei richtigem Tag führen Container mit fester Pixelbreite, überlaufende Tabellen, zu große Bilder oder fehlende Media-Queries zu waagerechtem Scrollen. Dieses Werkzeug prüft das Tag; für Layout-Überläufe müssen Sie ins CSS der Seite schauen.
Ist mehr als ein Viewport-Tag ein Problem?
Ja. Welches gilt, überlässt man dem Browser, und das Verhalten wird unvorhersehbar. Meist rührt es daher, dass Theme und Plugin oder Vorlage und Komponente je ein eigenes Tag ausgeben. Lassen Sie nur eines stehen.
Sind initial-scale und width=device-width nicht dasselbe?
Nein, sie tun Verschiedenes. width=device-width legt fest, auf welcher Breite das Layout beruht; initial-scale legt fest, mit welcher Zoomstufe die Seite öffnet. Beides gemeinsam zu definieren verhindert zudem die Skalierungssprünge, die manche ältere Browser beim Drehen des Geräts zeigen.
Sollte ich viewport-fit=cover hinzufügen?
Nur wenn Ihr Entwurf sich über den gesamten Bildschirm erstrecken soll. Wenn Sie es hinzufügen, müssen Sie den sicheren Bereich mit den CSS-Variablen env(safe-area-inset-*) schützen, sonst können Überschriften und Schaltflächen unter der Notch oder der Home-Leiste landen. Brauchen Sie es nicht, lassen Sie es weg.