Estoy trabajando para mejorar los tiempos de visualización de la velocidad de la página, y uno de los métodos es extraer el contenido del servidor web.
Tenga en cuenta que gzipping solo es beneficioso para recursos más grandes. Debido a la sobrecarga y latencia de la compresión y descompresión, solo debe comprimir archivos por encima de un cierto umbral de tamaño; Recomendamos un rango mínimo entre 150 y 1000 bytes. Los archivos comprimidos de menos de 150 bytes pueden hacerlos más grandes.
Servimos nuestro contenido a través de Akamai , utilizando su red para un proxy y CDN. Lo que me han dicho:
Continuando con su pregunta sobre cuál es el tamaño mínimo, Akamai comprimirá el objeto solicitado cuando lo envíe al usuario final: El tamaño mínimo es de 860 bytes.
Mi respuesta:
¿Cuál es la razón por la cual el tamaño mínimo de Akamai es de 860 bytes? ¿Y por qué, por ejemplo, este no es el caso de los archivos que Akamai sirve para Facebook? ( ver abajo ) Google recomienda gzip de manera más agresiva. Y eso parece apropiado en nuestro sitio donde las visitas más frecuentes, con mucho, son llamadas AJAX que son <860 bytes.
La respuesta de Akamai:
Las razones por las que 860 bytes son el tamaño mínimo para la compresión son dos: (1) La sobrecarga de comprimir un objeto por debajo de 860 bytes supera la ganancia de rendimiento. (2) Los objetos de menos de 860 bytes se pueden transmitir a través de un solo paquete de todos modos, por lo que no hay una razón convincente para comprimirlos.
Así que estoy aquí para verificar algunos hechos. ¿El límite de 860 bytes debido al tamaño del paquete es el final de este razonamiento? ¿Por qué los sitios de alto tráfico llevarían esto al límite de 150 bytes ... solo para ahorrar en costos de ancho de banda (ya que los CDN basan sus cargos en el ancho de banda descargado desde el origen), o hay una ganancia de rendimiento al hacerlo?
7/9/12 Actualización: le pregunté a Steve Souders si hay una ganancia de rendimiento en las respuestas de gzipping que ya son más pequeñas que un paquete y cuál es el tamaño mínimo de objeto recomendado para los beneficios de rendimiento de gzip, y esta es su respuesta:
Gracias por tu email. El tamaño está en algún lugar entre 1-5K. Apache tiene un valor predeterminado, pero se me olvida lo que es: sería una buena guía.
Hacemos nuestra compresión en un dispositivo F5, por lo que vamos a reducirlo a ~ 350 bytes, ya que hay una cantidad decente de llamadas AJAX entre eso y 1K. Las llamadas AJAX que tienen menos de 350 bytes en nuestro sitio web tienen una capacidad de alrededor de 70 bytes ... menos que las recomendaciones de Google ... por lo que realmente parece recurrir a: conocer su sitio web y ajustarlo según su código .
Volveré a esta publicación después de que la actualización F5 se ejecute en Producción por un tiempo. Creo que habrá pocos beneficios de rendimiento, pero reduciremos un poco nuestros costos de Akamai, ya que están sirviendo menos.
Respuestas:
Estás hablando de los beneficios para tus costos de ancho de banda, pero también comparas el rendimiento de la carga de la página en un navegador. Son dos cosas diferentes.
Cada vez que comprime una solicitud, algo tiene que hacer realmente la compresión (en su caso, el F5) y el cliente (o técnicamente proxies) tiene que manejar la descompresión. Esto puede agregar más latencia a su solicitud, dependiendo de cuán capaz sea el hardware en ambos extremos.
El "tamaño mínimo para gzip" se basa en el tiempo necesario para comprimir / descomprimir esa pequeña cantidad de datos que no son útiles desde la perspectiva de la experiencia del navegador web. Si solo está hablando de ahorro de ancho de banda, continúe y establezca su mínimo tan bajo como desee, pero hágalo sabiendo que es posible que no le esté dando a sus usuarios finales ninguna ganancia de rendimiento.
fuente