Su tienda tarda ocho segundos en mostrar la página de inicio. El reflejo es inmediato: “necesitamos una CDN”. Habilitas Cloudflare en modo proxy, esperas un milagro y el carrito aún tarda cinco segundos en responder. El diagnóstico no fue incorrecto, solo en el orden incorrecto.
Una CDN acelera la entrega de lo que se puede almacenar en caché en el borde. No repara una consulta SQL que escanea toda la tabla de pedidos, ni una imagen principal de 4 MB entregada sin compresión. La verdadera pregunta no es "¿CDN o no CDN?" ". Es: ¿dónde se pierde el tiempo: en el origen, en la red o en ambos?
Leer una cascada antes de comprar una capa de red
Abra las herramientas de desarrollo del navegador o una prueba desde WebPageTest. Dos figuras guían el resto:
- TTFB (Tiempo hasta el primer byte): tiempo antes de que responda el servidor de origen. ¿Criado en todas partes? Problema original (PHP, base de datos, disco, sobrecarga de CPU).
- Tiempo de descarga de recursos: ¿mucho para JS/CSS/imágenes pero bajo TTFB? Problema de red, tamaño de archivo o falta de caché estática.
| Síntoma | Causa probable | Acción prioritaria |
|---|---|---|
| TTFB > 800 ms en Europa | Base de datos lenta, PHP, disco lleno | Perfiles SQL, caché de páginas, actualización de disco |
| TTFB bajo, imágenes pesadas | Activos no optimizados | WebP/AVIF, carga diferida, cambio de tamaño |
| Bueno en Francia, lento en EE.UU. | Latencia geográfica | CDN o origen más cercano |
| LCP inestable en dispositivos móviles | Todo en la mitad superior de la página sin prioridad | CSS crítico, precarga, imágenes CDN |
Una CDN no reduce la deuda de la solicitud. A veces lo saca de su campo de visión.
Optimizar el origen: las palancas que sujetan el camino
Antes de cualquier capa de red, verifique qué usted controla en el servidor.
Imágenes y medios. Esto suele representar entre el 50 y el 70% del peso de una página de WordPress o de comercio electrónico. Formatos modernos, dimensiones adaptadas a la ventana gráfica, carga diferida en la parte inferior de la página: ganancias inmediatas sin un contrato CDN.
HTTP y caché de aplicaciones. Un proxy inverso (Nginx, Varnish) o un complemento de caché de páginas evita volver a calcular la misma página PHP en cada visita. Verifique los encabezados de Cache-Control, la depuración posterior a la implementación y el comportamiento de los usuarios que han iniciado sesión.
Base de datos. Habilite el registro de consultas lentas de una hora de tráfico real. Un índice faltante en una tabla de WooCommerce o una meta_query de WordPress cuesta más que un plan Business CDN.
PHP y competencia. En un sitio compartido saturado, el TTFB sube incluso con una CDN al frente: las páginas dinámicas no pasan por el caché perimetral. Un VPS de mejor tamaño o un PHP-FPM correctamente ajustado pueden ser suficientes.
Qué ofrece una CDN y qué no cubre
Una CDN duplica sus activos (y a veces sus páginas HTML) en puntos de presencia cercanos a los visitantes. Los beneficios concretos:
- Latencia reducida para JS, CSS, fuentes e imágenes.
- Terminación TLS y HTTP/2 o HTTP/3 en el borde
- Protección DDoS y limitación de velocidad (según oferta)
- Reducción de ancho de banda hacia el origen
Por otro lado, la CDN no reemplaza:
- Entradas de base de datos (cesta, formularios, POST API)
- Caché de aplicaciones mal configurado (páginas "sin caché" en todas partes)
- Un origen de tamaño insuficiente que satura de CPU
- Coherencia de las reglas de purga después de la implementación.
Para un sitio predominantemente estático (blog, escaparate, Jamstack), la CDN puede ser el segundo paso después de un origen limpio. Para una aplicación transaccional, casi siempre ocurre lo contrario.
Escenarios A vs B: dos órdenes de batalla
Escenario A: blog de WordPress, audiencia de Francia, TTFB 200 ms, imágenes pesadas. Comience con ShortPixel o Imagify, un caché de página, luego un CDN gratuito o incluido con el host. La CDN sólo será útil una vez que el peso de la página esté bajo control.
Escenario B: SaaS con API en Europa, clientes en EE. UU. y Asia, origen ya optimizado. TTFB de Asia sigue siendo prohibitivo a pesar de una base indexada: allí, CDN con caché de API selectiva o región de origen adicional se vuelve relevante.
Escenario C: pico del Viernes Negro, origen correcto bajo carga normal. Anticipe la CDN y el caché antes del pico, no en el día. Pruebe la purga y el comportamiento de la cesta en caché parcial.
The Summit: CDN es un amplificador, no una solución
Las páginas comerciales de CDN muestran curvas verdes. Felizmente omiten las páginas Cache-Control: private, las cookies de sesión que destruyen el caché y las solicitudes de administrador que nunca pasarán por el borde.
Decide y avanza sin puntos ciegos
- Medir TTFB y cascada de dos regiones sin CDN.
- Corregir el origen: imágenes, caché, SQL: hasta TTFB estable por debajo de 400 ms en su mercado principal.
- Vuelva a probar: si la latencia de la red aún domina, seleccione la CDN (general o especializada).
- Documentar reglas de purga, comportamiento del carrito/sesión y origen real (algunos servidores proxy enmascaran la IP).
Compare las ofertas de CDN y proveedores de hosting en nuestro directorio y la comparación. Para explorar la elección de la capa de red, lea Cloudflare o CDN especializado.
Preguntas frecuentes
¿Cómo sé si el problema viene del origen o de la red?
Mida TTFB desde múltiples regiones sin CDN. Si permanece alto incluso cerca del servidor, la culpa es del origen o de la base. Si el TTFB es bajo pero la carga total es larga, dominan la red o los activos estáticos.
¿Puede una CDN ocultar un origen mal configurado?
Sí, temporalmente, para archivos estáticos. Las páginas dinámicas, las API y las escrituras permanecen en el origen. Sin un caché de aplicación, la ganancia desaparece tan pronto como la CDN no puede entregar la respuesta.
¿Qué optimizaciones originales tienen la mejor relación esfuerzo/ganancia?
Compresión de imágenes, caché HTTP, índices SQL y minificación de complementos de WordPress. La creación de perfiles (registro de consultas lentas, cascada) guía la prioridad.
¿Cuándo se convierte CDN en el primer paso correcto?
Cuando el origen está en buen estado, el tráfico es mayoritariamente estático o geográficamente disperso y la latencia de la red domina la cascada.
Antes de agregar una capa de red, haga una pregunta simple: Si desactivo la CDN mañana, ¿mi sitio seguirá funcionando? Si la respuesta es no, aún no ha terminado de trabajar en el origen.