🎨 Sysprovider Code
Sysprovider LogoWiki
🇪🇸Hosting español para ecommerce

Edge Computing con WordPress: CDN, Varnish y Cloudflare Workers

Actualizado el 27 de febrero de 2026

Introducción: El Desafío de la Velocidad en WordPress

WordPress alimenta más del 43% de la web, pero su naturaleza dinámica y basada en PHP/MySQL presenta un desafío inherente: la latencia. Cada solicitud a un servidor de origen implica procesamiento de scripts, consultas a la base de datos y generación de HTML. Para un usuario en Australia accediendo a un servidor en Madrid, la latencia de red puede superar los 300 ms, a lo que se suma el tiempo de generación de la página.

Aquí es donde entra en juego el Edge Computing. La idea es simple pero poderosa: mover la lógica de procesamiento y almacenamiento en caché lo más cerca posible del usuario final, al “borde” de la red (edge). Dejar de tratar a WordPress como un monolito centralizado y orquestar una arquitectura donde el borde maneje la mayoría de las peticiones.

Este artículo explora cómo combinar tres tecnologías clave —CDN, Varnish y Cloudflare Workers— para construir un stack de Edge Computing sobre WordPress que minimice la latencia, reduzca la carga del servidor y ofrezca una experiencia de usuario ultrarrápida.

La Base: CDN WordPress y Caching Estático

Un CDN (Content Delivery Network) es el primer escalón del Edge Computing. Su función principal es cachear activos estáticos (CSS, JS, imágenes) en servidores perimetrales (PoPs). Para WordPress, esto es crítico, pero no suficiente.

¿Por qué un CDN tradicional se queda corto?

Un CDN típico (como Cloudflare en modo proxy simple) acelera la entrega de archivos estáticos, pero la página HTML dinámica sigue generándose en el origen. El usuario final recibe el HTML desde el servidor central, no desde el borde.

Para cachear el HTML dinámico de WordPress en el borde, necesitamos algo más: reglas de caché inteligentes y la capacidad de purgar selectivamente. Aquí es donde Varnish y Cloudflare Workers marcan la diferencia.

[TIP] No todos los CDN son iguales. Busca uno que permita Edge Side Includes (ESI) o reglas de caché personalizadas a nivel de borde. Cloudflare, Fastly y KeyCDN son buenas opciones.

Varnish: El Orquestador de Caché en el Origen

Varnish Cache es un acelerador de aplicaciones web que se sitúa frente a tu servidor web (Nginx/Apache). Su potencia reside en su lenguaje de configuración, VCL (Varnish Configuration Language), que permite un control granular sobre cómo se cachea y sirve el contenido.

Integrando Varnish con WordPress

Varnish actúa como un proxy inverso de alto rendimiento. Cuando un visitante solicita una página:

  1. La petición llega a Varnish.
  2. Varnish busca la página en su memoria caché.
  3. Si existe (HIT): la sirve al instante (latencia de milisegundos).
  4. Si no existe (MISS): la solicita al backend de WordPress, la cachea y la sirve.

Para WordPress, la configuración típica implica:

  • Cachear por URL: wp-content/uploads/*, wp-includes/* con TTL largos.
  • Saltar la caché para administradores: No cachear /wp-admin/ ni usuarios logueados.
  • Manejar cookies: Eliminar cookies de seguimiento (Google Analytics, etc.) para no romper la caché.

Ejemplo de configuración VCL básica para WordPress:

sub vcl_recv {
    # No cachear wp-admin ni wp-login
    if (req.url ~ "^/wp-(login|admin)") {
        return (pass);
    }

    # No cachear si hay cookie de sesión de WordPress
    if (req.http.cookie ~ "wordpress_logged_in_" || req.http.cookie ~ "comment_author_") {
        return (pass);
    }

    # Eliminar cookies que no sean esenciales para la caché
    if (req.http.cookie) {
        set req.http.cookie = ";" + req.http.cookie;
        set req.http.cookie = regsuball(req.http.cookie, "; +", ";");
        set req.http.cookie = regsuball(req.http.cookie, ";(PHPSESSID|wordpress_test_cookie)=", ";");
        set req.http.cookie = regsuball(req.http.cookie, ";[^ ][^;]*", "");
        set req.http.cookie = regsuball(req.http.cookie, "^[; ]+|[; ]+$", "");

        if (req.http.cookie == "") {
            unset req.http.cookie;
        }
    }

    # Cachear normalmente
    return (hash);
}

sub vcl_backend_response {
    # Cachear páginas HTML de WordPress por 1 hora
    if (beresp.http.content-type ~ "text/html") {
        set beresp.ttl = 1h;
        # Permitir que el borde (CDN) cachee también
        set beresp.http.Cache-Control = "public, max-age=3600, s-maxage=3600";
    }
}

[WARNING] Nunca cachees el área de administración. Una caché de /wp-admin/ puede exponer datos sensibles de otros usuarios o impedir la edición en tiempo real. Siempre usa return(pass) para esas rutas.

Limitaciones de Varnish solo

Varnish es excelente para acelerar el servidor de origen, pero sigue estando en un único datacenter (o varios si tienes alta disponibilidad). La latencia geográfica persiste. Para un usuario en Japón, la petición viajará hasta tu servidor con Varnish en Virginia, aunque Varnish responda rápido, el viaje de ida y vuelta añade latencia.

Cloudflare Workers: La Revolución del Edge Computing

Cloudflare Workers es una plataforma de Edge Computing que ejecuta código JavaScript (o WASM) en los más de 300 datacenters de Cloudflare en todo el mundo. Esto permite ejecutar lógica personalizada directamente en el borde, sin tocar el servidor de origen.

Casos de Uso para WordPress con Workers

Los Workers pueden interceptar, modificar y responder a peticiones HTTP antes de que lleguen a tu servidor. Aquí tienes los usos más potentes:

1. Caché Personalizada de HTML (Edge Cache)

Puedes cachear páginas HTML completas de WordPress directamente en el borde de Cloudflare, con un control de TTL mucho más fino que el CDN estándar.

Ejemplo de Worker para cachear HTML:

// Escuchar el evento 'fetch'
addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const url = new URL(request.url)

  // Solo cachear GET y no páginas de admin
  if (request.method !== 'GET' || url.pathname.startsWith('/wp-admin/')) {
    return fetch(request)
  }

  // Clave de caché: URL + cabeceras de idioma (si usas WPML)
  const cacheKey = new Request(url.toString(), request)
  const cache = caches.default

  // Intentar obtener del caché del borde
  let response = await cache.match(cacheKey)

  if (!response) {
    // Si no está en caché, ir al origen
    response = await fetch(request)

    // Solo cachear respuestas exitosas
    if (response.status === 200) {
      // Clonar la respuesta para poder modificarla
      const newResponse = new Response(response.body, response)

      // Establecer cabeceras de caché en el borde
      newResponse.headers.set('Cache-Control', 'public, max-age=0, s-maxage=3600') // 1 hora en el borde
      newResponse.headers.set('CF-Cache-Status', 'MISS')

      // Almacenar en el caché del Worker
      event.waitUntil(cache.put(cacheKey, newResponse.clone()))
      return newResponse
    }
  } else {
    // Devolver desde el borde
    return response
  }
}

[INFO] Este Worker cachea el HTML en el borde durante 1 hora. Cuando un usuario visita la página, el Worker responde desde el datacenter más cercano, reduciendo la latencia de 200ms a <10ms.

2. Personalización Dinámica sin Tocar el Origen

Puedes modificar el HTML en el borde para personalizar contenido (por geolocalización, dispositivo, etc.) sin que WordPress lo sepa. Por ejemplo, mostrar un banner diferente a usuarios de EE.UU. vs. Europa.

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const response = await fetch(request)
  const country = request.cf.country // Cloudflare detecta el país

  // Solo modificar HTML
  if (response.headers.get('content-type').includes('text/html')) {
    const html = await response.text()
    let newHtml = html

    if (country === 'ES') {
      newHtml = html.replace('{{BANNER}}', '¡Oferta especial para España!')
    } else if (country === 'MX') {
      newHtml = html.replace('{{BANNER}}', 'Envío gratis a México')
    }

    return new Response(newHtml, response)
  }

  return response
}

3. A/B Testing en el Borde

Puedes dividir el tráfico entre dos versiones de una página (control vs. variante) sin añadir latencia ni tocar el servidor.

Arquitectura Completa: Varnish + Cloudflare Workers + CDN

La combinación óptima es una arquitectura en tres capas:

  1. Capa 1: Cloudflare Workers (Borde Global)

    • Cachea el HTML en los 300+ PoPs.
    • Ejecuta lógica personalizada (geolocalización, A/B testing, redirecciones).
    • Reduce la latencia al mínimo absoluto.

  2. Capa 2: Cloudflare CDN (Borde Global)

    • Sirve activos estáticos (imágenes, CSS, JS) con TTL largos.
    • Actúa como proxy inverso global.

  3. Capa 3: Varnish Cache (Origen)

    • Acelera el servidor de WordPress.
    • Maneja el caché de las páginas que no están en el borde.
    • Protege el servidor de picos de tráfico.

Flujo de una petición:

  1. Usuario solicita https://tusitio.com/producto-a.
  2. Cloudflare Worker recibe la petición en el PoP más cercano.
  3. Si el Worker tiene la página en su caché: responde al instante.
  4. Si no: la petición viaja al origen, donde Varnish la recibe.
  5. Varnish busca en su caché local. Si existe, la sirve. Si no, la solicita a WordPress.
  6. La respuesta viaja de vuelta al Worker, que la cachea para futuras peticiones.

Estrategias para Minimizar la Latencia

Aquí tienes tácticas concretas para cada capa:

En el Borde (Workers + CDN)

  • Cachea todo lo que puedas: HTML, API REST (si es pública), fragmentos de AJAX.
  • Usa TTLs agresivos: Para contenido no crítico, 1 hora o más. Para contenido dinámico (comentarios recientes), 5 minutos.
  • Implementa purga inteligente: Cuando publiques un artículo, purga solo las URLs afectadas (home, categoría, artículo) mediante la API de Cloudflare.

En el Origen (Varnish + WordPress)

  • Fragmenta el HTML: Usa ESI (Edge Side Includes) para que partes dinámicas (como el carrito de la compra) se sirvan desde el borde sin romper la caché del resto de la página.
  • Optimiza WordPress: Usa un plugin de caché (WP Rocket, W3 Total Cache) que integre con Varnish.
  • Minimiza las consultas a la BD: Usa Redis o Memcached para objetos.

[WARNING] Cuidado con la purga masiva. Si purgas todo el caché del borde cada vez que publicas un artículo, tu servidor de origen recibirá una avalancha de peticiones. Purga solo lo necesario.

Métricas Clave para Medir el Éxito

No basta con implementar; hay que medir. Monitorea estas métricas:

  • Latencia de origen: Tiempo que tarda Varnish en responder (debería ser <50ms).
  • Tasa de aciertos del Worker: Porcentaje de peticiones servidas desde el borde (objetivo >80%).
  • Tasa de aciertos de Varnish: Porcentaje de peticiones servidas desde la caché de Varnish (objetivo >90%).
  • Tiempo hasta el primer byte (TTFB): Medido desde distintas geografías (objetivo <100ms global).
  • Carga del servidor: Reducción de peticiones al backend de WordPress.

Conclusión: El Futuro es el Borde

Combinar Edge Computing con WordPress no es una opción, es una necesidad para competir en velocidad. Varnish te da el control granular en el origen, mientras que Cloudflare Workers te permite ejecutar lógica y cachear contenido en el borde global, eliminando la latencia geográfica.

Esta arquitectura no solo acelera tu sitio, sino que lo hace más resiliente. Durante un pico de tráfico (como un artículo viral), el borde absorbe la mayoría de las peticiones, protegiendo tu servidor de WordPress. El resultado: una experiencia ultrarrápida para el usuario, mejor SEO y menores costos de infraestructura.

¿El siguiente paso? Empieza por implementar Varnish en tu servidor, luego activa Workers para cachear el HTML dinámico. Tu audiencia (y Google) te lo agradecerán.

¿Necesitas ayuda?Son dos de nuestros técnicos, Agustín y Mikel, y están disponibles para resolver cualquier problema.

Hablar con ellos ahora
Agustín y Mikel