Traitement de fichiers CSS et JavaScript gzippés à partir d'Amazon CloudFront via S3
Je cherchais des moyens d'accélérer le chargement de mon site et l'un des moyens que j'aimerais explorer consiste à utiliser davantage Cloudfront.
Cloudfront n’ayant pas été conçu à l’origine comme un CDN d’origine personnalisée et ne prenant pas en charge gzipping, je l’utilise 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 de manière lointaine. -futures en-têtes.
Les fichiers CSS et javascript, en revanche, sont hébergés sur mon propre serveur, car j’avais l’impression qu’ils ne pouvaient pas être servis avec Cloud Computing et que le gain de gzipping (environ 75%) était supérieur à ce qu’il était. Utilisation d’un CDN (environ 50%): Amazon S3 (et donc Cloudfront) ne prend pas en charge la fourniture standard de contenu gzippé à l’aide de l’en-tête HTTP Accept-Encoding envoyé par les navigateurs pour indiquer leur prise en charge de la compression gzip, et ils ne pouvaient donc pas utiliser Gzip et servir des composants à la volée.
Ainsi, j’avais l’impression, jusqu’à présent, qu’il fallait choisir entre deux alternatives:
déplacez tous les actifs sur Amazon CloudFront et oubliez GZipping;
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 étaient solutions pour résoudre ce problème, mais essentiellement ne fonctionnaient pas . [ lien ].
Il semble maintenant qu'Amazon Cloudfront prenne en charge Origin personnalisée et que il est désormais possible d'utiliser la méthode HTTP Accept-Encoding standard pour la fourniture de contenu gzippé si vous utilisez une origine personnalisée [ lien ].
Je n'ai pas encore été capable d'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 que gzipping (solutions de contournement, que je ne souhaite pas utiliser), si vous optez pour Origine personnalisée, qui Je préférerais que non: je trouve plus simple d’héberger les fichiers correspondants sur mon serveur Cloudfront et d’y accéder par l’intermédiaire de liens. Malgré la lecture attentive de la documentation, je ne sais pas:
la nouvelle fonctionnalité signifie-t-elle que les fichiers doivent être hébergés sur mon propre serveur de domaine via Origine personnalisée et, dans l'affirmative, quelle configuration de code permet d'atteindre cet objectif;
comment configurer les en-têtes css et javascript pour s'assurer qu'ils sont gzippés depuis Cloudfront.
UPDATE: Amazon prend désormais en charge la compression gzip. Cette opération n'est donc plus nécessaire. Annonce Amazon
Réponse originale:
La réponse est de gzip les fichiers CSS et JavaScript. Oui, tu l'as bien lu.
gzip -9 production.min.css
Cela produira production.min.css.gz. Retirer le .gz, chargez-le sur S3 (ou le serveur d’origine que vous utilisez) et définissez explicitement le Content-Encoding _ en-tête du fichier à gzip.
Ce n'est pas à la volée, mais vous pouvez très facilement l'intégrer dans vos scripts de construction/déploiement. Les avantages sont:
- Apache ne nécessite aucun processeur pour gzip le contenu lorsque le fichier est demandé.
- Les fichiers sont compressés au plus haut niveau de compression (en supposant que
gzip -9). - 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 processeur nécessaire à la décompression sur la machine de l'utilisateur, vous pouvez obtenir des gains de performances significatifs ici.
Rappelez-vous simplement que si vous modifiez 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 sur ceci: http://blog.kenweiner.com/2009/08/serving-gzipped-javascript-files-from.html
En vous appuyant sur la réponse de Skyler, vous pouvez télécharger une version gss ou non des versions css et js. Soyez prudent en nommant et testez dans Safari. Parce que le safari ne gèrera pas .css.gz ou .js.gz des dossiers.
site.js et site.js.jgz et site.css et site.gz.css _ (vous aurez besoin de régler le content-encoding en-tête avec le bon type MIME pour que ces derniers servent correctement)
Puis dans votre page mis.
<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 vérifie que le navigateur peut gérer le code compressé 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 fichiers js sont dans un 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, alors 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 le contenu gzippé aux connexions HTTP 1.0, mais vous pouvez le faire 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, il vaut vraiment la peine de les échanger.
Tiré de http://www.cdnplanet.com/blog/gzip-nginx-cloudfront/
Modifier
Le service de contenu compressé à la volée via le cloud Amazon est dangereux et ne devrait probablement pas être fait. Fondamentalement, si votre serveur Web est en train de gzipper 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 prématurément interrompue, Cloudfront met toujours en cache le résultat partiel et le sert comme version mise en cache jusqu'à son expiration.
La réponse acceptée consistant à gzipper d'abord le disque puis à servir la version gzippée est une meilleure idée, car Nginx sera en mesure de définir l'en-tête Content-Length et donc Cloudfront ignorera les versions tronquées.
Nous avons récemment optimisé uSwitch.com pour compresser certains des actifs statiques de notre site. Bien que nous ayons configuré un proxy nginx complet pour ce faire, nous avons également mis au point une petite application Heroku qui sert de proxy entre CloudFront et S3 pour compresser le contenu: http://dfl8.co
Il est possible d'accéder aux objets S3 accessibles au public en utilisant une simple structure d'URL, http://dfl8.co utilise simplement la même structure. C'est à dire. 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 les fichiers .gz ajoutés, j'ai essayé la nouvelle fonctionnalité aujourd'hui et cela fonctionne très bien. (besoin d'invalider vos objets actuels cependant)
Vous pouvez configurer CloudFront pour compresser automatiquement les fichiers de certains types et servir les fichiers compressés.
Voir AWS Guide du développeur