Je travaille sur l'amélioration des temps d'affichage de la vitesse des pages, et l'une des méthodes consiste à compresser le contenu du serveur Web.
Notez que le gzipping n'est bénéfique que pour des ressources plus importantes. En raison de la surcharge et de la latence de la compression et de la décompression, vous ne devez gzip que les fichiers au-dessus d'un certain seuil de taille; nous recommandons une plage minimale comprise entre 150 et 1 000 octets. Gzipper des fichiers inférieurs à 150 octets peut en fait les agrandir.
Nous servons notre contenu via Akamai , en utilisant leur réseau pour un proxy et CDN. Ce qu'ils m'ont dit:
Suite à votre question concernant la taille minimale, Akamai compressera l'objet demandé lors de son envoi à l'utilisateur final: La taille minimale est de 860 octets.
Ma réponse:
Quelle est la ou les raisons pour lesquelles la taille minimale d'Akamai est de 860 octets? Et pourquoi, par exemple, n'est-ce pas le cas pour les fichiers qu'Akamai sert pour Facebook? ( voir ci-dessous ) Google recommande de gzip plus agressivement. Et cela semble approprié sur notre site où les hits les plus fréquents, de loin, sont des appels AJAX <860 octets.
Réponse d'Akamai:
La raison pour laquelle la taille minimale de compression est de 860 octets est double: (1) La surcharge de compression d'un objet de moins de 860 octets l'emporte sur le gain de performances. (2) Les objets de moins de 860 octets peuvent de toute façon être transmis via un seul paquet, il n'y a donc pas de raison impérieuse de les compresser.
Je suis donc ici pour une vérification des faits. La limite de 860 octets en raison de la taille des paquets est-elle la fin de ce raisonnement? Pourquoi les sites à fort trafic ramèneraient-ils cela à la limite de 150 octets ... juste pour économiser sur les coûts de bande passante (puisque les CDN basent leurs frais sur la bande passante déchargée d'origine), ou y a-t-il un gain de performances?
Mise à jour du 7/9/12: J'ai demandé à Steve Souders s'il y avait un gain de performances dans les réponses gzipping qui sont déjà plus petites qu'un paquet et quelle est la taille d'objet minimale recommandée pour les avantages de performances gzip, et voici sa réponse:
Merci pour ton mail. La taille se situe entre 1-5K. Apache a un défaut mais j'oublie ce que c'est - ce serait un bon guide.
Nous effectuons notre compression sur un appareil F5, nous allons donc le réduire à ~ 350 octets, car il y a une quantité décente d'appels AJAX entre cela et 1K. Les appels AJAX qui font moins de 350 octets sur notre site Web sont tous en baisse d'environ 70 octets ... de moins que les recommandations de Google ... il semble donc vraiment revenir à: connaître votre site Web et ajuster en fonction de votre code .
Je reviendrai sur ce post après la mise à jour F5 en production pendant un certain temps. Je pense qu'il y aura peu d'avantages en termes de performances, mais nous allons réduire un peu nos coûts Akamai car ils servent moins.
Réponses:
Vous parlez des avantages de vos coûts de bande passante, mais vous comparez également les performances du chargement de la page dans un navigateur. Ce sont deux choses différentes.
Chaque fois que vous gzipez une requête, quelque chose doit réellement faire la compression (dans votre cas, le F5) et le client (ou techniquement les mandataires) doit gérer la décompression. Cela peut ajouter plus de latence à votre demande, selon la capacité du matériel aux deux extrémités.
La "taille minimale pour gzip" est basée sur le temps nécessaire pour compresser / décompresser ce petit nombre de données qui ne sont pas utiles du point de vue de l'expérience du navigateur Web. Si vous parlez uniquement d'économies de bande passante, alors allez-y et fixez votre minimum aussi bas que vous le souhaitez, mais faites-le en sachant que vous n'apporterez peut-être aucun gain de performances à vos utilisateurs finaux.
la source