Tengo una herramienta que escribí para dejar de discutir si una página se ve bien en el celular. Abre la página en ocho anchos distintos —de 320 a 1440— y busca lo que no se ve leyendo el código: texto que se sale, botones más chicos de lo que un dedo puede tocar, letra por debajo de 12 píxeles, tarjetas que no caben.
La corrí sobre un documento que acababa de generar.
"Sin problemas en ninguna combinación."
Ocho anchos, cero avisos. El documento estaba mal.
Lo que pasó
La herramienta pide dos cosas por separado: la base (el servidor) y la ruta (el archivo). Yo le pasé la URL completa de un jalón, como se le pasa a un navegador.
Entonces tomó la URL entera como base, y como no le quedó ruta, usó /. Lo que terminó pidiendo fue archivo.html/ — con una barra de más al final. Eso no existe. El servidor contestó 404.
Y ahí es donde la cosa se pone interesante, porque no salió ningún error. Salió un verde perfecto.
Por qué un 404 siempre pasa la prueba
La página de error de un servidor de desarrollo es dos líneas de texto sin ningún estilo. No trae .
Sin esa etiqueta, un navegador móvil no intenta acomodar la página al ancho del teléfono: asume que es un sitio de escritorio, la dibuja a 980 píxeles de ancho y la encoge para que quepa. Es un comportamiento de hace quince años que sigue vivo por compatibilidad.
Y a 980 píxeles no hay nada que se salga. Cabe todo. No hay botones chicos porque no hay botones. No hay texto ilegible porque casi no hay texto.
Así que mi herramienta hizo su trabajo con total honestidad sobre una página que no era la mía, y le dio un aprobado impecable. Todas las mediciones eran correctas. Ninguna era sobre lo que yo creía.
El error no fue el 404
El 404 fue un dedazo, y los dedazos pasan. Lo que me quedó dando vueltas es otra cosa:
el fallo se veía exactamente igual que el éxito.
No hubo nada en la salida que me dijera "oye, esto no es tu página". Al contrario: me dijo justo lo que quería oír, con el mismo formato de siempre. Si no llego a abrir el documento por otro motivo, ese verde se queda en mi cabeza como "ya está medido".
Y hay una segunda versión del mismo problema que me había pasado la semana anterior, midiendo una pantalla que está detrás de un login. Sin sesión iniciada, la herramienta medía la pantalla de acceso: un formulario de dos campos. Todo lo que vive del otro lado mide cero — cero desbordes, cero scroll lateral, cero tarjetas grandes. Verde perfecto sobre una pantalla que nadie vio.
Lo que hace esa trampa creíble es que no todo es mentira. El tamaño de letra sí se calcula aunque el contenedor esté oculto, así que la revisión de texto chico devolvía resultados válidos mientras toda la geometría era falsa. Media verdad convence más que ninguna.
Lo que le cambié, y lo que me cambió
A la herramienta le agregué dos líneas: ahora mira el código HTTP y se detiene si no es 200, y avisa si el bloque que midió tiene altura o ancho cero. Fue el arreglo barato.
El arreglo caro es el otro, y es de cabeza: una herramienta de medición te entrena a confiar en su silencio. Después de veinte corridas limpias, el verde deja de leerse como un resultado y empieza a leerse como un permiso para seguir. Eso es justo lo que uno quiere de una herramienta — y es lo que la vuelve peligrosa el día que se equivoca de objetivo.
La regla que me llevé:
Cuando la herramienta salga limpia y algo se vea mal, la primera pregunta no es "¿qué le arreglo a la página?". Es "¿por qué no lo vio?".
Arreglar la página y seguir adelante deja la herramienta mintiendo para la próxima. Y la próxima vez a lo mejor ya no abro el archivo para descubrirlo.
Es la misma familia de esas pruebas automáticas que llevan meses en verde porque el escenario que deberían ejercitar nunca llega a correrse. La prueba pasa. No prueba nada.
