La balise meta viewport indique aux navigateurs mobiles quelle largeur donner à la zone de mise en page et quel zoom appliquer au départ. Presque tous les sites devraient utiliser exactement cette ligne dans le <head> :
<meta name="viewport" content="width=device-width, initial-scale=1">Sans elle, les téléphones supposent que la page est conçue pour le desktop, la mettent en page sur environ 980 px de large et la réduisent pour qu’elle tienne à l’écran. Votre CSS responsive n’a jamais l’occasion de s’appliquer.
Ce qui se passe sans balise meta viewport
Quand les premiers smartphones sont apparus, la plupart des sites étaient conçus pour des écrans d’ordinateur. Pour pouvoir les afficher, les navigateurs mobiles faisaient comme s’ils avaient une « zone de mise en page » de taille desktop (980 px dans Safari iOS et Chrome pour Android) et dézoomaient pour que toute la page tienne à l’écran. Les utilisateurs zoomaient ensuite avec deux doigts pour lire.
Ce comportement par défaut s’applique toujours à toute page sans balise viewport. Sur un téléphone de 390 px de large, une telle page :
- annonce au CSS et à JavaScript une zone d’affichage d’environ 980 px ;
- ne correspond jamais à des media queries comme
(max-width: 600px); - affiche le texte à environ 40 % de sa taille prévue.
Si votre site ressemble à une minuscule page desktop sur téléphone, vérifiez d’abord cette balise. C’est la cause la plus fréquente parmi celles décrites dans pourquoi un site s’affiche mal sur mobile.
Ce que signifie chaque valeur
| Valeur | Signification | Recommandée |
|---|---|---|
width=device-width |
Donne à la zone de mise en page la largeur de l’appareil en pixels CSS (par exemple 390 sur de nombreux iPhone) | Oui |
initial-scale=1 |
Démarre à 100 % de zoom, 1 pixel CSS correspondant à 1 pixel indépendant de l’appareil | Oui |
minimum-scale |
Zoom minimal autorisé | Rarement utile |
maximum-scale |
Zoom maximal autorisé | Évitez les valeurs inférieures à 5 |
user-scalable=no |
Désactive le zoom à deux doigts | À éviter |
width=1024 (nombre fixe) |
Impose une largeur de mise en page fixe | À éviter sur un site responsive |
viewport-fit=cover |
Étend la page sous l’encoche et les coins arrondis | Seulement avec des marges safe area |
interactive-widget |
Contrôle la façon dont le clavier à l’écran redimensionne la page | Facultatif |
Pourquoi il ne faut pas désactiver le zoom
user-scalable=no et maximum-scale=1 empêchent de zoomer. La page devient difficile, voire impossible, à lire pour les personnes malvoyantes, et cela contredit l’exigence des WCAG selon laquelle le texte doit pouvoir être agrandi jusqu’à 200 %. Lighthouse le signale dans son audit d’accessibilité.
Les développeurs l’ajoutent souvent pour empêcher Safari sur iOS de zoomer sur les champs de formulaire. La bonne solution est une taille de police d’au moins 16 px dans les champs :
input, select, textarea { font-size: 1rem; }Safari iOS récent ignore de toute façon user-scalable=no pour le zoom à deux doigts : la balise pénalise surtout les autres navigateurs.
viewport-fit=cover et zones de sécurité
Sur les téléphones avec encoche, Dynamic Island ou coins arrondis, les navigateurs gardent par défaut la page dans un rectangle sûr. viewport-fit=cover permet à la page d’occuper tout l’écran, ce qui peut être souhaitable pour un design bord à bord. Vous devez alors tenir vous-même le contenu à l’écart de l’encoche et de l’indicateur d’accueil :
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">.site-header {
padding-left: max(1rem, env(safe-area-inset-left));
padding-right: max(1rem, env(safe-area-inset-right));
}
.bottom-bar { padding-bottom: env(safe-area-inset-bottom); }Testez en paysage, où l’encoche se trouve sur le côté.
interactive-widget et le clavier à l’écran
Quand le clavier s’ouvre, les navigateurs réduisent soit la seule zone d’affichage visuelle (le comportement par défaut de Chrome et Safari), soit toute la mise en page. La valeur récente interactive-widget permet de choisir :
resizes-visual: par défaut ; la mise en page garde sa taille et le clavier en recouvre une partie ;resizes-content: la zone de mise en page rétrécit, donc les éléments en100dvhet les pieds de page fixes remontent au-dessus du clavier ;overlays-content: rien n’est redimensionné ; gérez vous-même la situation avec l’API VirtualKeyboard.
La prise en charge varie selon les navigateurs (les navigateurs Chromium la gèrent ; vérifiez l’état actuel avant de vous y fier) : testez donc de toute façon les formulaires sur de vrais téléphones.
Les valeurs obsolètes que vous pouvez supprimer
shrink-to-fit=noétait un contournement pour iOS 9 et n’a plus aucun effet.target-densitydpiétait une ancienne valeur Android, désormais ignorée.<meta name="HandheldFriendly">et<meta name="MobileOptimized">datent des téléphones à touches.
Comment vérifier votre balise viewport
- Affichez le code source de la page et cherchez
name="viewport". Il doit y en avoir exactement une. - Lancez un audit Lighthouse en mode mobile (mode d’emploi) : il signale les balises viewport absentes ou qui bloquent le zoom.
- Ouvrez la page en vue mobile. Dans le mode appareil des DevTools, ou dans Mobile View Extension qui charge la page à la taille d’un vrai téléphone, une page sans balise paraît dézoomée, avec un texte minuscule.
Questions fréquentes
Quelle est la bonne balise meta viewport ?
<meta name="viewport" content="width=device-width, initial-scale=1">. N’ajoutez viewport-fit=cover que si vous concevez des mises en page plein écran et gérez les zones de sécurité.
La balise meta viewport est-elle nécessaire pour un site responsive ?
Oui. Sans elle, les navigateurs mobiles mettent les pages en page sur environ 980 px de large, et les media queries mobiles ne s’appliquent jamais.
Est-ce une mauvaise idée d’utiliser user-scalable=no ?
Oui, pour l’accessibilité. Cela empêche les utilisateurs d’agrandir le texte. Corrigez plutôt le zoom indésirable sur les champs de formulaire avec une taille de police de 16 px.