Inicio/Guía/Optimización de sitios web/Detalles

Si dividimos la optimización del rendimiento de WordPress en tres niveles:

  • Capa del servidor de origenServidor / PHP / Base de datos / Plugin de caché —— Determina el TTFB y la carga del backend
  • Capa de recursos: Optimización de imágenes: determina el tamaño de descarga y la velocidad de carga de las imágenes grandes en la primera pantalla
  • Capa de entrega: CDN — determina que los recursos estén más cerca de los visitantes, con una tasa de aciertos más estable y menos carga para el servidor de origen

Este artículo trata sobre CDN Aceleración：

  • Conoce lo que CDN puede y no puede resolver
  • Elegir la modalidad y el proveedor CDN adecuados para ti y entender los límites de la versión gratis y la básica
  • Implementar por menor riesgo, sin tumbar el sitio ni causar problemas de caché en e-commerce/membresías
  • Una vez implementado, podemos verificar que “funciona correctamente” e investigar “por qué no se ha actualizado, por qué va lento o por qué el contenido está desordenado”.”

1. Primero, aclaremos el concepto: qué resuelve CDN y qué no resuelve

1.1 CDN resuelve principalmente 3 cosas

1.1.1 Entrega más rápida de recursos estáticos
Los recursos estáticos, como imágenes, CSS, JavaScript, fuentes e iconos, se sirven más cerca del visitante, lo que se traduce en tiempos de descarga más rápidos y una visualización de la página más estable.
En el caso de WordPress, especialmente en lo que respecta a los temas y los complementos (wp-content/themes/、wp-content/plugins/) e imágenes de la biblioteca multimedia (wp-content/uploads/) suelen ser los “artículos más voluminosos”.

1.1.2 Reducción de la carga en el servidor de origen
Después de acertar en la caché del borde, las solicitudes ya no tendrán que volver con tanta frecuencia al origen, y la carga sobre el ancho de banda, las conexiones concurrentes, el IO de disco y las fluctuaciones de CPU del servidor de origen será menor.
Esto se hace especialmente evidente en situaciones de máxima actividad, como “páginas de campaña, artículos virales y páginas de productos que reciben un gran volumen de tráfico”.

1.1.3 Mejora de la estabilidad (mayor resistencia a las fluctuaciones)
Durante los picos de tráfico, los nodos perimetrales absorben una gran cantidad de solicitudes repetidas, lo que hace menos probable que el servidor de origen se sature.
Notarás un “acceso más fluido”: incluso si el servidor de origen sufre un aumento repentino del tráfico, la caché perimetral seguirá sirviendo el contenido.

1.2 Tres tipos de problemas que CDN no resolverá automáticamente

1.2.1 El servidor de origen en sí es lento
La base de datos lenta, la lógica del complemento lenta y el cálculo de PHP lento: estos pertenecen a problemas de la capa del sitio de origen.
CDN puede acelerar los recursos estáticos, pero si hasta el HTML de la página principal se genera muy lento, el usuario igual sentirá que “abre lento”. En ese caso, prioriza volver a: hosting/plugin de caché/optimización de base de datos.

1.2.2 La imagen en sí es demasiado grande
CDN no puede “encoger mágicamente” la imagen grande de 3MB.
Deberías empezar por optimizar tus imágenes: gestión del tamaño (evita descargar imágenes demasiado grandes), compresión, formatos WebP/AVIF, estrategias de carga diferida, etc.

1.2.3 Scripts de terceros lentos
Anuncios, estadísticas, servicio al cliente, componentes de redes sociales, etc., provienen de dominios de terceros.
CDN normalmente no puede hacerlos “más rápidos”; solo puedes manejarlo reduciendo o retrasando la carga, cambiando de proveedor o optimizando la estrategia de scripts.

Recomendaciones

Primero corrige bien la capa del sitio de origen y la capa de recursos; después haz CDN, y el efecto será más evidente y habrá menos problemas.

2. Selección en 30 segundos: ¿Qué tipo de formato CDN necesitas?

En lo que respecta a WordPress, hay dos categorías principales. Si eliges primero el “tipo” y luego el “proveedor”, el proceso te resultará mucho más claro.

2.1 Tipo “proxy inverso” integrado (más sencillo, adecuado para la mayoría de los sitios web)

**特点：**它不仅是 CDN，还把 DNS / SSL / Protección básica de seguridad (como DDoS/WAF) Todo incluido. Una vez integrado, actúa como un proxy frente a tu sitio web.

Lo que obtendrás:

  • Gestión de certificados y TLS más sencilla
  • Punto de acceso unificado de protección de seguridad (DDoS básico, control de acceso, WAF, etc.)
  • Almacenamiento en caché en el borde y motor de reglas (que permite estrategias de almacenamiento en caché más detalladas y reglas de omisión)
  • “Mayor escalabilidad”: si en el futuro deseas añadir medidas de seguridad, límites de velocidad o protección contra bots, estas funciones suelen formar parte del mismo sistema

Proveedor: Cloudflare / Tencent Cloud International EdgeOne / Alibaba Cloud International ESA

Si desea:

  • Esperas que HTTPS + CDN + Seguridad básica Todo de una sola vez
  • ¿Estaría dispuesto a confiar la gestión de la resolución de su nombre de dominio y las capas de proxy a una única plataforma?
  • Valoras más la “experiencia integral y la expansión futura” y no quieres separar DNS, los certificados, CDN y la seguridad en varios conjuntos distintos

2.2 Pull “estático” puro CDN (inicio de bajo riesgo, acelera principalmente imágenes/CSS/JS)

**特点：**你只把静态资源放到 CDN 边缘缓存；HTML 页面仍由源站（以及源站缓存插件）负责。

Lo que obtendrás:

  • Riesgo operativo muy bajo: siempre y cuando no modifiques el código HTML, prácticamente no hay riesgo de que “se mezclen los datos del contenido o de la cesta de la compra”.”
  • El modelo de precios es más intuitivo: la facturación suele basarse en el tráfico, las solicitudes o la región
  • Una arquitectura más sencilla: más parecida a un “servicio de entrega de recursos estáticos”

**代表：**bunny.net（按量计费模型清晰）

Si desea:

  • Lo mejor es empezar por la “opción más segura”: acelerar los recursos estáticos
  • ¿Quieres obtener ganancias rápido y luego decidir si usar caché por proxy o caché de todo el sitio?
  • Le gustaría que los costos se ajustaran más a un modelo de “pago por uso”

3. ¿Cómo hacerlo?

  • Nivel 1: Modelo de agencia integrada (preferido): Cloudflare / EdgeOne / ESA
  • Segunda capa: Pull estático CDN (inicio seguro): bunny.net / Cloudways CDN, etc.

4. Proveedores recomendados

4.1 Cloudflare: Proxy inverso integrado (gratis al principio, ecosistema consolidado)

¿Qué es?
Después de conectar el dominio, este funciona como un proxy delante del sitio web y ofrece CDN, certificados, protección básica y capacidades de reglas de caché.

¿A quién va dirigido?

  • ¿Quieres despreocuparte? HTTPS + CDN + seguridad básica todo en uno
  • Para crear un ecosistema maduro: tendremos que añadir un WAF, limitación de velocidad, reglas de perímetro, etc.; el camino a seguir está claro.

Factores de riesgo

  • La actualización no se ha aplicado: Tras habilitar CDN, la cadena de caché se alarga (caché del navegador + caché de CDN + caché del origen), y se necesita una “estrategia de versiones” para que las actualizaciones sean controlables (más adelante hay un árbol de diagnóstico)
  • Ten cuidado al almacenar HTML en caché: Si se almacena el HTML en caché, las páginas de comercio electrónico, de miembros y personalizadas deben excluirse estrictamente; de lo contrario, pueden surgir problemas graves (consulte la lista de casos a continuación).

Notas：

  • Posicionamiento: integración de proxy inverso (SSL + CDN + protección básica)
  • Ideal para: lanzamiento fácil y gran margen para futuras ampliaciones
  • Valores fundamentales: Punto de acceso único para certificados, seguridad y almacenamiento en caché
  • Riesgo: las actualizaciones dependen de la estrategia de versiones; se debe omitir estrictamente el caché de HTML

4.2 Tencent Cloud International EdgeOne: Proxy inverso integrado

¿Qué es?
Esta plataforma también sigue el modelo integrado de “aceleración + seguridad + certificados”, lo que la convierte en la opción ideal para gestionar sitios web a través de una capa de proxy unificada.

  • Como Cloudflare, tiene una versión gratis, pero normalmente incluye Cuota/Límite funcional(cantidad de reglas, cantidad de tareas de registro, etc.), pero no es necesario modificar DNS, solo se requiere acceso mediante cname.No se recomienda la versión gratuita para sitios web comerciales！
  • Al mismo tiempo, los planes gratuitos suelen implicar SLA no garantiza
    Funciona, pero no lo consideres un “paquete comercial de SLA”.
  • Si deseas cambiar automáticamente a una conexión de China continental mientras te encuentras en China continental, normalmente tendrás que completar primeroRegistro ICP en China; a menos que estés registrado, solo podrás utilizar rutas internacionales.

Nota:

  • Posicionamiento: Proxy inverso integrado (aceleración + seguridad + certificados)
  • Ideal para: quienes buscan una conectividad integrada y tienen en cuenta la capacidad de los nodos en China continental
  • Gratis: Hay disponible un plan o una versión gratuita, pero con cuotas limitadas y, por lo general, sin garantía de SLA
  • Riesgos: Las reglas, los registros y los límites de los subdominios deben planificarse con antelación; también hay que tener cuidado con el almacenamiento en caché de HTML

4.3 Alibaba Cloud International ESA América Latina (es-419) Español: Proxy inverso integrado

  • Como Cloudflare, tiene una versión gratis, pero normalmente incluye Cuota/Límite funcional(cantidad de reglas, cantidad de tareas de registro, etc.), pero no es necesario modificar DNS, solo se requiere acceso mediante cname.No se recomienda la versión gratuita para sitios web comerciales！
  • Registra una cuenta del sitio internacional para usarlo
  • Inicie sesión en la consola de ESA, añada un sitio y seleccione la opción gratuita Entrada Activación del paquete
  • Si deseas cambiar automáticamente a rutas de China continental mientras te encuentras en China continental, normalmente tendrás que completar primero el registro ICP; sin dicho registro, solo podrás utilizar rutas internacionales.
  • La versión gratuita es más adecuada para el desarrollo, las pruebas y la evaluación, y no suele ser equivalente a un paquete SLA comercial
  • Los planes gratuitos suelen incluir límites de velocidad o restricciones en las opciones de soporte (por ejemplo, acuerdos de nivel de servicio, etc.)

En cuanto a las rutas a China continental:

  • Para habilitar nodos de China continental, normalmente debes cumplir con los requisitos de registro y región
  • El servicio de entrada gratuito utiliza por defecto la ruta internacional; para utilizar la ruta de China continental, debe completarRequisitos de registro de ICP en China

Nota:

  • Posicionamiento: Proxy inverso integrado (aceleración de sitios web + seguridad)
  • Gratis: Las cuentas del sitio internacional se pueden conectar a través de Entrance sin costo alguno; la aceleración para China continental no está incluida de forma predeterminada
  • Adecuado para: evaluación/pruebas y uso ocasional; o para pasar a un nivel superior más adelante
  • Riesgos: Infórmate bien sobre los límites del plan gratuito (SLA, límites de velocidad, opciones de soporte); planifica con antelación la elección de la región y el registro en el ICP

4.4 bunny.net: Pull estático CDN (inicio de bajo riesgo, cobro claro según el uso)

Si prefieres “asegurar primero la ganancia más estable”, un Pull CDN como bunny te viene muy bien:
Se trata más bien de un “servicio de distribución de recursos”: le entregas tus recursos estáticos para que los distribuya, y los costos suelen basarse en el tráfico, las solicitudes o la región; el modelo de precios es claro y fácil de manejar.

Apto para:

  • Haz esto primero Imágenes / CSS / JavaScript / Fuentes aceleración estática
  • ¿Quieres obtener primero beneficios estables y de bajo riesgo, sin apresurarte a entregar todo el sitio a una plataforma tipo agente (DNS/SSL/WAF integrada)?
  • Preferirías un modelo de precios más parecido al de “pago por uso” en lugar de adoptar desde el principio un sistema de paquetes más complejo

Factores de riesgo

La “actualización” de recursos estáticos que no surte efecto casi nunca es un bug de CDNsino el comportamiento normal del sistema de caché:
Cuando actualizas el CSS, el JavaScript o las imágenes en el backend, peroLa URL del recurso no ha cambiado(con la misma dirección/nombre de archivo/ruta), CDN y el navegador seguirán usando razonablemente la caché antigua, así que verás “¿por qué no se actualizó?”

Un principio claro y aplicable:

Da prioridad a los números de versión; utiliza `Purge` como alternativa.

¿Por qué es este el enfoque más confiable?

  • Cambios en los números de versión y los nombres de archivo → Cambios en la URL → CDN se almacena en caché como recurso nuevo → la nueva versión entra en vigor casi de inmediato
  • **Purge（清缓存）**需要你主动触发，容易范围不准、节点传播有延迟；频繁 Purge 还会导致命中率下降、回源增加、波动变大

Un ejemplo fácil de entender:

  • style.css El contenido ha cambiado, pero la URL sigue siendo style.css → CDN Seguir usando la caché antigua (razonable)
  • La URL ha cambiado a style.css?ver=20260103 或 style.abc123.css → CDN considera que es un recurso nuevo → la nueva versión entra en vigor de inmediato

bunny como práctica recomendada para “paso 1 CDN”

  1. Por ahora, solo se incluirán los recursos estáticos(Imágenes/CSS/JS/fuentes); no almacenes en caché el HTML de inmediato
    • Ventaja: Prácticamente no hay riesgo de que se produzcan incidentes graves, como que los usuarios vean el contenido de otras personas o los detalles de la cesta de la compra.
    • También te resulta más fácil verificar los beneficios: los recursos estáticos son más rápidos y el servidor de origen está más ligero.
  2. Diseña una buena estrategia de actualización
    • CSS/JS: Siempre que sea posible, utiliza números de versión o cambios en los nombres de los archivos
    • Imagen: Evita sobrescribir archivos existentes con el mismo nombre durante largos periodos de tiempo; es preferible utilizar nuevos nombres de archivo o rutas (especialmente en el caso de los banners de la página de inicio y las imágenes promocionales).
  3. Tras la implementación, utilice la lista de verificación de validación para confirmar que se han cumplido los requisitos
    • ¿Los recursos estáticos provienen de CDN?
    • La tasa de aciertos está subiendo gradualmente y el ancho de banda/las solicitudes del origen son más estables (hay una lista de verificación más adelante)

Tenga en cuenta que

Si su empresa opera en China continental, o si desea que su sitio web se cargue más rápido en China continental.

Tanto Alibaba Cloud China como Tencent Cloud China son opciones válidas. Si tu dominio ya está registrado en el ICP de China continental, EdgeOne o ESA cambiarán automáticamente a las rutas de China continental cuando se acceda a ellas desde allí.

“Utiliza un servidor de China continental”Esto suele implicar el registro en el ICP»

A modo de referencia

“Optimización de la experiencia de acceso transfronterizo al sitio web”Esto podría ser una función independiente, que no suele ser lo mismo que el “acceso gratuito a los nodos de China continental”».”

5. Hoja de ruta de lanzamiento: avanzar en 3 fases (de estable a fuerte)

La razón por la que CDN se vuelve más fácil de “desordenar” al lanzarse es querer activar todas las funciones al máximo desde el principio.

Fase 1: solo recursos estáticos CDN (se recomienda encarecidamente hacerlo primero)

ObjetivoLas imágenes/CSS/JS/fuentes van primero por CDN; HTML no se almacena en caché en CDN (o se deja igual por ahora).

¿Por qué es esta la opción más segura para empezar?

  • Riesgo mínimo: si el caché de recursos estáticos falla, como mucho no se actualizan los estilos o imágenes; es controlable
  • No afecta el estado de inicio de sesión, el proceso de compra ni la precisión de la información de la cuenta
  • Las ventajas son evidentes: descargas más rápidas de los recursos estáticos y un servidor de origen más estable

Problemas habituales en esta etapa (más adelante se proporcionará un árbol de resolución de problemas)

  • Contenido mixto (la página carga recursos HTTP)
  • Los cambios en los recursos estáticos no se están aplicando (la URL no ha cambiado)

Etapa 2: Actualizar la estrategia (dando prioridad al número de versión, con «Purge/expiración» como alternativa)

Este es el parteaguas entre si “CDN” está hecho de manera profesional o no.

Una regla inquebrantable:

Para las actualizaciones que se pueden resolver cambiando el número de versión o el nombre del archivo, no confíes en Purge.

¿Por qué el almacenamiento en caché se vuelve tan complicado cuando la cadena se alarga?

  • Caché del navegador: es posible que tengas archivos CSS/JS antiguos almacenados en la caché local
  • Caché de CDN: es posible que los nodos de borde hayan almacenado en caché recursos antiguos
  • Caché del sitio original: el plugin de caché o la caché del servidor aún podrían estar mostrando contenido antiguo

Si no tienes una política de numeración de versiones, la versión será:
“Hice algunos cambios → Actualicé la página → No funcionó → Volví a borrar la caché → Seguía sin funcionar → Borré otra parte de la caché”
Ese es el mayor punto de dolor que mucha gente tiene con CDN.

Etapa 3 (Avanzada): Si se debe almacenar en caché el HTML (máximos beneficios, pero máximo riesgo)

El almacenamiento en caché de HTML (almacenamiento en caché de todo el sitio o almacenamiento en caché perimetral) puede reducir considerablemente el TTFB, pero también es una fuente habitual de problemas en entornos de WordPress.

Si no estás seguro, no caches HTML. Primero usa CDN estático + plugin de caché del servidor de origen.

Al almacenar HTML en caché, hay dos principios:

  1. Empieza simplemente adoptando una “mentalidad de visitante”: Páginas en caché solo para visitantes no registrados
  2. En primer lugar, escribe la lista de exclusiones: Primero la precisión, luego la tasa de acierto

6. Lista de reglas por escenario: cómo evitar incidentes según el tipo de sitio

6.1 Sitios web de contenido / blogs (principalmente artículos, con un alto volumen de visitas)

Recomendado

  • Recursos estáticos: Almacenamiento en caché completo
  • HTML: Considera la posibilidad de almacenar en caché la “página para visitantes no registrados”

Por lo general, hay que dar la vuelta

  • Backend e inicio de sesión:/wp-admin/*、/wp-login.php
  • Vista previa/Borrador
  • Página de resultados de búsqueda (si los parámetros cambian mucho, mejor no usar caché por ahora)
  • Solicitud POST de envío de formulario/comentario

Una clave de caché debe, como mínimo, distinguir entre

  • ¿Ha iniciado sesión?
  • Idioma (sitio web multilingüe)

6.2 Sitios web corporativos / Páginas de destino de marketing (con numerosos formularios y campañas)

Recomendado

  • Recursos estáticos: Almacenamiento en caché completo
  • HTML: Las páginas de destino públicas se pueden almacenar en caché (en modo visitante), pero hay que tener cuidado al gestionar las páginas de resultados de los formularios

El error más común: el seguimiento de parámetros que provoca la fragmentación de la caché
Páginas de destino habituales utm_* Parámetros:

  • Todas las claves se almacenan en caché → La caché está fragmentada, lo que da lugar a bajas tasas de aciertos
  • Ignorar todo → Es posible que algunas páginas que dependen de parámetros para su visualización no se muestren como se esperaba

6.3 Sitios para miembros / Plataformas de cursos / Comunidades (alta proporción de usuarios registrados)

Conclusión: Debes tener mucho cuidado con el almacenamiento en caché de HTML.
La opción más segura suele ser: CDN estático + caché/caché de objetos en el servidor de origen; en HTML, cachear solo para visitantes.

se debe omitir

  • Iniciar sesión / Registrarse / ¿Olvidó su contraseña?
  • Centro de cuentas, Pedidos/Suscripciones, Perfil
  • Cualquier página e interfaz que sea “muy dependiente del usuario”

6.4 Sitio de comercio electrónico (WooCommerce)

La lista de desvíos más importante

  • Cesta de la compra, Finalizar compra, Página de cuenta
  • Páginas relacionadas con la confirmación de pedidos y las notificaciones de pago
  • Iniciar sesión/Registrarse, Cupones/Recompensas y otros enlaces relacionados con el usuario

Por qué el comercio electrónico es más propenso a tener problemas

  • Una vez que el usuario tiene una cesta de la compra, una sesión o ha iniciado sesión, la página se personaliza al máximo
  • Si no se desactiva el almacenamiento en caché de HTML o este no distingue entre los distintos estados, las consecuencias más comunes son: errores en la cesta de la compra, confusiones entre cuentas y visualizaciones incorrectas de los precios.
    La precisión es lo primero; no la sacrifiques en aras de las tasas de acierto.

6.5 Sitios web multilingües y multidivisa

Recomendado

  • Recursos estáticos: Almacenamiento en caché completo
  • HTML: El estado del visitante se puede almacenar en caché, pero la clave de caché debe distinguir claramente entre las variantes de idioma y moneda

Se debe tener en cuenta la clave de caché

  • Idioma (ruta) /en/ /zh/ o subdominio en.）
  • ¿Has iniciado sesión?
  • Moneda/Tasa impositiva (si procede)

7. Aviso de riesgo

Riesgo 1: Contenido almacenado en caché incorrecto (el más grave)

  • Error de caché de recursos estáticos: suele ser CSS/imágenes antiguas
  • Error de almacenamiento en caché de HTML: podría afectar al contenido, a las carritos de la compra o a las cuentas; se trata de un problema grave

Riesgo 2: Las actualizaciones no se aplican (el más común)

Después de que la cadena de caché se alarga, será más común que “se cambió pero no surta efecto”:

  • Priorizar los cambios en los números de versión y los nombres de archivo
  • Purga/Recurso alternativo
  • El proceso de lanzamiento debe ser reproducible (para que sepamos qué URL se han modificado en cada lanzamiento)

Riesgo 3: El alcance de la versión gratuita/básica

  • Características comunes de los planes gratuitos: cuotas limitadas, ciertas funciones excluidas y condiciones del SLA y del servicio de asistencia que difieren de las de los planes de pago

Riesgo 4: Las capacidades de China continental se malinterpretan con facilidad

  • ESA: Para operar en China continental, es obligatorio registrarse en el ICP ante las autoridades chinas.
  • EdgeOne: Para utilizar la ruta de China continental, debe registrarse ante la autoridad china responsable del ICP.

8 lista de verificación: cómo confirmar después del lanzamiento que “realmente está funcionando”

8.1 ¿Los recursos estáticos realmente pasaron por CDN?

  • ¿Las imágenes/CSS/JS provienen del dominio/nodo perimetral CDN?
  • ¿Ves signos claros de que se ha producido una entrada en caché (los indicadores varían según la plataforma)?

8.2 ¿Ha disminuido la carga en el servidor de origen?

  • ¿Es más estable el ancho de banda del servidor de origen?
  • ¿Disminuyó el número de solicitudes/conexiones al origen (especialmente las de recursos duplicados)?

8.3 ¿Se pueden controlar las actualizaciones?

  • Realiza un solo cambio en el CSS o el JavaScript, o sustituye una imagen
  • ¿Se puede implementar rápidamente la nueva versión cambiando el número de versión o el nombre del archivo?
  • Si solo puedes actualizar mediante `Purge`, significa que tu política de control de versiones aún no está configurada correctamente (da prioridad a perfeccionar tu política; no recurras a `Purge` como práctica habitual).

8.4 ¿Son correctas las páginas de claves dinámicas?

(Imprescindible para sitios de comercio electrónico y de membresía)

  • ¿El contenido de la página es correcto después de iniciar o cerrar sesión?
  • ¿Se muestran correctamente las páginas de la cesta de la compra, la caja y la cuenta?
  • ¿Se ha producido alguna anomalía (de alto riesgo) en la que distintos usuarios hayan visto el mismo contenido específico de un usuario?

8.5 ¿Ha aumentado la tasa de errores?

  • Tiempo de espera agotado al origen, 5xx, acceso intermitente no disponible
  • Por lo general, esto indica: capacidad insuficiente en el servidor de origen, reglas incorrectas, activación de la limitación de velocidad o problemas con la conexión al servidor de origen

9. Árbol de diagnóstico cuando las actualizaciones no surten efecto (convertir la “magia” en pasos)

En primer lugar, determine qué tipo de problema tiene:

9.1 Los recursos estáticos no se han actualizado (el CSS, el JavaScript y las imágenes siguen siendo las versiones antiguas)

Escenario A: Solo tú puedes ver la versión anterior; cuando navegas de incógnito o cambias de dispositivo, aparece la nueva versión
Lo primero que hay que comprobar: la caché del navegador

  • Solución: Liberar los nuevos recursos cuando cambien los números de versión o los nombres de los archivos

Escenario B: Todos ven la versión anterior (incluidos aquellos que navegan de incógnito o utilizan un dispositivo diferente)
Sospecha prioritaria: CDN sigue alcanzando la caché anterior

  • 99% Motivo: La URL del recurso no ha cambiado
  • Solución recomendada: Estrategia de control de versiones
  • Solución alternativa: Purgar (medida temporal)

Caso C: tras sobrescribir la imagen con el mismo nombre, siempre se sigue mostrando la imagen anterior
Este es el problema clásico de la superposición entre la caché del navegador y la caché de CDN

  • Consejo práctico: Intenta evitar que se sobrescriban los nombres de los archivos a largo plazo utilizando un nuevo nombre de archivo, una nueva ruta o un nuevo número de versión

9.2 El HTML no se ha actualizado (el contenido y los módulos de la página siguen siendo los antiguos)

Escenario A: La vista del backend o posterior al inicio de sesión es nueva, pero los visitantes ven la versión anterior
La causa más probable: el código HTML de la sesión del visitante se ha almacenado en caché

  • En primer lugar, comprueba si este tipo de página debe almacenarse en caché
  • Si debe almacenarse en caché: se necesita una estrategia de actualización controlable; de lo contrario, la publicación será incontrolable.

Escenario B: Solo algunas regiones o redes muestran contenido desactualizado
Sospecha principal: estados de almacenamiento en caché diferentes entre los nodos periféricos

  • Enfoque: Utilizar políticas de control de versiones y actualización para resolver las discrepancias; aplicar una invalidación más explícita cuando sea necesario

Escenario C: Problemas con los usuarios que han iniciado sesión o con la cesta de la compra
Advertencia: Es posible que la caché contenga datos incorrectos

  • Comprueba de inmediato si las páginas en modo de usuario (como las de la cesta de la compra, el proceso de pago y la cuenta) se han almacenado en caché
  • Verifica si la Cache Key está ignorando variaciones clave como “estado de usuario cookie/idioma/moneda”

10. Recomendado

Cloudflare

  • Proxy inverso integrado
  • Ideal para: un comienzo sin complicaciones
  • Punto clave: resolver las actualizaciones con una estrategia de versiones; el caché de HTML se maneja desde el estado de visitante
  • Riesgo: Las páginas dinámicas deben omitirse

Tencent Cloud International EdgeOne

  • Proxy inverso integrado
  • Adecuado para: considerar la capacidad de los nodos de China continental y la integración de acceso unificado
  • Gratis: Hay un plan gratuito o una versión gratuita, pero asegúrate de revisar con atención los límites de uso y los términos y condiciones
  • Riesgo: planificar cuota de reglas/registros/subdominios; usar con cuidado la caché HTML

Alibaba Cloud International ESA América Latina (es-419) Español

  • Proxy inverso integrado
  • Gratis: Las cuentas del sitio internacional se pueden integrar con Entrance sin costo alguno
  • Riesgos: Es necesario confirmar con antelación las condiciones del plan gratuito (SLA, asistencia técnica y límites de velocidad), así como los requisitos regionales y de registro.
  • Adecuado para: evaluación/pruebas y acceso ligero; o para pasar a un plan de nivel superior más adelante; o para quienes estén considerando la capacidad de nodos en China continental y el acceso integrado

bunny.net

  • Extracción estática CDN
  • Recomendación: Empieza con una aceleración estática de bajo riesgo
  • Clave: la versión tiene prioridad, Purge como respaldo; evita sobrescribir con el mismo nombre
  • Riesgo: si la estrategia de actualización no está bien hecha, te encontrarás con frecuencia con “recursos antiguos”

11. Recomendaciones de acción

  1. Primero elige la modalidad: proxy inverso integrado (Cloudflare/EdgeOne/ESA) o Pull estático CDN (bunny)
  2. Implementación por fases:Primero, el contenido estático → luego, la política de control de versiones → por último, considerar el almacenamiento en caché de HTML
  3. Después del lanzamiento, revisar según la lista de verificación: acierto/origen/actualización/omitir dinámico/tasa de error
  4. Si necesitas más velocidad: vuelve a “Plugin de caché” y “Optimización de imágenes”, y comprime otra ronda la capa del sitio de origen y la capa de recursos

Preguntas frecuentes de CDN WordPress

1. ¿Por qué sigue siendo lento incluso usando CDN?

La razón más común no es que CDN no sirva, sino que el cuello de botella no está en la “capa de entrega”.

Puedes evaluar esto en el siguiente orden:

  • El TTFB sigue siendo alto: Indica que el servidor de origen tarda en generar el código HTML (base de datos/complementos/configuración del complemento de caché/rendimiento del servidor) → Volver a la capa del servidor de origen para optimizarlo
  • La imagen grande de la primera pantalla tarda mucho en cargarse: Si el tamaño, las dimensiones o el formato del archivo de imagen son incorrectos → Optimiza primero la imagen (compresión, WebP/AVIF, estrategia de redimensionamiento)
  • Los scripts de terceros están ralentizando el sistemaLos scripts de anuncios, estadísticas y atención al cliente suelen no beneficiarse de CDN; conviene reducir o retrasar su carga.
  • Solo en algunas zonas es lento: Esto podría deberse a la cobertura del nodo, a la conexión de backhaul o a una falta de acierto en la caché (baja tasa de aciertos) → Comprueba la tasa de aciertos y el estado del backhaul

CDN se encarga de entregar más rápido los “recursos ya optimizados”; si el servidor de origen es lento, las imágenes son grandes o los scripts son lentos, hay que tratar cada caso por separado.

2. ¿Por qué actualicé el CSS/JS/las imágenes, pero los usuarios siguen viendo la versión anterior?

Este es el problema más común en este escenario de CDN; la causa principal suele ser:La URL del recurso no ha cambiado...el sistema de caché seguirá sirviendo los resultados de la caché anterior según corresponda.

El método más fiable:

  • Primero el número de versión: Permitir cambios en las URL de los recursos (por ejemplo style.css?ver=xxxx (o hash del nombre del archivo)
  • Purga: una red de seguridad: El borrado de la caché solo debe utilizarse como medida temporal hasta que se haya establecido una política de control de versiones

Si actualizas con frecuencia el banner de la página de inicio o las imágenes promocionales, te recomendamos que evites “sobrescribir con el mismo nombre de archivo”; en su lugar, utiliza un nuevo nombre de archivo o una nueva ruta de directorio (lo cual te ofrece un mayor control).

3. ¿Necesito almacenar en caché el HTML? ¿Si no se almacena en caché, entonces no tendría sentido?

No es imprescindible.

Para muchos sitios, el mayor valor de CDN proviene de:

  • Carga más rápida de los recursos estáticos (imágenes, CSS, JavaScript y fuentes)
  • Menor carga en el servidor de origen y mayor estabilidad

Almacenar HTML en caché Es cierto que las ventajas pueden ser mayores (con un TTFB más bajo), pero los riesgos también son los más elevados: el comercio electrónico, los servicios de suscripción, el contenido personalizado y los sistemas multilingües y multidivisa son propensos a almacenar en caché el contenido incorrecto.

El enfoque seguro:

  1. Primero, versión estática CDN (bajo riesgo, alto rendimiento)
  2. Completar la estrategia de versiones y la lista de validación
  3. Reevaluar si se debe almacenar en caché el HTML (empezando por el “modo visitante”)

4. ¿Un sitio de comercio electrónico puede usar CDN? ¿Eso desordenará el carrito de compras?

Se puede, e incluso se debe (al menos para los recursos estáticos), pero hay que evitar almacenar en caché las páginas de usuario.

  • Los recursos estáticos se pueden almacenar en caché: Imágenes, CSS, JS
  • Se debe omitir la página del modo de usuario: No almacenes en caché el HTML de las páginas relacionadas con el carrito de compras, el proceso de pago y la cuenta
  • Siempre y cuando no almacenes estas páginas en caché en formato HTML, el riesgo de que se produzcan problemas relacionados con la “comparación entre carritos” o entre cuentas se reducirá considerablemente

5. ¿Cómo hacer un sitio multilingüe y multidivisa para que CDN no mezcle idiomas ni precios?

El quid de la cuestión es Clave de caché ¿Es eso correcto?

  • Idioma (ruta o subdominio)
  • Moneda (si afecta a la visualización del precio)
  • ¿Has iniciado sesión?
  • Región/Tasa impositiva (si la página varía según la región)

Si estas dimensiones no se incorporan a la lógica de almacenamiento en caché, es muy probable que los usuarios del idioma A vean contenido destinado al idioma B, o que los precios no sean coherentes.

6. ¿Debo elegir el proxy inverso integrado o Pull estático?

Puedes elegir en función de tus “objetivos” y tu “tolerancia al riesgo”:

  • Quiero resolver de una vez HTTPS + CDN + seguridad básica, y luego poder ampliar reglas/WAFઃProxy inverso integrado
  • Quiero empezar por el primer paso más seguro (los recursos estáticos se cargan más rápido) y no quiero configurar un proxy para todo el sitio:Extracción estática CDN(p. ej., conejito)

Si no estás seguro, la recomendación predeterminada es:Primero estático CDN → Prueba la política de control de versiones y la lista de validación → A continuación, decide si implementar una solución de almacenamiento en caché basada en proxy o en HTML.

7. ¿Se puede usar directamente la versión gratuita en un sitio web oficial?

Se puede utilizar, pero debes entender que “gratis” significa “básico/de prueba/para uso ligero”, y no una “solución completa con un SLA comercial”.

  • ¿Te parecería bien la opción gratuita?Límites de cuota, funciones que faltan, diferencias en las opciones de soporte técnico y la posible ausencia de un compromiso de SLA？
  • Si no es así, deberías considerar la versión gratuita como una prueba y pasar a un plan más adecuado más adelante.

8. ¿Cómo puedo confirmar que CDN realmente funciona y que no es solo un efecto placebo?

Sigue estos tres pasos para comprobarlo (no se necesitan herramientas complicadas):

  1. Ver si los recursos estáticos se devuelven desde CDN(¿Ha cambiado la fuente de las imágenes, el CSS o el JS?)
  2. Comprueba si han mejorado la tasa de visitas y la tasa de retorno(Solo cuenta como ganancia real si suben los aciertos y baja el retorno al origen)
  3. Actualizar la política de validación de CSS e imágenes(Número de versión vigente, lo que indica que el enlace está bajo control)

Si no cumples con el punto 3, cuanto más optimices tu sitio, más probable será que te veas afectado por actualizaciones que no surten efecto; por lo tanto, te recomendamos que des prioridad a poner al día tu estrategia de control de versiones.

9. ¿Por qué se queda trabado con frecuencia al activar la aceleración para China continental?

Las razones más comunes son:La región seleccionada no cumple con los requisitos de registro。

  • Si deseas seleccionar una región de proxy que incluya China continental, normalmente tendrás que completar primero Presentación del ICP; Si aún no te has registrado, solo podrás seleccionar regiones que no incluyan China continental.

10. ¿Debo instalar primero el complemento de caché o usar primero CDN?

El orden que se suele recomendar es:

  1. Capa de origen: primero estabiliza el plugin de caché/infraestructura del hosting (baja el TTFB y la carga del panel)
  2. Capa de recursos: Optimiza las imágenes para reducir su tamaño de archivo
  3. Capa de entrega: CDN entrega recursos más rápido y de forma más estable

Si hay algo que te gustaría hacer ahora mismo, pero te preocupa que pueda salir mal:Primero usar estático CDN (Fase 1), que ofrecen rendimientos estables y el menor riesgo.