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

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

  • Capa del servidor de origenServidor / PHP / Base de datos / Plugin de caché — Determina el TTFB y la carga del backend
  • Capa de recursos: Optimización de imágenes: determina el tamaño de descarga y la velocidad de carga de las imágenes grandes en la primera pantalla
  • Capa de entrega: CDN — 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 los servidores 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 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
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 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”: 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 hasta el HTML de la página de inicio se genera muy lento, el usuario igual sentirá que “abre lento”. En ese caso, prioriza volver a: hosting/plugin de caché/optimización de base de datos.

1.2.2 La imagen en sí es demasiado grande
CDN no puede 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 que tardan en cargarse
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.

Recomendaciones

Primero deja bien configuradas la capa del sitio de origen y la capa de recursos, y luego haz CDN; el efecto será más evidente 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
  • 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 sola vez
  • ¿Estaría dispuesto a confiar la gestión de la resolución de su nombre de dominio y las capas de proxy a una única plataforma?
  • 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” estático puro (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”

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

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 ajustaran 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 el HTML en caché, las páginas de comercio electrónico, de miembros y personalizadas deben excluirse estrictamente; de lo contrario, pueden surgir problemas graves (consulte la lista de casos a continuación).

Notas：

  • 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 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 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 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: 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 fácil de manejar.

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 enfoque más confiable?

  • 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
  • La purga (borrar caché) requiere que la actives manualmente; es fácil que el alcance no sea preciso y hay retrasos en la propagación entre nodos. Además, hacer purgas con frecuencia reduce la tasa de aciertos, aumenta las solicitudes al origen y agrava la inestabilidad.

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 或 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 nuevos nombres de archivo o rutas (especialmente en el caso de los banners de la página de inicio y las imágenes promocionales).
  3. Tras la implementación, utilice la lista de verificación de validación para confirmar que se han cumplido los requisitos
    • ¿Los recursos estáticos provienen de CDN?
    • ¿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 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 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 suele fallar al iniciarse por primera vez es que los usuarios intentan aprovechar al máximo todas sus funciones desde el principio.

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

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

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

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

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

  • Contenido mixto (la página HTTPS carga el recurso 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 que marca la diferencia entre “CDN hecho de manera profesional o no”.

Una regla inquebrantable:

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

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

  • Caché del navegador: es posible que tengas archivos CSS/JS antiguos almacenados en la caché local
  • Caché de CDN: es posible que los nodos perimetrales hayan almacenado en caché recursos antiguos
  • Caché del sitio de origen: el plugin de caché o la caché del servidor puede 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 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 pongas en caché el HTML. Primero, CDN estático + plugin de caché del servidor de origen.

Al almacenar HTML en caché, hay dos principios:

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

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

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 (como los parámetros cambian mucho, mejor no guardar en caché por ahora)
  • Solicitud POST de envío de formulario/comentario

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

  • Inició 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 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 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 para miembros / Plataformas 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.
La práctica más segura suele ser: caché estática CDN + caché del sitio de origen/caché de objetos; el 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 otras secciones relacionadas 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 caché de recursos estáticos: suelen ser estilos/imágenes antiguas
  • Error de almacenamiento en caché de HTML: podría afectar al contenido, a las carritos de la compra o a las cuentas; se trata de un problema grave

Riesgo 2: Las actualizaciones no surten efecto (el más común)

Después de que la cadena de caché se hace más larga, será más común que “lo cambié y no surtió efecto”:

  • Se da prioridad a los cambios en el número de versión o el nombre del 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 la versión comercial completa

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

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

  • ¿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 producido una disminución en el número de solicitudes al servidor de origen o en el número de conexiones (en particular, solicitudes 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 en todo momento las páginas relacionadas con el carrito de compras, el proceso de pago 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 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 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 antigua (oculta/antigua también en otros dispositivos)
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 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 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 debe almacenarse en caché: se necesita una estrategia de actualización controlable; de lo contrario, la publicación queda fuera de control.

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 usuario (como las de la cesta de la compra, el proceso de pago y la cuenta) se han almacenado en caché
  • Verifica si la Cache Key omite variantes clave como “estado 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 un acceso integrado a los nodos de 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
  • Riesgo: hay que planificar las cuotas de reglas/registros/subdominios; usar con cuidado la caché HTML

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

  • Proxy inverso integrado
  • Gratis: Las cuentas del sitio internacional se pueden 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 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 implementa bien, te encontrarás con frecuencia con “recursos antiguos”

11. Recomendaciones de 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: aciertos, solicitudes de origen, actualizaciones, omisiones dinámicas y tasa de error
  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 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 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 imprescindible.

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 HTML en caché Es cierto que las ventajas potenciales 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. 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 del modo de usuario: No almacenes en caché el HTML de las páginas relacionadas con el carrito de compras, el proceso de pago y la cuenta
  • Siempre y cuando no almacenes estas páginas en caché en formato HTML, el riesgo de que se produzcan problemas relacionados con la “cesta de la compra cruzada” o las «cuentas cruzadas» 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:Pull estático 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 “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 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 han mejorado la tasa de visitas y la tasa de retorno(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; indica que el enlace está bajo control)

Si no cumples con el punto 3, cuantas más optimizaciones realices más adelante, más probable será que te encuentres con actualizaciones que no surtan efecto; por lo tanto, te recomendamos que des prioridad a poner al día tu estrategia 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 se ha registrado, solo podrá 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 apetece 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.