git.kernel.org gasta más CPU en scrapers que en clones

Catorce núcleos de CPU, repartidos entre cinco nodos geodistribuidos, dedicados en exclusiva a convertir commits de git en páginas HTML para rastreadores automáticos. Ese es el dato que aporta Konstantin Ryabitsev, responsable de la infraestructura de kernel.org, en un texto titulado Creepy crawlies que Simon Willison recogió el 7 de septiembre en su weblog.

Su resumen, traducido, es todavía más incómodo:

> Gastamos más ciclos de CPU renderizando commits para scrapers que en todos los demás tipos de acceso legítimo, incluidos los clones de git.

Hablamos de git.kernel.org, el repositorio oficial del kernel de Linux. No de un blog personal con dos visitas al mes.

Por qué un servidor git es el peor sitio posible para esto

La superficie rastreable de un repositorio grande es, a efectos prácticos, infinita. Cada commit tiene su página, cada commit tiene su diff, cada fichero tiene una vista por cada revisión en la que cambió, y a eso se suman rangos, comparaciones entre ramas y vistas de anotación. El espacio de URLs crece de forma combinatoria mientras el contenido realmente útil no crece al mismo ritmo.

Además, cada una de esas páginas es cara. Renderizar un diff obliga a leer objetos del repositorio y calcular la diferencia en ese momento. Y como casi ninguna se pide dos veces, la caché apenas ayuda: el rastreador visita una URL, la abandona y pasa a la siguiente. Un sitio de páginas estáticas absorbe ese tráfico sin enterarse; una forja git lo paga en CPU.

No es un problema exclusivo del kernel

Willison apunta en su entrada que el asunto le preocupa por Datasette, su herramienta para publicar bases de datos como sitios web navegables, que también genera un número enorme de páginas rastreables. El patrón se repite en cualquier cosa que derive muchas URLs de una base de datos: forjas, wikis, catálogos, buscadores internos, archivos documentales. El propio Willison llegó al texto vía Hacker News.

Lo relevante no es que existan rastreadores. Existen desde siempre y con ellos hay un pacto tácito razonable: tú me indexas, yo recibo visitas. Lo que ha cambiado es el volumen y la asimetría. El coste de generar la página lo asume quien la sirve; el beneficio se lo lleva quien la ingiere.

Qué se puede hacer sin romper la web abierta

Tres líneas de actuación que sí funcionan:

1. Abaratar la vista cara. Precalcular diffs, cachear de forma agresiva las rutas más golpeadas o servir una versión reducida al tráfico anónimo recorta el gasto sin cerrar nada.
2. Ofrecer el bulto por delante. Si alguien quiere el histórico completo, un clon, un volcado o un endpoint de datos sale más barato para todos que doscientas mil peticiones HTML. Publicar la vía barata y señalizarla bien desvía tráfico de la cara.
3. Poner fricción donde toca. Limitar por ASN y colocar un challenge de proof of work delante de las rutas costosas, con opciones como Anubis que varios proyectos de software libre han adoptado, filtra el grueso del abuso sin exigir registro a los humanos.

Y si construyes agentes, esto también va contigo

Aquí es donde la noticia toca de lleno a quien trabaja con Claude. Un agente que navega webs de terceros es, técnicamente, un rastreador más. Las reglas de higiene son las mismas que llevan veinte años escritas: identificar el user agent, respetar robots.txt, limitar la concurrencia, cachear lo ya visto y preferir la API o el feed a la página HTML cuando existan.

Y por el lado del publicador hay una lectura útil. Exponer un servidor MCP o un endpoint documentado sobre tus propios datos es más barato que ser raspado a ciegas. Un cliente que puede consultar lo que necesita en una llamada estructurada deja de recorrer diez mil páginas para encontrarlo.

No hay aquí una crisis de la web, pero sí una factura que alguien está pagando en silencio y que en buena parte recae sobre infraestructura pública sostenida con donaciones. Nos parece razonable que quien construye sobre datos ajenos asuma la parte del coste que genera, empezando por lo más sencillo: pedir menos y pedirlo mejor.