CDN para WordPress: cómo elegir el adecuado

Para WordPress existen dos tipos de CDN: un CDN de recursos, que un plugin conecta reescribiendo las URL de tus imágenes, CSS y JavaScript, y un proxy de sitio completo, que se coloca delante de todo tu dominio y también puede cachear las propias páginas HTML. Cuál te conviene depende de dónde pierde tiempo tu web, de quiénes son tus visitantes y de cuánto estás dispuesto a cambiar tu DNS. Esta guía compara los dos tipos y te da una checklist para elegir proveedor.

Para lo básico, consulta qué es un CDN. Si aún no sabes por qué va lenta tu web, busca primero la causa con la guía sobre por qué va lento un WordPress.

Los dos tipos de CDN para WordPress

CDN de recursos (archivos estáticos mediante plugin)

Un CDN de recursos sirve solo archivos estáticos. Creas una pull zone en el proveedor y obtienes un nombre de host como cdn.example.com. Después, un plugin de WordPress reescribe las URL de tu HTML para que los archivos de wp-content y wp-includes se carguen desde ese host. En la primera petición, el CDN descarga cada archivo de tu servidor y guarda una copia.

Tu dominio, tu DNS y tu HTML se quedan donde están. Cada visita sigue llegando a tu hosting, que genera el HTML como siempre. Solo los archivos a los que hace referencia la página vienen del CDN.

Proxy de sitio completo (todo el dominio mediante servidores de nombres o DNS)

Un proxy de sitio completo se hace cargo del tráfico de todo tu dominio. Según el proveedor, delegas en él tus servidores de nombres o apuntas el DNS de tu dominio hacia él. A partir de ahí, todas las peticiones, HTML incluido, pasan primero por los servidores edge del proveedor. El edge sirve lo que puede cachear y reenvía el resto a tu hosting.

Como todo el tráfico pasa por él, un proxy de sitio completo puede cachear el HTML de las páginas públicas, gestionar el HTTPS y filtrar ataques antes de que lleguen a tu servidor. También es el cambio más grande, porque toda tu web depende de que el proxy esté bien configurado.

Qué cachea cada tipo

La diferencia que más importa es el HTML. En un WordPress típico, la parte lenta de una visita es el servidor generando la página con PHP y la base de datos. Un CDN de recursos no toca ese paso, así que tu tiempo hasta el primer byte sigue igual.

Un proxy de sitio completo puede servir ese HTML desde el edge a los visitantes anónimos, sin que intervengan ni PHP ni la base de datos. Por eso este tipo es el que más ayuda cuando el TTFB es alto o tu servidor sufre en los picos de tráfico.

Los dos tipos cachean los recursos. Si tus páginas ya se generan rápido (por ejemplo, gracias a una buena caché de página en el servidor) y los visitantes esperan sobre todo a archivos grandes, un CDN de recursos puede cubrir buena parte de lo que necesitas.

Ventajas e inconvenientes en la práctica

Cuándo basta con un CDN de recursos

• La respuesta de tu servidor ya es rápida y el cuello de botella son imágenes o scripts pesados.
• No puedes o no quieres cambiar los servidores de nombres ni el DNS de tu dominio.
• Quieres un cambio que puedas deshacer desactivando un plugin.

Ojo con los efectos secundarios típicos. Los archivos escritos a mano en el tema, en el CSS del maquetador o en estilos en línea a menudo no se reescriben y se siguen cargando desde tu origen. Las fuentes web que se cargan desde otro host necesitan la cabecera Access-Control-Allow-Origin adecuada, o el navegador se niega a usarlas. Y WordPress añade una query string ?ver= a los scripts y estilos que encola: el CDN debe incluir las query strings en su clave de caché, o los visitantes seguirán recibiendo el archivo antiguo después de una actualización.

Cuándo compensa un proxy de sitio completo

• Tu TTFB es alto en las páginas públicas o el servidor se ralentiza al enviar una newsletter o durante unas rebajas.
• Tus visitantes están repartidos por varios países o continentes.
• Quieres que el filtrado de DDoS y el HTTPS se gestionen delante de tu hosting.

Los inconvenientes también son reales. Tienes que acertar con las reglas de exclusión para que ninguna página personal se cachee nunca para todos. Cuando publicas o editas una entrada, hay que refrescar el HTML cacheado. Tu servidor ve ahora el proxy como cliente, así que tus plugins de seguridad o de estadísticas tienen que leer la IP real del visitante en la cabecera que transmite el proveedor. Y quien conozca la IP de tu servidor puede saltarse el edge, salvo que tu hosting solo acepte tráfico del proxy.

La checklist para elegir

Usa estas preguntas al comparar proveedores. Valen para cualquier CDN, se llame como se llame.

Caché de HTML y reglas de exclusión

¿Puede cachear HTML y cómo decide qué saltarse? En WordPress, esto siempre tiene que llegar a tu servidor sin caché:

• /wp-admin/, wp-login.php y admin-ajax.php
• Visitantes con una cookie wordpress_logged_in_ (la referencia de cookies de WordPress (en inglés) enumera todas las cookies que crea el núcleo)
• Personas que han comentado, con una cookie comment_author_, para que vean su comentario pendiente de moderación
• Entradas protegidas con contraseña, que usan una cookie wp-postpass_
• Vistas previas de entradas y todo lo personalizado, como carritos y páginas de cuenta en una tienda

WordPress ayuda: para usuarios con sesión iniciada, entradas protegidas con contraseña y páginas 404 envía Cache-Control: no-cache, must-revalidate, max-age=0, no-store, private. Un proxy que respete las cabeceras Cache-Control se saltará por tanto esas respuestas. El riesgo son los plugins que personalizan páginas sin enviar esas cabeceras, así que pruébalos.

Vaciar la caché al publicar

Cuando actualizas una entrada, cambia la propia entrada, pero también la portada, los archivos de categorías y etiquetas y el feed. Pregunta cómo se vacía la caché: ¿por URL, para todo el dominio, desde un panel, mediante API? El vaciado automático al publicar depende del proveedor y de tu configuración. Sin él, necesitas una vida en caché lo bastante corta o una rutina para vaciar la caché después de editar.

Optimización de imágenes

¿Convierte el CDN las imágenes a WebP o AVIF, y sigue sirviendo el original a los navegadores que no admiten el nuevo formato? Esto puede ahorrarte un plugin de imágenes que hace el trabajo en tu servidor.

SSL entre visitante, edge y servidor

Con un CDN de recursos, el host del CDN necesita su propio certificado. Con un proxy de sitio completo, el edge tiene el certificado de tu dominio. Asegúrate de que la conexión del edge a tu servidor también usa HTTPS. Si el proxy habla HTTP plano con un WordPress que fuerza HTTPS, puedes acabar en un bucle de redirecciones infinito, como explica la documentación de WordPress sobre HTTPS (en inglés).

Seguridad y protección DDoS

Un CDN de recursos solo protege los archivos que sirve. Los ataques contra tus páginas, el login o XML-RPC siguen golpeando directamente tu servidor. Un proxy de sitio completo puede filtrar inundaciones de tráfico, bloquear países o rangos de IP y limitar las peticiones de clientes abusivos en el edge. Comprueba qué incluye el plan que estás valorando y qué se paga aparte.

Ubicaciones edge cerca de tu público

Un CDN solo reduce la distancia si tiene servidores edge cerca de tus visitantes. Mira de dónde vienen realmente tus visitantes y luego qué regiones cubre el proveedor en tu plan.

Esfuerzo de configuración y qué pasa con el DNS y el correo

En un CDN de recursos, introduces un host en un plugin y quizá añades un registro CNAME. En un proxy de sitio completo, normalmente tu DNS pasa al proveedor. Eso significa que todos los registros tienen que estar allí antes del cambio, incluidos los registros MX del correo y los TXT para SPF, DKIM y verificación de dominio. La checklist para cambiar los servidores de nombres sin caídas te guía paso a paso.

Visibilidad

Busca una cabecera de respuesta que indique hit, miss o bypass en cada petición, y estadísticas de tasa de aciertos de caché, tráfico servido desde el edge frente al origen y tasas de error. Sin eso, no puedes saber si el CDN hace algo útil.

Mide antes y después

No juzgues un CDN por sensaciones. Antes del cambio, registra una línea base:

1. Analiza tu portada, una entrada y una página de archivo en corewebvitals.page. Anota los datos de usuarios reales (si tu web tiene tráfico suficiente) y los resultados de Lighthouse para móvil y escritorio.
2. Mide la respuesta del servidor para el HTML desde tu propio equipo:

curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s\n" https://example.com/

3. Después del cambio, pide la misma página dos veces y mira las cabeceras. La segunda petición debería mostrar un acierto de caché.

curl -sI https://example.com/ | grep -i -E "cache|age"

4. Inicia sesión y comprueba que wp-admin y tu front end muestran un bypass, no un hit.
5. Vuelve a comparar los datos de usuarios reales cuando se hayan puesto al día, porque abarcan los últimos 28 días.

La guía para medir la velocidad de una web explica cómo hacer que esa comparación sea justa.

Cómo te ayuda fast.site

fast.site es un proxy de sitio completo. Se coloca delante de tu hosting actual de WordPress, así que mantienes tu proveedor y tu web. Añades tu dominio en el panel, apuntas tus servidores de nombres a fast.site y lo verificas. A partir de ahí, fast.site gestiona tu DNS, así que todos los registros existentes, incluidos los MX del correo, tienen que estar en la zona DNS de fast.site.

Fast Edge Cache™ sirve páginas públicas y recursos desde servidores edge en las regiones disponibles en tu plan. fast.site respeta las cabeceras Cache-Control que envía tu WordPress, y la cabecera de respuesta fs-cache muestra HIT, MISS o BYPASS, así que puedes comprobar tú mismo wp-admin y las sesiones iniciadas. Después de publicar, puedes vaciar URL concretas o todo el dominio desde el panel, con un registro de purgas, o mediante la API desde tus propios scripts.

Las imágenes JPEG y PNG se convierten a WebP al vuelo para los navegadores que lo admiten, y a AVIF según tu plan. Cada dominio recibe detección automática de DDoS en capa 7 y certificados SSL gratuitos que se renuevan solos. Tienes los detalles en la página de WordPress y en la documentación de caché.

Mide tu web antes y después con las mismas páginas y herramientas. Puedes probarlo con una prueba gratuita de 7 días.

Preguntas frecuentes

¿Necesito un plugin de CDN para WordPress?

Solo para un CDN de recursos, porque el plugin reescribe las URL de tus archivos al host del CDN. Un proxy de sitio completo funciona a nivel de DNS y no necesita reescribir URL, ya que tu dominio sigue siendo el mismo. Algunos proveedores ofrecen aun así un plugin para tareas como vaciar la caché.

¿Un CDN sustituye a mi plugin de caché?

No necesariamente. Una caché de página en tu servidor acelera todas las peticiones que no acierta el CDN y todo el tráfico con sesión iniciada, como describe la documentación de caché de WordPress (en inglés). Con un proxy de sitio completo importa menos para los visitantes anónimos, pero mantenerla rara vez perjudica.

¿Un CDN puede romper wp-admin o el inicio de sesión?

No debería, siempre que wp-admin, la página de login y los visitantes con sesión iniciada se salten la caché. WordPress envía cabeceras no-cache para los usuarios con sesión iniciada. Pruébalo tras la configuración: inicia sesión, edita una entrada y revisa la cabecera de caché en las páginas de administración.

¿Por qué no aparecen mis cambios después de actualizar una entrada?

El CDN sigue sirviendo la copia en caché. Vacía la URL de la entrada y las páginas que la listan, como la portada y los archivos de categorías. Para CSS y JavaScript, comprueba que el CDN conserva la query string ?ver= en su clave de caché.