Dos rediseños en tres días: cómo example.com se complicó para ahorrar ancho de banda

Dos rediseños en tres días: cómo example.com se complicó para ahorrar ancho de banda

Arquitectura FrontendOptimización de Ancho de BandaDisponibilidad del Sistema

Fuentes:Lobsters 讨论 + 线上实测

A principios de octubre de 2026, la página web de marcador de posición más citada de todo el mundo, example.com, encadenó dos rediseños sucesivos en el transcurso de apenas tres días. Un sitio que originalmente se limitaba a devolver una única línea de texto sin formato no solo abandonó su arquitectura en HTML estático puro, sino que delegó la representación de su documentación principal en un archivo JavaScript externo. En una era en la que el rendimiento web se mide al milisegundo, un dominio canónico de ejemplo documental decidió transformarse en un componente dinámico con dependencias externas, todo por arañar un ahorro marginal de ancho de banda.

En el conjunto de la infraestructura de Internet, example.com no es un sitio web convencional pensado para la lectura de usuarios humanos. Su auténtica razón de ser es servir de marcador de posición universal en especificaciones RFC, manuales de instrucciones y documentación técnica. Cuando los ingenieros configuran Nginx o realizan pruebas de resolución DNS, es habitual copiar y pegar directamente ejemplos de configuración oficiales. Si olvidan sustituir el dominio de ejemplo por su dirección de producción real, esas peticiones impactan de lleno en los servidores de la IANA. La inmensa mayoría de las solicitudes que bombardean esta página no son humanas: se trata de bancos de pruebas automatizados, sondas de monitorización y rastreadores desconfigurados que barren el sitio sin descanso.

En una respuesta por correo electrónico enviada el 30 de septiembre al desarrollador Oliver Dunk, el vicepresidente de la IANA, Kim Davies, señaló el principal detonante de este cambio: reducir el ancho de banda agregado necesario para mantener en funcionamiento el dominio. Esta distribución de tráfico tan descompensada plantea dilemas de ingeniería radicalmente distintos a los de un sitio web habitual. Si la abrumadora mayoría de las visitas proviene de scripts y programas automatizados que jamás descargan recursos secundarios, extraer el bloque de texto explicativo del documento HTML inicial permite evitar la transferencia innecesaria de miles de millones de bytes. Bloquear la información fuera del documento base equivale a aplicar una degradación a nivel de protocolo orientada específicamente a clientes que no son navegadores.

La estructura estática cede ante las dependencias externas

Antes del 28 de septiembre, la página conservaba su sencillez intuitiva y clásica. Su diseño se basaba en HTML puramente estático, cuyo cuerpo albergaba tan solo el encabezado principal Example Domain, una breve advertencia («This domain is for use in documentation examples without needing permission. Avoid use in operations.») y un enlace a la web oficial de la IANA con el texto «Learn more». Este aviso de advertencia se había incorporado a la página apenas el año anterior; hacia 2020 la redacción era una frase más larga que autorizaba el uso en literatura técnica, y antes de 2015 la formulación era aún más permisiva.

Captura de la versión archivada del 28 de septiembre Figura: Aspecto de la versión archivada del 28 de septiembre, donde figuran las frases «Avoid use in operations» y «Learn more». Fuente: Blog de Henry Catalinismith

Aquella estructura DOM minimalista fue considerada durante años un punto de referencia para medir la capacidad de respuesta de la infraestructura básica de la red. Una respuesta HTTP de apenas unas decenas de bytes, sumada a un procesamiento instantáneo y sin bloqueos por parte del navegador, permitía mostrar la información de forma inmediata bajo cualquier condición de red. Para los administradores de sistemas encargados de depurar reglas en cortafuegos, consultar el dominio desde la terminal y recibir texto plano completo constituía la prueba de conectividad más fiable. Si una arquitectura estática y austera fue capaz de soportar el tráfico real durante décadas, la decisión de incorporar recursos externos conllevaba inevitablemente el riesgo de añadir fragilidad y complejidad estructural.

Un retraso de 3,2 milisegundos que rompió la función de copiar

A finales de septiembre, la IANA desplegó la primera fase del rediseño. Esta actualización introdujo una controvertida lógica de renderizado: cada carácter del texto se envolvió en una etiqueta individual, a la que se asignó un atributo de retraso de animación incremental. Los caracteres aparecían de forma secuencial a partir de un estado totalmente transparente. Varios desarrolladores examinaron el árbol DOM en foros técnicos y descubrieron que los intervalos de retraso entre caracteres estaban programados con precisión matemática: 0 ms, 3,20513 ms, 6,41026 ms, y así sucesivamente.

Una velocidad de aparición gradual de unos 3,205 milisegundos por carácter producía un efecto visual que imitaba el tecleo de una máquina de escribir. En una página de aterrizaje comercial, este tipo de microinteracciones puede concebirse como un detalle de acabado visual, pero imponer un bloqueo de renderizado en una página básica de documentación contradice por completo la razón de ser del sistema. Descomponer unas pocas decenas de caracteres en racimos de nodos DOM con estado independiente convirtió lo que debía ser una única operación de pintado en una innecesaria batalla de fotogramas en la canalización gráfica del navegador.

Esta interferencia forzada en el flujo de renderizado provocó un grave retroceso funcional. La consecuencia más evidente fue que el texto no podía seleccionarse con el ratón durante la animación ni tampoco una vez finalizada, lo que anuló por completo la acción básica de copiar y pegar. Varios ingenieros de frontend documentaron el fallo de inmediato y lo señalaron como una infracción directa del criterio de accesibilidad WCAG 2.2.2 (Pausar, detener, ocultar / Pause, Stop, Hide). Una animación forzada de varios segundos sin controles para detenerla resulta una experiencia hostil y excluyente, en especial para personas con trastornos vestibulares.

Recortar texto para cargar una petición de 2,15 KB

Ante el aluvión de críticas de la comunidad técnica, la IANA reaccionó con rapidez y publicó hoy, 3 de octubre, una segunda versión corregida. Al descargar el código fuente de la página actual mediante el comando curl, la terminal muestra la siguiente estructura:

<p>This domain is for use in documentation examples without needing permission. This is not a service; avoid relying on it for testing and monitoring purposes.</p><script src=/s.js></script>

La animación de máquina de escribir carácter a carácter fue eliminada por completo. El enjambre de etiquetas individuales y los retrasos escalonados han desaparecido, pero se mantiene la decisión arquitectónica de trasladar el resto de la documentación a un archivo externo independiente.

El script externo que alberga el contenido restante ocupa 1.579 caracteres. Su cometido en el cliente es muy concreto y abarca tres tareas principales: primero, inyecta en el documento los párrafos explicativos traducidos a cinco idiomas (árabe, chino, francés, ruso y español) y añade el enlace «Learn more» al final; segundo, consulta las preferencias de idioma del sistema operativo (navigator.languages) para reorganizar y situar en primer lugar el párrafo correspondiente al idioma del usuario; y por último, inserta en el documento una hoja de estilos y un icono vectorial en SVG con forma de libro.

Renderizado real de example.com hoy Figura: Visualización actual de example.com: un aviso principal junto con traducciones a cinco idiomas, donde todo el contenido secundario se inyecta mediante /s.js. Fuente: Captura de pantalla de la página en vivo vía thum.io

Aquí surge la gran paradoja del rediseño. Varios desarrolladores comprobaron en el panel de red que el script independiente, sumado a las cabeceras HTTP de respuesta, alcanza un peso de 2,15 KB. Para frenar el gasto de ancho de banda atribuible a rastreadores automatizados, la IANA recortó unos cientos de bytes de texto estático del documento base. Sin embargo, para los usuarios reales que acceden a través de un navegador web, leer esas mismas frases ahora exige establecer una conexión HTTP adicional y descargar más de dos kilobytes de código. Penalizar las peticiones legítimas con el pretexto de recortar tráfico residual es una optimización basada en métricas aisladas que perjudica la eficiencia real de entrega.

La comunidad de código abierto ha mostrado opiniones divididas ante esta decisión. Quienes la defienden argumentan la carga operativa real expuesta por Kim Davies: el dominio de ejemplo nunca se concibió como un punto de control de disponibilidad abierto a cualquiera, y ofrecer respuestas HTTP responde a una mera cortesía de ingeniería, por lo que reorganizar la arquitectura para contener el tráfico es una medida de autoprotección razonable. Por el contrario, los críticos sostienen con igual firmeza que, aun tratándose de un servicio de cortesía, no tiene sentido transformar una página web limpia y estática en un componente complejo dependiente de recursos externos. Algunos desarrolladores llegaron incluso a sugerir que, si el propósito era minimizar los datos al extremo, se deberían eliminar por completo la declaración DOCTYPE y las etiquetas html y body, entregando únicamente texto plano sin procesar.

Trasladar la factura del ancho de banda a los visitantes humanos

En la historia de la infraestructura de Internet, las decisiones de diseño siempre han hecho equilibrios entre los elevados costes de transferencia y la experiencia básica del usuario. Los dos rediseños precipitados de example.com pueden parecer a simple vista meros ajustes de desarrollo frontend, pero en el fondo reflejan un dilema estructural de mantenimiento. Cuando la mayor parte de los recursos de un sistema es consumida por comportamientos no deseados, es fácil caer en la trampa de optimizar una única métrica. Ocultar el contenido tras un flujo de carga dinámica reduce el consumo de ancho de banda en los paneles de control, pero ese ahorro se consigue a costa de exigir mayor potencia de cálculo y latencia a los clientes reales.

La veterana página se articula ahora en torno a 6 párrafos, 22 elementos DOM y un tamaño inicial de descarga de 1.977 bytes. Al imponer un script externo, la IANA logró cortar el camino fácil para que los rastreadores obtengan el flujo documental completo con mínimo esfuerzo. Sin embargo, los desarrolladores que necesitan consultar avisos o directrices de documentación deben asumir el coste de saltos visuales, retrasos en el repintado y peticiones de red suplementarias. Sacrificar la eficiencia de procesamiento del navegador a cambio de aliviar el ancho de banda del servidor no es más que trasladar los costes de transporte de la infraestructura a cada visitante humano de carne y hueso.

Referencias:

  • Blog de Oliver Dunk: La respuesta de la IANA
  • Debate en Lobsters: Correo de la IANA sobre los cambios en example.com
  • Henry Catalinismith: Análisis sobre Pause, Stop, Hide