aboutsummaryrefslogtreecommitdiff
path: root/files/fr
diff options
context:
space:
mode:
authorNicolas Boisteault <nboisteault@3liz.com>2022-01-29 09:06:28 +0100
committerGitHub <noreply@github.com>2022-01-29 09:06:28 +0100
commitd9c78eaf0a95af5981a95bf3a0caf1828a6d6190 (patch)
tree73a24b49d0300aad870146feec611f6fb3098728 /files/fr
parente86435de8cd57e092bebba81cc703e9d1b518e6d (diff)
downloadtranslated-content-d9c78eaf0a95af5981a95bf3a0caf1828a6d6190.tar.gz
translated-content-d9c78eaf0a95af5981a95bf3a0caf1828a6d6190.tar.bz2
translated-content-d9c78eaf0a95af5981a95bf3a0caf1828a6d6190.zip
Fix trés => très (#3838)
Diffstat (limited to 'files/fr')
-rw-r--r--files/fr/web/http/caching/index.md8
1 files changed, 4 insertions, 4 deletions
diff --git a/files/fr/web/http/caching/index.md b/files/fr/web/http/caching/index.md
index ff8267e065..09f7dd6c48 100644
--- a/files/fr/web/http/caching/index.md
+++ b/files/fr/web/http/caching/index.md
@@ -102,11 +102,11 @@ Où `responseTime` est le moment auquel a été reçue la réponse selon le navi
### Ressources revues et corrigées
-Plus nous utilisons les ressources en cache, mieux se porteront la "responsivité" et les performances d'un site Web.  Pour optimiser ceci, les bonnes pratiques recommandent de fixer les temps d'expiration aussi loin que possible dans le futur.  C'est possible avec des ressources mises à jour régulièrement ou trés souvent mais ça devient problématique pour les ressources mises à jour trés rarement.  Ce sont les ressources qui bénéficieraient au mieux de la mise en cache mais cela les rend difficiles à mettre à jour. C'est typique des ressources techniques incluses ou liées depuis chaque page web :  les fichiers JavaScript et CSS ne changent pas fréquemment mais quand ils changent, vous voulez qu'ils soient mis à jour au plus vite.
+Plus nous utilisons les ressources en cache, mieux se porteront la "responsivité" et les performances d'un site Web.  Pour optimiser ceci, les bonnes pratiques recommandent de fixer les temps d'expiration aussi loin que possible dans le futur.  C'est possible avec des ressources mises à jour régulièrement ou très souvent mais ça devient problématique pour les ressources mises à jour très rarement.  Ce sont les ressources qui bénéficieraient au mieux de la mise en cache mais cela les rend difficiles à mettre à jour. C'est typique des ressources techniques incluses ou liées depuis chaque page web :  les fichiers JavaScript et CSS ne changent pas fréquemment mais quand ils changent, vous voulez qu'ils soient mis à jour au plus vite.
-Les développeurs Web ont inventé une technique que Steve Sounders a appelée _revving_ ([source](https://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/)). Les fichiers rarement mis à jour sont nommés d'une maniére spécifique : dans leur URL, habituellement dans le nom de fichier, est ajouté un numéro de révision (ou version). Comme ceci, chaque nouvelle révision / version de la ressource est considérée comme une ressource elle-même, qui ne change jamais et qui peut avoir un temps d'expiration trés éloigné dans le futur. En général un an ou plus. Dans le but d'avoir les nouvelles versions, tous les liens doivent être changés. C'est l'inconvénient de cette méthode : une complexité additionnelle habituellement prise en charge par la chaîne d'outils de développeurs Web.  Quand les ressources qui ne sont pas mises à jour fréquemment changent, elles induisent un changement supplémentaire aux ressources régulièrement rafraîchies. Quand elles sont lues, les nouvelles versions des autres sont lues aussi.
+Les développeurs Web ont inventé une technique que Steve Sounders a appelée _revving_ ([source](https://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/)). Les fichiers rarement mis à jour sont nommés d'une maniére spécifique : dans leur URL, habituellement dans le nom de fichier, est ajouté un numéro de révision (ou version). Comme ceci, chaque nouvelle révision / version de la ressource est considérée comme une ressource elle-même, qui ne change jamais et qui peut avoir un temps d'expiration très éloigné dans le futur. En général un an ou plus. Dans le but d'avoir les nouvelles versions, tous les liens doivent être changés. C'est l'inconvénient de cette méthode : une complexité additionnelle habituellement prise en charge par la chaîne d'outils de développeurs Web.  Quand les ressources qui ne sont pas mises à jour fréquemment changent, elles induisent un changement supplémentaire aux ressources régulièrement rafraîchies. Quand elles sont lues, les nouvelles versions des autres sont lues aussi.
-Cette technique a un avantage de plus : mettre à jour deux ressources en cache en même temps ne fera pas qu'une version périmée d'une des ressources sera utilisée avec la nouvelle version de l'autre. C'est trés important quand les sites ont des feuilles de style CSS ou des scripts JS qui ont des dépendances mutuelles c'est-à-dire qui dépendent l'un de l'autre parce qu'ils se réfèrent aux mêmes éléments HTML.
+Cette technique a un avantage de plus : mettre à jour deux ressources en cache en même temps ne fera pas qu'une version périmée d'une des ressources sera utilisée avec la nouvelle version de l'autre. C'est très important quand les sites ont des feuilles de style CSS ou des scripts JS qui ont des dépendances mutuelles c'est-à-dire qui dépendent l'un de l'autre parce qu'ils se réfèrent aux mêmes éléments HTML.
![How the revved cache mechanism works.](http_revved_fix_typo.png)
@@ -134,7 +134,7 @@ Quand un cache reçoit une requête qui peut être satisfaite par une réponse e
![The Vary header leads cache to use more HTTP headers as key for the cache.](http_vary.png)
-Cela peut être trés utile pour servir du contenu dynamique par exemple. Quand on se sert de l'en-tête  `Vary: User-Agent`, les serveurs de cache devront considérer l'agent utilisateur pour décider de servir la page du cache. Si vous servez du contenu varié aux utilisateurs de mobiles, cela vous aidera à éviter qu'un cache puisse servir, par erreur, une version "Desktop" de votre site. En plus, cela aidera Google et d'autres moteurs de recherche  à découvrir la version mobile d'une page et peut aussi les avertir qu'aucun "masquage" ([Cloaking](https://en.wikipedia.org/wiki/Cloaking)) n'est à craindre.
+Cela peut être très utile pour servir du contenu dynamique par exemple. Quand on se sert de l'en-tête  `Vary: User-Agent`, les serveurs de cache devront considérer l'agent utilisateur pour décider de servir la page du cache. Si vous servez du contenu varié aux utilisateurs de mobiles, cela vous aidera à éviter qu'un cache puisse servir, par erreur, une version "Desktop" de votre site. En plus, cela aidera Google et d'autres moteurs de recherche  à découvrir la version mobile d'une page et peut aussi les avertir qu'aucun "masquage" ([Cloaking](https://en.wikipedia.org/wiki/Cloaking)) n'est à craindre.
Vary: User-Agent