Quelle est la taille minimale recommandée de l’objet pour optimiser les performances de gzip?
Je travaille sur l'amélioration des temps d'affichage de la vitesse des pages, et l'une des méthodes consiste à gzip le contenu du serveur Web.
Notez que 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 utiliser que des fichiers gzip dépassant un certain seuil. nous recommandons une plage minimale comprise entre 150 et 1000 octets. Les fichiers Gzipping inférieurs à 150 octets peuvent en réalité les agrandir.
Nous servons notre contenu via Akamai , en utilisant leur réseau pour un proxy et un CDN. Ce qu'ils m'ont dit:
Pour répondre à 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 raison pour laquelle la taille minimale d'Akamai est de 860 octets? Et pourquoi, par exemple, n’est-ce pas le cas des fichiers qu’Akamai sert pour Facebook? ( voir ci-dessous ) Google recommande de gzip de manière plus agressive. Et cela semble approprié sur notre site où les appels les plus fréquents sont, de loin, les appels AJAX <860 octets.
Réponse d'Akamai:
La taille minimale de la compression est double pour 860 octets: (1) La surcharge de la compression d'un objet sous 860 octets est supérieure au gain en performances. (2) Les objets de moins de 860 octets peuvent quand même être transmis via un seul paquet, il n'y a donc aucune raison impérieuse de les compresser.
Je suis donc ici pour une vérification des faits. La limite de 860 octets due à la taille de paquet est-elle la fin de ce raisonnement? Pourquoi les sites à fort trafic vont-ils abaisser la limite à 150 octets ... juste pour économiser sur les coûts de bande passante (puisque les CDN basent leurs redevances sur la bande passante déchargée d'Origine), ou y a-t-il un gain de performance?
09/07/12 Mise à jour: J'ai demandé à Steve Souders s'il y avait un gain de performance dans les réponses gzipping déjà plus petites qu'un paquet et quelle est la valeur recommandée. taille minimale de l'objet pour les avantages de performance gzip, et voici sa réponse:
Merci pour ton mail. La taille est quelque part entre 1-5K. Apache a un défaut mais j'oublie ce que c'est - ce serait un bon guide.
Nous faisons notre compression sur une appliance F5, nous allons donc la réduire à environ 350 octets, car il existe un nombre décent d'appels AJAX entre 1K et 1K. Les AJAX appels de moins de 350 octets sur notre site Web ont tous une réduction d'environ 70 octets ... moins que les recommandations de Google ... donc, il semble vraiment tomber à: connaître votre site Web et ajuster en fonction de votre code .
J'y reviendrai après que la mise à jour F5 ait été exécutée pendant un certain temps en production. Je pense qu'il y aura peu d'avantages en termes de performances, mais nous allons réduire un peu nos coûts d'Akamai car ils servent moins.
Vous parlez des avantages de vos coûts de bande passante, mais vous comparez également les performances de chargement de la page dans un navigateur. Ce sont deux choses différentes.
Chaque fois que vous gzip une demande, quelque chose doit réellement faire la compression (dans votre cas, le F5) et le client (ou les proxys techniques) doit gérer la décompression. Cela peut ajouter une latence supplémentaire à votre demande, en fonction de la capacité du matériel aux deux extrémités.
La "taille minimale de gzip" est basée sur le temps nécessaire pour compresser/décompresser cette petite donnée qui n'est pas utile du point de vue de l'expérience du navigateur Web. Si vous parlez uniquement d'économies de bande passante, définissez votre minimum aussi bas que vous le souhaitez, tout en sachant que vous n'apporterez peut-être pas à vos utilisateurs finaux des gains de performances.