Servicio de CSS y JavaScript comprimidos con gzip desde Amazon CloudFront a través de S3


He estado buscando formas de hacer que mi sitio cargue más rápido y una forma que me gustaría explorar es hacer un mayor uso de Cloudfront.

Debido a que Cloudfront no fue diseñado originalmente como una CDN de origen personalizado y porque no soportaba gzipping, hasta ahora lo he estado usando para alojar todas mis imágenes, a las que se hace referencia mediante su cname de Cloudfront en el código de mi sitio, y optimizado con encabezados de futuro lejano.

Los archivos CSS y javascript, por otro lado, están alojados por mi cuenta servidor, porque hasta ahora tenía la impresión de que no se podían servir gzipped desde Cloudfront, y que la ganancia de gzipping (alrededor del 75 por ciento) supera la del uso de una CDN (alrededor del 50 por ciento): Amazon S3 (y por lo tanto Cloudfront) no soportaba el servicio de contenido gzipped de una manera estándar mediante el uso del encabezado HTTP Accept-Encoding que envían los navegadores para indicar su soporte para la compresión gzip, por lo que no volar.

Así que tenía la impresión, hasta ahora, de que había que elegir entre dos alternativas:

  1. Mueva todos los activos a Amazon CloudFront y olvídese de GZipping;

  2. Mantenga los componentes auto alojados y configure nuestro servidor para detectar solicitudes entrantes y realizar GZipping sobre la marcha según corresponda, que es lo que elegí hacer hasta ahora.

Hay de soluciones para resolver este problema, pero, esencialmente, estos no trabajo. [link ].

Ahora, parece que Amazon Cloudfront admite origen personalizado, y que ahora es posible usar el método estándar HTTP Accept-Encoding para servir contenido comprimido con gzip si está utilizando un Origen personalizado [link ].

Hasta ahora no he podido implementar la nueva característica en mi servidor. La entrada del blog a la que enlacé anteriormente, que es la única que encontré detallando el cambio, parece implicar que solo puedes habilitar gzipping (bar soluciones alternativas, que no quiero usar), si opta por el origen personalizado, que prefiero no: me resulta más sencillo alojar los archivos de respuesta conjunta en mi servidor Cloudfront y vincularlos desde allí. A pesar de leer cuidadosamente la documentación, no lo sé:

  • Si la nueva característica significa que los archivos deben hospedarse en mi propio servidor de dominio a través de origen personalizado, y si es así, qué configuración de código logrará esto;

  • Cómo configurar css y javascript encabezados para asegurarse de que se sirven con gzipped desde Cloudfront.

Author: Jo Liss, 2011-03-26

6 answers

ACTUALIZACIÓN: Amazon ahora admite la compresión gzip, por lo que ya no es necesario. Anuncio de Amazon

Respuesta original:

La respuesta es gzip los archivos CSS y JavaScript. Sí, has leído bien.

gzip -9 production.min.css

Esto producirá production.min.css.gz. Elimine .gz, suba a S3 (o al servidor de origen que esté utilizando) y establezca explícitamente el encabezado Content-Encoding para el archivo en gzip.

No es gzipping sobre la marcha, pero podrías envolverlo fácilmente en sus scripts de compilación / implementación. Las ventajas son:

  1. No requiere CPU para Apache para gzip el contenido cuando se solicita el archivo.
  2. Los archivos se comprimen en el nivel de compresión más alto (suponiendo gzip -9).
  3. Está sirviendo el archivo desde una CDN.

Suponiendo que sus archivos CSS / JavaScript son (a) minificados y (b) lo suficientemente grandes como para justificar la CPU necesaria para descomprimir en la máquina del usuario, puede obtener ganancias significativas de rendimiento aqui.

Solo recuerde: Si realiza un cambio en un archivo que está almacenado en caché en CloudFront, asegúrese de invalidar la caché después de realizar este tipo de cambio.

 196
Author: Skyler Johnson,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-12-28 22:19:35

Mi respuesta es un despegue en esto: http://blog.kenweiner.com/2009/08/serving-gzipped-javascript-files-from.html

Basándote en la respuesta de Skyler puedes subir una versión gzip y no gzip de css y js. Tenga cuidado de nombrar y probar en Safari. Porque safari no maneja archivos .css.gz o .js.gz.

site.js y site.js.jgz y site.css y site.gz.css (tendrá que establecer el encabezado content-encoding en el tipo MIME correcto para que estos se sirvan correctamente)

Luego en tu página poner.

<script type="text/javascript">var sr_gzipEnabled = false;</script> 
<script type="text/javascript" src="http://d2ft4b0ve1aur1.cloudfront.net/js-050/sr.gzipcheck.js.jgz"></script> 

<noscript> 
  <link type="text/css" rel="stylesheet" href="http://d2ft4b0ve1aur1.cloudfront.net/css-050/sr-br-min.css">
</noscript> 
<script type="text/javascript"> 
(function () {
    var sr_css_file = 'http://d2ft4b0ve1aur1.cloudfront.net/css-050/sr-br-min.css';
    if (sr_gzipEnabled) {
      sr_css_file = 'http://d2ft4b0ve1aur1.cloudfront.net/css-050/sr-br-min.css.gz';
    }

    var head = document.getElementsByTagName("head")[0];
    if (head) {
        var scriptStyles = document.createElement("link");
        scriptStyles.rel = "stylesheet";
        scriptStyles.type = "text/css";
        scriptStyles.href = sr_css_file;
        head.appendChild(scriptStyles);
        //alert('adding css to header:'+sr_css_file);
     }
}());
</script> 

Gzipcheck.js.jgz es solo sr_gzipEnabled = true; Esta prueba para asegurarse de que el navegador puede manejar el código gzipped y proporcionar una copia de seguridad si no pueden.

Luego haga algo similar en el pie de página asumiendo que todo su js está en un archivo y puede ir en el pie de página.

<div id="sr_js"></div> 
<script type="text/javascript"> 
(function () {
    var sr_js_file = 'http://d2ft4b0ve1aur1.cloudfront.net/js-050/sr-br-min.js';
    if (sr_gzipEnabled) {
       sr_js_file = 'http://d2ft4b0ve1aur1.cloudfront.net/js-050/sr-br-min.js.jgz';
    }
    var sr_script_tag = document.getElementById("sr_js");         
    if (sr_script_tag) {
    var scriptStyles = document.createElement("script");
    scriptStyles.type = "text/javascript";
    scriptStyles.src = sr_js_file;
    sr_script_tag.appendChild(scriptStyles);
    //alert('adding js to footer:'+sr_js_file);
    }
}());
</script> 

ACTUALIZACIÓN: Amazon ahora admite la compresión gzip. Anuncio, por lo que esto ya no es necesario. Anuncio de Amazon

 15
Author: Sean,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-02-29 21:41:33

Cloudfront admite gzipping.

Cloudfront se conecta a su servidor a través de HTTP 1.0. De forma predeterminada, algunos servidores web, incluido nginx, no sirven contenido comprimido con gzip a conexiones HTTP 1.0, pero puede indicarle que lo haga agregando:

gzip_http_version 1.0

A su configuración de nginx. La configuración equivalente podría establecerse para cualquier servidor web que esté utilizando.

Esto tiene un efecto secundario de hacer que las conexiones keep-alive no funcionen para conexiones HTTP 1.0, pero como los beneficios de la compresión son enorme, definitivamente vale la pena el intercambio.

Tomado de http://www.cdnplanet.com/blog/gzip-nginx-cloudfront/

Editar

Servir contenido que es gzipped sobre la marcha a través de Amazon cloud front es peligroso y probablemente no debería hacerse. Básicamente, si su servidor web está gzipeando el contenido, no establecerá una Longitud de contenido y en su lugar enviará los datos como fragmentados.

Si se interrumpe la conexión entre Cloudfront y su servidor y cortado prematuramente, Cloudfront aún almacena en caché el resultado parcial y lo sirve como la versión en caché hasta que caduque.

La respuesta aceptada de gzipear primero en el disco y luego servir la versión gzipeada es una mejor idea, ya que Nginx será capaz de establecer el encabezado Content-Length, por lo que Cloudfront descartará las versiones truncadas.

 14
Author: Danack,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-06-01 11:04:47

Hemos hecho algunas optimizaciones para uSwitch.com recientemente para comprimir algunos de los activos estáticos en nuestro sitio. Aunque configuramos un proxy nginx completo para hacer esto, también he creado una pequeña aplicación Heroku que proxy entre CloudFront y S3 para comprimir contenido: http://dfl8.co

Dado que los objetos S3 de acceso público se pueden acceder utilizando una estructura de URL simple, http://dfl8.co solo usa la misma estructura. Es decir, las siguientes URLs son equivalentes:

http://pingles-example.s3.amazonaws.com/sample.css
http://pingles-example.dfl8.co/sample.css
http://d1a4f3qx63eykc.cloudfront.net/sample.css
 5
Author: pingles,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-08-18 14:17:07

Ayer Amazon anunció una nueva función, ahora puede habilitar gzip en su distribución.

Funciona con s3 sin añadido .gz archivos a ti mismo, he probado la nueva característica hoy y funciona muy bien. (sin embargo, necesitas invalidar tus objetos actuales)

Más información

 5
Author: Chris,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-12-18 12:55:36

Puede configurar CloudFront para comprimir automáticamente archivos de ciertos tipos y servir los archivos comprimidos.

Consulte la Guía para desarrolladores de AWS

 0
Author: Rafi,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-07-06 07:42:51