Cómo calentar la caché de tu sitio web en Mac — Medir tiempos de respuesta en frío y en caché

Si administras un sitio web — WordPress, TYPO3, Drupal, Shopify o cualquier CMS — probablemente hayas notado que la primera visita después de un vaciado de caché o un despliegue es dolorosamente lenta, mientras que cada visita posterior es rápida. Eso es tu caché haciendo su trabajo. La pregunta es: ¿qué le pasa al visitante que llega primero?

En la mayoría de las configuraciones, ese visitante paga el precio completo. Espera a que el servidor genere la página desde cero, consulte la base de datos, ejecute cada plugin, y solo entonces recibe una respuesta. El segundo visitante, ahora servido desde la caché, obtiene la versión rápida. El calentamiento de caché cierra esa brecha simulando ser el primer visitante — en cada página — para que los usuarios reales no tengan que serlo.

Este artículo explica qué hace realmente el calentamiento de caché, por qué los enfoques ingenuos como wget --recursive se quedan cortos, y cómo medir si tu caché está funcionando. Terminaremos con una herramienta nativa de macOS construida específicamente para esto.

¿Qué es el calentamiento de caché, realmente?

Un calentador de caché es un crawler con una tarea concreta: visitar cada URL de tu sitio para que el servidor almacene en caché la respuesta generada. La próxima vez que un usuario real solicite esa página, se servirá desde la caché — desde Nginx FastCGI, Varnish, LiteSpeed, Redis, un plugin de WordPress como WP Rocket o W3 Total Cache, o un nodo edge de CDN como Cloudflare o Fastly.

Un buen calentador de caché hace tres cosas:

1. Activar la generación de caché en cada página (el paso en frío).
2. Verificar que la caché se está poblando y sirviendo realmente (el paso caliente).
3. Medir la diferencia para saber si tu configuración de caché está funcionando.

El tercer punto es donde la mayoría de las herramientas fallan. Hay muchos scripts que pueden rastrear un sitio. Muy pocos te dicen si el rastreo sirvió de algo.

Cuándo el calentamiento de caché es imprescindible

No siempre necesitas calentar tu caché. Para un blog pequeño con tráfico estable y TTL largos, el primer visitante del día calienta la página de forma natural. Pero hay escenarios donde el calentamiento no es opcional:

• Después de un despliegue. La mayoría de los backends de caché invalidan entradas cuando la aplicación cambia. La primera visita post-despliegue a cada página es un render en frío. Si tienes 500 páginas de productos y despliegas dos veces al día, son 1.000 primeras visitas lentas al día — muchas de ellas de bots, crawlers o enlaces de marketing.
• Después de un vaciado de caché. Las purgas de caché programadas (limpiezas nocturnas, recargas de configuración, importaciones de contenido) borran toda la caché. Sin calentamiento, la siguiente hora de tráfico es una estampida sobre tu origen.
• Con TTL cortos. Si tu caché expira cada 15 minutos, cada página está sin caché 96 veces al día. El calentamiento mantiene las cosas consistentemente calientes.
• Para SEO y Core Web Vitals. Googlebot penaliza las primeras respuestas lentas. Si Googlebot rastrea una página fría, tus puntuaciones de LCP y TTFB sufren — y el bot no vuelve cinco minutos después a ver la versión rápida.
• Para campañas publicitarias y envíos de email. Cuando envías 50.000 destinatarios de un boletín simultáneamente a una landing page, no quieres que los primeros 500 visitantes pongan el servidor de rodillas antes de que la caché se llene.

Por qué wget --mirror no es suficiente

El reflejo clásico del desarrollador es usar wget o curl en un bucle:

wget --recursive --no-directories --delete-after https://example.com

Esto funciona más o menos. Visita las páginas, activa el renderizado, llena la caché. Pero no te da ninguna visibilidad sobre lo que pasó. No puedes responder ninguna de las preguntas que importan:

• ¿La caché realmente funcionó? Quizás tu cabecera Cache-Control: no-cache está silenciosamente anulando toda la configuración.
• ¿Cloudflare sirve desde el edge, o pasa al origen cada vez? La cabecera CF-Cache-Status lo sabe, pero wget no te lo muestra.
• ¿Cuánto más rápida es una respuesta en caché que una en frío? ¿80 ms vs. 2.000 ms (excelente) o 800 ms vs. 900 ms (tu caché no hace casi nada)?
• ¿Qué páginas faltan en el sitemap? ¿Cuáles devuelven 404? ¿Cuáles tienen cabeceras de caché que nunca les permitirán almacenarse?

wget descarga el HTML y sigue. Debes analizar los logs manualmente, añadir --server-response, hacer pipe a awk, y cuando por fin tienes un informe útil has reinventado la mitad de una herramienta de análisis de caché.

Lo que mide un buen calentador de caché

El trabajo real no es solo visitar páginas. Es responder estas preguntas después de una ejecución:

• Tasa de aciertos de caché. De N páginas, ¿cuántas se sirvieron desde caché en el segundo paso?
• Tiempo de respuesta en frío vs. caliente. Por cada URL, ¿cuál era la latencia en la primera visita frente a la segunda?
• Porcentaje de mejora. En promedio, ¿cuánto más rápido respondieron las páginas en caché?
• Inventario de cabeceras de caché. ¿Qué páginas envían Cache-Control: public, max-age=..., cuáles envían no-store, cuáles devuelven X-Cache: HIT o CF-Cache-Status: DYNAMIC? Esto te dice de un vistazo dónde está mal configurada tu caché.
• Errores. ¿Qué URLs devuelven 404? ¿Cuáles se agotan? ¿Cuáles devuelven 500 bajo carga de rastreo?

Sin esto, estás calentando a ciegas. Podrías tener un cron job ejecutándose cada hora que genera carga en tu origen sin poblar una sola entrada de caché — y no lo sabrías.

Detectar la caché detrás del telón

Los sitios web modernos funcionan con una pila de cachés. Un sitio WordPress típico en un hosting gestionado podría tener:

• Cloudflare en el edge (CF-Cache-Status, Age)
• LiteSpeed o Nginx FastCGI cache en el servidor web (X-LiteSpeed-Cache, X-Cache)
• Varnish delante de la aplicación (X-Varnish, Age)
• WP Rocket o W3 Total Cache dentro de WordPress (comentarios HTML, cabeceras personalizadas)
• Object cache (Redis, Memcached) para consultas DB — invisible en cabeceras HTTP

Cuando una página es lenta, saber qué capa falló importa. Si Cloudflare es HIT pero el tiempo de respuesta sigue siendo de 800 ms, tu problema es que Cloudflare está sirviendo una respuesta en caché obsoleta pero lenta. Si Cloudflare es MISS pero LiteSpeed es HIT, tu configuración edge es incorrecta. Un calentador de caché que inspecciona las cabeceras de respuesta te da una vista capa por capa.

Del mismo modo, conocer el CMS importa. WordPress, TYPO3, Drupal, Shopify, Magento, Ghost y los generadores de sitios estáticos tienen cada uno sus propias convenciones de caché. Un calentador que detecta el CMS puede mostrar los valores predeterminados relevantes y sugerencias de plugins — wp-super-cache se comporta diferente de Drupal con Varnish, que se comporta diferente de un sitio Hugo exportado estáticamente.

Descubrimiento del sitemap — no pierdas la mitad de tus páginas

El rastreo solo por enlaces pierde las páginas que no están enlazadas desde la página de inicio. Landing pages huérfanas, entradas de blog antiguas, variantes de productos, archivos paginados, páginas de etiquetas — están en el sitemap pero no en la navegación principal. Si no rastreos el sitemap, esas páginas permanecen frías, y a menudo son las que reciben tráfico de búsqueda orgánica.

Un calentador serio obtiene robots.txt, analiza las directivas Sitemap: y recorre el árbol del sitemap — incluyendo índices de sitemaps que referencian múltiples sitemaps hijo. Combinado con el rastreo por enlaces, esto cubre tanto las páginas estructurales como el contenido de larga cola.

La forma nativa en Mac: WebCacheWarmer

Si quieres todo esto sin ensamblarlo tú mismo, esto es exactamente para lo que fue construido WebCacheWarmer. Es una aplicación macOS nativa que realiza un rastreo en dos pasos:

• Paso 1 (en frío): visita cada URL descubierta, activa la generación de caché, mide el tiempo de respuesta en frío.
• Paso 2 (caliente): revisita cada URL, mide el tiempo de respuesta en caché, calcula la mejora.

Al final obtienes un informe claro: páginas rastreadas, errores, tiempo en frío promedio, tiempo caliente promedio, porcentaje de mejora y tasa de aciertos de caché. Puedes ver exactamente qué páginas se están almacenando en caché y cuáles no — y el inspector de cabeceras de caché muestra por qué.

Algunos detalles que importan en el uso diario:

• Descubrimiento del sitemap desde robots.txt, con un visor integrado y exportación XML.
• Detección de CMS para WordPress, Drupal, Shopify, TYPO3, Magento, Joomla, Wix, Squarespace, Ghost, Hugo, Jekyll y más.
• Análisis de cabeceras de caché a través de Cache-Control, X-Cache, CF-Cache-Status, Age, ETag, Varnish y LiteSpeed.
• Exportación a CSV, Excel o JSON con todos los detalles de cabeceras, para rastrear la salud de la caché a lo largo del tiempo o entregar un informe a un proveedor de hosting.
• Descargador de sitios estáticos integrado, con modo de reanudación e incremental y vista previa local — útil para archivar un sitio antes de una migración.
• Recrawls programados a intervalos de 1, 4, 12 o 24 horas para mantener las páginas de alto tráfico constantemente calientes.
• Cumplimiento de robots.txt con semántica de coincidencia de ruta más larga, para no rastrear rutas que no deberías.

Todo se ejecuta localmente en tu Mac. No se envían datos a ningún lugar excepto las solicitudes HTTP al sitio que estás calentando — lo que importa cuando rastreas entornos de staging con contenido de acceso controlado.

Un flujo de trabajo típico

1. Después de un despliegue, ejecuta WebCacheWarmer contra tu URL de producción. Comprueba la tasa de aciertos de caché en el paso caliente — 90%+ es saludable, por debajo del 50% significa que algo está mal configurado.
2. Inspecciona las cabeceras de caché para las páginas que todavía estaban frías en el paso caliente. Normalmente una de estas tres causas: una cabecera Cache-Control ausente, una cookie que derrota la caché, o un parámetro de URL que la caché trata como único.
3. Exporta los resultados a CSV si necesitas compartirlos con una agencia, proveedor de hosting o un compañero que quiere los números en bruto.
4. Programa un recrawl cada pocas horas si tus TTL son cortos. El calentador mantendrá las páginas calientes sin intervención manual.

Conclusión

El calentamiento de caché es una de esas prácticas operativas que se paga a sí misma instantáneamente pero rara vez se comenta. Si tus tiempos de respuesta en la primera visita son lentos y tu tasa de aciertos de caché es mediocre, un pase de calentamiento después de cada despliegue cierra la brecha — y los usuarios reales obtienen la versión rápida que se supone que tu caché debía entregar desde el principio.

La medición es lo que hace que esto valga la pena. Una caché que no has medido es una caché sobre la que estás adivinando. WebCacheWarmer te da los números, en vivo, en una aplicación Mac nativa que respeta tu tiempo y tus datos.

Si aprecias las utilidades de Mac sin fricción que hacen una cosa bien, Convertir CSV a Excel en Mac sigue la misma filosofía para el trabajo con hojas de cálculo.