Servant CSS et JavaScript compressés à partir d'Amazon CloudFront via S3

Je cherchais des moyens d'accélérer le chargement de mon site et j'aimerais explorer une meilleure utilisation de Cloudfront.

Parce 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 jusqu'à présent utilisé pour héberger toutes mes images, qui sont référencées par leur nom de domaine Cloudfront dans mon code de site, et optimisées avec loin -en-têtes futurs.

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 au format gzip depuis Cloudfront, et que le gain du gzipping (environ 75%) l'emporte sur celui d'utiliser un CDN (environ 50%): Amazon S3 (et donc Cloudfront) ne prend pas en charge la diffusion de contenu gzippé de manière standard en utilisant l'en-tête HTTP Accept-Encoding envoyé par les navigateurs pour indiquer leur prise en charge de la compression gzip, et ils n'ont donc pas pu Gzip et servir des composants à la volée.

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

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

2. garder les composants auto-hébergés et configurer notre serveur pour détecter les demandes entrantes et effectuer le GZipping à la volée selon les besoins, ce que j'ai choisi de faire jusqu'à présent.

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

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

Jusqu'à présent, je n'ai pas pu implémenter la nouvelle fonctionnalité sur mon serveur. Le billet de blog que j'ai lié ci-dessus, qui est le seul que j'ai trouvé détaillant le changement, semble impliquer que vous ne pouvez activer le gzipping (barres de contournement, que je ne veux pas utiliser), si vous optez pour une origine personnalisée, qui Je préfère ne pas: je trouve plus simple d'héberger les fichiers correspondants sur mon serveur Cloudfront et de les lier à partir de là. Malgré la 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 une origine personnalisée, et si oui, quelle configuration de code y parviendra;

• comment configurer les en-têtes css et javascript pour vous assurer qu'ils sont servis au format gzip depuis Cloudfront.

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

Réponse originale:

La réponse est de compresser les fichiers CSS et JavaScript. Oui, tu l'as bien lu.

gzip -9 production.min.css

Cela produira production.min.css.gz. Supprimez le .gz, téléchargez vers S3 (ou quel que soit le serveur d'origine que vous utilisez) et définissez explicitement l'en- Content-Encodingtête du fichier gzip.

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

1. Il ne nécessite aucun processeur pour qu'Apache puisse compresser le contenu lorsque le fichier est demandé.
2. Les fichiers sont compressés au plus haut niveau de compression (en supposant gzip -9 ).
3. Vous diffusez le fichier à partir d'un CDN.

En supposant que vos fichiers CSS / JavaScript sont (a) minifiés et (b) suffisamment volumineux pour justifier le processeur requis pour décompresser sur la machine de l'utilisateur, vous pouvez obtenir des gains de performances significatifs ici.

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

Ma réponse est un décollage à ce sujet: 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 css et js. Soyez prudent en nommant et en testant dans Safari. Parce que safari ne gérera .css.gzni .js.gzfichiers.

site.jset site.js.jgzet site.csset site.gz.css (vous devrez définir l'en- content-encodingtête sur le type MIME correct pour que ceux-ci fonctionnent 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; Ceci teste pour s'assurer que le navigateur peut gérer le code gzippé et fournir une sauvegarde s'il ne le peut pas.

Ensuite, faites 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> 

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

Cloudfront prend en charge le gzipping.

Cloudfront se connecte à votre serveur via HTTP 1.0. Par défaut, certains serveurs Web, y compris nginx, ne servent pas de contenu compressé aux connexions HTTP 1.0, mais vous pouvez le dire en ajoutant:

gzip_http_version 1.0

à votre configuration nginx. La configuration équivalente peut être définie pour le serveur Web que vous utilisez.

Cela a pour effet secondaire de faire en sorte que les connexions persistantes ne fonctionnent pas pour les connexions HTTP 1.0, mais comme les avantages de la compression sont énormes, cela vaut vraiment le coup.

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

Éditer

Servir du contenu compressé à la volée à travers le cloud d'Amazon est dangereux et ne devrait probablement pas être fait. Fondamentalement, si votre serveur Web est en train de compresser le contenu, il ne définira pas de longueur de contenu et enverra plutôt les données en bloc.

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 de version mise en cache jusqu'à son expiration.

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

Nous avons récemment effectué quelques optimisations pour uSwitch.com afin de compresser certains des actifs statiques de notre site. Bien que nous ayons configuré 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

Étant donné que les objets S3 accessibles au public sont accessibles à l'aide d'une structure d'URL simple, http://dfl8.co utilise simplement la même structure. C'est-à-dire que les URL suivantes sont équivalentes:

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

Hier, Amazon a annoncé une nouvelle fonctionnalité, vous pouvez maintenant activer gzip sur votre distribution.

Cela fonctionne avec s3 sans ajouter de fichiers .gz vous-même, j'ai essayé la nouvelle fonctionnalité aujourd'hui et cela fonctionne très bien. (vous devez cependant invalider vos objets actuels)

Plus d'informations

Vous pouvez configurer CloudFront pour compresser automatiquement les fichiers de certains types et servir les fichiers compressés.

Voir le Guide du développeur AWS