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

Implementación de Edge Computing con WordPress y Cloudflare Workers

Actualizado el 6 de septiembre de 2025

La latencia es el enemigo silencioso de cualquier sitio web moderno. Cuando tu WordPress está alojado en un único servidor central, un usuario en Tokio puede experimentar tiempos de carga de 3 o 4 segundos, mientras que uno en Madrid lo carga en 200ms. Esta disparidad geográfica mata conversiones, perjudica el SEO y degrada la experiencia de usuario. La solución no es simplemente comprar un servidor más potente, sino cambiar la arquitectura: bienvenido al Edge Computing.

Implementar Edge Computing con Cloudflare Workers sobre WordPress te permite ejecutar lógica personalizada (sin servidor, serverless) en la capa de borde de la red de Cloudflare, justo donde está tu usuario. Esto transforma tu WordPress en una aplicación global, ultrarrápida y resiliente, sin necesidad de gestionar infraestructura compleja.

En este artículo, exploraremos a fondo cómo combinar WordPress con Cloudflare Workers para lograr una optimización global real. Verás desde la teoría hasta ejemplos prácticos de código Workers que cachean dinámicamente, modifican HTML sobre la marcha y hasta sirven contenido desde el edge sin tocar tu servidor de origen.

¿Por qué Edge Computing para WordPress? El problema de la distancia

El modelo tradicional de WordPress es monolítico: un servidor PHP + MySQL centralizado. Cada petición viaja desde el navegador del usuario hasta ese servidor, sin importar si está al otro lado del mundo.

El Edge Computing invierte esta lógica. En lugar de llevar la petición al servidor, llevamos la lógica de procesamiento (y el contenido) al usuario. Con Cloudflare Workers, tu código se ejecuta en más de 330 ciudades en todo el mundo.

Beneficios clave:

  • Reducción drástica de latencia: El tiempo de ida y vuelta (RTT) se reduce de cientos de milisegundos a menos de 20ms.
  • Escalado instantáneo: Los Workers son serverless. Si recibes un pico de 10,000 peticiones por segundo, el edge lo absorbe sin necesidad de escalar tu servidor WordPress.
  • Ahorro en costes de servidor: Al cachear y procesar en el borde, reduces la carga en tu origen. Un VPS pequeño puede servir a millones de visitas diarias si está bien protegido por un Worker.
  • Personalización geolocalizada: Puedes servir diferente contenido, idiomas o redirecciones basadas en la ubicación del visitante, todo desde el edge.

Arquitectura: Cómo encaja Cloudflare Workers en tu WordPress

Antes de escribir código, es crucial entender el flujo de peticiones cuando introduces un Worker.

  1. Usuario visita tudominio.com -> La petición llega al DNS de Cloudflare.
  2. Cloudflare enruta la petición a su Worker (si está configurado como ruta).
  3. El Worker se ejecuta:
    • Puede devolver una respuesta directamente desde la caché (cache API de Workers o KV).
    • Puede modificar la petición (añadir cabeceras, reescribir URLs).
    • Puede hacer fetch a tu servidor de origen (WordPress).
  4. Respuesta optimizada: El Worker procesa la respuesta del origen (minifica HTML, inyecta scripts, cachea fragmentos) y la devuelve al usuario.

Componentes necesarios:

  • Un dominio en Cloudflare (gratuito o de pago).
  • Un plan de Workers (gratuito: 100,000 peticiones/día; pagado: desde $5/mes).
  • Un WordPress funcionando (puede estar en cualquier hosting, incluso compartido).

Configuración inicial del Worker

Crearemos un Worker básico que actúe como proxy inteligente. Usaremos el panel de Cloudflare o la CLI wrangler.

1. Crear el Worker en el panel de Cloudflare

Ve a Workers & Pages > Crear aplicación > Crear Worker. Ponle un nombre, por ejemplo wordpress-edge.

2. Código base: Proxy con caché inteligente

Este Worker intercepta todas las peticiones a tu dominio. Si la petición es a un recurso estático (CSS, JS, imágenes) o a una página pública, intenta servir desde la caché del edge. Si falla, va al origen y cachea la respuesta.

// wordpress-edge worker
const ORIGIN_URL = 'https://tu-servidor-wordpress.com'; // Tu servidor de origen
const CACHE_TTL_DEFAULT = 60; // segundos (1 minuto)
const CACHE_TTL_STATIC = 86400; // 24 horas para assets

async function handleRequest(request) {
  const url = new URL(request.url);
  const cache = caches.default;

  // 1. Comprobar si la respuesta ya está en caché de Cloudflare (edge)
  let response = await cache.match(request);
  if (response) {
    return response;
  }

  // 2. Si no está en caché, vamos al origen
  const originRequest = new Request(ORIGIN_URL + url.pathname + url.search, request);
  response = await fetch(originRequest);

  // 3. Determinar TTL según tipo de contenido
  let ttl = CACHE_TTL_DEFAULT;
  const contentType = response.headers.get('content-type') || '';
  if (contentType.includes('image') || contentType.includes('font') || 
      contentType.includes('javascript') || contentType.includes('css')) {
    ttl = CACHE_TTL_STATIC;
  } else if (response.status === 404) {
    ttl = 10; // Cachear 404s solo 10 segundos
  }

  // 4. Clonar la respuesta y almacenarla en caché
  response = new Response(response.body, response);
  response.headers.set('Cache-Control', `public, max-age=${ttl}`);
  // Añadir cabecera para depuración
  response.headers.set('X-Worker-Cache', 'MISS');

  // 5. Almacenar en la caché del edge
  await cache.put(request, response.clone());

  return response;
}

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

[TIP] Reemplaza ORIGIN_URL por la URL real de tu servidor WordPress. Asegúrate de que tu WordPress acepte peticiones desde el Worker (puede que necesites configurar un plugin de seguridad o un secreto compartido).

Técnicas avanzadas de optimización global con Workers

El proxy básico es solo el principio. Aquí tienes técnicas más potentes para exprimir el Edge Computing en WordPress.

1. Reescritura dinámica de HTML en el edge

Los Workers pueden modificar el HTML que devuelve WordPress antes de que llegue al navegador. Esto es útil para inyectar scripts de analytics, cambiar enlaces absolutos a relativos, o incluso eliminar bloques de CSS/JS no utilizados.

// Fragmento de Worker que modifica HTML
async function handleRequest(request) {
  const response = await fetch(request); // Obtiene respuesta del origen
  const contentType = response.headers.get('content-type') || '';
  
  if (contentType.includes('text/html')) {
    // Leer el body como texto
    let html = await response.text();
    
    // Ejemplo: Reemplazar URLs de assets locales por CDN
    html = html.replace(/https:\/\/tu-servidor-wordpress\.com\/wp-content/g, 
                         'https://cdn.tudominio.com/wp-content');
    
    // Ejemplo: Inyectar un script de consentimiento de cookies
    html = html.replace('</head>', 
                        '<script src="/cookie-consent.js"></script></head>');
    
    // Devolver el HTML modificado
    return new Response(html, response);
  }
  
  // No es HTML, devolver sin modificar
  return response;
}

2. Geolocalización y personalización (sin plugins pesados)

Cloudflare Workers exponen la cabecera CF-IPCountry. Puedes redirigir o mostrar contenido diferente según el país sin que tu servidor WordPress se entere.

async function handleRequest(request) {
  const country = request.cf.country; // 'ES', 'US', 'JP', etc.
  const url = new URL(request.url);
  
  // Redirigir a subdirectorio por país
  if (country === 'ES' && !url.pathname.startsWith('/es/')) {
    return Response.redirect(`https://tudominio.com/es${url.pathname}`, 302);
  }
  
  // O cambiar el idioma en la cabecera Accept-Language
  const newRequest = new Request(request);
  if (country === 'JP') {
    newRequest.headers.set('Accept-Language', 'ja');
  }
  
  return fetch(newRequest);
}

3. Cacheo de APIs de WordPress (REST API y AJAX)

Las peticiones a /wp-json/wp/v2/posts o a endpoints de plugins pueden ser costosas. Con Workers puedes cachearlas en Cloudflare KV (almacenamiento clave-valor global) para evitar consultas repetitivas a la base de datos.

// Usando Workers KV
const API_CACHE = 'WORDPRESS_API_CACHE'; // Namespace de KV

async function handleRequest(request) {
  const url = new URL(request.url);
  
  // Solo cachear peticiones GET a la API
  if (request.method === 'GET' && url.pathname.startsWith('/wp-json/')) {
    const cacheKey = url.pathname + url.search;
    
    // Intentar obtener del KV
    let cachedData = await API_CACHE.get(cacheKey, 'json');
    if (cachedData) {
      return new Response(JSON.stringify(cachedData), {
        headers: { 'Content-Type': 'application/json', 'X-Cache': 'HIT' }
      });
    }
    
    // No en caché, ir al origen
    const response = await fetch(request);
    const data = await response.json();
    
    // Almacenar en KV por 1 hora (3600 segundos)
    await API_CACHE.put(cacheKey, JSON.stringify(data), { expirationTtl: 3600 });
    
    return new Response(JSON.stringify(data), response);
  }
  
  return fetch(request);
}

[WARNING] KV no es transaccional. Si tu API requiere consistencia estricta (ej: WooCommerce stock), no uses KV para esos endpoints. Úsalo solo para contenido público como posts, páginas o menús.

Estrategias de caché y purgado inteligente

Uno de los mayores desafíos con WordPress edge es la invalidación de caché. Cuando publicas un nuevo post o actualizas una página, el edge debe purgar la caché antigua.

Purgado automático desde WordPress

Puedes usar un plugin como Cloudflare (el oficial) o WP Cloudflare Super Page Cache para purgar la caché automáticamente. Pero si usas Workers personalizados, necesitas un enfoque más fino.

Solución: Crea un Worker que exponga un endpoint secreto para purgar.

// Endpoint de purga: /__purge?token=mi-secreto
addEventListener('fetch', event => {
  const url = new URL(event.request.url);
  if (url.pathname === '/__purge' && url.searchParams.get('token') === 'mi-secreto') {
    // Purga todo el caché del Worker
    event.respondWith(handlePurge(event.request));
  } else {
    event.respondWith(handleRequest(event.request));
  }
});

async function handlePurge(request) {
  const cache = caches.default;
  // Por simplicidad, purgamos todo (en producción, purga por URL)
  await cache.delete(request); // Esto purga solo la URL actual
  return new Response('Cache purged', { status: 200 });
}

Luego, desde tu WordPress (functions.php o un plugin personalizado), haces una petición HTTP a https://tudominio.com/__purge?token=mi-secreto cada vez que se actualiza un post.

Monitorización y depuración

Cuando implementas una arquitectura de Edge Computing, la visibilidad es clave. Cloudflare Workers ofrece:

  • Logs en tiempo real desde el panel de Workers.
  • Traza de peticiones con cabeceras personalizadas.
  • Métricas de ancho de banda, CPU y tiempo de ejecución.

Añade siempre cabeceras de depuración en tus Workers:

response.headers.set('X-Worker-Version', '1.0');
response.headers.set('X-Worker-Country', request.cf.country);
response.headers.set('X-Worker-Cache-Status', cacheHit ? 'HIT' : 'MISS');

Caso de uso real: WooCommerce en el edge

WooCommerce es notoriamente difícil de cachear por su naturaleza dinámica (carritos, sesiones). Sin embargo, con Workers puedes cachear páginas de producto y categoría para usuarios no logueados, y servir contenido dinámico solo para usuarios con sesión.

async function handleRequest(request) {
  const url = new URL(request.url);
  const hasSessionCookie = request.headers.get('Cookie')?.includes('wordpress_logged_in');
  
  // Si el usuario NO está logueado, cachea agresivamente
  if (!hasSessionCookie && (url.pathname.startsWith('/producto/') || url.pathname.startsWith('/categoria-producto/'))) {
    const cache = caches.default;
    let response = await cache.match(request);
    if (!response) {
      response = await fetch(request);
      response = new Response(response.body, response);
      response.headers.set('Cache-Control', 'public, max-age=300'); // 5 minutos
      await cache.put(request, response.clone());
    }
    return response;
  }
  
  // Usuarios logueados o páginas de checkout -> pasar directamente al origen sin cachear
  return fetch(request);
}

[INFO] Para WooCommerce, asegúrate de no cachear nunca las páginas de /carrito/, /finalizar-compra/ o /mi-cuenta/. Usa Workers para excluirlas explícitamente.

Limitaciones y consideraciones

El Edge Computing no es una bala de plata. Ten en cuenta:

  • Límite de tiempo de ejecución: Un Worker gratuito tiene 10ms de CPU (50ms en plan pagado). Si tu lógica es muy pesada (ej: parsear HTML gigante), puedes excederlo.
  • Tamaño de script: Máximo 1MB. Suficiente para la mayoría de casos.
  • Consistencia de datos: Si necesitas datos frescos al segundo (ej: stock en tiempo real), no los cachees en el edge. Usa Workers solo para capas de presentación.
  • Coste: El plan gratuito es generoso (100k peticiones/día), pero un sitio con mucho tráfico puede necesitar el plan pagado ($5 por 10 millones de peticiones).

Conclusión: El futuro de WordPress es distribuido

Implementar Edge Computing con Cloudflare Workers no es una moda, es una necesidad para cualquier WordPress que aspire a ser global. Al mover la lógica de caché, reescritura y personalización al borde de la red, consigues una optimización global que antes requería infraestructuras multimillonarias.

El serverless y el edge están aquí para quedarse. WordPress, con su arquitectura tradicional, se beneficia enormemente de esta capa intermedia. No necesitas migrar a un headless CMS ni reescribir tu tema. Con un Worker bien escrito, tu WordPress existente puede cargar en menos de 200ms en cualquier rincón del planeta.

Empieza hoy: despliega un Worker de prueba, monitoriza las cabeceras y observa cómo la latencia cae en picado. Tu servidor te lo agradecerá, y tus usuarios tambié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