Pull et Push : deux façons d'alimenter l'edge
Avec le modèle Pull, cdn.com.tr récupère chaque objet depuis votre origine existante lors de sa première requête, puis le met en cache à l'edge pour la durée du TTL que vous avez définie ; vous ne changez rien sur l'origine à part le DNS. Avec le modèle Push, vous téléversez vos assets dans le stockage cdn.com.tr et l'edge les sert directement depuis là, ce qui est idéal quand vous ne voulez pas garder de serveur d'origine en ligne du tout. La plupart des clients démarrent avec Pull car cela ne nécessite aucune migration, puis déplacent plus tard les médias volumineux vers Push ou l'Object Storage. Les deux modèles partagent les mêmes règles de cache, outils de purge et rapports.
Règles de cache, TTL et clés de cache sous votre contrôle
Le véritable travail d'un CDN consiste à décider ce qu'il est sûr de mettre en cache et pendant combien de temps, et c'est exactement ce que le panel expose. Vous définissez les TTL par chemin ou extension de fichier, choisissez de respecter ou de surcharger l'en-tête Cache-Control de l'origine, et contrôlez quelles query strings et quels cookies font partie de la clé de cache, afin que /list?page=2 et /list?page=3 soient mis en cache séparément tandis que les paramètres de tracking ne fragmentent pas le cache. Bien régler la clé de cache est ce qui transforme un faible taux de hit en un taux élevé, et les rapports le rendent visible pour que vous puissiez ajuster au lieu de deviner.
Déchargement et protection de l'origine
Chaque requête servie depuis l'edge est une requête que votre origine ne verra jamais, si bien qu'une page de contenu très fréquentée, qui martelait auparavant votre serveur avec des centaines d'appels d'images et d'assets, se réduit à une poignée de requêtes d'origine par fenêtre de TTL. Comme les visiteurs se résolvent vers l'edge plutôt que vers l'IP de votre origine, celle-ci cesse également de recevoir du trafic direct, ce qui réduit à la fois le coût de bande passante et l'exposition. Ce déchargement est ce qui permet à un site de tenir debout lors d'une campagne, d'un pic d'actualité ou d'un partage viral qui envoie soudainement une vague de visiteurs.
Optimisation d'image automatique : AVIF et WebP
L'optimisation d'image est un interrupteur pour tout votre compte ou pour une seule règle de diffusion. L'edge convertit les images JPEG et PNG en WebP, ou en AVIF et WebP si vous choisissez WebP + AVIF pour le compte, et chaque navigateur reçoit un format qu'il accepte ; les navigateurs qui n'acceptent ni l'un ni l'autre reçoivent l'image dans son format d'origine. Avec WebP + AVIF, la réponse vient de la même URL, avec Vary: Accept ; avec WebP seul, les navigateurs qui acceptent le WebP sont redirigés vers une copie .webp. Dans les deux cas, votre HTML garde les mêmes URL d'images. En pleine taille, une image nouvellement convertie n'est envoyée que si elle est plus légère que l'original. Si une conversion échoue, l'edge sert l'image d'origine à la place. Le traitement est décompté de votre quota mensuel.
Vous choisissez le format une fois pour le compte : WebP, ou WebP + AVIF. Mesuré le 5 octobre 2026 avec l'optimiseur d'images de CDN.com.tr, une photo d'actualité JPEG de 262 025 octets part en 86 936 octets d'AVIF, et une capture d'écran PNG de 105 078 octets en 27 942. Votre médiathèque reste telle quelle. Notre guide AVIF ou WebP donne toutes les mesures, et le vérificateur de format d'image montre ce que vos propres pages envoient aujourd'hui. Pour le fonctionnement général du choix du format, du redimensionnement et de la mise en cache, voyez le guide du CDN d'images.
Mettre en cache du contenu dynamique en toute sécurité
Le cache ne concerne pas uniquement les fichiers statiques. De nombreuses pages qui semblent dynamiques, comme des listes de catégories, des fiches produit ou des corps d'article, ne changent que toutes les quelques minutes et peuvent être micro-cachées avec un TTL court pour absorber le trafic tout en restant fraîches. cdn.com.tr vous permet de mettre en cache ces réponses avec des règles qui excluent les sessions connectées et les chemins personnalisés, afin que les visiteurs anonymes soient servis depuis l'edge tandis que le panier ou la page de compte d'un utilisateur va toujours à l'origine. Le résultat est une vitesse de niveau CDN sur des pages que la plupart des plateformes laissent non mises en cache.
Mesurer le gain : taux de hit et temps de chargement
On ne peut pas améliorer ce qu'on ne voit pas, c'est pourquoi le panel rapporte le taux de hit du cache, les octets servis depuis l'edge par rapport à l'origine, et le statut de cache par réponse. Un site statique en bonne santé devrait atteindre un taux de hit élevé une fois le cache réchauffé ; un taux faible pointe généralement vers une clé de cache incluant un cookie ou une query string volatile, ce que vous pouvez alors corriger dans les règles. Observer ces chiffres après chaque changement referme la boucle entre la configuration et la vitesse réelle ressentie par vos visiteurs.
Comment le configurer, étape par étape
Ajoutez votre domaine au compte CDN
Dans le panel, ouvrez la zone des domaines, ajoutez votre nom d'hôte (par exemple www.example.com), et choisissez si cdn.com.tr agit comme une origine Pull vis-à-vis de votre serveur existant ou comme une cible Push vers laquelle vous téléversez des fichiers. Pour la plupart des sites, Pull est le démarrage le plus rapide : aucune migration de fichiers n'est nécessaire.
Pointez le DNS vers l'edge
Mettez à jour le CNAME (ou l'enregistrement apex si vous hébergez votre DNS chez nous) afin que le trafic se résolve vers l'edge de cdn.com.tr plutôt que vers l'IP de votre origine. Une fois la résolution propagée, chaque requête entre d'abord dans un edge node et est servie depuis le cache lorsque c'est possible.
Définissez vos règles de cache
Définissez des TTL par chemin ou par extension : des TTL longs (plusieurs jours) pour les assets versionnés comme /assets/*.css, /*.js, les images et les polices ; des règles courtes ou de contournement pour /cart, /checkout, ou tout ce qui contient un cookie de session. Vous pouvez respecter l'en-tête Cache-Control de l'origine ou le surcharger depuis le panel.
Activez l'optimisation d'image
Activez l'optimisation d'image pour tout le compte ou pour une seule règle de diffusion, puis choisissez le format d'image du compte : WebP, ou WebP + AVIF. Les images JPEG et PNG sont converties à l'edge ; vos fichiers source restent intacts.
Vérifiez que le cache fonctionne
Chargez une page et inspectez les en-têtes de réponse pour connaître le statut de cache (HIT/MISS) et l'âge. Une deuxième requête vers la même URL devrait renvoyer un HIT servi depuis l'edge. Utilisez les rapports du panel pour observer le taux de hit du cache grimper à mesure que l'edge se réchauffe.
Purgez lors d'un changement de contenu
Après un déploiement ou une modification de contenu, purgez les URL concernées (ou l'ensemble) depuis le panel ou l'API de purge, afin que les visiteurs obtiennent immédiatement la nouvelle version au lieu d'attendre l'expiration du TTL.
Exemples de scénarios
Un site d'actualités ou un blog sert ses images, son CSS et son JavaScript depuis l'edge avec des TTL longs, réduisant fortement le trafic vers l'origine et diminuant le temps de chargement des pages pour les lecteurs éloignés de l'origine.
Lors d'une vente flash, les pages de listing produits sont micro-cachées et les assets statiques sont entièrement mis en cache, si bien qu'un pic de trafic soudain est absorbé à l'edge au lieu de submerger l'origine de la boutique.
Un éditeur distribue des installateurs et des paquets de mise à jour via le stockage Push à l'edge, livrant rapidement de gros fichiers aux utilisateurs tout en protégeant l'origine des pics de bande passante.
Questions fréquentes
Comment savoir si une requête a été servie depuis le cache ?
Chaque réponse porte un en-tête de statut de cache indiquant HIT (servi depuis l'edge) ou MISS (récupéré depuis l'origine), ainsi qu'une valeur d'âge. Chargez une URL deux fois : la deuxième requête vers une ressource cacheable devrait renvoyer un HIT. Les rapports du panel agrègent également cela en un taux de hit du cache global.
Le cache va-t-il servir du contenu obsolète après une mise à jour de mon site ?
Les objets mis en cache ne vivent que jusqu'à l'expiration de leur TTL, mais vous n'êtes pas obligé d'attendre. Purgez les URL modifiées ou toute la zone depuis le panel ou l'API de purge juste après un déploiement, et l'edge récupère des copies fraîches à la prochaine requête tout en continuant à servir tout le reste depuis le cache.
Puis-je mettre en cache des pages qui utilisent des cookies ou des query strings ?
Oui, avec un contrôle total. Vous décidez quels cookies et quels paramètres de query font partie de la clé de cache, de sorte que les essentiels créent des variantes de cache séparées tandis que les paramètres de tracking sont ignorés. Les requêtes de session ou connectées peuvent être configurées pour contourner entièrement le cache, afin que le contenu personnalisé atteigne toujours l'origine.
La conversion WebP ou AVIF modifie-t-elle mes fichiers image d'origine ?
Non. La conversion se produit dans le chemin de diffusion et vos originaux stockés restent intacts. Les navigateurs qui acceptent l'AVIF ou le WebP reçoivent une copie convertie, les autres reçoivent l'image dans son format d'origine, et si une conversion échoue, l'edge sert l'original. Votre HTML garde les mêmes URL d'images.
Que se passe-t-il si mon serveur d'origine tombe en panne ?
Tout ce qui est déjà mis en cache à l'edge continue d'être servi aux visiteurs pendant la fenêtre de TTL, si bien qu'une brève panne d'origine ne met pas nécessairement votre contenu statique hors ligne. Les requêtes vers des objets non mis en cache ou expirés auront toujours besoin de l'origine, ce qui est une raison de plus pour garder des TTL généreux sur les assets stables.
Dois-je déplacer mes fichiers pour utiliser le CDN ?
Pas avec le modèle Pull. Vous conservez votre serveur d'origine existant et changez uniquement le DNS pour que l'edge se place devant, en récupérant et en mettant en cache le contenu à la demande. Le stockage Push est optionnel et utile lorsque vous voulez que l'edge serve des médias sans aucune origine du tout.