En los artículos anteriores de esta serie hablamos del object caching con Redis (para que WordPress deje de bombardear la base de datos) y del reverse proxy como primera línea de defensa dentro de tu propio servidor. Hoy cerramos el círculo con la capa más externa y, en muchos casos, la que más impacto genera: la caché en el edge mediante un CDN.
¿Qué es realmente la caché en el edge?
El «edge» se refiere a los servidores que un CDN (Content Delivery Network) tiene distribuidos por todo el mundo. Estos puntos de presencia (PoPs) están mucho más cerca de tus visitantes que tu servidor de origen, que normalmente vive en un único datacenter.
Cuando alguien entra a tu web, el CDN intenta servir la página directamente desde el servidor edge más cercano. Si la tiene en caché (cache HIT), la respuesta sale en milisegundos y la petición nunca llega a tu hosting. Si no la tiene (cache MISS), el CDN consulta tu servidor, guarda una copia y la sirve a los siguientes visitantes.
Los CDNs modernos para WordPress pueden cachear páginas HTML completas (full-page caching). Esto reduce drásticamente el Time To First Byte (TTFB), sobre todo para visitantes que están lejos geográficamente de tu servidor.
Las tres capas de caché trabajando juntas
Piensa en tu WordPress como una cebolla con varias capas de protección:
- Capa Edge (CDN) –> Resuelve la mayoría de las peticiones de usuarios anónimos sin tocar tu servidor.
- Capa Proxy (dentro del servidor) –> Si la petición llega, Nginx o LiteSpeed intentan servirla desde su propia caché HTTP antes de ejecutar PHP.
- Capa de Aplicación (Object Cache) –> Si PHP se ejecuta, Redis evita miles de consultas repetitivas a MySQL.
Cuanto más lejos del origen resuelvas la petición, mejor para tu servidor y tu bolsillo.
Flujo ideal de una petición:
- Usuario en México o España –> Edge del CDN (HIT) –> Respuesta casi instantánea, sin tocar tu servidor.
- Miss en el edge –> Proxy en tu servidor (HIT en fastcgi_cache o LSCache) –> Sin ejecutar PHP.
- Miss en el proxy –> PHP + Redis (con buen hit ratio) –> Muy pocas consultas a la base de datos.
graph TD
A[Cliente
Usuario final] --> B[Edge CDN
Caché en el edge]
B -->|Cache HIT — respuesta instantánea| A
B -->|Cache MISS| C[Servidor web / Reverse proxy
Nginx · LiteSpeed · Caché HTTP]
subgraph servidor["Capas de optimización — servidor"]
C -->|Cache MISS — ejecuta PHP| D[WordPress PHP]
subgraph aplicacion["Capa de aplicación"]
D -->|Consulta objeto cacheado| E[Redis / Object cache]
E -->|Cache MISS| F[(MySQL
Base de datos)]
end
end
Cuanto más arriba en el diagrama se resuelve la petición, menos carga recibe tu servidor.
Con las tres capas bien configuradas puedes servir mucho más tráfico con el mismo plan de hosting, o incluso bajar de categoría sin perder rendimiento.
Impacto real en WordPress
- Reducción fuerte de TTFB, especialmente para audiencia internacional (muchos ven caídas del 50-80% en métricas globales).
- Mejores Core Web Vitals: mejor LCP, INP y estabilidad.
- Offload del servidor de origen: es común que entre el 80% y 95% del tráfico se resuelva en el edge.
- Menores costos: menos CPU, RAM y ancho de banda consumidos.
- Mayor resistencia ante picos de tráfico o intentos de DDoS (se absorben en el edge).
Funciona muy bien en blogs, sitios corporativos y tiendas WooCommerce, siempre que configures correctamente los bypass para carrito, checkout y usuarios logueados.
¿Qué CDN usar en 2026 para WordPress?
| CDN | Precio orientativo | Facilidad | Mejor para |
|---|---|---|---|
| Cloudflare + APO | Gratis / $5 mes (APO) |  | La mayoría de sitios WordPress |
| QUIC.cloud | Freemium | | Sitios con LiteSpeed + LSCache |
| Bunny.net | Muy bajo (pay per use) | | Assets estáticos e imágenes |
¿Se pueden combinar? Sí, y muchas veces es la mejor opción. Un setup habitual es usar Cloudflare para DNS, seguridad y caché de páginas HTML, y Bunny.net para servir assets estáticos (imágenes, CSS, JS), aprovechando su excelente red y precios bajos.
Si usas LiteSpeed en tu servidor, combinar QUIC.cloud con Cloudflare te da optimizaciones muy específicas para WordPress que otros CDNs no ofrecen.
Configuración importante (para no romper nada)
- Reglas de caché inteligentes: cachear para visitantes anónimos, pero hacer bypass para usuarios logueados, carrito, checkout y wp-admin.
- Purgas automáticas: al publicar o editar, el CDN debe invalidar la caché correctamente.
- Headers Cache-Control y Vary: controlan el comportamiento según cookies, dispositivos o idiomas.
- Edge Rules / Page Rules: para configuraciones granulares (por ejemplo, cachear más tiempo páginas estáticas).
- Seguridad extra: WAF, rate limiting y protección DDoS que ya incluyen la mayoría de CDNs.
Errores comunes que hay que evitar:
- Cachear contenido dinámico sin reglas –> los usuarios ven versiones antiguas.
- No configurar purgas –> contenido desactualizado.
- Ignorar el impacto en usuarios logueados y en WooCommerce.
La optimización por capas es la clave
Ninguna capa por sí sola salva tu WordPress. Redis protege la base de datos cuando PHP se ejecuta. El proxy protege el PHP cuando la petición llega al servidor. Y el CDN con caché en el edge protege todo lo anterior, resolviendo muchas peticiones antes de que siquiera lleguen a tu infraestructura.
La estrategia más efectiva es empezar por el edge (resultados rápidos y visibles con el menor esfuerzo), reforzar el proxy y, por último, pulir el object cache.
Si este artículo te ayudó, compártelo con otros que están luchando con el rendimiento de WordPress. En los próximos artículos profundizaremos en configuraciones específicas (Cloudflare APO + Redis, reglas avanzadas en Bunny, etc.). ¡Nos leemos pronto!
Tema Relacionado: WordPress Performance