Bereitstellen von komprimiertem CSS und JavaScript von Amazon CloudFront über S3

Ich habe nach Möglichkeiten gesucht, meine Website schneller zu laden, und eine Möglichkeit, die ich untersuchen möchte, besteht darin, Cloudfront stärker zu nutzen.

Da Cloudfront ursprünglich nicht als CDN mit benutzerdefiniertem Ursprung konzipiert war und GZIP nicht unterstützte, habe ich es bisher verwendet, um alle meine Bilder zu hosten, auf die in meinem Site-Code durch ihren Cloudfront-C-Namen verwiesen wird, und mit weit optimiert -Futures Header.

CSS- und Javascript-Dateien werden dagegen auf meinem eigenen Server gehostet, da ich bisher den Eindruck hatte, dass sie nicht über Cloudfront gzippt bereitgestellt werden können und dass der Gewinn durch gzipping (ca. 75 Prozent) diesen überwiegt Verwendung eines CDN (ca. 50 Prozent): Amazon S3 (und damit Cloudfront) unterstützte das standardmäßige Bereitstellen von komprimiertem Inhalt nicht, indem der von Browsern gesendete HTTP Accept-Encoding-Header verwendet wurde, um die Unterstützung für die gzip-Komprimierung anzugeben Daher waren sie nicht in der Lage, Komponenten im laufenden Betrieb zu Gzipen und zu bedienen.

So hatte ich bisher den Eindruck, man müsse zwischen zwei Alternativen wählen:

1. Verschieben Sie alle Assets in Amazon CloudFront und vergessen Sie GZipping.

2. Halten Sie die Komponenten selbst gehostet und konfigurieren Sie unseren Server so, dass eingehende Anforderungen erkannt werden und das entsprechende GZipping im laufenden Betrieb durchgeführt wird. Dies habe ich bisher gewählt.

Es gab Problemumgehungen, um dieses Problem zu lösen, aber im Wesentlichen funktionierten diese nicht . [ Link ].

Es scheint, dass Amazon Cloudfront benutzerdefinierten Ursprung unterstützt und dass es jetzt möglich ist, die Standardmethode für die HTTP-Akzeptanzcodierung zum Bereitstellen von komprimiertem Inhalt zu verwenden, wenn Sie einen benutzerdefinierten Ursprung verwenden [ Link ].

Ich konnte die neue Funktion bisher nicht auf meinem Server implementieren. Der Blog-Beitrag, auf den ich oben verlinkt habe und der der einzige ist, bei dem ich die Änderung detailliert gefunden habe, scheint zu implizieren, dass Sie das Zippen nur aktivieren können (Balkenumgehungen, die ich nicht verwenden möchte), wenn Sie sich für einen benutzerdefinierten Ursprung entscheiden Ich möchte lieber nicht: Ich finde es einfacher, die entsprechenden Dateien auf meinem Cloudfront-Server zu hosten und von dort aus auf sie zu verlinken. Trotz sorgfältiger Lektüre der Dokumentation weiß ich nicht:

• ob die neue Funktion bedeutet, dass die Dateien über einen benutzerdefinierten Ursprung auf meinem eigenen Domänenserver gehostet werden sollen , und wenn ja, mit welchem ​​Code-Setup wird dies erreicht;

• So konfigurieren Sie die CSS- und Javascript-Header, um sicherzustellen, dass sie über Cloudfront gzippt bereitgestellt werden.

UPDATE: Amazon unterstützt jetzt die gzip-Komprimierung, sodass dies nicht mehr benötigt wird. Amazon Ankündigung

Ursprüngliche Antwort:

Die Antwort ist, die CSS- und JavaScript-Dateien zu komprimieren. Ja, das hast du richtig gelesen.

gzip -9 production.min.css

Dies wird produzieren production.min.css.gz. Entfernen Sie den .gz, laden Sie ihn auf S3 (oder den von Ihnen verwendeten Ursprungsserver) hoch und setzen Sie den Content-EncodingHeader für die Datei explizit auf gzip.

Es ist kein spontanes Gzipping, aber Sie können es sehr einfach in Ihre Build- / Bereitstellungsskripte einbinden. Die Vorteile sind:

1. Apache benötigt keine CPU, um den Inhalt zu komprimieren, wenn die Datei angefordert wird.
2. Die Dateien werden mit der höchsten Komprimierungsstufe (vorausgesetzt gzip -9) komprimiert .
3. Sie liefern die Datei von einem CDN.

Angenommen, Ihre CSS / JavaScript-Dateien sind (a) minimiert und (b) groß genug, um die zum Dekomprimieren auf dem Computer des Benutzers erforderliche CPU zu rechtfertigen, können Sie hier erhebliche Leistungssteigerungen erzielen.

Denken Sie daran: Wenn Sie eine Änderung an einer in CloudFront zwischengespeicherten Datei vornehmen, stellen Sie sicher, dass Sie den Cache nach dieser Art von Änderung ungültig machen.

Meine Antwort lautet: http://blog.kenweiner.com/2009/08/serving-gzipped-javascript-files-from.html

Aufbauend auf der Antwort von skyler können Sie eine gzip- und eine nicht-gzip-Version von css und js hochladen. Seien Sie vorsichtig beim Benennen und Testen in Safari. Da Safari nicht verarbeiten .css.gzoder .js.gzDateien.

site.jsund site.js.jgzund site.cssund site.gz.css (Sie müssen den content-encodingHeader auf den richtigen MIME-Typ setzen, damit diese richtig funktionieren)

Dann in deine Seite setzen.

<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 ist nur sr_gzipEnabled = true; Dieser Test stellt sicher, dass der Browser mit dem komprimierten Code umgehen kann, und stellt ein Backup bereit, wenn dies nicht möglich ist.

Machen Sie dann etwas Ähnliches in der Fußzeile, vorausgesetzt, alle Ihre js befinden sich in einer Datei und können in die Fußzeile gehen.

<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 unterstützt jetzt die gzip-Komprimierung. Ankündigung, daher wird dies nicht mehr benötigt. Amazon Ankündigung

Cloudfront unterstützt Gzipping.

Cloudfront stellt über HTTP 1.0 eine Verbindung zu Ihrem Server her. Standardmäßig stellen einige Webserver, einschließlich Nginx, keine komprimierten Inhalte für HTTP 1.0-Verbindungen bereit. Sie können dies jedoch durch Hinzufügen von:

gzip_http_version 1.0

zu Ihrer Nginx-Konfiguration. Die entsprechende Konfiguration kann für jeden von Ihnen verwendeten Webserver festgelegt werden.

Dies hat den Nebeneffekt, dass Keep-Alive-Verbindungen für HTTP 1.0-Verbindungen nicht funktionieren. Da die Vorteile der Komprimierung jedoch enorm sind, lohnt sich der Kompromiss auf jeden Fall.

Entnommen aus http://www.cdnplanet.com/blog/gzip-nginx-cloudfront/

Bearbeiten

Das Bereitstellen von Inhalten, die im laufenden Betrieb über die Amazon Cloud Front gezippt werden, ist gefährlich und sollte wahrscheinlich nicht durchgeführt werden. Wenn Ihr Webserver den Inhalt komprimiert, legt er grundsätzlich keine Inhaltslänge fest und sendet die Daten stattdessen als Chunked.

Wenn die Verbindung zwischen Cloudfront und Ihrem Server unterbrochen und vorzeitig getrennt wird, speichert Cloudfront das Teilergebnis weiterhin im Cache und dient als zwischengespeicherte Version, bis es abläuft.

Die akzeptierte Antwort, es zuerst auf der Festplatte zu komprimieren und dann die komprimierte Version bereitzustellen, ist eine bessere Idee, da Nginx den Header für die Inhaltslänge festlegen kann und Cloudfront daher abgeschnittene Versionen verwirft.

Wir haben kürzlich einige Optimierungen für uSwitch.com vorgenommen, um einige der statischen Assets auf unserer Website zu komprimieren. Obwohl wir dafür einen ganzen Nginx-Proxy eingerichtet haben, habe ich auch eine kleine Heroku-App zusammengestellt, die Proxys zwischen CloudFront und S3 erstellt, um Inhalte zu komprimieren: http://dfl8.co

Da auf öffentlich zugängliche S3-Objekte über eine einfache URL-Struktur zugegriffen werden kann, verwendet http://dfl8.co nur dieselbe Struktur. Dh die folgenden URLs sind äquivalent:

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

Gestern hat amazon eine neue Funktion angekündigt. Jetzt können Sie gzip für Ihre Distribution aktivieren.

Es funktioniert mit s3 ohne selbst hinzugefügte .gz-Dateien. Ich habe die neue Funktion heute ausprobiert und sie funktioniert hervorragend. (Sie müssen jedoch Ihre aktuellen Objekte ungültig machen.)

Mehr Info

Sie können CloudFront so konfigurieren, dass Dateien bestimmter Typen automatisch komprimiert und die komprimierten Dateien bereitgestellt werden.

Siehe AWS Developer Guide