Pull y Push: dos formas de alimentar el edge
Con el modelo Pull, cdn.com.tr obtiene cada objeto desde tu origin existente la primera vez que se solicita, y luego lo cachea en el edge durante el TTL que definiste; no cambias nada en el origin salvo el DNS. Con el modelo Push subes los assets al storage de cdn.com.tr y el edge sirve directamente desde allí, lo cual es ideal cuando no quieres mantener un servidor origin en línea en absoluto. La mayoría de los clientes empieza con Pull porque no requiere migración, y después mueve el contenido multimedia pesado a Push u Object Storage. Ambos modelos comparten las mismas reglas de caché, herramientas de purge y reportes.
Reglas de caché, TTL y cache keys que tu controlas
El verdadero trabajo de un CDN es decidir que es seguro cachear y por cuánto tiempo, y eso es exactamente lo que expone el panel. Defines TTLs por ruta o extensión de archivo, eliges si respetar o sobrescribir el header Cache-Control del origin, y controlas que query strings y cookies forman parte de la cache key, de modo que /list?page=2 y /list?page=3 se cacheen por separado mientras que los parámetros de tracking no fragmenten el caché. Ajustar bien la cache key es lo que convierte un hit ratio bajo en uno alto, y los reportes lo hacen visible para que puedas ajustarlo en lugar de adivinar.
Descarga y shielding del origin
Cada solicitud respondida desde el edge es una solicitud que tu origin nunca ve, de modo que una página de contenido concurrida que antes bombardeaba tu servidor con cientos de hits de imágenes y assets se reduce a un puñado de fetches al origin por ventana de TTL. Como los visitantes resuelven hacia el edge en lugar de la IP de tu origin, el origin también deja de recibir tráfico directo, lo que reduce tanto el costo de ancho de banda como la exposición. Esta descarga es lo que mantiene un sitio en pie cuando una campaña, un pico de noticias o un compartido viral en redes sociales envía de golpe una avalancha de visitantes.
Optimización automática de imágenes con WebP
Las imágenes suelen ser la parte más pesada de una página, y enviar archivos JPEG o PNG a tamaño completo a cada visitante desperdicia ancho de banda y ralentiza el renderizado. cdn.com.tr puede convertir de forma transparente las imágenes elegibles a WebP en el edge y servir la versión más liviana a los navegadores que anuncian soporte, mientras que los navegadores que no lo hacen reciben el original intacto. No necesitas reexportar tu biblioteca de medios ni cambiar tu HTML; la optimización ocurre en el camino de entrega, y el ahorro se refleja directamente en el peso de la página y el tiempo de carga.
Cachear contenido dinámico de forma segura
El caché no es solo para archivos estáticos. Muchas páginas que se sienten dinámicas, como listados de categorías, páginas de producto o cuerpos de artículos, cambian solo cada pocos minutos y se pueden micro-cachear con un TTL corto para absorber tráfico manteniendose frescas. cdn.com.tr te permite cachear estas respuestas con reglas que excluyen sesiones con inicio de sesión y rutas personalizadas, de modo que los visitantes anonimos se sirven desde el edge mientras que el carrito o la página de cuenta de un usuario siempre va al origin. El resultado es velocidad de nivel CDN en páginas que la mayoría de las plataformas dejan sin cachear.
Medir la ganancia: hit ratio y tiempo de carga
No puedes mejorar lo que no puedes ver, así que el panel reporta el cache hit ratio, los bytes servidos desde el edge frente al origin, y el estado de caché por respuesta. Un sitio saludable con mucho contenido estático debería alcanzar un hit ratio alto una vez que el caché se calienta; un ratio bajo generalmente señala una cache key que incluye una cookie o query string volátil, lo cual puedes corregir después en las reglas. Observar estos números tras cada cambio cierra el ciclo entre la configuración y la velocidad real que sienten tus visitantes.
Cómo configurarlo, paso a paso
Agrega tu dominio a la cuenta del CDN
En el panel abre el área de dominios, agrega tu hostname (por ejemplo www.example.com) y elige si cdn.com.tr actúa como origin Pull contra tu servidor existente o como destino Push al que subes archivos. Para la mayoría de los sitios, Pull es el inicio más rápido: no se necesita migrar archivos.
Apunta el DNS al edge
Actualiza el CNAME (o el registro apex si alojas tu DNS con nosotros) para que el tráfico resuelva hacia el edge de cdn.com.tr en lugar de la IP de tu origin. Una vez que la resolución se propaga, cada solicitud entra primero por un nodo edge y se responde desde caché cuando es posible.
Define tus reglas de caché
Define TTLs por ruta o extensión: TTLs largos (días) para assets versionados como /assets/*.css, /*.js, imágenes y fuentes; reglas cortas o de bypass para /cart, /checkout, o cualquier cosa con cookie de sesión. Puedes respetar el header Cache-Control del origin o sobrescribirlo desde el panel.
Activa la optimización de imágenes
Activa la conversión automática a WebP para que las imágenes JPEG y PNG se recodifiquen y se sirvan en un formato más liviano a los navegadores que lo acepten, manteniendo el original como fallback. Esto normalmente reduce el peso de las imágenes de forma sustancial sin tocar tus archivos fuente.
Verifica que el caché esté funcionando
Carga una página e inspecciona los headers de respuesta para ver el estado de caché (HIT/MISS) y la edad. Una segunda solicitud a la misma URL debería devolver un HIT servido desde el edge. Usa los reportes del panel para ver cómo sube el cache hit ratio a medida que el edge se calienta.
Purga cuando el contenido cambie
Después de un deploy o una edición de contenido, purga las URLs afectadas (o todo) desde el panel o la purge API para que los visitantes reciban de inmediato la nueva versión en lugar de esperar a que expire el TTL.
Escenarios de ejemplo
Un sitio de noticias o blog sirve sus imágenes, CSS y JavaScript desde el edge con TTLs largos, reduciendo drásticamente el tráfico al origin y recortando el tiempo de carga para lectores lejos del origin.
Durante una venta flash, las páginas de listado de productos se micro-cachean y los assets estáticos se cachean por completo, de modo que un pico repentino de tráfico se absorbe en el edge en lugar de saturar el origin de la tienda.
Un proveedor distribuye instaladores y paquetes de actualización mediante storage Push en el edge, entregando archivos grandes rápidamente a los usuarios mientras protege al origin de picos de ancho de banda.
Preguntas frecuentes
Cómo sé si una solicitud se sirvió desde caché?
Cada respuesta lleva un header de estado de caché que muestra HIT (servido desde el edge) o MISS (obtenido del origin), además de un valor de edad. Carga una URL dos veces: la segunda solicitud a un recurso cacheable debería devolver un HIT. Los reportes del panel también agregan esto en un cache hit ratio general.
El caché servirá contenido desactualizado después de que actualice mi sitio?
Los objetos cacheados viven solo hasta que expira su TTL, pero no tienes que esperar. Purga las URLs cambiadas o toda la zona desde el panel o la purge API justo después de un deploy, y el edge obtendrá copias frescas en la siguiente solicitud mientras sigue sirviendo todo lo demás desde caché.
Puedo cachear páginas que usan cookies o query strings?
Sí, con control. Tú decides que cookies y parámetros de query forman parte de la cache key, de modo que los esenciales crean variantes cacheadas separadas mientras que los parámetros de tracking se ignoran. Las solicitudes de sesión o con inicio de sesión pueden configurarse para saltarse el caché por completo, de modo que el contenido personalizado siempre llegue al origin.
La conversión a WebP cambia mis archivos de imagen originales?
No. La conversión ocurre en el camino de entrega. Tus originales almacenados quedan intactos; el edge genera y sirve una variante WebP a los navegadores que la soportan y usa el formato original para los que no.
Qué pasa si mi servidor origin se cae?
Todo lo que ya está cacheado en el edge sigue sirviendose a los visitantes durante la ventana de TTL, de modo que una interrupción breve del origin no necesariamente deja tu contenido estático fuera de línea. Las solicitudes de objetos no cacheados o expirados si necesitaran el origin, lo cual es otra razón para mantener TTLs generosos en assets estables.
Tengo que mover mis archivos para usar el CDN?
No con el modelo Pull. Conservas tu servidor origin existente y solo cambias el DNS para que el edge se ubique frente a el, obteniendo y cacheando contenido bajo demanda. El storage Push es opcional y util cuando quieres que el edge sirva medios sin ningún origin en absoluto.