¿Qué es el viewport?

El viewport es la superficie visible en la que un navegador —o el rastreador— dibuja una página, medida en las unidades con las que trabajan las hojas de estilo. No es lo mismo que el tamaño físico de la pantalla, y esa distinción es el origen de casi toda la confusión.

En un ordenador ambas cosas casi coinciden y nadie lo nota. En un teléfono no: la pantalla tiene muchísimos puntos en muy poco espacio, así que el navegador trabaja con una medida distinta de la del aparato.

La etiqueta, una de las meta tags de la cabecera, es lo que conecta las dos. Le dice al navegador que cuente con el ancho real del dispositivo en lugar de con uno supuesto, y sin ella la web adaptable mejor construida se ve encogida y minúscula.

Conviene ponerle fecha, porque explica por qué existe. Cuando los teléfonos empezaron a navegar, casi ninguna web estaba pensada para ellos; para que fueran usables, sus navegadores decidieron fingir una pantalla ancha y encoger el resultado. La etiqueta apareció como forma de decir «esta página sí sabe lo que hace, no la encojas».

De ahí una consecuencia práctica: el comportamiento por defecto sigue siendo el antiguo. Un archivo HTML nuevo, escrito hoy, sin esa línea, se comporta como una página de hace quince años. No es un fallo del navegador, es compatibilidad hacia atrás.

Y una precisión de vocabulario que evita discusiones: el viewport no es un elemento de la página ni algo que se pueda estilar. Es la ventana desde la que se mira, y por eso las unidades relativas a ella se comportan distinto de las que miden un contenedor, algo que se nota en cualquier diseño adaptable con tipografía fluida.

Cuando alguien dice «el ancho de la pantalla» puede estar hablando de tres cosas, y conviene separarlas antes de discutir nada: lo que mide el aparato, lo que usa la página, y lo que el navegador supone cuando no se le dice nada, que es lo que acaba viendo el índice.

Ese tercer valor es el que explica el síntoma clásico. Los navegadores móviles renderizan la página con un ancho de escritorio cuando no encuentran indicación, y luego encogen el resultado para que quepa. web.dev lo cifra en torno a 980 píxeles, con la cautela de decir «normalmente».

De ahí que el remedio no sea rediseñar nada, sino declarar el ancho correcto. A partir de esa declaración, las reglas escritas para pantallas pequeñas empiezan a aplicarse, y no antes.

Hay un cuarto ancho que aparece en cuanto se toca el teclado y sorprende a cualquiera que depure formularios: cuando se abre el teclado en pantalla, la superficie visible cambia sin que cambie el ancho. Los diseños que fijan alturas según el viewport se descolocan justo ahí, en el momento en que alguien está escribiendo.

Y una comprobación que separa las tres primeras en un minuto: mira qué ancho declara la página y compáralo con el que reporta el navegador. Si no coinciden, la etiqueta falta o dice algo distinto de lo que se cree, y todo lo que venga después —incluidas las medidas de velocidad— estará midiendo otra cosa.

La declaración habitual dice dos cosas: que se use el ancho del dispositivo y que la escala inicial sea la natural. Con eso basta para la inmensa mayoría de los sitios, y añadir más suele restar en lugar de sumar.

Lo que no debe declararse es un bloqueo del zoom. Impedir que alguien amplíe una página es una barrera de accesibilidad y de experiencia de usuario para cualquiera con la vista cansada, y no resuelve ningún problema real de diseño; si el texto no se lee, se arregla el texto.

Tampoco tiene sentido fijar un ancho en píxeles en lugar de dejar que mande el diseño adaptable. Congelarlo obliga a desplazarse en horizontal en los aparatos más estrechos y desperdicia espacio en los más anchos, que es justo lo contrario de lo que se quería.

Merece una nota lo que ocurre cuando la etiqueta está bien y aun así hay que desplazarse en horizontal. Casi siempre la culpa no es del viewport sino de un elemento más ancho que él: una imagen sin su atributo alt ni límite de ancho, una tabla rígida, un bloque de código sin contenedor propio. El síntoma parece de configuración y la causa está en el contenido.

Y un caso que se repite en migraciones: la etiqueta duplicada. Dos declaraciones distintas en la misma cabecera —una de la plantilla, otra de un módulo— dejan el resultado a merced de cuál gane, y eso puede cambiar entre versiones sin que nadie toque nada. Es el tipo de detalle que un SEO técnico encuentra revisando el HTML entregado y no la pantalla.

Google aplica la indexación mobile-first y trabaja con la versión móvil de las páginas, así que lo que ve un rastreador es lo que se muestra en una pantalla estrecha. Una página sin viewport declarado se le presenta encogida, con el texto ilegible y los elementos apretados.

El efecto llega además a las métricas. Un diseño que se comporta mal a esa anchura produce saltos que mide el CLS, y con frecuencia hace que la imagen principal se cargue en un tamaño equivocado, lo que empeora el LCP.

Y hay un efecto indirecto que se subestima: si la página se ve mal en el móvil, quien llega se va, y ese comportamiento se refleja en el porcentaje de rebote antes que en cualquier informe técnico.

Hay un efecto más, menos comentado y bastante caro: el que tiene sobre las imágenes. Si el navegador cree tener delante una pantalla ancha, elige de las variantes disponibles la que corresponde a ese ancho, y descarga una imagen mucho mayor de la necesaria, algo que ni el lazy loading arregla. Se paga en datos y en tiempo, sobre todo en conexiones lentas.

Y conviene mirar la otra dirección: la etiqueta correcta no basta si el contenido está pensado para un ratón. Objetivos táctiles diminutos, menús que solo se abren al pasar por encima y textos por debajo del tamaño legible siguen siendo problemas después de declarar el viewport, y se notan en el engagement antes que en cualquier auditoría.

El primero es no declararlo. Suena elemental y sigue apareciendo, sobre todo en páginas sueltas creadas fuera de la plantilla habitual: aterrizajes de campaña, avisos legales, páginas de agradecimiento — las que casi nunca aparecen en el sitemap.

El segundo es bloquear el zoom, ya dicho, y merece repetirse porque se sigue copiando de ejemplos antiguos que circulan por foros.

Y el tercero es comprobarlo solo encogiendo la ventana del ordenador. Eso cambia el ancho pero no reproduce el comportamiento de un navegador móvil; hace falta mirar en un aparato real o en una simulación que lo tenga en cuenta, algo que también vale para la indexación mobile-first.

Un cuarto error, típico de sitios grandes: suponer que si está en la plantilla está en todas partes. Basta con una sección construida aparte —una landing page de campaña, un configurador, una zona heredada de otro sistema— para que falte justo donde llega el tráfico de pago.

Y el último, el más silencioso: no volver a comprobarlo tras un rediseño. La etiqueta sobrevive a casi todo porque nadie la toca a propósito, pero desaparece sin avisar cuando se cambia la cabecera del documento, y el síntoma —una página encogida— es de los pocos que un análisis de logs no puede mostrar, porque el servidor entregó exactamente lo que se le pidió.