Minifique e compacte payloads de rede com o gzip

Houssein Djirdeh

Este codelab explica como a minimização e a compactação do pacote JavaScript para o aplicativo a seguir melhora o desempenho da página reduzindo o tamanho da solicitação do app.

Medida

Antes de começar a adicionar otimizações, é sempre bom 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 do aplicativo:

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

Embora muito progresso tenha sido feito no codelab "Remover código não utilizado" para reduzir o tamanho desse pacote, 225 KB ainda é muito 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 seria de cerca de 83 B. Se ele ficar ainda mais danificado, reduzindo o comprimento do nome da variável e modificando 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 atinge 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 B realmente não era muito para começar, mas ainda houve uma redução de 50% de 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á reduz o pacote por padrão durante o modo de produção. Ele usa TerserWebpackPlugin, um plug-in para Terser. Terser é uma ferramenta popular 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, minificado e corrompido, é mostrado no corpo da resposta. Para descobrir o tamanho do pacote se não tiver sido reduzido, abra webpack.config.js e atualize a configuração mode.

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

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

É uma grande diferença! 😅

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, nenhum trabalho extra precisará ser feito, 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 BabelMinifyWebpackPlugin e ClosureCompilerPlugin.
• Se um bundler de módulo não estiver sendo usado, use o Terser como uma ferramenta da CLI ou inclua-o diretamente como uma dependência.

Compactação

Embora o termo "compactação" seja usado vagamente para explicar como o código é reduzido durante o processo de minificação, ele não é compactado 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 compactado precisa ser descompactado antes de ser usado.

A cada solicitação e resposta HTTP, os navegadores e os servidores da Web podem adicionar headers para incluir mais informações sobre o recurso que está sendo buscado ou recebido. Confira isso na guia Headers do painel "DevTools Network", onde três tipos são mostrados:

• General representa os cabeçalhos gerais relevantes para toda a interação de solicitação/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 do cliente.

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

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

• Gzip (gzip): o formato de compactação mais usado para interações entre servidor e cliente. Ela se baseia 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 é compatível com as 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 à medida que eles são solicitados pelo navegador.

Prós

• A criação e a atualização de versões compactadas salvas de recursos não precisam ser feitas.
• A compactação funciona especialmente 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 do nó 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);
});

Atualmente, tudo isso faz é importar express e usar o middleware express.static para carregar todos os arquivos estáticos HTML, JS e CSS no diretório public/ (e 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 compression pode ser usada. Para começar, adicione-o como um devDependency no 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-o como um middleware antes de express.static ser ativado:

//...

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 a 61,6 KB! Agora, na 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 imediatamente para compactar arquivos, pois agora eles podem ser obtidos diretamente.

Contras

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

Compactação estática com o Node/Express e o webpack

Como a compactação estática envolve a compactação antecipada de arquivos, as configurações do webpack podem ser modificadas para compactar recursos como parte da etapa do build. 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-o na matriz plugins:

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

Por padrão, o plug-in compacta os arquivos de build usando gzip. Confira 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 exibido pelo servidor do nó.

• 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 em gzip do pacote, main.bundle.js.gz, agora 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 disponibilizados 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 a 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 a seguir.

Quando o app for atualizado, confira o painel Network mais uma vez.

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

Conclusão

Este codelab abordou o processo de minificação e compactação do código-fonte. Essas duas técnicas estão se tornando padrão em muitas das ferramentas disponíveis atualmente. Por isso, é importante descobrir se o conjunto de ferramentas já é compatível ou se você deve começar a aplicar os dois processos por conta própria.