Servir des CSS et JavaScript gzippés depuis Amazon CloudFront via S3

Question

J'ai cherché des moyens d'accélérer le chargement de mon site et l'une des solutions que j'aimerais explorer est d'utiliser davantage Cloudfront.

Étant donné que Cloudfront n'a pas été conçu à l'origine comme un CDN d'origine personnalisé et qu'il ne prend pas en charge le gzipping, je l'ai utilisé jusqu'à présent pour héberger toutes mes images, qui sont référencées par leur cname Cloudfront dans le code de mon site, et optimisées avec des en-têtes far-futures.

Les fichiers CSS et javascript, en revanche, sont hébergés sur mon propre serveur, car jusqu'à présent, j'avais l'impression qu'ils ne pouvaient pas être servis compressés à partir de Cloudfront, et que le gain lié à la compression (environ 75 %) l'emportait sur celui lié à l'utilisation d'un CDN (environ 50 %) : Amazon S3 (et donc Cloudfront) ne permettait pas de servir du contenu compressé de manière standard en utilisant l'en-tête HTTP Accept-Encoding qui est envoyé par les navigateurs pour indiquer leur prise en charge de la compression gzip, et il n'était donc pas possible de compresser et de servir les composants à la volée.

J'avais donc l'impression, jusqu'à présent, qu'il fallait choisir entre deux alternatives :

1. déplacer tous les actifs vers Amazon CloudFront et oublier le GZipping ;

2. garder les composants auto-hébergés et configurer notre serveur pour qu'il détecte les requêtes entrantes et effectue le GZipping à la volée comme il convient, ce que j'ai choisi de faire jusqu'à présent.

Il y a étaient des solutions de contournement pour résoudre ce problème, mais essentiellement ces n'a pas fonctionné . [ lien ].

Maintenant, il semble qu'Amazon Cloudfront prenne en charge l'origine personnalisée, et cela il est désormais possible d'utiliser la méthode standard HTTP Accept-Encoding pour servir du contenu gzippé si vous utilisez une origine personnalisée. [ lien ].

Je n'ai pas encore été en mesure de mettre en œuvre la nouvelle fonctionnalité sur mon serveur. L'article du blog dont j'ai donné le lien ci-dessus, qui est le seul que j'ai trouvé détaillant le changement, semble impliquer que vous ne pouvez activer le gzipping (avec des solutions de contournement, que je ne veux pas utiliser), que si vous optez pour une origine personnalisée, ce que je ne préfère pas : Je trouve plus simple d'héberger les fichiers correspondants sur mon serveur Cloudfront, et de créer des liens vers eux à partir de là. Malgré une lecture attentive de la documentation, je ne sais pas :

• si la nouvelle fonctionnalité signifie que les fichiers doivent être hébergés sur mon propre serveur de domaine via origine personnalisée et, si oui, quelle configuration de code permettra d'y parvenir ;

• comment configurer les en-têtes css et javascript pour s'assurer qu'ils sont servis gzippés depuis Cloudfront.

Answer 1

UPDATE : Amazon prend désormais en charge la compression gzip, ce n'est donc plus nécessaire. Annonce d'Amazon

Réponse originale :

La réponse est de gzip les fichiers CSS et JavaScript. Oui, vous avez bien lu.

gzip -9 production.min.css

Cela produira production.min.css.gz . Retirer le .gz téléchargez vers S3 (ou tout autre serveur d'origine que vous utilisez) et définissez explicitement l'attribut Content-Encoding pour le fichier à gzip .

Ce n'est pas un gzipping à la volée, mais vous pourriez très facilement l'envelopper dans vos scripts de construction/déploiement. Les avantages sont :

1. Apache n'a pas besoin de CPU pour compresser le contenu lorsque le fichier est demandé.
2. Les fichiers sont gzippés au niveau de compression le plus élevé (en supposant que gzip -9 ).
3. Vous servez le fichier à partir d'un CDN.

En supposant que vos fichiers CSS/JavaScript soient (a) minifiés et (b) suffisamment volumineux pour justifier le CPU nécessaire à leur décompression sur la machine de l'utilisateur, vous pouvez obtenir des gains de performance significatifs.

N'oubliez pas : si vous apportez une modification à un fichier mis en cache dans CloudFront, veillez à invalider le cache après avoir effectué ce type de modification.

Answer 2

Ma réponse est un décalage par rapport à ça : http://blog.kenweiner.com/2009/08/serving-gzipped-javascript-files-from.html

En vous basant sur la réponse de Skyler, vous pouvez télécharger une version gzip et non gzip des fichiers css et js. Faites attention aux noms et testez-les dans Safari. Parce que Safari ne gère pas .css.gz o .js.gz des fichiers.

site.js y site.js.jgz y site.css y site.gz.css (vous devrez définir l'option content-encoding au bon type MIME pour qu'ils puissent être utilisés correctement)

Ensuite, dans votre page, mettez.

<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 est juste sr_gzipEnabled = true; Ce test permet de s'assurer que le navigateur peut gérer le code gzippé et de fournir une solution de secours si ce n'est pas le cas.

Faites ensuite quelque chose de similaire dans le pied de page en supposant que tous vos js sont dans un seul fichier et peuvent aller dans le pied de page.

<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> 

UPDATE : Amazon prend désormais en charge la compression gzip. Annonce, donc ce n'est plus nécessaire. Annonce d'Amazon

Answer 3

Cloudfront prend en charge le gzipping.

Cloudfront se connecte à votre serveur via HTTP 1.0. Par défaut, certains serveurs Web, dont nginx, ne servent pas de contenu gzippé aux connexions HTTP 1.0, mais vous pouvez lui demander de le faire en ajoutant l'option :

gzip_http_version 1.0

à votre configuration nginx. La configuration équivalente peut être définie pour n'importe quel serveur web que vous utilisez.

Cela a pour effet secondaire que les connexions keep-alive ne fonctionnent pas pour les connexions HTTP 1.0, mais comme les avantages de la compression sont énormes, cela en vaut vraiment la peine.

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

Modifier

Servir du contenu qui est gzippé à la volée par le biais d'Amazon cloud front est dangereux et ne devrait probablement pas être fait. En effet, si votre serveur web compresse le contenu, il ne définira pas de Content-Length et enverra les données en morceaux.

Si la connexion entre Cloudfront et votre serveur est interrompue et rompue prématurément, Cloudfront met toujours en cache le résultat partiel et le sert comme version en cache jusqu'à son expiration.

La réponse acceptée, qui consiste à le compresser d'abord sur le disque et à servir ensuite la version compressée, est une meilleure idée, car Nginx sera en mesure de définir l'en-tête Content-Length, et Cloudfront rejettera les versions tronquées.

Answer 4

Documentation pertinente sur CloudFront+gzip d'AWS :

http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html

Answer 5

Nous avons récemment effectué quelques optimisations pour uSwitch.com afin de compresser certaines des ressources statiques de notre site. Bien que nous ayons mis en place un proxy nginx complet pour ce faire, j'ai également mis en place une petite application Heroku qui fait office de proxy entre CloudFront et S3 pour compresser le contenu : http://dfl8.co

Les objets S3 accessibles au public peuvent être consultés à l'aide d'une structure URL simple, http://dfl8.co utilise juste la même structure. Par exemple, les URLs suivantes sont équivalentes :

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