Minifique e compacte payloads de rede com o gzip

Houssein Djirdeh

Este codelab explora como a minificação e a compactação do pacote JavaScript para o aplicativo a seguir melhoram a performance da página, reduzindo o tamanho da solicitação do app.

Medir

Antes de adicionar otimizações, é sempre recomendável analisar o estado atual do aplicativo.

• Para visualizar o site, pressione View App. Em seguida, pressione Fullscreen .

Esse app, que também foi abordado no codelab "Remover código não utilizado", permite que você vote no seu gatinho favorito. 🐈

Agora confira o tamanho desse aplicativo:

1. Pressione "Control+Shift+J" (ou "Command+Option+J" no Mac) para abrir as Ferramentas do desenvolvedor.
2. Clique na guia Rede.
3. Marque a caixa de seleção Desativar cache.
4. Atualize o app.

Embora o codelab "Remove unused code" tenha feito muito progresso para reduzir o tamanho do pacote, 225 KB ainda é bastante grande.

Minificação

Considere o bloco de código a seguir.

function soNice() {
  let counter = 0;

  while (counter < 100) {
    console.log('nice');
    counter++;
  }
}

Se essa função for salva em um arquivo próprio, o tamanho do arquivo será de cerca de 112 B (bytes).

Se todos os espaços em branco forem removidos, o código resultante será parecido com este:

function soNice(){let counter=0;while(counter<100){console.log("nice");counter++;}}

O tamanho do arquivo agora é de cerca de 83 B. Se ele for ainda mais danificado ao reduzir o comprimento do nome da variável e modificar algumas expressões, o código final poderá ficar assim:

function soNice(){for(let i=0;i<100;)console.log("nice"),i++}

O tamanho do arquivo agora chega a 62 B.

A cada etapa, o código fica mais difícil de ler. No entanto, o mecanismo JavaScript do navegador interpreta cada um deles da mesma maneira. O benefício de ofuscar o código dessa maneira pode ajudar a alcançar tamanhos de arquivo menores. 112 bilhões não é muito para começar, mas ainda houve uma redução de 50% no tamanho.

Neste aplicativo, a versão 4 do webpack é usada como um bundler de módulos. A versão específica pode ser encontrada em package.json.

"devDependencies": {
  //...
  "webpack": "^4.16.4",
  //...
}

A versão 4 já minimiza o pacote por padrão durante o modo de produção. Ele usa TerserWebpackPlugin, um plug-in para Terser. O Terser é uma ferramenta conhecida usada para compactar código JavaScript.

Para ter uma ideia da aparência do código reduzido, clique em main.bundle.js enquanto ainda estiver no painel Network do DevTools. Agora clique na guia Resposta.

O código na forma final, minimizado e modificado, é mostrado no corpo da resposta. Para descobrir o tamanho do pacote se ele não fosse minimizado, abra webpack.config.js e atualize a configuração mode.

module.exports = {
  mode: 'production',
  mode: 'none',
  //...

Atualize o aplicativo e confira o tamanho do pacote novamente no painel Network do DevTools.

Essa é uma diferença muito grande! 😅

Reverta as mudanças aqui antes de continuar.

module.exports = {
  mode: 'production',
  mode: 'none',
  //...

A inclusão de um processo para reduzir código no aplicativo depende das ferramentas usadas:

• Se o webpack v4 ou mais recente for usado, não será necessário fazer mais nada, já que o código é minimizado por padrão no modo de produção. 👍
• Se uma versão mais antiga do webpack for usada, instale e inclua TerserWebpackPlugin no processo de build do webpack. A documentação explica isso em detalhes.
• Outros plug-ins de minificação também existem e podem ser usados, como o BabelMinifyWebpackPlugin e o ClosureCompilerPlugin.
• Se um bundler de módulos não estiver sendo usado, use o Terser como uma ferramenta de CLI ou inclua-o diretamente como uma dependência.

Compactação

Embora o termo "compressão" às vezes seja usado de forma vaga para explicar como o código é reduzido durante o processo de minificação, ele não é realmente comprimido no sentido literal.

A compactação geralmente se refere ao código que foi modificado usando um algoritmo de compactação de dados. Ao contrário da minificação, que acaba fornecendo um código perfeitamente válido, o código comprimido precisa ser descompactado antes de ser usado.

Com cada solicitação e resposta HTTP, os navegadores e servidores da Web podem adicionar cabeçalhos para incluir informações adicionais sobre o recurso que está sendo buscado ou recebido. Isso pode ser visto na guia Headers do painel de rede do DevTools, onde três tipos são mostrados:

• Geral representa cabeçalhos gerais relevantes para toda a interação entre solicitação e resposta.
• Cabeçalhos de resposta mostra uma lista de cabeçalhos específicos da resposta real do servidor.
• Cabeçalhos da solicitação mostra uma lista de cabeçalhos anexados à solicitação pelo cliente.

Observe o cabeçalho accept-encoding no Request Headers.

accept-encoding é usado pelo navegador para especificar quais formatos de codificação de conteúdo ou algoritmos de compactação ele aceita. Existem muitos algoritmos de compactação de texto, mas apenas três são compatíveis aqui para compactação (e descompactação) de solicitações de rede HTTP:

• Gzip (gzip): o formato de compactação mais usado para interações de servidor e cliente. Ele é baseado no algoritmo Deflate e é compatível com todos os navegadores atuais.
• Deflate (deflate): não é usado com frequência.
• Brotli (br): um algoritmo de compactação mais recente que visa melhorar ainda mais as taxas de compactação, o que pode resultar em carregamentos de página ainda mais rápidos. Ele tem suporte nas versões mais recentes da maioria dos navegadores.

O aplicativo de exemplo neste tutorial é idêntico ao concluído no codelab "Remover código não utilizado", exceto pelo fato de que o Express agora é usado como um framework de servidor. Nas próximas seções, vamos falar sobre a compactação estática e dinâmica.

Compactação dinâmica

A compactação dinâmica envolve a compactação de recursos em tempo real conforme eles são solicitados pelo navegador.

Prós

• Não é necessário criar e atualizar versões compactadas salvas de recursos.
• A compactação on-the-fly funciona muito bem para páginas da Web geradas dinamicamente.

Contras

• A compactação de arquivos em níveis mais altos para alcançar taxas de compactação melhores leva mais tempo. Isso pode causar um impacto de desempenho, já que o usuário espera a compactação dos recursos antes de serem enviados pelo servidor.

Compactação dinâmica com o Node/Express

O arquivo server.js é responsável por configurar o servidor Node que hospeda o aplicativo.

const express = require('express');

const app = express();

app.use(express.static('public'));

const listener = app.listen(process.env.PORT, function() {
  console.log('Your app is listening on port ' + listener.address().port);
});

No momento, isso importa express e usa o middleware express.static para carregar todos os arquivos estáticos de HTML, JS e CSS no diretório public/. Esses arquivos são criados pelo webpack em cada build.

Para garantir que todos os recursos sejam compactados sempre que forem solicitados, a biblioteca de middleware de compactação pode ser usada. Comece adicionando-o como um devDependency em package.json:

"devDependencies": {
  //...
  "compression": "^1.7.3"
},

E importe-o para o arquivo do servidor, server.js:

const express = require('express');
const compression = require('compression');

E adicione como um middleware antes de montar o express.static:

//...

const app = express();

app.use(compression());

app.use(express.static('public'));

//...

Agora atualize o app e confira o tamanho do pacote no painel Network.

De 225 KB para 61,6 KB! No Response Headers, um cabeçalho content-encoding mostra que o servidor está enviando esse arquivo codificado com gzip.

Compactação estática

A ideia por trás da compactação estática é ter os recursos compactados e salvos com antecedência.

Prós

• A latência devido aos altos níveis de compactação não é mais uma preocupação. Nada precisa acontecer em tempo real para compactar arquivos, já que eles podem ser buscados diretamente.

Contras

• Os recursos precisam ser compactados em cada build. Os tempos de build podem aumentar significativamente se níveis de compactação altos forem usados.

Compressão estática com Node/Express e webpack

Como a compactação estática envolve a compactação de arquivos com antecedência, as configurações do webpack podem ser modificadas para compactar recursos como parte da etapa de build. O CompressionPlugin pode ser usado para isso.

Para começar, adicione-o como um devDependency no package.json:

"devDependencies": {
  //...
  "compression-webpack-plugin": "^1.1.11"
},

Como qualquer outro plug-in do webpack, importe-o no arquivo de configurações, webpack.config.js:

const path = require("path");

//...

const CompressionPlugin = require("compression-webpack-plugin");

E inclua na matriz plugins:

module.exports = {
  //...
  plugins: [
    //...
    new CompressionPlugin()
  ]
}

Por padrão, o plug-in compacta os arquivos de build usando gzip. Consulte a documentação para saber como adicionar opções para usar um algoritmo diferente ou incluir/excluir determinados arquivos.

Quando o app é recarregado e criado, uma versão compactada do pacote principal é criada. Abra o Glitch Console para conferir o que está dentro do diretório public/ final que é servido pelo servidor Node.

• Clique no botão Ferramentas.
• Clique no botão Console.
• No console, execute os seguintes comandos para mudar para o diretório public e ver todos os arquivos:

cd public
ls

A versão compactada do pacote, main.bundle.js.gz, também é salva aqui. CompressionPlugin também compacta index.html por padrão.

A próxima etapa é pedir para o servidor enviar esses arquivos gzip sempre que as versões originais do JS forem solicitadas. Isso pode ser feito definindo uma nova rota em server.js antes que os arquivos sejam veiculados com express.static.

const express = require('express');
const app = express();

app.get('*.js', (req, res, next) => {
  req.url = req.url + '.gz';
  res.set('Content-Encoding', 'gzip');
  next();
});

app.use(express.static('public'));

//...

app.get é usado para informar ao servidor como responder a uma solicitação GET para um endpoint específico. Uma função de callback é usada para definir como processar essa solicitação. O trajeto funciona assim:

• Especificar '*.js' como o primeiro argumento significa que isso funciona para cada endpoint acionado para buscar um arquivo JS.
• No callback, .gz é anexado ao URL da solicitação, e o cabeçalho de resposta Content-Encoding é definido como gzip.
• Por fim, next() garante que a sequência continue para qualquer callback que possa ser o próximo.

Quando o app for recarregado, confira o painel Network novamente.

Assim como antes, uma redução significativa no tamanho dos pacotes.

Conclusão

Este codelab abordou o processo de redução e compactação do código-fonte. Essas duas técnicas estão se tornando o padrão em muitas das ferramentas disponíveis atualmente. Por isso, é importante descobrir se a cadeia de ferramentas já oferece suporte a elas ou se você precisa começar a aplicar os dois processos.