WordPress Serverless Cloudflare Workers 2026

Introducción: ¿Por qué una infraestructura serverless para WordPress?

WordPress sigue siendo el CMS más utilizado del mundo, pero su arquitectura tradicional, basada en un servidor Apache/Nginx con PHP y MySQL, presenta limitaciones claras: cuellos de botella en picos de tráfico, costos de escalado vertical y una superficie de ataque considerable. La infraestructura serverless promete resolver esto, y combinarla con Cloudflare Workers —la plataforma de edge functions de Cloudflare— permite ejecutar código en el borde de la red, reduciendo latencia y mejorando la seguridad.

Este artículo explora cómo construir un WordPress sin servidor utilizando Cloudflare Workers como capa de proxy, caché y lógica dinámica. Analizaremos los componentes clave, las estrategias de implementación y los casos de uso avanzados.

[INFO] No confundas “serverless” con “sin servidor”. En realidad, el código se ejecuta en servidores gestionados por terceros (como Cloudflare), pero tú no administras la infraestructura subyacente.

¿Qué es Cloudflare Workers y cómo encaja con WordPress?

Cloudflare Workers es una plataforma de computación en el borde (edge computing) que ejecuta código JavaScript (o WASM) en más de 330 centros de datos alrededor del mundo. Al actuar como intermediario entre el usuario y tu servidor de origen, puedes:

Cachear respuestas completas de WordPress a nivel de edge.
Modificar dinámicamente el HTML, CSS o JS antes de servirlo.
Redirigir tráfico basado en geolocalización, dispositivos o cookies.
Implementar lógica de autenticación o protección contra bots sin tocar el servidor.

Para WordPress, el Worker puede funcionar como un reverse proxy inteligente. En lugar de que cada visita llegue a tu VPS o hosting compartido, el Worker decide si servir desde caché, solicitar una página fresca al origen o ejecutar una función edge.

Componentes de la arquitectura serverless

Origen WordPress: Un servidor mínimo (p.ej., DigitalOcean Droplet de 2GB RAM) que ejecuta PHP y MySQL. No necesita escalar para picos de tráfico.
Cloudflare Workers: Scripts JavaScript que interceptan todas las peticiones.
Caché de Cloudflare: Almacena respuestas estáticas (páginas, imágenes, CSS/JS) en el edge.
Base de datos serverless (opcional): Para almacenar sesiones, comentarios o datos de WooCommerce sin depender de MySQL tradicional.
CDN global: Cloudflare ya es una CDN, pero los Workers permiten personalizar el comportamiento.

Estrategias de implementación: desde lo básico hasta lo avanzado

1. Proxy básico con caché inteligente

El Worker más simple reenvía las peticiones a tu servidor de origen, pero aplica reglas de caché agresivas para contenido público. Aquí tienes un ejemplo de script básico:

// Cloudflare Worker - Proxy básico con caché
addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const url = new URL(request.url)
  const originUrl = 'https://tu-wordpress.com' + url.pathname + url.search

  // Clonamos la request para modificar headers
  const modifiedRequest = new Request(originUrl, {
    method: request.method,
    headers: request.headers,
  })

  // Intentar servir desde caché de Cloudflare (edge)
  const cache = caches.default
  let response = await cache.match(request)

  if (!response) {
    response = await fetch(modifiedRequest)

    // Cachear solo si es GET y código 200
    if (request.method === 'GET' && response.status === 200) {
      const headers = new Headers(response.headers)
      headers.set('Cache-Control', 'public, max-age=3600') // 1 hora
      const cachedResponse = new Response(response.body, {
        status: response.status,
        statusText: response.statusText,
        headers: headers,
      })
      event.waitUntil(cache.put(request, cachedResponse))
      return cachedResponse.clone()
    }
  }
  return response
}

[TIP] Para contenido dinámico (carrito de WooCommerce, formularios de contacto), excluye rutas específicas usando url.pathname.includes('/checkout/') y no cacheadas.

2. Offloading de assets estáticos y optimización de imágenes

WordPress genera muchos assets dinámicamente (thumbnails, CSS combinados). Con Workers puedes redirigir las peticiones de imágenes a un bucket S3 o a la propia CDN de Cloudflare Images, reduciendo la carga del servidor.

// Ejemplo: redirigir imágenes a Cloudflare Images
if (url.pathname.startsWith('/wp-content/uploads/')) {
  const imageUrl = `https://imagedelivery.net/TU_ID/${encodeURIComponent(url.pathname)}`
  return Response.redirect(imageUrl, 301)
}

También puedes minificar HTML sobre la marcha usando Workers + HTMLRewriter:

class Minifier {
  element(element) {
    // Eliminar comentarios HTML
    if (element.tagName === 'comment') {
      element.remove()
    }
  }
}

async function handleRequest(request) {
  const response = await fetch(request)
  return new HTMLRewriter().on('*', new Minifier()).transform(response)
}

3. Edge Functions para personalización dinámica

Una de las ventajas más potentes de la infraestructura serverless es la capacidad de ejecutar lógica en el borde. Por ejemplo, puedes detectar la ubicación del usuario y modificar el menú de navegación o el idioma sin esperar a que el servidor procese PHP.

// Geolocalización con Cloudflare Workers
const country = request.cf.country // 'ES', 'US', etc.
if (country === 'ES') {
  // Redirigir a versión en español
  const spanishUrl = `https://tu-wordpress.com/es${url.pathname}`
  return Response.redirect(spanishUrl, 302)
}

También puedes implementar A/B testing modificando el HTML en el edge:

// A/B testing simple
const variant = Math.random() < 0.5 ? 'A' : 'B'
if (variant === 'B') {
  // Cambiar el título del héroe
  const response = await fetch(request)
  return new HTMLRewriter()
    .on('h1.hero-title', {
      element(element) {
        element.setInnerContent('¡Oferta especial solo hoy!')
      }
    })
    .transform(response)
}

Casos de uso reales y limitaciones

¿Cuándo tiene sentido esta arquitectura?

Sitios con tráfico variable: Un blog que recibe picos por un artículo viral. El Worker cachea la página y el servidor apenas nota el aumento.
Sitios multiregión: Usuarios en Asia, Europa y América. Cada uno recibe respuesta desde el edge más cercano.
Proyectos con presupuesto ajustado: Pagas solo por las peticiones al Worker (primeros 10 millones gratis) y un servidor pequeño para el backend.

Limitaciones importantes

No es para WooCommerce complejo: Los carritos de compra requieren sesiones de servidor. Puedes usar Workers + KV (key-value store) para almacenar carritos, pero la latencia puede ser mayor.
Plugins incompatibles: Algunos plugins asumen que PHP y WordPress están en el mismo servidor. Por ejemplo, plugins de caché como W3 Total Cache pueden entrar en conflicto.
Caché de páginas de administrador: Nunca cachees /wp-admin/. Usa condicionales en el Worker para excluir rutas de administración.

[WARNING] Si usas Cloudflare Workers para cachear páginas, asegúrate de purgar la caché cuando publiques contenido nuevo. Puedes automatizarlo con un webhook desde WordPress (usando el plugin Cloudflare).

Pasos para desplegar tu propia infraestructura serverless

Configura tu servidor WordPress: Instala WordPress en un VPS mínimo (1 CPU, 1GB RAM). Desactiva cualquier plugin de caché (W3 Total Cache, WP Super Cache) porque el Worker se encargará.
Crea un Worker en Cloudflare: Ve al panel de Cloudflare > Workers > Create a Service. Pega el script básico de proxy (el primero de este artículo).
Configura el enrutamiento: En Workers > Routes, añade una ruta como *tu-dominio.com/* y asígnala al Worker.
Ajusta reglas de caché: En Cloudflare > Caching > Configuration, activa “Cache Level: Standard” y “Edge Cache TTL: 1 hour”.
Prueba la velocidad: Usa herramientas como GTmetrix o WebPageTest. Deberías ver una reducción drástica en Time to First Byte (TTFB).

Conclusión: ¿Es el futuro de WordPress?

La infraestructura serverless para WordPress con Cloudflare Workers no es una solución mágica, pero resuelve problemas reales de escalabilidad, costos y rendimiento. Si tu sitio tiene mucho tráfico de lectura (blogs, medios, documentación), esta arquitectura te permite dormir tranquilo sin preocuparte por picos de visitas. Para sitios transaccionales complejos, aún necesitarás soluciones híbridas.

El ecosistema está madurando: Cloudflare ha lanzado Workers for Platforms y D1 (base de datos SQLite serverless), lo que acerca aún más la posibilidad de un WordPress sin servidor completo. Mientras tanto, empezar con un Worker como proxy inteligente es un paso sencillo y de bajo riesgo.

[INFO] Recuerda que la clave está en el equilibrio: usa Workers para lo que hacen mejor (caché, redirecciones, transformación de HTML) y deja que WordPress haga lo suyo (gestión de contenido, plugins esenciales). No intentes serverless todo de golpe.

¿Listo para dar el salto? Empieza con un Worker básico, mide los resultados y ve añadiendo capas de lógica en el edge. Tu servidor (y tu bolsillo) te lo agradecerán.