El crawler de LiteSpeed Cache puede ralentizarse por una combinación de factores: configuración agresiva de pre-caching, el estado de tu base de datos, cantidad de URLs a indexar, y conflictos con otros plugins. Si tu crawler tarda horas en completar el ciclo en lugar de minutos, probablemente tengas una configuración no optimizada o recursos del servidor insuficientes para el load que genera.

En 30 segundos

  • El crawler de LiteSpeed puede ralentizarse por pre-caching agresivo, URLs excesivas, o queries de BD lenta
  • Controlar la agresividad del crawler (crawl delay, simultaneous requests) es clave para evitar sobrecargar el servidor
  • La mayoría de ralentizaciones vienen de una configuración «dispara y olvida» sin ajuste a los recursos del servidor
  • Revisar logs de LiteSpeed y monitorear CPU/RAM durante un crawl ciclo te muestra donde está el cuello de botella
  • Cachear inteligentemente (no todo) reduce tanto el tamaño del cache como el tiempo de crawl

Qué es el crawler de LiteSpeed Cache

LiteSpeed Cache es un plugin de caching para WordPress que genera cachés almacenados en el servidor para entregar páginas más rápido a los visitantes. El «crawler» es un componente que visita automáticamente las URLs de tu sitio para pre-generar esos cachés antes de que un usuario real las visite. Suena perfecto en teoría: visitante llega, cache ya existe, boom, página súper rápida. (Spoiler: todo depende de cómo lo configures.)

Por qué el crawler puede estar lento

Cuando decís «el crawler está lento», generalmente significa que tarda horas en completar un ciclo de pre-caching cuando debería tardar minutos u horas máximo, dependiendo del tamaño del sitio. Las causas raíz son casi siempre una de estas tres cosas:

1. Configuración agresiva sin límites

Instalás LiteSpeed, activas pre-caching con todos los valores por defecto, y te olvidás. Eso significa que el crawler intenta visitar simultáneamente 5, 10 o más URLs al mismo tiempo, sin respetar los tiempos de carga del servidor. Si tu sitio ya está en el límite de CPU o memoria, ese crawler adicional es suficiente para que todo se ralentice. El servidor intenta procesar la solicitud 1 del crawler MIENTRAS procesa la solicitud real de un visitante MIENTRAS ejecuta un backup de BD. (El hosting compartido vuelve loco de aburrimiento acá.) Tema relacionado: configuración de firewall ralentiza el crawler.

2. Base de datos lenta o queries mal optimizadas

Cada página que el crawler visita genera queries a la BD: obtener posts, comentarios, metadata, taxonomías, etc. Si tu BD tiene queries lentas (sin índices, datos sin optimizar, demasiadas filas), cada visita del crawler se vuelve una espera. Y si tenés 5 crawlers simultáneos visitando 5 páginas diferentes, son 5 sets de queries lentas corriendo al mismo tiempo contra la misma BD. Ojo con esto si tu sitio tiene miles de posts.

3. Plugins conflictivos o hooks pesados

A veces otro plugin (un hook de análisis, un widget de redes sociales, un slider de imágenes pesado) se ejecuta cada vez que una página carga, incluso para el crawler. Si ese plugin hace una llamada externa a una API o procesa mucha data, multiplica ese tiempo por cada URL que el crawler visita. (Algunos plugins «rastreadores» de tráfico hacen esto constantemente sin ningún límite.)

Cómo identificar dónde está el problema

Antes de tocar configuraciones, necesitás datos. Entrá al admin de WordPress, andá a LiteSpeed Cache → Crawler. Mirá el log del último ciclo. ¿Cuánto tiempo tardó? ¿Cuántas URLs procesa? ¿Viste errores?

Ahora abrí SSH o una terminal en tu servidor y monitorea en vivo qué pasa cuando el crawler corre. Comandos útiles: Ya lo cubrimos antes en plugins que afectan el rendimiento.

  • top — ¿cuánta CPU y RAM está usando el proceso de PHP?
  • iotop — ¿está el disco siendo martilleado por I/O de BD?
  • mysql -e "SHOW PROCESSLIST;" — ¿hay queries lentas bloqueando?
  • Mirá los logs: /var/log/php-fpm.log o /var/log/apache2/error.log para slowqueries

Si el crawl es lento y la CPU/RAM está en 20-30%, el problema es la BD. Si alcanza 80-95% en CPU, el problema es sobrecarga. Si los tiempos de respuesta son inconsistentes (a veces rápido, a veces lento), es contención de recursos con otros procesos.

Ajustes que funcionan de verdad

Una vez que sabés qué te está frenando, los remedios son claros:

Reducir concurrencia del crawler

En LiteSpeed Cache → Settings → Crawler, baja el «Simultaneous Requests» de su defecto (que ponele es 5-10) a 1 o 2. Sí, va a tardar más en completar. Pero va a hacerlo sin sobrecargar el servidor. Un crawl que tarda 4 horas en lugar de 2, pero sin ralentizar a tus visitantes reales, es un ganar.

Agregar crawl delay

LiteSpeed te deja setear un delay entre requests: «espera 100 milisegundos antes de visitar la próxima URL». No suena como nada, pero multiplicado por cientos de URLs hace diferencia. Prueba 200-500ms si tu BD es lenta.

Reducir URLs del crawler

No todo en tu sitio necesita estar pre-cacheado. ¿Los términos de servicio? ¿La página de contacto? ¿Posts con 0 comentarios? Usa la opción «Exclude» en el crawler para omitir páginas innecesarias. Si tu sitio tiene 5.000 posts pero solo 200 reciben tráfico real, cachear solo esos 200 es mucho más eficiente que los 5.000. Relacionado: mantener actualizada tu infraestructura.

Optimizar la base de datos

Si el problema es BD lenta, ejecutá un OPTIMIZE TABLE en las tablas principales (wp_posts, wp_postmeta, wp_comments). Agrega índices si hace falta. Borra datos viejos (revisions de posts sin usar, comentarios spam, logs de plugins muertos). Una BD limpia es una BD que responde rápido.

Desactivar temporalmente plugins conflictivos durante el crawl

Si notaste que ciertos plugins ejecutan hooks pesados, desactivalos mientras corre el crawler. O mejor aún: configuralos para que NO se ejecuten si el User-Agent es «LiteSpeed» (el crawler de LiteSpeed se identifica a sí mismo). Muchos plugins ya tienen una opción para esto.

Errores comunes que ralentizan el crawler

Error 1: Cachear TODO sin discriminar

Pensás «si cacheo más páginas, más rápido es el sitio» y seteás el crawler para que visite cada URL que existe: posts, páginas, categorías, etiquetas, archivos, búsquedas, paginación. Te terminas cacheando 20.000 URLs innecesarias cuando 500 hubieran sido suficientes. El cache crece, el crawl tarda horas, y la mayoría del cache nunca se usa.

Error 2: Ignorar los logs del crawler

El crawler produce logs que dicen exactamente qué está pasando: «error 504 en esta URL», «timeout aquí», «esta página tardó 15 segundos en cargar». (Eso ultimo es una alarma: si una página tarda 15 segundos en renderizar, el problema no es el crawler, es tu sitio.) Nadie lee los logs, todos se quejan de que «tarda mucho». Más contexto en plugins de seguridad impactan el crawling.

Error 3: Confundir «el crawler está lento» con «mi sitio es lento»

A veces el crawler no está lento, pero tu sitio SÍ. El crawler refleja la velocidad real de tu sitio (porque visita URLs igual que un usuario). Si el crawler tarda horas, es porque cada página en tu sitio tarda mucho en renderizar. El problema no es LiteSpeed Cache, es tu tema, tus plugins, tu BD o tu servidor.

Podés leer más sobre esto en Why is the LiteSpeed ​​Cache crawler so slow?, donde cubrimos los detalles.

Preguntas Frecuentes

¿Cuánto tiempo debería tardar el crawler en completar un ciclo?

Depende del tamaño de tu sitio y tu configuración. Para un sitio pequeño (100-500 URLs), entre 10 minutos y 1 hora es normal. Para uno mediano (500-2000 URLs), 1-4 horas. Para sitios grandes (5000+ URLs), puede tardar más. La clave es que sea consistente: si siempre tarda lo mismo, está bien. Si de repente empezó a tardar 5x más, algo cambió (más tráfico, BD más lenta, plugin nuevo).

¿El crawler afecta a los visitantes reales del sitio?

Sí, si está muy agresivo. Por eso tenés que limitarlo. Un crawler con 1-2 requests simultáneos, con delay entre requests, casi no se nota. Un crawler descontrolado con 10 requests simultáneos puede ralentizar tu sitio durante las horas que corre. Si tu sitio es lento entre ciertos horarios, culpa al crawler (o a un backup de BD que corre simultáneamente).

¿Vale la pena pre-cachear todas las URLs?

No siempre. Pre-cachear es útil para URLs que reciben mucho tráfico. Las 80/20: si el 80% de tu tráfico viene del 20% de tus URLs, cachea solo ese 20%. Lo demás está desperdiciando recursos del servidor. Algunas URLs (búsquedas, filtros dinámicos, carrito de compras en WooCommerce) no deberían estar cacheadas porque cambian constantemente.

¿Qué diferencia hay entre LiteSpeed Cache y otros plugins de caching?

LiteSpeed es más agresivo que WP Super Cache o WP Fastest Cache porque el pre-caching es automático y el crawler es más sofisticado. Eso lo hace potente (cachés frescos todo el tiempo) pero también más pesado si no lo configuras. Si tu sitio es muy pequeño y tiene recursos limitados, un plugin más simple puede ser mejor opción. Si tenés servidor con LiteSpeed Web Server (no Apache), LiteSpeed Cache aprovecha características nativas y es muy eficiente.

Conclusión

Un crawler lento de LiteSpeed Cache es casi siempre síntoma de configuración no optimizada, no un defecto del plugin. La solución es entender dónde está el cuello de botella (CPU, BD, plugins, concurrencia), reducir carga sobre esos recursos, y setear límites realistas. No es «rápido por defecto», es «potente si lo configuras bien».

Lo que tiene que hacer vos: bajá la concurrencia, agregá delays, reducí las URLs a cachear, y optimizá la BD. En la mayoría de casos, con esos cambios el crawler vuelve a velocidad sensata en una o dos iteraciones. Si no cambia nada, el problema es más profundo (servidor sobrecargado, hosting compartido sin recursos). Eso ya es otra conversación.

Fuentes

Categorizado en:

Noticias Tech

Etiquetado en:

, , , ,