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 origenHost / 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 —— decide que los recursos estén más cerca de los visitantes, con una mayor tasa de aciertos y menos carga para el servidor de origen

Este artículo trata sobre CDN Aceleración：

  • Qué puede resolver CDN y qué no կարող resolver
  • Elegir la modalidad y el proveedor de CDN adecuados para usted y entender los límites entre la versión gratis y la versión básica
  • Publicar en orden de menor riesgo, sin tumbar el sitio ni causar problemas de caché en e-commerce o membresías
  • Una vez implementado, podemos comprobar que “funciona correctamente” e investigar “por qué no se ha actualizado, por qué va lento o por qué el contenido aparece distorsionado”.”

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
Tras acertar en la caché perimetral, las solicitudes ya no volverán con tanta frecuencia al servidor de origen, y se reducirán la carga de ancho de banda, las conexiones concurrentes, el IO de disco y las fluctuaciones de CPU del origen.
Esto se hace especialmente evidente en situaciones de picos de tráfico, como “páginas de campaña, artículos virales y páginas de productos que reciben un aumento repentino de visitas”.

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, por lo que es menos probable que el servidor de origen se sature.
Notarás un “acceso más fluido”: aunque la carga del servidor de origen aumente momentáneamente, la caché perimetral seguirá sirviendo contenido.

1.2 3 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 de los plugins lenta y el cálculo de PHP lento: estos pertenecen a problemas de la capa del servidor de origen.
CDN puede acelerar los recursos estáticos, pero si incluso el HTML de la página de inicio se genera muy lento, el usuario igual sentirá que “abre lento”. En ese caso, priorizá 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 “reducir mágicamente” la imagen grande de 3MB.
Deberías empezar por optimizar tus imágenes: gestión del tamaño (evita descargar imágenes excesivamente grandes), compresión, formatos WebP/AVIF, estrategias de carga diferida, etc.

1.2.3 Scripts de terceros lentos
Los anuncios, las estadísticas, el servicio al cliente y los componentes de redes sociales, entre otros, provienen de dominios de terceros.
CDN normalmente no se puede hacer “más rápido”; solo se puede reducir o retrasar la carga, cambiar de proveedor u optimizar la estrategia de scripts.

Recomendaciones

Primero dejen bien la capa del sitio de origen y la capa de recursos, y después hagan CDN; el efecto se va a notar más y va a haber menos problemas.

2. Selección en 30 segundos: ¿qué tipo de formato CDN necesitás?

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:

  • Administrar certificados y TLS es más fácil con HTTPS
  • Punto de entrada 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é y de omisión más detalladas)
  • “Mayor escalabilidad”: si en el futuro desea añadir funciones de seguridad, límites de velocidad o protección contra bots, por lo general se pueden integrar en el mismo sistema

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

Si desea:

  • Esperas que HTTPS + CDN + Seguridad básica Todo de una 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?
  • Valorás más la experiencia integral y la expansión posterior, y no querés dividir DNS, certificados, CDN y seguridad en varios conjuntos separados.

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é de proxy o caché de sitio completo?
  • 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
  • Segundo nivel: Pull estático CDN (inicio seguro): bunny.net / Cloudways CDN, etc.

4. Proveedor recomendado

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

¿Qué es?
Después de conectar el dominio, este actúa como proxy frente al sitio web y ofrece CDN, certificados, protección básica y capacidades de reglas de caché.

¿Para quién es adecuado?

  • ¿Querés despreocuparte? HTTPS + CDN + seguridad básica integral
  • Para crear un ecosistema maduro: tendremos que incorporar 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: Después de poner en producción CDN, la cadena de caché se alarga (caché del navegador + caché de CDN + caché del servidor de 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 (véase la lista de casos a continuación).

Notas：

  • Posicionamiento: proxy inverso integrado (SSL + CDN + protección básica)
  • Ideal para: lanzamiento sin complicaciones y amplio 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 versionado; se debe omitir estrictamente la 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.

  • Al igual que Cloudflare, tiene versión gratuita, pero normalmente hay 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

  • Al igual que Cloudflare, tiene versión gratuita, pero normalmente hay 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！
  • Regístrese para usar la cuenta del sitio internacional
  • Inicia sesión en la consola de ESA, añade un sitio y selecciona el plan gratuito 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 comercial con acuerdo de nivel de servicio (SLA)
  • 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 es necesario 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 ligero; 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 del ICP

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

Si querés “asegurarte primero la ganancia más estable”, un Pull CDN como bunny es muy adecuado:
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 predecible.

Apto para:

  • Haz esto primero Imágenes / CSS / JavaScript / Fuentes aceleración estática
  • Quiere obtener primero ingresos estables y de bajo riesgo, sin apurarse a entregar todo el sitio a una plataforma administrada todo en uno (DNS/SSL/WAF)
  • 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 los recursos estáticos casi nunca falla por un bug de CDNsino un 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 cambiadoCon la misma dirección/nombre de archivo/ruta, tanto CDN como el navegador seguirán usando razonablemente la caché anterior, y por eso ves “¿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 método más fiable?

  • Cambios en los números de versión y los nombres de archivo → El cambio de URL → CDN se almacena en caché como un recurso nuevo → la nueva versión entra en vigor casi de inmediato
  • El Purge (limpiar caché) requiere que lo activés manualmente; es fácil que el alcance no sea preciso y hay retrasos en la propagación entre nodos. Además, hacer Purge con frecuencia reduce la tasa de aciertos, aumenta las solicitudes al origen y provoca más variación.

Un ejemplo fácil de entender:

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

bunny como práctica recomendada para “primer paso 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 comprobar los beneficios: los recursos estáticos son más rápidos y el servidor de origen queda más liviano
  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 períodos prolongados; es preferible utilizar un nombre de archivo nuevo o cambiar la ruta del archivo (especialmente en el caso de los banners de la página de inicio y las imágenes promocionales).
  3. Confirmar aciertos con lista de verificación después del lanzamiento
    • ¿Los recursos estáticos provienen de CDN?
    • ¿La tasa de aciertos aumenta gradualmente y el ancho de banda/las solicitudes del servidor de 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, al utilizar EdgeOne o ESA, la conexión se redirigirá automáticamente a las rutas de China continental cuando se acceda desde ese país.

“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 etapas (de estable a sólido)

La razón por la que CDN es más propenso a “desordenarse” al lanzarse es que al principio se quiere activar todas las capacidades al máximo.

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

ObjetivoLas imágenes/CSS/JS/fuentes usan primero 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 las imágenes; es controlable
  • No afectará al estado de sesión, a los procesos de comercio electrónico ni a la exactitud 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 (HTTPS página carga HTTP recursos)
  • 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 «Purga/caducidad» como alternativa)

Este es el punto de inflexión de “CDN: hacerlo profesional o no profesional”.

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
  • CDN Caché: Los nodos de borde pueden haber almacenado en caché recursos antiguos.
  • Caché del servidor de origen: Los complementos de caché o el caché del servidor pueden seguir mostrando contenido antiguo.

Si no tienes una estrategia de numeración de versiones, el lanzamiento quedará así:
“Hice algunos cambios → Actualicé la página → No funcionó → Volví a borrar la caché → Seguía sin funcionar → Borré otra parte de la caché”
Este es el mayor punto de dolor para muchas personas con respecto al 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 guardés en caché el HTML. Primero usá CDN estático + el plugin de caché del servidor de origen.

Al almacenar HTML en caché, hay dos principios:

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

6. Lista de reglas por escenario: qué hacer según el tipo de sitio para evitar accidentes

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

Recomendado

  • Recursos estáticos: Almacenamiento completo en caché
  • 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 (los parámetros varían mucho, es más sencillo no almacenar en caché por ahora)
  • Solicitud POST de envío de formulario/comentario

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

  • ¿Iniciar sesión? (Dimensión cookie)
  • 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 completo en caché
  • 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 están incluidas en la caché → La caché está fragmentada, lo que da lugar a bajos índices 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 de miembros / Sitios de cursos / Comunidades (alta proporción de usuarios que han iniciado sesión)

Conclusión: Debes tener mucho cuidado con el almacenamiento en caché de HTML.
Una práctica segura suele ser: CDN estático + caché de origen/caché de objetos; HTML solo se almacena en caché para visitantes.

se debe omitir

  • Iniciar sesión / Registrarse / ¿Olvidaste tu 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é los comercios electrónicos son más propensos a accidentes?

  • 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 completo en caché
  • 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.）
  • ¿Iniciar sesión? (cookie)
  • Moneda/Tasa impositiva (si procede)

7. Advertencia de riesgo

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

  • Error de caché de recursos estáticos: generalmente archivos de estilo/imagen desactualizados
  • 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)

Cuando la cadena de caché se alarga, “cambios sin efecto” se vuelve más común:

  • 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, exclusión de determinadas funciones 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 en el ICP chino.

8 Lista de verificación: ¿Cómo confirmar que “realmente funciona” después del lanzamiento?”

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

  • ¿Las imágenes, CSS y JS provienen del dominio/nodo perimetral CDN?
  • ¿Ves indicios 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?
  • ¿Ha disminuido el número de solicitudes al servidor de origen o el número de conexiones (especialmente en el caso 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?
  • ¿Las páginas relacionadas con carrito de compras/pago/cuenta siempre son correctas?
  • ¿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 al volver al origen, errores 5xx, problemas de acceso intermitentes
  • 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 para actualizaciones sin efecto (convertir “misterio” 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 aún acierta en caché antiguo

  • 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: La imagen antigua sigue mostrándose después de sobrescribir con el mismo nombre.
Este es un problema clásico de superposición entre la caché del navegador y la caché + CDN

  • Consejo práctico: Intenta evitar “conflictos de nombres” a largo plazo utilizando un nuevo nombre de archivo, ruta o 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 las versiones antiguas)

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 se debe almacenar en caché: se necesita una estrategia de actualización controlada, de lo contrario, la publicación no es controlable.

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: La caché puede contener datos incorrectos

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

10. Recomendado

Cloudflare

  • Proxy inverso integrado
  • Ideal para: un comienzo sin complicaciones
  • Puntos clave: la estrategia de versiones resuelve las actualizaciones; el caché HTML se hace 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 unificada
  • 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 cuotas de reglas/registros/subdominios; usar caché HTML con precaución

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

  • Pull estático CDN
  • Recomendación: Empieza con una aceleración estática de bajo riesgo
  • Puntos clave: Dar prioridad a los números de versión; utilizar `Purge` como alternativa; evitar sobrescribir archivos con el mismo nombre
  • Riesgo: si la estrategia de actualización no se hace bien, te vas a topar frecuentemente con “recursos antiguos”

11. Recomendaciones de acción

  1. Primero elija el tipo: 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 → y, por último, considerar el almacenamiento en caché de HTML
  3. Después de publicar, revise la lista de verificación: acierto/origen/actualización/omisión dinámica/tasa de errores
  4. Si necesitas que sea más rápido: Vuelve a “Plugin de caché” > “Optimización de imágenes” y ejecuta otra ronda de compresión tanto en la capa del servidor de origen como en la capa de recursos

Preguntas frecuentes de WordPress CDN

¿Por qué sigue lento después de usar CDN?

La causa 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 reducirlos o cargarlos más tarde
  • 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”; el origen lento, las imágenes pesadas y los scripts lentos deben tratarse por separado.

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

Este es el problema más común en el escenario CDN, y la razón 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 que cambie la URL del recurso (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 archivos con el mismo nombre”; 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 lo hago, no tendría sentido?

No es algo que se exija necesariamente.

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 las configuraciones multilingües y multidivisa son propensos a almacenar en caché contenido incorrecto.

El enfoque seguro:

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

4. ¿Se puede poner CDN en un sitio de comercio electrónico? ¿Se desordenará el carrito de compras?

Se puede, y se debería (al menos para los recursos estáticos), pero hay que evitar poner en caché las páginas en estado de usuario.

  • Los recursos estáticos se pueden almacenar en caché: Imágenes, CSS, JS
  • Se debe omitir la página en modo 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 de compra” o «entre cuentas» se reducirá considerablemente

5. ¿Cómo hacer un sitio multilingüe y multimoneda con CDN sin mezclar 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)
  • ¿Iniciar sesión? (cookie)
  • 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 proxy inverso integrado (Cloudflare/EdgeOne/ESA) o Pull estático CDN (bunny)?

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

  • Quiero resolver de una vez HTTPS + CDN + seguridad básica, y después poder ampliar reglas/WAFProxy 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:Pull estático 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 verificación 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 “nivel básico/de prueba/uso ligero”, y no una “solución completa con un SLA comercial”.

  • ¿Estarías dispuesto a aceptar el plan gratuito?Límites de cuota, funciones que faltan, diferencias en las opciones de soporte 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 confirmo que CDN realmente está funcionando y 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 beneficio real si aumentan los aciertos y disminuye el tráfico de retorno)
  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 pega tan seguido 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. ¿Debería instalar primero el plugin de caché o implementar primero CDN?

El orden que se suele recomendar es:

  1. Capa de origen: primero estabilizar el plugin de caché y la base del hosting (baja el TTFB y la carga del panel)
  2. Capa de recursos: Optimizar las imágenes para reducir el tamaño de los archivos
  3. Capa de entrega: CDN entrega recursos más rápido y con mayor estabilidad

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