Cache, CDN ou headless : quelle solution pour accélérer votre site ?

Passer en headless ne rend pas une page rapide à lui seul : la vitesse dépend du code envoyé au navigateur et du cache. L’architecture n’est qu’une partie de la performance technique d’une page de destination. Une page lente peut augmenter le risque d’abandon après un clic sur vos annonces Google Ads. Mais la lenteur seule ne prouve pas que vous y perdez du budget. Vérifiez d’abord si l’offre et son message, les erreurs, l’appareil ou le type de trafic n’expliquent pas mieux les abandons.

Deux mesures : l’affichage et la réaction au clic

Tous deux font partie des Core Web Vitals de Google. Le but est de les ramener sous leurs seuils, sans faire baisser les contacts ni dégrader l’accessibilité ou la sécurité.

PageSpeed Insights affiche, quand il en dispose, les mesures de vrais visiteurs de Chrome sur 28 jours glissants, à côté d’un test simulé. Les mesures réelles montrent si le problème existe, et le test simulé aide à en trouver la cause. Si la page a trop peu de visites, faites installer votre propre mesure.

Une réaction lente au clic peut venir d’un long calcul du navigateur, d’une page très chargée ou d’un téléphone modeste. Une migration peut alléger ce travail, ou au contraire ajouter des scripts. Pour réduire l’INP d’un formulaire qui répond mal, commencez par l’étape la plus longue, repérée dans un enregistrement technique de cette interaction.

Trouver l’étape qui retarde l’affichage

Google découpe le LCP en quatre étapes, et chacune se corrige à un endroit différent.

• Le délai avant le premier octet (TTFB) inclut les redirections, la connexion et le serveur. Examinez le réseau et le cache.
• Le repérage de l’élément principal se corrige en le plaçant, prioritaire, dès le code initial de la page.
• Le téléchargement de cet élément se corrige par son format, ses dimensions et la compression.
• L’affichage final se corrige dans les styles, les polices et les scripts qui le retardent.

Un cache raccourcit surtout la première étape, la réponse du serveur. Un CDN, un réseau de serveurs proches du visiteur, peut aussi accélérer le téléchargement quand les visiteurs sont loin. Aucun des deux ne corrige une image repérée tard ou un style qui bloque l’affichage.

Quand le délai du serveur compte vraiment

Google conseille un délai de réponse de 0,8 seconde ou moins au 75e centile. Ce repère sert au diagnostic, car ce délai ne fait pas partie des Core Web Vitals. Un délai plus long peut donc coexister avec un bon LCP.

Un test fait avec un cache déjà rempli n’indique rien sur le visiteur qui tombe sur un cache vide. À l’inverse, beaucoup de réponses en cache peuvent masquer un serveur lent. Faites mesurer la page avec le cache rempli, avec le cache vide et en le contournant, puis relevez à part le temps de calcul du serveur.

Ce qu’il faut mesurer avant de choisir

1. Les vraies visites. Comparez mobile et ordinateur, puis découpez par pays, par réseau et par type de trafic.
2. Le déroulé du chargement. Chaque étape se suit sur plusieurs vitesses de connexion, des redirections jusqu’aux scripts.
3. Les caches. Relevez si chaque réponse vient du cache, depuis combien de temps, et le délai du serveur.
4. L’hébergement. Croisez ces mesures avec les journaux du serveur, sa charge, ses erreurs et les mises en ligne.

Un score PageSpeed isolé n’indique donc pas si la faute vient de l’hébergement ou du code. Un bon audit mesure avant et après dans les mêmes conditions, puis compare le gain au coût et au risque.

Dans quel ordre corriger la page

Voici l’ordre que je vous conseille ; sautez les étapes que vos mesures écartent.

1. La référence. Notez le LCP, l’INP et leurs étapes au 75e centile, avec un test simulé que vous pourrez refaire.
2. L’étape qui domine. Cherchez d’abord une correction dans l’étape qui contribue le plus au LCP.
3. Les images. L’image principale se place dans le code initial et ne se charge jamais en différé ; le chargement différé est réservé aux images plus bas dans la page.
4. La compression, avec mesure. Gzip ou Brotli allègent les fichiers texte, mais une compression trop forte consomme du calcul serveur.
5. Peu de préchargements. Seule une ressource vraiment critique mérite d’être chargée en avance, car les préchargements se partagent la connexion.
6. L’architecture en dernier. N’en changez que si les besoins du projet ou un gain mesuré justifient le coût.

Le cache : garder une copie prête à servir

Un cache évite de refaire un travail déjà fait, et il peut se placer à plusieurs endroits.

• Le navigateur du visiteur évite de retélécharger un fichier déjà reçu.
• Le serveur, pour la page entière, évite de reconstruire la page à chaque visite.
• Le serveur, pour un morceau de page, évite de refaire un calcul ou une lecture en base de données.
• Le CDN, partagé entre visiteurs, évite le trajet jusqu’à votre serveur et le soulage.

Un fichier dont le nom change à chaque version se garde longtemps en cache. Pour une page qui doit rester à jour, faites plutôt redemander au serveur si elle a changé.

Une réponse personnelle ou sensible ne doit jamais entrer dans un cache partagé. La norme HTTP sur le cache réserve la consigne « private » au navigateur du visiteur, et « no-store » interdit la conservation dans les caches HTTP. Excluez les sessions et pages après connexion, les données propres à un client et les envois de formulaire. Aucune règle personnalisée du CDN ne doit contourner ces consignes. Avant d’activer le cache, faites tester automatiquement qu’un compte ne peut pas recevoir la réponse d’un autre.

Comment choisir et contrôler un CDN

Si le CDN possède une réponse réutilisable, il la sert directement. Sinon, il contacte votre serveur pour la récupérer ou la vérifier. Le gain dépend donc de l’éloignement des visiteurs, de la part de réponses en cache et des règles posées. Un CDN mal réglé peut même ajouter une étape.

Ne le choisissez pas sur la promesse d’une offre gratuite. Je compare d’abord la couverture des pays utiles et la mise en cache des pages elles-mêmes, puis l’effacement ciblé des copies et les journaux. Le support, le tarif et la possibilité de revenir en arrière comptent aussi.

La documentation de Cloudflare, consultée le 25 juillet 2026, indique que ce CDN ne garde pas par défaut les pages HTML ni les données JSON. Activer ce service ne suffit donc pas à accélérer la page elle-même. Une règle de cache sur mesure peut changer ce comportement, et elle se vérifie à part.

Les options de compression ou d’optimisation d’images aident quand le ralentissement vient de là. Elles ne remplacent pas l’examen des scripts tiers réellement chargés par la page. Surveillez ensuite la part de réponses en cache et les erreurs par région.

Mettre à jour le cache sans casser le site

Effacer les copies du serveur et du CDN ne vide pas forcément le navigateur du visiteur. Après chaque mise en ligne, vérifiez la version servie depuis plusieurs régions. Un effacement complet vide tout le cache d’un coup, et votre serveur risque alors de recevoir toutes les demandes en même temps. Remplissez ensuite le cache à l’avance pour les seules pages utiles.

Pendant un test A/B, chaque visiteur doit retrouver sa version à chaque passage, sans que le cache mélange les groupes. Si la version attribuée n’entre pas dans la règle de cache, il faut contourner le cache pour cette page. Préparez aussi les deux versions de la même façon avant de mesurer, sinon l’une démarre avec un cache déjà rempli.

Ce que change vraiment un site headless

Dans un site headless, le logiciel qui gère vos contenus (le CMS) est séparé de la partie visible du site, qui reçoit ces contenus par une API. Cette séparation change les outils et les responsabilités. Elle ne garantit ni la vitesse, ni le référencement, ni le confort de publication.

Où la page est fabriquée

• À l’avance : la page est prête avant la visite, mais il faut la tenir à jour, et elle peut envoyer trop de code.
• Sur le serveur, à chaque visite : les données sont fraîches, mais le serveur travaille à chaque passage.
• À l’avance, puis rafraîchie : un visiteur peut recevoir l’ancienne version pendant le rafraîchissement.
• Dans le navigateur : le téléphone construit la page. Un code trop lourd peut dégrader l’INP.
• Un site classique bien mis en cache demande moins de connexions à maintenir entre logiciels.

Préparer une page à l’avance n’est pas propre au headless : un générateur de site statique le fait sans CMS séparé. Construire la page dans le navigateur lui confie davantage de travail, selon le code utilisé. Comparez deux projets précis plutôt que deux étiquettes.

Le vrai coût d’une migration

Au-delà du devis initial, faites chiffrer le coût complet, poste par poste.

• Le socle : développement, hébergement, maintenance et fonctions propres à votre activité.
• Le contenu : organisation des contenus, formulaires et aperçu avant publication.
• La conformité : redirections, mesure des résultats, cookies, accessibilité et référencement.
• L’exploitation : sécurité, caches, journaux et alertes, sauvegardes, retour arrière et astreinte.

Avant la bascule, faites tester les tâches quotidiennes de ceux qui publient, puis les adresses et les titres des pages pour le référencement. Le contrat doit nommer qui maintient la partie visible. Choisissez entre headless et site classique d’après le travail réel de votre équipe.

Une page plus rapide ne vend pas automatiquement plus. L’indicateur qui compte se choisit à l’avance, et l’effet se mesure sur un cycle de vente complet, par appareil et par source de trafic. Isolez ce qui a changé en même temps, comme l’offre ou le trafic Google Ads. Pour une refonte, laissez si possible une part des visiteurs sur l’ancienne version pour comparer.

Cache, CDN ou headless : quelle solution choisir ?

Le prix de la solution se discute une fois le problème localisé par vos mesures.

Commencer petit, puis élargir

Une page qui reçoit du trafic Google Ads accueille des visiteurs acquis avec votre budget publicitaire. La plus petite modification qui traite l’étape dominante passe en premier ; on n’élargit qu’après avoir revu les vraies visites sur une période suffisante.

Questions fréquentes

Vincent Duquesne

Expert Google Ads Certifié depuis 2011 : j’ai audité et restructuré des centaines de comptes dans des dizaines de thématiques différentes. +20M€ gérés.

Google Partner Premier 2026