¿Qué tamaños de navegador debes probar para un diseño responsive?

No existe una lista permanente de tamaños de navegador que garantice un diseño adaptable. Empiece con anchos de referencia estrechos, intermedios y amplios, como 390, 820 y 1440 píxeles CSS, y pruebe justo por debajo y por encima de cada punto de ruptura de su contenido. El mejor punto de ruptura está donde empieza a fallar el diseño, no en el límite de un modelo de teléfono concreto.

La Prueba de renderizado de sitios web de ClockTools puede capturar una página pública con anchos de referencia de móvil, tableta y escritorio, y comprobar sus metadatos. Úsela para una revisión visual rápida y después interactúe con la página mediante las herramientas de desarrollo del navegador y dispositivos reales representativos antes del lanzamiento.

¿Por qué tres capturas de pantalla no son tres dispositivos?

La ventana gráfica CSS es el área disponible para el contenido web, medida en píxeles CSS. No equivale sin más al número de píxeles físicos indicado en las especificaciones de un dispositivo. El zoom, la relación de píxeles del dispositivo, los controles del navegador, la pantalla dividida, las barras de desplazamiento y la orientación pueden cambiar el área disponible.

Por eso, una lista de los «tamaños de teléfono más populares» queda obsoleta. La guía de diseño adaptable de MDN recomienda diseños que respondan a todo el rango disponible, y sus fundamentos de las consultas de medios aconsejan añadir un punto de ruptura donde el contenido empieza a fallar, en lugar de dirigirse a cada dispositivo.

Tres capturas siguen siendo útiles. Son referencias rápidas que muestran grandes diferencias en navegación, columnas, tablas y tipografía. Considérelas una primera revisión del rango, no una prueba de que todos los anchos funcionan.

¿Qué revela cada ventana gráfica ClockTools?

La herramienta en vivo ClockTools ofrece tres capturas seleccionables de forma independiente:

El resultado también muestra el estado de la respuesta, el título, H1, la URL canónica, el valor de robots, el tamaño del HTML y el tiempo de respuesta. Esa combinación es útil: una captura atractiva de una página redirigida, bloqueada, con noindex o una URL canónica incorrecta sigue indicando que la comprobación previa al lanzamiento ha fallado.

El renderizador acepta páginas públicas HTTP o HTTPS. Rechaza deliberadamente el host local, las direcciones IP privadas y las páginas de la red interna porque la solicitud de captura se ejecuta fuera de su dispositivo. No envíe enlaces de vista previa firmados, contraseñas, tokens ni URL de prueba confidenciales.

¿Cómo se construye un barrido de punto de interrupción?

Utilice cinco pases en lugar de recolectar una enorme matriz de dispositivos:

1. Comience con 320 o 360 píxeles para exponer supuestos de ancho mínimo.
2. Capture un anclaje móvil común, como 390 píxeles, y pruebe la interacción vertical.
3. Aumente poco a poco el ancho hasta que el contenido necesite un cambio de disposición; anote ese ancho.
4. Pruebe un píxel debajo y un píxel encima de cada punto de interrupción declarado, luego repita con etiquetas largas, errores de validación y menús ampliados.
5. Termine con un ancla de escritorio amplia, como 1440 píxeles, y una ventana más ancha para captar longitudes de línea incontroladas o medios estirados.

Si una hoja de estilos cambia a 768 píxeles, el par útil es 767 y 768, no solo un ajuste genérico de tableta. Si otra cuadrícula cambia a 1024, añada 1023 y 1024. Las pruebas a ambos lados del límite revelan huecos de un píxel y reglas mínimas y máximas superpuestas.

Incluya la altura cuando un encabezado fijo, un modal, un banner de consentimiento o un teclado en pantalla puedan consumir espacio vertical. Gire al menos un dispositivo táctil o simulador. Un diseño que se ajuste a 390 x 844 aún puede fallar con el mismo ancho y con mucha menos altura disponible.

¿Qué fallos de diseño responsive debería solucionar primero?

Priorice según si el usuario puede completar la tarea principal de la página:

El Documento de comprensión del reflujo de las WCAG explica por qué el contenido debe redistribuirse sin desplazamiento bidimensional en anchos estrechos, con excepciones limitadas para contenido como mapas o tablas de datos que realmente requieren dos dimensiones.

Pruebe estados de contenido reales. Reemplace marcadores de posición cortos con la etiqueta admitida más larga, muestre errores debajo de los campos, abra la navegación, expanda acordeones y cargue la fila de tabla realista más grande. Los fallos de diseño responsive suelen aparecer después de la interacción, no en la captura de pantalla inicial limpia.

¿Cuándo necesitas un dispositivo real?

Utilice dispositivos reales cuando el resultado dependa de la interacción táctil, el teclado en pantalla, los márgenes del área segura, los permisos de cámara o ubicación, el audio, la rotación, el movimiento reducido, los controles del navegador móvil o el rendimiento en un dispositivo con recursos limitados. Una captura realizada sin interfaz gráfica no reproduce todos los métodos de entrada ni comportamientos del sistema operativo.

También ejecute la página con zoom del navegador y ampliación del texto. Un diseño puede ajustarse a su ventana gráfica nominal y aún así recortarse cuando el texto crece. El editor HTML en tiempo real es útil para aislar un experimento de CSS, mientras que el comprobador de diferencias de texto puede confirmar exactamente qué ediciones de reglas de respuesta cambiaron entre dos versiones.

El registro de lanzamiento práctico es una pequeña matriz: ancho y alto probados, estado del contenido, navegador o motor, problema observado y resultado después de la solución. Esa evidencia es más duradera que una carpeta de capturas de pantalla que lleva el nombre únicamente de las marcas de dispositivos.