enable Servindo CSS e JavaScript com gzip do Amazon CloudFront via S3




aws s3 enable gzip (5)

Ontem amazon anunciou novo recurso, agora você pode ativar o gzip em sua distribuição.

Ele funciona com o s3 sem adicionar arquivos .gz, tentei o novo recurso hoje e ele funciona muito bem. (precisa invalidar seus objetos atuais)

Mais informações

Eu tenho procurado maneiras de fazer meu site carregar mais rápido e uma maneira que eu gostaria de explorar é fazer um uso maior do Cloudfront.

Como o Cloudfront originalmente não foi projetado como um CDN de origem personalizada e, por não ter suporte ao gzipping, até agora eu o usei para hospedar todas as minhas imagens, que são referenciadas pela cname do Cloudfront no código do site e otimizadas com -futuros cabeçalhos.

Os arquivos CSS e javascript, por outro lado, estão hospedados em meu próprio servidor, porque até agora eu estava com a impressão de que eles não poderiam ser servidos com gzip da Cloudfront, e que o ganho de gzipping (cerca de 75%) supera isso de usar um CDN (cerca de 50 por cento): O Amazon S3 (e, portanto, o Cloudfront) não suportava a exibição de conteúdo compactado de maneira padrão usando o cabeçalho HTTP Accept-Encoding enviado pelos navegadores para indicar seu suporte à compactação gzip e então eles não foram capazes de Gzip e servir componentes na mosca.

Assim, fiquei com a impressão, até agora, de que era preciso escolher entre duas alternativas:

  1. mova todos os ativos para o Amazon CloudFront e esqueça o GZipping;

  2. mantenha os componentes auto-hospedados e configure nosso servidor para detectar solicitações de entrada e executar GZipping on-the-fly conforme apropriado, que é o que eu escolhi fazer até agora.

Havia soluções alternativas para resolver esse problema, mas essencialmente isso não funcionou . [ link ].

Agora, parece que o Amazon Cloudfront suporta origem personalizada e que agora é possível usar o método HTTP Accept-Encoding padrão para servir conteúdo gzipado se você estiver usando uma Custom Origin [ link ].

Até agora não consegui implementar o novo recurso no meu servidor. A postagem do blog que eu criei acima, que é a única que eu encontrei detalhando a mudança, parece implicar que você só pode habilitar o gzipping (barras alternativas, que eu não quero usar), se você optar pela origem personalizada, que Prefiro não: acho mais simples hospedar os arquivos correspondentes no meu servidor Cloudfront e vinculá-los a partir deles. Apesar de ler atentamente a documentação, não sei:

  • se o novo recurso significa que os arquivos devem ser hospedados em meu próprio servidor de domínio através de origem personalizada e, em caso afirmativo, qual configuração de código vai conseguir isso;

  • como configurar os cabeçalhos css e javascript para garantir que eles sejam servidos com gzip do Cloudfront.


Você pode configurar o CloudFront para compactar automaticamente arquivos de determinados tipos e atender os arquivos compactados.

Veja o Guia do desenvolvedor da AWS


Minha resposta é uma decolagem sobre isso: http://blog.kenweiner.com/2009/08/serving-gzipped-javascript-files-from.html

Com base na resposta do skyler, você pode fazer upload de uma versão gzip e non-gzip do css e do js. Seja cuidadoso ao nomear e testar no Safari. Porque safari não irá lidar com arquivos .js.gz ou .js.gz .

site.js e site.js.jgz e site.css e site.gz.css (você precisará definir o cabeçalho de content-encoding para o tipo MIME correto para que eles sejam exibidos corretamente)

Então na sua página colocar.

<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 é apenas sr_gzipEnabled = true; Isso testa para garantir que o navegador possa manipular o código compactado e fornecer um backup, se não puder.

Então faça algo similar no rodapé supondo que todos os seus js estejam em um arquivo e possam entrar no rodapé.

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

ATUALIZAÇÃO: A Amazon agora suporta a compactação gzip. Anúncio, então isso não é mais necessário. Anúncio da Amazon


Cloudfront suporta gzipping.

Cloudfront se conecta ao seu servidor via HTTP 1.0. Por padrão, alguns servidores da Web, incluindo nginx, não fornecem conteúdo compactado para conexões HTTP 1.0, mas você pode fazer isso adicionando:

gzip_http_version 1.0

para sua configuração nginx. A configuração equivalente pode ser definida para qualquer servidor da Web que você esteja usando.

Isso tem um efeito colateral de fazer conexões keep-alive não funcionarem para conexões HTTP 1.0, mas como os benefícios da compressão são enormes, definitivamente vale a pena.

Extraído de http://www.cdnplanet.com/blog/gzip-nginx-cloudfront/

Editar

Servir conteúdo que é compactado rapidamente através da nuvem da Amazon é perigoso e provavelmente não deve ser feito. Basicamente, se o seu servidor web está gzipando o conteúdo, ele não irá definir um Content-Length e, em vez disso, enviará os dados como chunked.

Se a conexão entre o Cloudfront e o servidor for interrompida e prematuramente interrompida, o Cloudfront ainda armazenará em cache o resultado parcial e o exibirá como a versão em cache até expirar.

A resposta aceita de gzipping primeiro em disco e, em seguida, servindo a versão gzipped é uma idéia melhor, como Nginx será capaz de definir o cabeçalho Content-Length, e assim Cloudfront irá descartar versões truncadas.


Fizemos algumas otimizações para o uSwitch.com recentemente para compactar alguns dos ativos estáticos em nosso site. Embora tenhamos configurado um proxy nginx inteiro para fazer isso, eu também montei um pequeno aplicativo Heroku que faz proxies entre o CloudFront e o S3 para compactar o conteúdo: http://dfl8.co

Considerando que os objetos do S3 acessíveis publicamente podem ser acessados ​​usando uma estrutura de URL simples, o http://dfl8.co apenas usa a mesma estrutura. Ou seja, os seguintes URLs são equivalentes:

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






amazon-cloudfront