{"id":20746,"date":"2026-08-17T18:25:40","date_gmt":"2026-08-17T16:25:40","guid":{"rendered":"https:\/\/webhosting.de\/http-cache-control-header-richtig-einsetzen-web-optimierung\/"},"modified":"2026-08-17T18:25:40","modified_gmt":"2026-08-17T16:25:40","slug":"utilisation-correcte-de-len-tete-cache-control-dans-http-optimisation-web","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/http-cache-control-header-richtig-einsetzen-web-optimierung\/","title":{"rendered":"Utiliser correctement l'en-t\u00eate HTTP Cache-Control pour une optimisation Web efficace"},"content":{"rendered":"<p>Je vais te montrer comment utiliser l'en-t\u00eate HTTP <strong>Contr\u00f4le du cache<\/strong> utilise de mani\u00e8re cibl\u00e9e pour r\u00e9duire les temps de chargement, limiter le nombre de requ\u00eates et g\u00e9rer efficacement les caches des navigateurs. Vous b\u00e9n\u00e9ficiez de consignes claires, de combinaisons judicieuses et de param\u00e8tres pratiques pour le HTML, le CSS, le JS, les images et les API \u2013 sans avoir \u00e0 t\u00e2tonner, mais avec <strong>concr\u00e8tes<\/strong> En quelques gestes.<\/p>\n\n<h2>Points centraux<\/h2>\n<p>Les points cl\u00e9s suivants te permettront \u00e0 coup s\u00fbr d'obtenir un r\u00e9sultat rapide et <strong>fiable<\/strong> Strat\u00e9gie de mise en cache.<\/p>\n<ul>\n  <li><strong>max-age<\/strong> en tant que temporisateur : contr\u00f4le la dur\u00e9e de conservation en secondes<\/li>\n  <li><strong>public\/priv\u00e9<\/strong>: d\u00e9finit qui est autoris\u00e9 \u00e0 mettre en cache<\/li>\n  <li><strong>no-cache<\/strong> vs. <strong>no-store<\/strong>: r\u00e9\u00e9duquer plut\u00f4t qu'interdire<\/li>\n  <li><strong>ETag<\/strong> et <strong>Derni\u00e8re modification<\/strong>: Les appels conditionnels permettent d'\u00e9conomiser des donn\u00e9es<\/li>\n  <li><strong>Versionnement<\/strong> + <strong>immuable<\/strong>: caches longues sans vestiges<\/li>\n<\/ul>\n\n<h2>Principes de base : \u00e0 quoi sert l'en-t\u00eate Cache-Control ?<\/h2>\n<p>L'en-t\u00eate contient des instructions qui d\u00e9terminent si, pendant combien de temps et par qui une r\u00e9ponse sera envoy\u00e9e dans le <strong>Cache<\/strong> peut se trouver. Je fais ici la distinction entre les caches client dans le navigateur et les caches partag\u00e9s, tels que les proxys ou les CDN, qui desservent souvent plusieurs utilisateurs et g\u00e9n\u00e8rent ainsi des <strong>Efficacit\u00e9<\/strong> apportent. Alors que l'en-t\u00eate \u201e Expires \u201c, d\u00e9sormais obsol\u00e8te, utilise une date, j'utilise avec \u00ab Cache-Control \u00bb des dur\u00e9es relatives via \u00ab max-age \u00bb, ce qui est moins sujet aux erreurs. Je d\u00e9termine ainsi combien de temps une ressource reste \u00ab \u00e0 jour \u00bb et si elle doit \u00eatre revalid\u00e9e avant d'\u00eatre utilis\u00e9e. Cela me permet de conserver la possibilit\u00e9 de contr\u00f4ler les contenus dynamiques et de conserver tr\u00e8s longtemps les fichiers statiques en local.<\/p>\n<p>Cache-Control s'applique aussi bien aux r\u00e9ponses qu'aux requ\u00eates, ce qui m'est utile pour la revalidation, notamment en association avec ETag ou Last-Modified pour <strong>Conditionnel<\/strong> Requ\u00eates. Je d\u00e9finis par exemple des param\u00e8tres agressifs pour les ressources inchang\u00e9es et des r\u00e8gles prudentes pour le HTML. Cette distinction permet de s'assurer que les requ\u00eates suivantes proviennent autant que possible du cache du navigateur, ce qui r\u00e9duit ainsi la <strong>Charge du serveur<\/strong> diminue. Il est important de mettre en place une coordination bien planifi\u00e9e afin de ne pas bloquer involontairement des ressources ou de les laisser s'\u00e9puiser trop t\u00f4t. En respectant ces principes fondamentaux, on pose les bases pour des temps de chargement courts et des r\u00e8gles claires concernant le comportement du cache.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/weboptimierung-cachecontrol-4732.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Les principales directives expliqu\u00e9es de mani\u00e8re claire<\/h2>\n<p>Avec <strong>max-age<\/strong> Je d\u00e9finis la dur\u00e9e de vie d'une ressource en secondes, \u00e0 compter de sa mise en ligne. Pour les images, les fichiers CSS, JS et les polices, je choisis souvent 31536000 (un an), afin que les visiteurs qui reviennent sur le site utilisent presque tout en local. Pour les pages HTML, je d\u00e9finis une dur\u00e9e plus courte, environ 300 secondes, ou je les associe \u00e0 une revalidation afin que les modifications soient rapidement visibles. Une dur\u00e9e de validit\u00e9 trop longue sans gestion des versions des fichiers conduit facilement \u00e0 la pr\u00e9sence d\u2019anciennes versions dans le cache ; c\u2019est pourquoi je modifie les noms de fichiers \u00e0 chaque mise \u00e0 jour. Je combine ainsi une actualit\u00e9 rigoureuse avec <strong>haute<\/strong> Taux de r\u00e9ussite du cache.<\/p>\n<p>Les directives <strong>public<\/strong> et <strong>priv\u00e9<\/strong> d\u00e9finir qui est autoris\u00e9 \u00e0 mettre en cache. J\u2019attribue le niveau \u00ab Public \u00bb aux contenus non personnalis\u00e9s, afin que les proxys et les CDN puissent \u00e9galement les mettre en cache. J\u2019attribue le niveau \u00ab Priv\u00e9 \u00bb lorsque seul le navigateur de l\u2019utilisateur doit en conserver une copie, par exemple sur les pages de compte. J\u2019\u00e9vite ainsi que des donn\u00e9es personnelles ne se retrouvent dans des caches partag\u00e9s et y <strong>se tromper<\/strong>. Cette distinction permet d'\u00e9viter les d\u00e9sagr\u00e9ments et de prot\u00e9ger les informations sensibles.<\/p>\n<p><strong>no-cache<\/strong> est souvent mal interpr\u00e9t\u00e9 : il n'interdit pas la mise en cache, mais exige une revalidation aupr\u00e8s du serveur avant toute nouvelle utilisation. Cela convient aux contenus qui changent r\u00e9guli\u00e8rement, sans pour autant devoir \u00eatre enti\u00e8rement recharg\u00e9s \u00e0 chaque consultation. Gr\u00e2ce \u00e0 l'ETag ou \u00e0 l'en-t\u00eate \u00ab Last-Modified \u00bb, le client conserve les donn\u00e9es en local et v\u00e9rifie simplement si elles sont toujours \u00e0 jour. J'\u00e9vite ainsi des octets superflus tout en conservant le <strong>Contenu<\/strong> r\u00e9cent. Pour les donn\u00e9es hautement sensibles, \u00ab no-cache \u00bb reste toutefois trop laxiste.<\/p>\n<p><strong>no-store<\/strong> C'est la mesure la plus stricte, car elle interdit tout enregistrement dans le navigateur et dans les proxys. Je l'utilise pour les pages de connexion, les processus de paiement ou les documents contenant des donn\u00e9es confidentielles. Ainsi, aucune copie ne se retrouve dans des dossiers temporaires qui pourraient tomber par inadvertance entre de mauvaises mains. D\u00e8s que j'utilise \u00ab no-store \u00bb, je combine souvent cette option avec \u00ab max-age=0 \u00bb afin d'emp\u00eacher toute r\u00e9utilisation <strong>exclure<\/strong>. Ici, la s\u00e9curit\u00e9 prime sur les performances.<\/p>\n<p><strong>must-revalidate<\/strong> impose une nouvelle requ\u00eate aupr\u00e8s du serveur d\u00e8s que le d\u00e9lai est \u00e9coul\u00e9. En cas de panne du serveur, le cache ne doit pas simplement continuer \u00e0 servir la ressource. Cette directive est adapt\u00e9e aux contextes o\u00f9 la coh\u00e9rence prime sur une strat\u00e9gie de tol\u00e9rance aux pannes souple. Je l\u2019applique lorsque des donn\u00e9es obsol\u00e8tes risqueraient d\u2019entra\u00eener des d\u00e9cisions erron\u00e9es. Cette r\u00e8gle \u00e9tablit clairement <strong>caract\u00e8re contraignant<\/strong> lors du d\u00e9roulement.<\/p>\n\n<h2>Directives avanc\u00e9es pour les caches partag\u00e9s et la r\u00e9silience<\/h2>\n<p>Au-del\u00e0 des param\u00e8tres de base, j'utilise <strong>s-maxage<\/strong>, <strong>stale-while-revalidate<\/strong> et <strong>stale-if-error<\/strong>, afin de g\u00e9rer de mani\u00e8re cibl\u00e9e les serveurs proxy et les CDN et d'assurer une exp\u00e9rience fluide aux utilisateurs, m\u00eame en cas de perturbations. <em>s-maxage<\/em> d\u00e9finit un TTL sp\u00e9cifique uniquement pour les caches partag\u00e9s (les navigateurs l'ignorent). Je peux ainsi, par exemple, limiter la dur\u00e9e de mise en cache dans le navigateur (max-age=600), tout en la prolongeant au niveau de la p\u00e9riph\u00e9rie (s-maxage=86400). <em>stale-while-revalidate<\/em> Cela permet aux caches de continuer \u00e0 diffuser des contenus p\u00e9rim\u00e9s pendant une dur\u00e9e d\u00e9finie, tandis que la mise \u00e0 jour s'effectue d\u00e9j\u00e0 en arri\u00e8re-plan. <em>stale-if-error<\/em> intervient en cas d'erreur (par exemple, 500\/timeout) et pr\u00e9serve l'exp\u00e9rience utilisateur en affichant une version l\u00e9g\u00e8rement plus ancienne plut\u00f4t que de signaler une erreur fatale.<\/p>\n<p>Voici \u00e0 quoi ressemble un mod\u00e8le pratique pour les r\u00e9ponses API publiques, rarement modifi\u00e9es, ou les plans de site JSON : <code>Cache-Control : public, max-age=600, s-maxage=86400, stale-while-revalidate=30, stale-if-error=600<\/code>. Ainsi, les navigateurs restent relativement \u00e0 jour, les CDN sont efficaces et les utilisateurs ne ressentent ni br\u00e8ves interruptions ni retards dans la mise \u00e0 jour des pages. J\u2019exclus d\u00e9lib\u00e9r\u00e9ment les zones critiques ou personnalis\u00e9es de ces directives souples.<\/p>\n\n<h2>Interaction avec les en-t\u00eates \u00ab Expires \u00bb, \u00ab ETag \u00bb et \u00ab Last-Modified \u00bb<\/h2>\n<p>J'utilise <strong>Expire<\/strong> Tout au plus comme solution de secours, car Cache-Control offre un contr\u00f4le plus pr\u00e9cis et pr\u00e9vaut lorsque les deux sont d\u00e9finis. Avec ETag, je fournis une empreinte unique de la ressource, ce qui permet au navigateur de d\u00e9clencher une revalidation simple via If-None-Match. Last-Modified fournit la date et l\u2019heure de la derni\u00e8re modification et fonctionne en association avec If-Modified-Since. Ces deux m\u00e9thodes permettent d\u2019\u00e9conomiser de la bande passante, car si le contenu n\u2019a pas chang\u00e9, le serveur renvoie uniquement le statut 304. Cette interaction maintient les donn\u00e9es \u00e0 proximit\u00e9 de l\u2019utilisateur et r\u00e9duit <strong>Allers-retours<\/strong>.<\/p>\n<p>Est-ce que je vais l'acheter ? <a href=\"https:\/\/webhosting.de\/fr\/http-conditional-requests-cache-validation-optimisation-paquet\/\">Demandes conditionnelles<\/a>, les co\u00fbts par consultation de page diminuent consid\u00e9rablement, sans que je bloque l'affichage de nouveaux contenus. Cette technique compl\u00e8te les valeurs \u00ab max-age \u00bb restreintes en HTML et garantit des affichages \u00e0 jour. En revanche, pour les ressources versionn\u00e9es, je privil\u00e9gie surtout une dur\u00e9e de validit\u00e9 longue et j'\u00e9vite les validations inutiles. Je soulage ainsi le <strong>Serveur<\/strong> et acc\u00e9l\u00e8re sensiblement les visites suivantes. Au final, on obtient un parcours de donn\u00e9es simplifi\u00e9, r\u00e9gi par des r\u00e8gles claires.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/WebOptimizationCacheControl1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>ETag\/Last-Modified en pratique : puissant, faible et \u00e9volutif<\/h2>\n<p>Dans les configurations distribu\u00e9es, je veille \u00e0 ce que les ETags <em>coh\u00e9rent<\/em> \u00eatre calcul\u00e9s \u00e0 tous les niveaux. Les ETags bas\u00e9s sur les fichiers, qui int\u00e8grent les inodes, entra\u00eenent des \u00ab misses \u00bb inutiles dans les clusters. Sous Apache, je configure donc d\u00e9lib\u00e9r\u00e9ment le calcul des ETags :<\/p>\n<pre><code># Apache : ETags coh\u00e9rents pour les fichiers statiques\nFileETag MTime Size\n# Facultatif : supprimer l'ETag par d\u00e9faut et d\u00e9finir sa propre logique\n\n  #Header unset ETag\n<\/code><\/pre>\n<p>Avec Nginx, il suffit souvent de <code>\u00e9tage activ\u00e9 ;<\/code> pour les fichiers statiques. Pour <em>dynamique<\/em> Je g\u00e9n\u00e8re moi-m\u00eame les ETags dans les r\u00e9ponses \u2013 id\u00e9alement sous forme de hachage du corps de la r\u00e9ponse. Si j'ai besoin d'une certaine tol\u00e9rance pour les modifications mineures (par exemple, des horodatages format\u00e9s), j'utilise <strong>ETags faibles<\/strong> (<code>W\/\" ... \"<\/code>), qui permettent de reconna\u00eetre comme inchang\u00e9s des contenus s\u00e9mantiquement identiques malgr\u00e9 des diff\u00e9rences au niveau des octets. \u00c0 titre de solution de secours, j'utilise l'en-t\u00eate \u00ab Last-Modified \u00bb, par exemple \u00e0 la date de mise \u00e0 jour de l'enregistrement. Important : ETag et Last-Modified <em>en m\u00eame temps<\/em> Il n'y a pas de mal \u00e0 proposer cette option : c'est le client qui choisit celle qu'il prend en charge.<\/p>\n\n<h2>Utiliser Vary \u00e0 bon escient : la personnalisation sans chaos au niveau du cache<\/h2>\n<p><strong>Vary<\/strong> d\u00e9termine quels en-t\u00eates de requ\u00eate sont pris en compte dans la cl\u00e9 du cache. Je garde volontairement l'en-t\u00eate \u00ab Vary \u00bb aussi simple que possible : <em>Accept-Encoding<\/em> c'est la norme (Gzip\/Brotli), <em>Accepter la langue<\/em> uniquement si je fournis des r\u00e9ponses sp\u00e9cifiques \u00e0 la langue. De <em>Vary : User-Agent<\/em> Je le d\u00e9conseille, car cela fait exploser la taille du cache. Si le contenu d\u00e9pend des cookies, je pr\u00e9f\u00e8re <strong>priv\u00e9<\/strong> ou <strong>no-store<\/strong>, plut\u00f4t que de g\u00e9rer des r\u00e8gles Vary trop complexes. Pour les ressources, je supprime si possible les cookies superflus afin que <strong>public<\/strong>- La mise en cache en p\u00e9riph\u00e9rie est activ\u00e9e. Si l'authentification via l'API utilise l'en-t\u00eate, il est possible de <em>Vary : Autorisation<\/em> emp\u00eacher les caches partag\u00e9s de m\u00e9langer les r\u00e9ponses de diff\u00e9rents utilisateurs \u2013 mais souvent, dans ce cas, <strong>priv\u00e9<\/strong> le choix le meilleur et le plus clair.<\/p>\n<p>Je v\u00e9rifie dans DevTools si l'en-t\u00eate Vary est d\u00e9fini de mani\u00e8re involontaire (par exemple par des middlewares), car un en-t\u00eate Vary \u201e trop large \u201c r\u00e9duit consid\u00e9rablement le taux de r\u00e9ussite. Quelques en-t\u00eates, choisis avec soin, permettent de garder le cache g\u00e9rable et <strong>efficace<\/strong>.<\/p>\n\n<h2>Strat\u00e9gies par type de contenu<\/h2>\n<p>Je fais une distinction stricte entre les contenus statiques et dynamiques afin de pouvoir tirer parti des avantages des deux. Les ressources statiques b\u00e9n\u00e9ficient d\u2019une longue dur\u00e9e de vie et d\u2019une identification claire gr\u00e2ce \u00e0 des noms de fichiers versionn\u00e9s. Je traite le code HTML et les contenus personnels avec plus de prudence, afin que les modifications soient rapidement disponibles et qu\u2019aucune donn\u00e9e ne se retrouve dans des caches erron\u00e9s. Je classe les API en fonction de la fr\u00e9quence des modifications et du caract\u00e8re sensible des informations. Cette diff\u00e9renciation apporte <strong>Tempo<\/strong> sans compromettre la confidentialit\u00e9 et <strong>Correction<\/strong>.<\/p>\n<p>Le tableau suivant r\u00e9sume les r\u00e9glages pratiques et pr\u00e9sente leurs avantages en un coup d'\u0153il.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Type de ressources<\/th>\n      <th>Exemple d'en-t\u00eate<\/th>\n      <th>Pourquoi<\/th>\n      <th>Remarque<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>CSS\/JS\/Images\/Polices<\/td>\n      <td>Contr\u00f4le du cache : public, max-age=31536000, immutable<\/td>\n      <td>Utilisation prolong\u00e9e \u00e0 partir de <strong>Cache du navigateur<\/strong>, moins de requ\u00eates<\/td>\n      <td>Num\u00e9roter les noms de fichiers pour plus de clart\u00e9 <strong>Rolling<\/strong> Mise \u00e0 jour<\/td>\n    <\/tr>\n    <tr>\n      <td>HTML non personnalis\u00e9<\/td>\n      <td>Cache-Control : no-cache, must-revalidate (ou max-age=300)<\/td>\n      <td>Le niveau d'actualit\u00e9 reste \u00e9lev\u00e9, le volume de donn\u00e9es reste faible<\/td>\n      <td>Avec ETag\/Last-Modified pour une <strong>r\u00e9habilitation<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>HTML personnalis\u00e9<\/td>\n      <td>Cache-Control : private, no-cache, must-revalidate<\/td>\n      <td>Pas de mise en cache dans les caches partag\u00e9s<\/td>\n      <td>Prot\u00e9ger les donn\u00e9es de session et <strong>Leaks<\/strong> \u00e9viter<\/td>\n    <\/tr>\n    <tr>\n      <td>API statiques \/ \u00e9voluant rarement<\/td>\n      <td>Cache-Control : public, max-age=3600<\/td>\n      <td>Un taux de r\u00e9ussite \u00e9lev\u00e9 chez de nombreux <strong>Clients<\/strong><\/td>\n      <td>Restez flexibles pour des d\u00e9ploiements fr\u00e9quents<\/td>\n    <\/tr>\n    <tr>\n      <td>API tr\u00e8s dynamiques \/ sensibles<\/td>\n      <td>Cache-Control : no-store, max-age=0<\/td>\n      <td>Ne pas enregistrer de donn\u00e9es sensibles<\/td>\n      <td>Direct <strong>Actualit\u00e9<\/strong> au lieu de \u00ab risque \u00bb<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n<p>Pour les galeries d'images, les gros bundles JS ou les polices web, les valeurs \u00ab max-age \u00bb \u00e9lev\u00e9es sont rapidement rentabilis\u00e9es. Je veille \u00e0 ce que les cha\u00eenes de version figurent dans les noms de fichiers, afin que les utilisateurs ne voient jamais de bundles obsol\u00e8tes. Le code HTML reste concis et recourt \u00e0 la revalidation, afin que m\u00eame les petites corrections apport\u00e9es aux textes ou aux prix soient mises en ligne rapidement. Les API se voient attribuer des r\u00e8gles en fonction du profil d'utilisation et des besoins de modification. Cette combinaison garantit une performance durable <strong>flotte<\/strong> Nombre de pages vues et \u00e9conomise <strong>Bande passante<\/strong>.<\/p>\n\n<h2>SPA vs MPA : HTML d'index court, ressources longues<\/h2>\n<p>En ce qui concerne les applications monopages, je consid\u00e8re que la <em>Index HTML<\/em> d'une dur\u00e9e de vie particuli\u00e8rement courte (par exemple,. <code>no-cache, must-revalidate<\/code> ou <code>max-age=60<\/code>), car elle d\u00e9termine quelle version des bundles est charg\u00e9e. En revanche, tous les chunks, polices et images g\u00e9n\u00e9r\u00e9s sont strictement versionn\u00e9s et re\u00e7oivent <code>public, max-age=31536000, immutable<\/code>. Je m'assure ainsi qu'une nouvelle version avec un fichier HTML d'index mis \u00e0 jour fasse imm\u00e9diatement r\u00e9f\u00e9rence aux nouveaux noms de fichiers corrects, tandis que les utilisateurs existants continuent \u00e0 utiliser le <em>grands<\/em> R\u00e9cup\u00e9rer les ressources depuis leur cache local.<\/p>\n<p>Les cha\u00eenes de requ\u00eate comme moyen de contourner la mise en cache (<code>?v=123<\/code>) Je ne l'utilise que lorsque les noms de fichiers ne peuvent pas \u00eatre modifi\u00e9s facilement. Il est pr\u00e9f\u00e9rable d'utiliser des noms de fichiers uniques (hachages), car ils permettent une segmentation plus pr\u00e9cise des caches et g\u00e9n\u00e8rent moins de cas particuliers.<\/p>\n\n<h2>Configuration du serveur : Apache et Nginx<\/h2>\n<p>Sous Apache, je d\u00e9finis g\u00e9n\u00e9ralement les en-t\u00eates dans le fichier <strong>.htaccess<\/strong>, \u00e0 condition que le module mod_headers soit actif. J'attribue une dur\u00e9e de validit\u00e9 longue aux ressources statiques, tandis que le code HTML est trait\u00e9 de mani\u00e8re plus stricte. Sous Nginx, je g\u00e8re cela dans des blocs \u00ab location \u00bb, souvent en association avec la directive \u00ab expires \u00bb comme solution de repli. Je teste chaque modification avec DevTools dans l\u2019onglet R\u00e9seau afin de voir les valeurs r\u00e9elles des en-t\u00eates. Cela me permet d\u2019\u00e9viter les r\u00e8gles erron\u00e9es qui, sinon, pourraient entra\u00eener de co\u00fbteuses <strong>Demandes non pertinentes<\/strong> produire.<\/p>\n<pre><code># Apache (.htaccess)\n\n  \n    Header set Cache-Control \"public, max-age=31536000, immutable\"\n  \n\n  \n    Header set Cache-Control \"no-cache, must-revalidate\"\n<\/code><\/pre>\n<pre><code># Nginx (bloc serveur)\nlocation ~* \\.(jpg|jpeg|png|gif|css|js|woff2?)$ {\n    expires 365d;\n    add_header Cache-Control \"public, immutable\";\n}\n\nlocation ~* \\.(html)$ {\n    add_header Cache-Control \"no-cache, must-revalidate\";\n}\n<\/code><\/pre>\n<p>Je veille \u00e0 ce qu'aucune r\u00e8gle concurrente dans les services en amont ne vienne interf\u00e9rer avec ces en-t\u00eates. Un CDN en amont peut, par exemple, d\u00e9finir ses propres TTL, ce que je dois g\u00e9rer de mani\u00e8re cibl\u00e9e. Si tous les niveaux sont coh\u00e9rents, les ressources restent fiables. <strong>facile \u00e0 trouver<\/strong> et coh\u00e9rentes. En v\u00e9rifiant soigneusement ces points, on \u00e9vite de longues sessions de d\u00e9bogage. De petites v\u00e9rifications permettent d'\u00e9conomiser beaucoup de temps par la suite <strong>Temps<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/futuristic-web-optimization-7643.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Pratique du CDN et du proxy : configuration de \u00ab s-maxage \u00bb et des strat\u00e9gies \u00ab Stale \u00bb<\/h2>\n<p>Pour les caches en p\u00e9riph\u00e9rie, j'ajoute les \u00e9l\u00e9ments suivants \u00e0 la configuration du serveur : <em>s-maxage<\/em> ainsi que les directives Stale. Exemple Apache :<\/p>\n<pre><code># Apache : r\u00e8gles optimis\u00e9es pour le CDN\n\n  \n    Header set Cache-Control \"public, max-age=600, s-maxage=86400, stale-while-revalidate=30, stale-if-error=600\"\n<\/code><\/pre>\n<p>Et dans Nginx :<\/p>\n<pre><code># Nginx : optimisation du cache partag\u00e9\nlocation ~* \\.(json|xml|map)$ {\n    add_header Cache-Control \"public, max-age=600, s-maxage=86400, stale-while-revalidate=30, stale-if-error=600\";\n}\n<\/code><\/pre>\n<p>De nombreux CDN respectent directement ces directives. Si ta couche p\u00e9riph\u00e9rique (Edge Layer) attend ses propres en-t\u00eates (par exemple, des en-t\u00eates \u00ab Surrogate \u00bb), j'y reproduis la m\u00eame logique et je s\u00e9pare clairement la strat\u00e9gie du navigateur de celle du cache partag\u00e9. Gr\u00e2ce au versionnage, j'ai rarement besoin de purges ; lorsque c'est le cas, je les planifie comme une intervention cibl\u00e9e et de faible ampleur.<\/p>\n\n<h2>Cas particuliers : redirections, pages d'erreur et workflows de formulaires<\/h2>\n<p><strong>Redirections :<\/strong> Les r\u00e9ponses 301 sont, selon la sp\u00e9cification, mises en cache. Lorsque je configure des redirections temporaires (302\/307), j'attribue des TTL clairs ou je d\u00e9finis d\u00e9lib\u00e9r\u00e9ment <code>no-store<\/code>, afin d'\u00e9viter que rien ne devienne d\u00e9finitif. Les routes 301 permanentes peuvent avoir une valeur TTL mod\u00e9r\u00e9e ; les modifications constituent alors une d\u00e9marche d\u00e9lib\u00e9r\u00e9e et coordonn\u00e9e.<\/p>\n<p><strong>Pages d'erreur :<\/strong> Les r\u00e9ponses 404\/410 peuvent \u00eatre mises en cache pendant une courte dur\u00e9e (par exemple,. <code>max-age=60<\/code>), afin de r\u00e9duire la charge g\u00e9n\u00e9r\u00e9e par les bots. Pour les 500, j'ai, selon l'environnement, <code>stale-if-error<\/code> active, afin que les utilisateurs pr\u00e9f\u00e8rent voir une page plus ancienne mais qui fonctionne plut\u00f4t qu'un message d'erreur.<\/p>\n<p><strong>POST\/T\u00e9l\u00e9chargement :<\/strong> En r\u00e8gle g\u00e9n\u00e9rale, les r\u00e9ponses aux requ\u00eates POST ne sont pas mises en cache par le navigateur. Pour les exportations de fichiers contenant des donn\u00e9es personnelles (par exemple, des factures), j'active syst\u00e9matiquement <code>no-store<\/code> ainsi qu'une distribution s\u00e9curis\u00e9e (par exemple, Content-Disposition), afin que rien ne soit conserv\u00e9 par inadvertance. En revanche, les t\u00e9l\u00e9chargements volumineux non personnalis\u00e9s (par exemple, les versions) peuvent tirer parti des caches publics pendant une longue p\u00e9riode.<\/p>\n\n<h2>\u00c9viter les erreurs typiques<\/h2>\n<p>Beaucoup confondent <strong>no-cache<\/strong> avec \u201e pas de cache du tout \u201c, ce qui entra\u00eene une charge inutile. \u00c0 lire correctement, \u00ab no-cache \u00bb autorise la mise en cache, mais exige une revalidation. Autre erreur classique : des valeurs \u00ab max-age \u00bb trop longues sans gestion des versions pour les fichiers CSS ou JS, ce qui entra\u00eene le maintien de fichiers obsol\u00e8tes. L\u2019absence de s\u00e9paration entre le HTML et les ressources statiques nuit \u00e0 la vitesse, car le HTML ne peut g\u00e9n\u00e9ralement pas \u00eatre mis en cache de mani\u00e8re intensive. Ignorer cela ralentit le <strong>Exp\u00e9rience utilisateur<\/strong> de.<\/p>\n<p>Les conflits entre le serveur, le CDN et l'application sapent les effets de la mise en cache sans que l'on s'en aper\u00e7oive. V\u00e9rifiez donc les \u00e9crasements et les niveaux interm\u00e9diaires lorsque les en-t\u00eates changent \u201e comme par magie \u201c. Il est utile ici d'examiner la logique et la cha\u00eene des r\u00e9ponses pour mettre au jour les mauvaises priorit\u00e9s. Une liste de contr\u00f4le concise et les pi\u00e8ges typiques li\u00e9s \u00e0 <a href=\"https:\/\/webhosting.de\/fr\/http-cache-headers-saboter-la-mise-en-cache-cachefix\/\">Saboter les en-t\u00eates de cache<\/a> facilitent le contr\u00f4le. Des priorit\u00e9s bien d\u00e9finies permettent d'\u00e9viter <strong>Effets secondaires<\/strong> lors des d\u00e9ploiements.<\/p>\n\n<h2>Rendre mesurable le gain de performance<\/h2>\n<p>J'\u00e9value les effets de Cache-Control \u00e0 l'aide d'indicateurs tels que le TTFB, le LCP et le nombre de <strong>Requ\u00eates<\/strong> par page consult\u00e9e. Un coup d\u2019\u0153il dans les DevTools me permet de voir si les fichiers proviennent du \u201e cache disque \u201c ou du \u201e cache m\u00e9moire \u201c. Lighthouse, WebPageTest et d\u2019autres outils similaires indiquent si la mise en cache du navigateur fonctionne correctement. Je mesure les performances avant et apr\u00e8s une modification afin de constater clairement les am\u00e9liorations r\u00e9elles. Cette rigueur permet d\u2019optimiser <strong>compr\u00e9hensible<\/strong> et cibl\u00e9.<\/p>\n<p>Les images volumineuses, les polices Web et les ensembles de fichiers, qui ne sont plus charg\u00e9s lors des consultations suivantes, ont un impact particuli\u00e8rement important. Le code HTML reste ainsi proche du serveur, ce qui permet aux utilisateurs d\u2019acc\u00e9der rapidement aux nouveaux contenus. Les API en tirent un avantage notable lorsque les routes fr\u00e9quemment utilis\u00e9es sont associ\u00e9es \u00e0 un TTL mod\u00e9r\u00e9. Les r\u00e9sultats se traduisent par des temps de chargement plus courts, une r\u00e9duction du volume de donn\u00e9es et une charge serveur plus stable. En v\u00e9rifiant syst\u00e9matiquement ces \u00e9l\u00e9ments, on r\u00e9alise des \u00e9conomies durables <strong>Ressources<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/WebOptimierung4102.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Service Worker et cache HTTP : ne pas les faire fonctionner en concurrence<\/h2>\n<p>Si j'utilise un Service Worker, sa strat\u00e9gie doit correspondre \u00e0 mes en-t\u00eates HTTP. Pour les ressources statiques et versionn\u00e9es, la strat\u00e9gie \u201e cache-first \u201c avec un TTL long et <em>immuable<\/em> Excellent. Pour le HTML ou les donn\u00e9es API qui changent fr\u00e9quemment, je privil\u00e9gie les m\u00e9thodes \u201e network-first \u201c ou \u201e stale-while-revalidate \u201c, afin que les utilisateurs voient rapidement les r\u00e9ponses et que les mises \u00e0 jour soient effectu\u00e9es en temps r\u00e9el. Important : le Service Worker doit respecter les revalidations (transmettre les en-t\u00eates If-None-Match\/If-Modified-Since) au lieu de bloquer artificiellement le contenu.<\/p>\n<p>Je tiens \u00e9galement \u00e0 pr\u00e9ciser clairement que le cache HTTP peut d\u00e9j\u00e0 prendre en charge une grande partie du travail ; le Service Worker vient compl\u00e9ter ce fonctionnement, il ne le remplace pas. Cela permet de garder le d\u00e9bogage et l'exploitation sous contr\u00f4le.<\/p>\n\n<h2>Comprendre les directives c\u00f4t\u00e9 requ\u00eate<\/h2>\n<p>Les requ\u00eates peuvent \u00e9galement contr\u00f4ler la mise en cache. <code>Cache-Control : no-cache<\/code> \u00e0 l'adresse suivante : <em>Demande<\/em> force une revalidation au niveau du serveur, <code>max-age=0<\/code> c'est pareil. <code>no-store<\/code> Dans la requ\u00eate, cela emp\u00eache la mise en cache de la r\u00e9ponse tout au long de la cha\u00eene. Pour les cas hors ligne, il est possible de <code>uniquement si mis en cache<\/code> \u00eatre utile : le client n'accepte alors que les r\u00e9ponses provenant du cache. Ce m\u00e9canisme est utile dans les applications qui doivent offrir une exp\u00e9rience d\u00e9finie en cas de connexion faible.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/WebOptimization_9254.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Bonnes pratiques pour ton flux de travail<\/h2>\n<p>Je commence par faire le point : quels sont les types de fichiers disponibles, lesquels sont personnalis\u00e9s, lesquels changent rarement ? Ensuite, je d\u00e9finis des r\u00e8gles adapt\u00e9es \u00e0 chaque cas afin que les ressources restent longtemps dans le <strong>Cache<\/strong> et que le code HTML reste \u00e0 jour. La suppression des cha\u00eenes de version dans les noms de fichiers \u00e9limine le risque de bundles obsol\u00e8tes et permet des temps d'ex\u00e9cution optimis\u00e9s. Lors de fen\u00eatres de maintenance r\u00e9guli\u00e8res, je v\u00e9rifie les en-t\u00eates et les taux de r\u00e9ussite afin d'identifier rapidement les tendances. Cette routine permet de maintenir le site <strong>performant<\/strong> et pr\u00e9visible.<\/p>\n<p>Je documente les configurations de mani\u00e8re concise et claire afin d'\u00e9viter que de futures modifications ne causent des dysfonctionnements par inadvertance. Les scripts de d\u00e9ploiement mettent automatiquement \u00e0 jour les hachages des fichiers, ce qui m'\u00e9vite d'oublier des \u00e9tapes. Pour les versions, j\u2019utilise des d\u00e9ploiements \u00e0 port\u00e9e limit\u00e9e afin de tester le comportement en production. Les retours d\u2019exp\u00e9rience issus de la surveillance et des journaux sont directement int\u00e9gr\u00e9s dans les r\u00e8gles d\u2019en-t\u00eate. Cela permet de garantir que la strat\u00e9gie reste r\u00e9aliste et <strong>efficace<\/strong>.<\/p>\n\n<h2>Gestion des versions et ressources immuables<\/h2>\n<p>J'ajoute des hachages aux noms de fichiers, par exemple app.20260817.js, puis je d\u00e9finis public, max-age=31536000, <strong>immuable<\/strong>. Le navigateur sait ainsi que le fichier ne change jamais \u201e en silence \u201c, ce qui \u00e9vite les revalidations. Lors de la prochaine mise \u00e0 jour, le fichier re\u00e7oit un nouveau nom, ce qui permet au navigateur de charger pr\u00e9cis\u00e9ment la nouvelle version. J\u2019\u00e9vite ainsi les versions obsol\u00e8tes apr\u00e8s un d\u00e9ploiement. Cette strat\u00e9gie s\u2019accorde avec de nombreuses <a href=\"https:\/\/webhosting.de\/fr\/http-controle-du-cache-strategies-hebergement-cachemaster\/\">Strat\u00e9gies de gestion du cache<\/a> des piles les plus diverses.<\/p>\n<p>Pour le HTML, je n'utilise pas \u00ab immutable \u00bb car la page change souvent et je souhaite une revalidation flexible. Il en va de m\u00eame pour les r\u00e9ponses API dont les donn\u00e9es varient. Les polices et les images volumineuses sont particuli\u00e8rement concern\u00e9es, car les utilisateurs les r\u00e9utilisent plusieurs fois sur diff\u00e9rents appareils. Il reste important d'assurer une correspondance sans faille entre les hachages et les versions. La documentation et une <strong>Noms<\/strong> \u00e9viter les confusions au sein de l'\u00e9quipe et dans les builds.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/weboptimization-header-8274.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>\u00c9tapes pratiques de test et de d\u00e9bogage<\/h2>\n<p>J'ouvre DevTools et j'examine, dans l'onglet \u00ab R\u00e9seau \u00bb, les en-t\u00eates de r\u00e9ponse pour v\u00e9rifier les champs Cache-Control, ETag, Expires et <strong>Vary<\/strong> \u00e0 v\u00e9rifier. Un nouveau rechargement sans cache (Ctrl+F5) me permet de voir si les r\u00e8gles s'appliquent r\u00e9ellement. Ensuite, je recharge la page normalement et je v\u00e9rifie quels \u00e9l\u00e9ments proviennent du cache. Pour les proxys et les CDN, je v\u00e9rifie les en-t\u00eates tels que \u00ab Age \u00bb ou \u00ab X-Cache \u00bb, s\u2019ils sont disponibles. Ces v\u00e9rifications permettent de d\u00e9tecter les conflits et les erreurs <strong>Priorit\u00e9s<\/strong> rapidement sur.<\/p>\n<p>Au niveau du serveur, je compare la configuration et les journaux afin de d\u00e9tecter d'\u00e9ventuelles anomalies. Une erreur courante : une application ajoute des en-t\u00eates a posteriori et \u00e9crase les r\u00e8gles du serveur. Dans les pipelines CI\/CD, je teste automatiquement les en-t\u00eates en environnement de pr\u00e9production afin d'\u00e9viter toute mauvaise surprise sur le syst\u00e8me de production. En cas de probl\u00e8me, j'utilise temporairement des TTL courts jusqu'\u00e0 ce que la cause soit identifi\u00e9e. Gr\u00e2ce \u00e0 des tests clairs, je garde <strong>Contr\u00f4le<\/strong> sur le comportement de mise en cache dans toutes les couches.<\/p>\n\n<h2>R\u00e9alit\u00e9 du navigateur : types de m\u00e9moire et lib\u00e9ration de m\u00e9moire<\/h2>\n<p>Les navigateurs font la distinction entre le cache m\u00e9moire et le cache disque. Les petits fichiers fr\u00e9quemment utilis\u00e9s b\u00e9n\u00e9ficient du cache m\u00e9moire (acc\u00e8s extr\u00eamement rapides), tandis que les ressources volumineuses sont souvent stock\u00e9es sur le disque dur. Les appareils mobiles vident leur m\u00e9moire de mani\u00e8re plus agressive ; c\u2019est pourquoi je ne pr\u00e9vois pas de strat\u00e9gie reposant exclusivement sur une tr\u00e8s longue persistance du navigateur, mais je me prot\u00e8ge en mettant en place de bonnes m\u00e9thodes de revalidation. <em>immuable<\/em> Cela permet certes d'\u00e9viter des r\u00e9\u00e9valuations inutiles, mais uniquement tant que l'entr\u00e9e n'a pas \u00e9t\u00e9 supprim\u00e9e par manque de place.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/futuristic-web-optimization-7643.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>A emporter<\/h2>\n<p>D\u00e9finir <strong>Contr\u00f4le du cache<\/strong> Ciblez pr\u00e9cis\u00e9ment : des dur\u00e9es de validit\u00e9 longues et des valeurs \u00ab immutable \u00bb pour les ressources versionn\u00e9es, des r\u00e8gles prudentes et une revalidation pour le HTML et les contenus personnels. Combinez \u00ab max-age \u00bb avec \u00ab ETag \u00bb ou \u00ab Last-Modified \u00bb afin d\u2019\u00e9conomiser de la bande passante et de garantir l\u2019actualit\u00e9 des contenus. V\u00e9rifie tous les niveaux, y compris le CDN, pour t'assurer que les r\u00e8gles ne se contredisent pas. \u00c9vite d\u2019utiliser \u00ab no-store \u00bb par r\u00e9flexe, et r\u00e9serve-le aux cas o\u00f9 la protection des donn\u00e9es est une priorit\u00e9 absolue. Gr\u00e2ce \u00e0 une s\u00e9paration claire par type de contenu, \u00e0 un versionnage coh\u00e9rent et \u00e0 des mesures continues, tu obtiendras des pages nettement plus rapides et tu conserveras la <strong>Altesse<\/strong> \u00e0 propos de ta pratique du g\u00e9ocaching.<\/p>","protected":false},"excerpt":{"rendered":"<p>Apprenez \u00e0 utiliser correctement les en-t\u00eates HTTP \u00ab Cache-Control \u00bb pour am\u00e9liorer la mise en cache par les navigateurs et l'optimisation Web. L'accent est mis sur des strat\u00e9gies de mise en cache s\u00e9curis\u00e9es et performantes.<\/p>","protected":false},"author":1,"featured_media":20739,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[679],"tags":[],"class_list":["post-20746","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-seo"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"177","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Cache-Control","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20739","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20746","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/comments?post=20746"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20746\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/20739"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=20746"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=20746"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=20746"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}