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 avec WebP
Les images sont généralement la partie la plus lourde d'une page, et envoyer des fichiers JPEG ou PNG en pleine taille à chaque visiteur gaspille de la bande passante et ralentit le rendu. cdn.com.tr peut convertir de manière transparente les images éligibles en WebP à l'edge et servir la version allégée aux navigateurs qui annoncent leur compatibilité, tandis que les navigateurs qui ne la supportent pas reçoivent l'original intact. Vous n'avez pas besoin de réexporter votre médiathèque ni de modifier votre HTML ; l'optimisation se produit dans le chemin de diffusion, et les gains se traduisent directement en poids de page et en temps de chargement réduits.
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 la conversion WebP automatique afin que les images JPEG et PNG soient réencodées et servies dans un format plus léger aux navigateurs qui l'acceptent, tout en conservant l'original en solution de repli. Cela réduit généralement le poids des images de façon substantielle sans toucher à vos fichiers source.
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 du monde entier.
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 modifie-t-elle mes fichiers image d'origine ?
Non. La conversion se produit dans le chemin de diffusion. Vos originaux stockés restent intacts ; l'edge génère et sert une variante WebP aux navigateurs qui la prennent en charge et revient au format original pour ceux qui ne la supportent pas.
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.