Sirviendo CSS y JavaScript comprimidos desde Amazon CloudFront a través de S3

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

Debido a que Cloudfront originalmente no fue diseñado como un CDN de origen personalizado y porque no admitía el gzipping, hasta ahora lo he estado usando para alojar todas mis imágenes, a las que hace referencia su nombre de Cloudfront en el código de mi sitio, y optimizado con mucho -futures encabezados.

Los archivos CSS y JavaScript, por otro lado, están alojados en mi propio servidor, porque hasta ahora tenía la impresión de que no podían ser enviados desde Cloudfront, y que la ganancia de gzipping (alrededor del 75 por ciento) supera eso por usar un CDN (aproximadamente el 50 por ciento): Amazon S3 (y, por lo tanto, Cloudfront) no admitía la publicación de contenido comprimido de manera estándar al usar el encabezado HTTP Accept-Encoding que se envía por los navegadores para indicar su compatibilidad con la compresión gzip, y por lo que no pudieron Gzip y servir componentes sobre la marcha.

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

1. mover todos los activos a Amazon CloudFront y olvidarse de GZipping;

2. mantenga los componentes autohospedados 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.

No eran soluciones para resolver este problema, pero esencialmente éstos no funcionaron . [ enlace ].

Ahora, parece que Amazon Cloudfront es compatible con el origen personalizado, y que ahora es posible usar el método de codificación de aceptación HTTP estándar para servir contenido comprimido si está utilizando un origen personalizado [ enlace ].

Hasta ahora no he podido implementar la nueva función en mi servidor. La publicación de blog a la que he vinculado anteriormente, que es la única que encontré que detalla el cambio, parece implicar que solo puede habilitar el gzipping (soluciones alternativas de barras, que no quiero usar), si opta por un origen personalizado, que Prefiero no hacerlo: me resulta más sencillo alojar los archivos correspondientes en mi servidor Cloudfront y vincularlos desde allí. A pesar de leer detenidamente la documentación, no sé:

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

• cómo configurar los encabezados css y javascript para asegurarse de que se sirvan comprimidos desde Cloudfront.

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

Respuesta original:

La respuesta es descomprimir los archivos CSS y JavaScript. Sí, lo leiste bien.

gzip -9 production.min.css

Esto producirá production.min.css.gz. Elimine .gz, cargue en S3 (o el servidor de origen que esté utilizando) y configure explícitamente el Content-Encodingencabezado para el archivo gzip.

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

1. No requiere CPU para que Apache comprima 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ás sirviendo el archivo desde un CDN.

Suponiendo que sus archivos CSS / JavaScript están (a) minimizados y (b) lo suficientemente grandes como para justificar la CPU requerida para descomprimir en la máquina del usuario, puede obtener ganancias significativas de rendimiento aquí.

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

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

A partir de la respuesta de Skyler, puede cargar una versión gzip y no gzip de css y js. Tenga cuidado al nombrar y probar en Safari. Porque el safari no manejará .css.gzo.js.gz archivará.

site.jsy site.js.jgzy site.cssy site.gz.css (deberá configurar el content-encodingencabezado con el tipo MIME correcto para que estos se publiquen correctamente)

Luego en su 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; esto prueba para asegurarse de que el navegador pueda manejar el código comprimido y proporcionar una copia de seguridad si no pueden.

Luego, haga algo similar en el pie de página, suponiendo que todos sus js estén en un archivo y puedan 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 es compatible con la compresión gzip. Anuncio, por lo que ya no es necesario. Anuncio de Amazon

Cloudfront admite gzipping.

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

gzip_http_version 1.0

a su configuración 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 de mantenimiento no funcionen para las conexiones HTTP 1.0, pero como los beneficios de la compresión son enormes, definitivamente vale la pena.

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

Editar

Servir contenido que se comprime sobre la marcha a través del frente de la nube de Amazon es peligroso y probablemente no debería hacerse. Básicamente, si su servidor web está comprimiendo el contenido, no establecerá una longitud de contenido y, en su lugar, enviará los datos como fragmentados.

Si la conexión entre Cloudfront y su servidor se interrumpe y se corta 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 comprimirlo primero en el disco y luego servir la versión comprimida es una mejor idea, ya que Nginx podrá establecer el encabezado Content-Length, por lo que Cloudfront descartará las versiones truncadas.

Hemos realizado 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 de Heroku que sirve de proxy entre CloudFront y S3 para comprimir contenido: http://dfl8.co

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

http://pingles-example.s3.amazonaws.com/sample.css
http://pingles-example.dfl8.co/sample.css
http://d1a4f3qx63eykc.cloudfront.net/sample.css

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

Funciona con s3 sin archivos .gz agregados, probé la nueva característica hoy y funciona muy bien. (aunque necesita invalidar sus objetos actuales)

Más información

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

Consulte la Guía para desarrolladores de AWS