Datasette y el header rel=next que Firefox precarga

Un header HTTP de una línea hace que Firefox descargue páginas completas que casi nadie va a ver, y el reporte del bug lleva 24 años abierto. Simon Willison, creador de Datasette, lo descubrió por casualidad mirando el panel de red de su propio producto, y el hallazgo aplica a cualquier SaaS que pagine resultados.

Qué pasó con Datasette y el header rel=next

Willison estaba revisando el panel de red de Firefox cuando notó que cada vez que abría una página de tabla de Datasette, el navegador disparaba una petición de precarga (prefetch) a la página siguiente de filas. Nadie la había pedido: el navegador simplemente la hacía.

La causa estaba en un header que las páginas de Datasette sirven de forma automática:

link: ; rel="next"

Ese rel="next" es una señal de paginación. Firefox la interpreta como una invitación a descargar por adelantado la próxima página del listado.

El problema, según el propio autor, es de eficiencia pura: solo una fracción mínima de los visitantes hace clic en el enlace «siguiente». Pero el navegador ya descargó esa página y el servidor de Datasette ya la renderizó completa, para descartarla después. Ancho de banda y CPU gastados en algo que casi nadie va a ver.

Un bug de Firefox con 24 años de antigüedad

Investigando el origen del comportamiento, Willison encontró que Firefox tiene un reporte abierto en Bugzilla (el 175418) sobre esto desde hace 24 años. Y el detalle que cierra el círculo: uno de los primeros comentarios de ese reporte enlaza a un post de su propio blog de 2002 donde ya se quejaba exactamente de lo mismo.

Su reacción, según contó, fue que no solo había olvidado que había escrito sobre el tema: había olvidado por completo que la función existía. Es un recordatorio incómodo de cuántas decisiones técnicas heredadas siguen activas en producción sin que nadie las revise.

Qué es el prefetch y por qué existe

Un prefetch es una instrucción que le dice al navegador: «esta página probablemente la vas a necesitar, descárgala antes». La idea suena bien en teoría. Cuando el usuario hace clic, la página ya está en caché y carga al instante.

El problema aparece cuando la señal es demasiado optimista. Un header rel="next" en una tabla paginada declara que existe una página siguiente, no que el usuario vaya a visitarla. En un listado largo, el navegador precarga la siguiente página en cada visita, aunque la mayoría de los usuarios se vaya después de la primera.

Para un sitio estático el costo es bajo. Para una aplicación que renderiza cada página contra una base de datos, cada prefetch es una consulta y un render completos que se tiran a la basura.

Por qué esto le importa a cualquier SaaS con listados paginados

Datasette es un caso visible porque su autor lo documentó públicamente, pero el patrón es común: cualquier producto que pagine resultados y anuncie la página siguiente con headers HTTP puede estar pagando el mismo costo sin saberlo.

• Costo de servidor: cada precarga es un render descartado. En un listado con tráfico alto, eso se multiplica por cada visita.
• Costo de datos: para el usuario en móvil con plan limitado, es tráfico que consume sin ningún beneficio.
• Señal mal calibrada: rel="next" nació como pista para buscadores, no como orden de descarga para el navegador. La misma línea de código sirve a dos audiencias con intereses opuestos.

¿Cómo saber si tu producto tiene el mismo problema?

La auditoría es rápida y no requiere instrumentación nueva:

1. Abre tu producto en Firefox y entra a una vista paginada: una tabla, un listado o resultados de búsqueda.
2. Abre el panel de red (F12, pestaña Red) y recarga la página.
3. Busca peticiones que no correspondan a nada que hayas clicado. Si aparece una URL con tu parámetro de paginación, tienes el mismo caso.
4. Revisa los headers de respuesta de esa página. Si hay un link con rel="next", ese es el origen.
5. Cruza con los logs del servidor: cuántas peticiones llegan con el parámetro de paginación y cuántas terminan en un clic real.

Qué significa esto para tu startup

El aprendizaje no es «quita el header». Es que las optimizaciones que agregas por defecto pueden tener un costo que nadie mide, y ese costo se acumula todos los días.

Acción 1: cuantifica el tráfico fantasma antes de decidir. Compara las peticiones a tu endpoint paginado contra los clics reales en el botón «siguiente». Si la diferencia es grande, tienes un problema de costos con solución simple. Si es mínima, no vale la pena tocar nada. La decisión sale del dato, no de la intuición.

Acción 2: sirve el header según quién lo pide. La propuesta del issue #3046 de Datasette apunta justo a eso: dejar de enviar el header a Firefox en las páginas HTML. Si tu paginación existe para que los buscadores descubran el contenido, puedes mantenerla para los crawlers y omitirla para los navegadores. Es un cambio acotado con impacto medible en carga de servidor.

Acción 3: revisa tus otras señales de precarga. El mismo razonamiento aplica a prefetch, preload y preconnect. Cada una es una apuesta sobre el comportamiento del usuario. Si nunca mediste si esa apuesta se cumple, probablemente estés pagando por ella igual.

Conclusión

El caso de Datasette es un recordatorio útil para cualquier equipo de producto: un header de una línea, escrito hace años con buena intención, puede estar consumiendo recursos de servidor y de red todos los días sin que nadie lo note. Willison lo encontró mirando el panel de red por casualidad, y el bug que lo explica lleva más de dos décadas abierto.

La lección práctica es que el rendimiento no se arregla solo agregando optimizaciones. También se arregla quitando las que ya no pagan su costo. Y para saber cuáles son, hay que medir antes de asumir.