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 origen: Servidor / PHP / Base de datos / Complemento de almacenamiento en 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 la imagen principal
  • Capa de entrega: CDN — garantizar que los recursos estén más cerca de los usuarios, que las respuestas sean más fiables y que se reduzca la carga en el servidor de origen

Este artículo trata sobre CDN Aceleración：

  • Entender qué puede y qué no puede resolver CDN
  • Elige el plan CDN y el proveedor que mejor se adapte a tus necesidades (y conoce las diferencias entre la versión gratuita y la versión básica)
  • Implementa en orden de menor riesgo, asegurándote de que el sitio no se bloquee y de que no surjan problemas con el comercio electrónico o el almacenamiento en caché de los miembros
  • 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. Empecemos por aclarar el concepto: qué hace y qué no hace CDN

1.1 El documento CDN aborda principalmente tres cuestiones clave

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 desde una ubicación más cercana al 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
Una vez que una solicitud llega a la caché periférica, ya no es necesario que recupere datos con frecuencia del servidor de origen, lo que se traduce en una menor carga sobre el ancho de banda del servidor de origen, las conexiones simultáneas, las operaciones de E/S de disco y las fluctuaciones de CPU.
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 las horas de mayor tráfico, los nodos periféricos absorben un gran volumen de solicitudes duplicadas, lo que reduce la probabilidad de que el servidor de origen se sobrecargue.
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 puede resolver automáticamente

1.2.1 El servidor de origen en sí es lento
Rendimiento lento de la base de datos, lógica lenta de los complementos, cálculos lentos de PHP: estos son problemas que se producen en el servidor de origen.
CDN puede acelerar los recursos estáticos, pero si el código HTML de la página de inicio tarda mucho en generarse, los usuarios seguirán teniendo la sensación de que el sitio “tarda en cargarse”. En este caso, debes dar prioridad a: el alojamiento web, los plugins de almacenamiento en caché y la optimización de la base de datos.

1.2.2 La imagen en sí es demasiado grande
CDN no puede reducir mágicamente la imagen grande 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
Los componentes relacionados con la publicidad, la analítica, el servicio al cliente y las redes sociales, entre otros, están alojados en dominios de terceros.
Por lo general, CDN no puede hacer que funcionen “más rápido”; la única forma de solucionar esto es reduciendo o aplazando la carga, cambiando de proveedor u optimizando las políticas de scripts.

Recomendación

Si primero te aseguras de que la capa del servidor de origen y la capa de recursos estén bien configuradas, antes de pasar a CDN, los resultados serán más evidentes y habrá menos problemas.

2. Guía rápida de 30 segundos: ¿Qué configuración del 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 (p. ej., DDoS/WAF) Todo incluido. Una vez integrado, actúa como un proxy frente a tu sitio web.

Lo que obtendrás:

  • Gestión más sencilla de certificados y TLS con HTTPS
  • Una puerta de enlace de seguridad unificada (protección básica contra DDoS, 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?
  • Usted da mayor importancia a la “experiencia general y la escalabilidad futura”, y no desea dividir el DNS, los certificados, el CDN y la seguridad en varios conjuntos

2.2 “Pull CDN” puramente estático (inicio de bajo riesgo, optimizando principalmente imágenes, CSS y 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”

Representa: bunny.net (modelo de facturación por consumo claro)

Si desea:

  • Lo mejor es empezar por la “opción más segura”: acelerar los recursos estáticos
  • ¿Quieres obtener un retorno rápido de tu inversión antes de decidir si optar por el almacenamiento en caché basado en proxy o el almacenamiento en caché de todo el sitio?
  • Le gustaría que los costos se acercaran más a un modelo de “pago por uso”

3. Cómo hacerlo

  • Nivel 1: Modelo de agencia integrada (preferido): Cloudflare / EdgeOne / ESA
  • Nivel 2: Tracción estática CDN (un inicio seguro): bunny.net / Cloudways / CDN, etc.

4. Proveedores de servicios recomendados

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

¿Qué es?
Una vez que hayas conectado tu dominio, este actuará como un proxy frente a tu sitio web, proporcionando CDN, certificados, protección de seguridad básica y reglas de almacenamiento en caché.

¿A quién va dirigido?

  • ¿Buscas una solución sin complicaciones?: HTTPS + CDN + paquete básico de seguridad completo
  • 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: Tras la implementación de CDN, la cadena de almacenamiento en caché se ha alargado (caché del navegador + caché de CDN + caché del servidor de origen); se requiere una “política de versiones” para garantizar que las actualizaciones se realicen de forma controlada (a continuación se incluye un árbol de resolución de problemas)
  • Ten cuidado al almacenar HTML en caché: Si se almacena en caché el código HTML, las páginas de comercio electrónico, de miembros y personalizadas deben excluirse estrictamente; de lo contrario, podrían producirse incidentes graves (véase la lista de situaciones a continuación)

Notas：

  • Configuración: Proxy inverso integrado (SSL + CDN + protección básica)
  • Ideal para: una puesta en marcha sin complicaciones con amplias posibilidades de expansión futura
  • Valores fundamentales: Punto de acceso único para certificados, seguridad y almacenamiento en caché
  • Riesgo: Las actualizaciones dependen de las políticas de control de versiones; el almacenamiento en caché de 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, ofrece una versión gratuita, pero normalmente hay Cuota/Límite funcional(número de reglas, número de tareas de registro, etc.), pero no es necesario modificar DNS; basta con configurar el registro CNAME para conectarse a él,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, ofrece una versión gratuita, pero normalmente hay Cuota/Límite funcional(número de reglas, número de tareas de registro, etc.), pero no es necesario modificar DNS; basta con configurar el registro CNAME para conectarse a él,No se recomienda la versión gratuita para sitios web comerciales！
  • Solo tienes que registrarte para crear una cuenta en el sitio web internacional y empezar
  • Inicie sesión en la consola de ESA, añada un sitio y seleccione la opción gratuita Entrada Suscripción al 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 un nodo en China continental, normalmente es necesario cumplir los requisitos relativos al registro ICP y a la ubicación geográfica.
  • 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 del ICP

4.4 bunny.net: Static Pull CDN (punto de entrada de bajo riesgo, estructura de precios clara de pago por uso)

Si quieres “asegurarte primero los rendimientos más estables”, una estrategia como «Pull CDN» en Bunny es ideal:
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
  • Lo que quieres es asegurarte primero de obtener “rendimientos estables y de bajo riesgo”, y no tienes prisa por ceder todo el sitio a una plataforma tipo agencia (solución 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

El problema de que “las actualizaciones de los recursos estáticos no surtan efecto” casi nunca se debe a un error en CDN... sino más bien un comportamiento normal del sistema de almacenamiento en 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 mostrando, como es lógico, la caché antigua, por lo que te preguntarás: “¿Por qué no se ha actualizado?”.

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 almacenado en caché como un nuevo recurso → La nueva versión entra en vigor casi de inmediato
  • Purge (limpiar caché) requiere activación manual, es propenso a imprecisión en el alcance y con retraso en la propagación de nodos; la Purge frecuente también puede causar disminución del hit rate, aumento en las peticiones al origen y mayor volatilidad

Un ejemplo fácil de entender:

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

Bunny como ejemplo de buenas prácticas 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.
    • Además, te resulta más fácil comprobar las ventajas: los recursos estáticos se cargan más rápido y el servidor de origen consume menos recursos
  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 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. 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?
    • ¿Está aumentando gradualmente la tasa de aciertos? ¿Se ha estabilizado el ancho de banda o el volumen de solicitudes del servidor de origen? (Consulte la lista de verificación que figura a continuación)

Tenga en cuenta que

Si su empresa opera en China continental, o si desea garantizar un acceso más rápido a su sitio web desde 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 navegación en sitios web transfronterizos”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. Plan de implementación: se llevará a cabo en tres fases (de estable a robusta)

La razón principal por la que el CDN tiende a “fallar” al iniciarse por primera vez es que los usuarios intentan aprovechar al máximo todas sus funciones desde el principio.

Etapa 1: Solo recursos estáticos (CDN) (se recomienda encarecidamente completarla primero)

Objetivo: Las imágenes, el CSS, el JS y las fuentes se sirven primero (CDN); el HTML no se almacena en caché (o se deja temporalmente sin cambios) en CDN.

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

  • Riesgo mínimo: si los recursos estáticos se almacenan en caché de forma incorrecta, lo peor que puede pasar es que “los estilos o las imágenes no se actualicen”, un problema que se puede solucionar fácilmente
  • 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 en la carga de la página, HTTP en los 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)

Esta es la diferencia fundamental entre si “CDN” se hace 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
  • CDN Caché: Es posible que el nodo periférico haya almacenado en caché un recurso obsoleto
  • Almacenamiento en caché del servidor de origen: es posible que el complemento de almacenamiento en caché o la caché del servidor sigan mostrando contenido obsoleto

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 principal problema que mucha gente tiene con el 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 almacenes el HTML en caché. Empieza con CDN estático + el complemento de almacenamiento en 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 excepciones: Primero la precisión, luego la tasa de acierto

6. Lista de verificación de normas específicas para cada lugar de trabajo: Cómo prevenir accidentes en diferentes tipos de lugares de trabajo

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 (dado que los parámetros varían considerablemente, lo más sencillo es no almacenarla en caché por ahora)
  • Solicitud de envío de formularios/comentarios POST

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

  • ¿Ha iniciado sesión el usuario? (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 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 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.
El enfoque habitual suele ser: CDN estático + almacenamiento en caché de origen/almacenamiento en caché de objetos; el HTML solo se almacena en caché para el visitante.

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é es más probable que se produzcan accidentes en el comercio electrónico?

  • Una vez que el usuario tiene una cesta de la compra, una sesión activa 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? (cookie)
  • Moneda/Tasa impositiva (si procede)

7. Información sobre riesgos

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

  • Error de almacenamiento en caché de recursos estáticos: suele deberse a hojas de estilo o imágenes obsoletas
  • 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 surten efecto (el más común)

A medida que la cadena de caché se vaya alargando, serán cada vez más frecuentes los casos en los que los cambios no surtan 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, 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 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 ¿De verdad ocupaban los recursos estáticos 1 TB y 219 TB?

  • ¿Los archivos de imágenes, CSS y JavaScript provienen del dominio CDN o de un nodo periférico?
  • ¿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?
  • ¿Se ha observado una disminución en el número de solicitudes al servidor de origen o en 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?
  • ¿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 volver al origen, errores 5xx, problemas de acceso intermitentes
  • Por lo general, esto indica: capacidad insuficiente del servidor, reglas incorrectas, activación de los límites de velocidad o problemas con la conexión al servidor de origen

9. Solución de problemas cuando las actualizaciones no surten efecto (convirtiendo la “magia negra” en un proceso paso a paso)

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 principal: CDN sigue accediendo a la caché antigua

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

Escenario C: Tras sobrescribir una imagen con el mismo nombre de archivo, la imagen anterior sigue apareciendo
Este es un problema clásico causado por la caché del navegador, junto con la caché de 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 requiere el almacenamiento en caché: es necesaria una estrategia de actualización controlada; de lo contrario, la publicación será incontrolada

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 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é
  • Comprueba si la clave de caché ignora variantes de clave como “Modo de usuario cookie/Idioma/Moneda”

10. Recomendaciones

Cloudflare

  • Proxy inverso integrado
  • Ideal para: un comienzo sin complicaciones
  • Puntos clave: Estrategia de control de versiones para gestionar las actualizaciones; Almacenamiento en caché de HTML desde la perspectiva del visitante
  • Riesgo: Las páginas dinámicas deben omitirse

Tencent Cloud International EdgeOne

  • Proxy inverso integrado
  • Ideal para: organizaciones que buscan una conectividad sólida y una integración perfecta con nodos en China continental
  • 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
  • Riesgos: Las reglas, los registros y los límites de los subdominios requieren una planificación minuciosa; se recomienda actuar con precaución al utilizar el almacenamiento en caché de 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

  • Tracción estática 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 implementa correctamente, te encontrarás con frecuencia con “recursos heredados”

11. Recomendaciones para la acción

  1. En primer lugar, elige la arquitectura: integración de proxy inverso (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. 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 sobre WordPress CDN

1. ¿Por qué sigue siendo lento aunque esté usando el CDN?

La razón más común no es que CDN sea ineficaz, sino que el cuello de botella no se encuentra 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 sistema: Problemas habituales con los scripts de publicidad, estadísticas y servicio al cliente → El código CDN no suele servir de ayuda; hay que reducir o retrasar la 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

El CDN se encarga de proporcionar “recursos optimizados” con mayor rapidez; los servidores de origen lentos, las imágenes de gran tamaño y los scripts lentos deben abordarse por separado.

2. ¿Por qué los usuarios siguen viendo la versión antigua aunque ya haya actualizado el CSS, el JS y las imágenes?

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 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 archivos con el mismo nombre” y que, en su lugar, utilices nuevos nombres de archivo o nuevas rutas (lo cual te ofrece un mayor control).

3. ¿Necesito almacenar en caché el HTML? ¿No tendría sentido no hacerlo?

No es algo que se exija necesariamente.

Para muchos sitios web, el mayor valor del CDN reside en:

  • 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é el contenido incorrecto.

El enfoque seguro:

  1. Empieza con una posición estática: CDN (bajo riesgo, alto rendimiento)
  2. Asegúrate de que la política de control de versiones y la lista de verificación de validación funcionen correctamente
  3. Reevaluar si se debe almacenar en caché el HTML (empezando por el “modo visitante”)

4. ¿Puede la tienda en línea utilizar CDN? ¿Afectará esto al carrito de compras?

Se puede servir, y de hecho se debe servir (al menos en el caso de los recursos estáticos), pero se debe evitar el almacenamiento en caché de las páginas destinadas a los usuarios.

  • 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 puedo configurar un sitio web multilingüe y multidivisa con CDN para que los idiomas y los precios no se mezclen?

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? (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. ¿Debería optar por una solución de proxy inverso (Cloudflare/EdgeOne/ESA) o por un servidor de extracción estático (bunny)?

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

  • Me gustaría cubrir HTTPS + CDN + seguridad básica de una sola vez, con la opción de ampliar más adelante a reglas y 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:Tracción estática CDN(p. ej., conejito)

Si no estás seguro, la recomendación predeterminada es:Primera imagen estática 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 utilizar la versión gratuita directamente en un sitio web activo?

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”.

  • ¿Estaría dispuesto a aceptar la opción gratuita?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 puedo estar seguro de que el CDN realmente funciona y no se trata solo de un efecto placebo?

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

  1. Comprueba si se devuelven recursos estáticos desde CDN(¿Ha cambiado la fuente de las imágenes, el CSS o el JS?)
  2. Comprueba si la tasa de visitas y la tasa de retorno han mejorado(Solo el aumento de la tasa de acierto y la reducción del costo de maná se consideran ventajas reales)
  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 cuelga a menudo la función de aceleración de 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 configurar primero CDN?

El orden que se suele recomendar es:

  1. Capa del servidor de origen: Asegúrate primero de que el complemento de almacenamiento en caché y la infraestructura de alojamiento sean estables (reducción del TTFB, reducción de la carga del backend)
  2. Capa de recursos: Optimiza las imágenes para reducir su tamaño de archivo
  3. Capa de entrega: CDN – Entrega de recursos más rápida y fiable

Si hay algo que te gustaría hacer ahora mismo, pero te preocupa que pueda salir mal:En primer lugar, la configuración estática: CDN (Fase 1), que ofrecen rendimientos estables y el menor riesgo.