J'ai essayé un outil pour mesurer la vitesse de mon site web. C'est Pingdom https://tools.pingdom.com
Il y a une réponse que je ne comprends pas "Les ressources compressibles suivantes pouvant être mises en cache publiquement devraient avoir un en-tête" Vary: Accept-Encoding ": https://www.example.com/ "
Quelqu'un peut-il expliquer en quoi consiste simplement cela et comment puis-je l'améliorer?
Si je comprends bien, cela est lié à la façon dont les fichiers sont compressés. Mon serveur n'accepte pas Gzip. Cela fonctionne bien avec dégonfler. Je mets ce code dans le .htaccess:
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
Cela fonctionne bien pour la vitesse de la page Google. Mais il semble que Pingdom donne toujours une erreur.
L'en-tête de réponse HTTP Vary indique aux agents utilisateurs (clients) que la réponse du serveur peut varier si le client modifie l'un des en-têtes de demande mentionnés.
Vary: Accept-Encoding
Cela signifie que si le navigateur envoie une valeur différente dans l'en-tête de demande Accept-Encoding, le serveur peut envoyer une réponse différente.
(Il convient de noter que l'en-tête Accept-Encoding indique les algorithmes de compression pris en charge par le navigateur. Les codages de caractères sont appelés des jeux de caractères dans HTTP.)
La raison pour laquelle l’en-tête est nécessaire est qu’il peut exister un cache entre l’agent utilisateur (navigateur) et le serveur et que ce dernier doit savoir que la même page peut avoir un contenu différent pour différents agents utilisateur. Si le serveur n'a pas envoyé d'en-tête Vary, un cache intermédiaire pourrait mettre en cache une variante "étrange" d'une page et la transmettre à tout le monde, exemples:
Envoi d'une "page mobile" aux ordinateurs de bureau.
Envoi de la page compressée avec une méthode de compression peu commune/non prise en charge.
Envoi de la page dans une langue que vous ne parlez pas.
Si vous n'envoyez pas l'en-tête Vary, un cache intermédiaire peut ruiner votre site.
Quelques exemples d’en-têtes qui sont ¿couramment? mentionné dans l'en-tête Vary:
User-Agent: généralement utilisé par les sites qui servent des pages de mobile et de bureau distinctes sur les mêmes URL. (Certains moteurs de recherche, y compris Google, exigent que vous utilisiez l'en-tête Vary si vous utilisez cette méthode.)
Accept-Language: un site internationalisé peut utiliser l'en-tête Accept envoyé par le navigateur.
Honnêtement: Ce n'est pas la plus importante en-tête Vary. La plupart des navigateurs supportent gzip, il est donc peu probable que vous ayez réellement besoin de le mettre en œuvre.
Mais je ne dirais pas cela, n’est-ce pas? J’aime être pédant sur ce genre de choses, alors je vous suggère de jeter un coup d’œil à ceci question de Stackoverflow qui demande comment l’appliquer .
Une des principales raisons d’utiliser "Vary: Accept-encoding" est, comme l’a mentionné Oskar, de permettre la diffusion de contenu en fonction des capacités du navigateur.
"Accept-encoding" est un paramètre particulièrement important pour l'en-tête "Vary", car il permet aux mandataires (serveurs intermédiaires) de bien comprendre que plusieurs versions compressées de votre page peuvent être mises en cache dans les mandataires. Par conséquent, votre page Web sera chargé rapidement pour les nouveaux navigateurs prenant en charge la compression et non compressé pour les navigateurs plus anciens ne prenant pas en charge la compression.
Cette URL explique très bien pourquoi la variation est extrêmement importante et indique même que vous pouvez économiser de l'argent grâce à son utilisation:
https://www.fastly.com/blog/best-practices-using-vary-header/