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 / Complemento de caché —— Determina TTFB y 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 entregaCDN —— Decidir que los recursos estén más cerca de los visitantes, con mayor estabilidad en los aciertos y más facilidad para el servidor de origen.

Este artículo trata sobre CDN Aceleración：

  • Saber qué puede y qué no puede resolver CDN
  • Seleccionar la forma y proveedor de CDN adecuados (y comprender los límites de la versión gratuita/de inicio)
  • Publicar en orden de menor riesgo, sin tumbar el sitio ni causar problemas de caché en ecommerce/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 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 alcanzar la caché perimetral, las solicitudes ya no regresan con frecuencia al origen, lo que reduce significativamente las fluctuaciones en el ancho de banda, las conexiones concurrentes, el IO de disco y CPU del servidor de origen.
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 periféricos absorben una gran cantidad de solicitudes repetidas, lo que hace que el servidor de origen sea menos propenso a saturarse.
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 CDN 3 tipos de problemas que no se resuelven automáticamente

1.2.1 El servidor de origen en sí es lento
Base de datos lenta, lógica de complementos lenta, cálculo PHP lento: estos son problemas de la capa de origen.
CDN puede acelerar los recursos estáticos, pero si incluso el HTML de la página principal se genera lentamente, los usuarios seguirán sintiendo que “se abre lento”. En este caso, prioriza: optimización del servidor/plugin de caché/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 ayudarlas a “ir más rápido”, solo puedes manejarlo reduciendo/retrasando la carga, reemplazando proveedores o optimizando estrategias de scripts.

Recomendación

Primero, haz bien la capa de origen y la capa de recursos, luego haz CDN, el efecto será más evidente y habrá menos problemas.

2. Selección de 30 segundos: ¿Qué tipo de forma 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 de seguridad básica (por ejemplo, DDoS/WAF) Todo incluido. Una vez integrado, actúa como un proxy frente a tu sitio web.

Lo que obtendrás:

  • Certificado HTTPS y gestión TLS más sencilla
  • Entrada unificada 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 / EdgeOne / 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?
  • Valoras más la “experiencia integral y la expansión futura”, y no quieres dividir DNS, certificados, CDN y seguridad en múltiples conjuntos.

2.2 “Pull estático puro CDN” (inicio de bajo riesgo, principalmente acelera 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 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. Proveedores recomendados

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

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

¿A quién va dirigido?

  • Para ahorrar preocupaciones: HTTPS + CDN + paquete básico de seguridad
  • 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 aplicadoDespués de implementar CDN, la cadena de caché se alarga (caché del navegador + caché de CDN + caché del servidor de origen), se requiere 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)
  • Adecuado para: Lanzamiento sin preocupaciones, gran espacio para expansión futura
  • Valores fundamentales: Punto de acceso único para certificados, seguridad y almacenamiento en caché
  • Riesgo: las actualizaciones dependen de la estrategia de versiones; el caché HTML debe omitirse estrictamente

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 una versión gratuita, pero generalmente 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

  • Al igual que Cloudflare, tiene una versión gratuita, pero generalmente 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 en el 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 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, facturación por uso clara)

Si quieres “asegurar primero las ganancias más estables”, un Pull como bunny CDN 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
  • ¿Quieres obtener primero “ingresos estables de bajo riesgo” sin apresurarte a entregar todo el sitio a una plataforma de proxy (DNS/SSL/WAF integrado)?
  • 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

Los recursos estáticos “no se actualizan” casi nunca son un error de CDN, sino 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 cambiado(Misma dirección/nombre de archivo/ruta), tanto CDN como el navegador seguirán accediendo razonablemente al caché antiguo, por lo que verás “¿por qué no se actualiza?”.

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 → Cambio de URL → CDN se trata como un recurso nuevo en caché → la nueva versión entra en vigor casi de inmediato
  • La purga (borrar caché) requiere que la actives manualmente; es fácil que el alcance no sea preciso y la propagación entre nodos tenga retraso. Además, hacer purgas con frecuencia reduce la tasa de aciertos, aumenta las solicitudes al origen y genera más fluctuaciones.

Un ejemplo fácil de entender:

  • style.css El contenido ha cambiado, pero la URL sigue siendo style.css → CDN continuar con caché antiguo (razonable)
  • La URL ha cambiado a style.css?ver=20260103 或 style.abc123.css → CDN considerar como nuevo recurso → nueva versión entra en vigor inmediatamente

bunny como la mejor práctica 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 es más fácil verificar los beneficios: recursos estáticos más rápidos, origen 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. después del lanzamiento, confirmar aciertos con lista de verificación
    • ¿Los recursos estáticos provienen de CDN?
    • ¿la tasa de aciertos aumenta gradualmente, el ancho de banda/solicitudes del origen son más estables? (hay 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.

Vale la pena considerar tanto Alibaba Cloud China como Tencent Cloud China. Si tu dominio ya está registrado en el ICP de China continental, EdgeOne o ESA cambiarán automáticamente a rutas de China continental cuando se acceda a ellos 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 del 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 más fácil de “desordenar” en el lanzamiento de CDN es querer activar todas las capacidades desde el principio.

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

ObjetivoImágenes/CSS/JS/fuentes primero van a CDN; HTML no se almacena en caché en CDN (o temporalmente no se mueve).

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

  • Riesgo más bajo: si el caché de recursos estáticos es incorrecto, como máximo es “estilos/imágenes no actualizados”, 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 (página HTTPS 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 «Purga/caducidad» como alternativa)

Este es el punto de inflexión de “qué tan profesional es CDN”.

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 aún pueden estar entregando 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 dolor de cabeza 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.

No almacenes en caché HTML si no estás seguro. Primero, usa CDN estático + un complemento 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 excepciones: Primero la precisión, luego la tasa de acierto

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

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

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 para envío de formulario/comentario

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

  • ¿Iniciar sesión? (Dimensión cookie)
  • Idioma (sitio 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 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.
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 del pedido y la devolución 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: principalmente estilos/imágenes 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)

Después de que la cadena de caché se alarga, “los cambios no surten 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 necesario 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/JS provienen del dominio/nodo de borde 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?
  • ¿El número de solicitudes/conexiones al servidor de origen ha disminuido (especialmente para 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 del 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?

  • Tiempos de espera de origen, errores 5xx, apertura intermitente
  • Por lo general, esto indica: capacidad insuficiente del servidor, reglas incorrectas, activación de la limitación de velocidad o problemas con la conexión al servidor de origen

9. Árbol de resolución de problemas de actualización no efectiva (convertir “misticismo” 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 versión nueva
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 impacta 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: Después de sobrescribir imagen con mismo nombre, siempre muestra imagen antigua
Este es un problema clásico de superposición de caché del navegador + caché CDN

  • Consejo práctico: Intenta evitar que se sobrescriban los nombres de los archivos 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 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é: necesita una estrategia de actualización controlada, de lo contrario la publicación es 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é
  • Verificar si la clave de caché omite variantes clave como “estado de usuario cookie/idioma/moneda”

10. Recomendación

Cloudflare

  • Proxy inverso integrado
  • Ideal para: un comienzo sin complicaciones
  • Puntos clave: la estrategia de versiones resuelve las actualizaciones; la caché de HTML se realiza 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 en la China continental y el acceso integrado.
  • 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; precaución con caché HTML

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

  • Proxy inverso integrado
  • Gratis: Las cuentas del sitio internacional se pueden vincular a 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 paquete 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

  • Estático Pull CDN
  • Recomendación: Empieza con una aceleración estática de bajo riesgo
  • Enfoque: priorizar el número de versión, Purge como respaldo; evitar la sobrescritura de nombres idénticos.
  • Riesgo: Si la estrategia de actualización no está bien implementada, se encontrará frecuentemente con “recursos antiguos”.”

11. Recomendaciones de acción

  1. Primero seleccione la forma: 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. Tras la implementación, comprueba los siguientes puntos de la lista de verificación: visitas/solicitudes de proxy/actualizaciones/omisiones dinámicas/índice de errores
  4. Necesita ser más rápido: vuelva a “Complemento de caché” “Optimización de imágenes” y comprima nuevamente la capa de origen y la capa de recursos

WordPress CDN Preguntas frecuentes

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

La razón más común no es que CDN no funcione, 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 alojamiento) → 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 sistemaScripts comunes de publicidad/estadísticas/atención al cliente → CDN generalmente no ayuda, necesita reducirse o cargarse 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 los “recursos ya optimizados” más rápido; los servidores de origen lentos, las imágenes grandes y los scripts lentos deben manejarse por separado.

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

Este es el problema más común en el escenario 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 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é HTML? ¿No tendría sentido si no lo hago?

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 en caché HTML 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é contenido incorrecto.

El enfoque seguro:

  1. Primero, implementar CDN estático (bajo riesgo, alta recompensa)
  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 usar CDN en un sitio de comercio electrónico? ¿No hará un lío con el carrito de compras?

Se puede implementar, y se debe hacer (al menos para recursos estáticos), pero evite almacenar en caché páginas de 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 CDN en sitios multilingües/multimoneda para no mezclar idiomas/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”:

  • Solucionar de una vez HTTPS + CDN + seguridad básica, con opción de ampliar reglas/WAF despuésProxy 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:Estático Pull 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. ¿La versión gratuita se puede usar directamente 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”.

  • ¿Te parecería bien la opción gratuita?Límites de cuota, funciones que faltan, diferencias en las opciones de asistencia técnica y la posible ausencia de un compromiso de SLA？
  • Si eso no es posible, 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 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 los aciertos aumentan y las solicitudes de origen disminuyen)
  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 congelado 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 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 backend)
  2. Capa de recursos: Optimiza las imágenes para reducir su tamaño de archivo
  3. Capa de entrega: CDN lleva los 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.