Notas sobre el cambio de Screaming Frog a RustySEO (y por qué no vuelvo atrás)
Llevo un par de semanas con un proyecto de esos que te quitan el sueño: un e-commerce con miles de productos, variaciones, facetados y una arquitectura que parece un plato de espaguetis. Intenté meterle mano con la «rana» de siempre (v20.2, en mi MacBook Pro M2 con Sonoma 14.4), pero fue frustrante.
A ver, no es que Screaming Frog sea mala, es que ver el monitor de recursos de macOS marcar 12.4 GB de RAM ocupados y notar que el cursor de mi ratón tiene lag mientras intento responder un Slack… pues no. Ahí es cuando te das cuenta de que la JVM (Java Virtual Machine) es un lastre para proyectos de este volumen. Te obliga a reservar memoria «a ciegas» y el ventilador del Mac empieza a sonar como si fuera a despegar. Literalmente, tuve que silenciar mi micro en un Meet porque el ruido soplaba directo al ambiente.
El descubrimiento de RustySEO (y el alivio de la RAM)
Me bajé RustySEO por probar, casi por desesperación. Al ser un binario nativo en Rust, la diferencia de filosofía es brutal. Mientras Java reserva bloques gigantes de memoria «por si acaso», Rust gestiona cada byte de forma quirúrgica.
Lo que más me voló la cabeza (y aquí me pongo técnica un segundo, prometido) es cómo gestiona la concurrencia. Usa la librería tokio para manejar las peticiones asíncronas. En lugar de crear un hilo pesado para cada URL —que es lo que acaba matando la estabilidad de la Rana en rastreos profundos—, RustySEO optimiza las conexiones de una forma mucho más ligera.
Resultado real en mi máquina: El rastreo de las 120k URLs se estabilizó entre los 3.8 y 4.2 GB de RAM. Lo mismo que consume Chrome con tres pestañas abiertas. Pude seguir editando el CSS de una landing en VS Code y el sistema ni se inmutó. No hubo que «asignar memoria manualmente» ni rezar para que no saltara el error de Out of Memory.
¿Significa esto que la Rana ha muerto?
Para nada. Si necesito ver rápidamente la visualización de directorios o cruzar datos con la API de Search Console para un informe rápido, sigo abriendo Screaming Frog. Sus visualizaciones son imbatibles y más «limpias» para enseñar a un cliente.
Pero para el SEO técnico de guerrilla, para cuando el servidor de origen es lento o cuando el volumen de datos es masivo, necesito algo que no me secuestre el ordenador. RustySEO me permite hacer el análisis de logs y el rastreo pesado en segundo plano sin que mi productividad caiga a cero.
Al final, en Daruma nos da igual la herramienta si el resultado es sólido. Pero trabajar con herramientas que respetan tu hardware y tu tiempo… eso es otro nivel.
Si tienes un proyecto grande y estás harto de ver la pelotita de colores de Mac cada vez que lanzas un crawl, dale un tiento al «óxido». Vale la pena el cambio de chip.
👉 Diseñamos y optimizamos sitios web pensados para posicionar y convertir, no solo para verse bien.
💡 El secreto está en la gestión de memoria (JVM vs. Native)
Muchos me habéis preguntado de dónde sale esa diferencia tan bruta de 12.4 GB vs. 4.1 GB. No es magia, es ingeniería:
- El «secuestro» de RAM de Java: Screaming Frog corre sobre la Java Virtual Machine (JVM). Para proyectos grandes, solemos asignar manualmente 8GB o 12GB de Heap Space. El problema es que Java «reserva» ese espacio por adelantado y su recolector de basura (Garbage Collector) no siempre lo libera rápido, lo que estresa al sistema operativo.
- La eficiencia quirúrgica de Rust: RustySEO no tiene una capa intermedia. Al ser un binario nativo, utiliza un modelo de ownership (propiedad) de memoria. Solo ocupa lo que necesita para procesar las colas de URLs en ese instante.
Dato real: En mis pruebas, mientras la Rana mantenía la memoria ocupada «por si acaso», RustySEO liberaba recursos de forma constante, permitiéndome mantener el flujo de trabajo sin un solo tirón en el resto de aplicaciones.
