A entrega front-end na era da publicação de alta frequência precisa redesenhar o armazenamento em cache e a colaboração de compactação

Assim que os recursos front-end entrarem em um ritmo de lançamento de alta frequência, os problemas de desempenho em breve não serão mais tão simples como “ligar o Brotli”. A primeira tela fica mais lenta, o tráfego de volta à origem aumenta e a CPU do nó de borda treme. Superficialmente, parece que a compressão não é agressiva o suficiente. Olhando mais profundamente, muitas vezes é o cache e a compactação que são otimizados separadamente e, finalmente, prejudicam um ao outro no link de publicação.

Esse tipo de problema geralmente não é exposto na primeira versão. No início, a equipe veria apenas alguns sinais dispersos: uma pequena mudança causou uma quebra na taxa de acerto de recursos estáticos, um aumento anormal na compressão de borda da CPU na véspera de uma grande promoção e o volume de pacotes de retorno no estágio de escala de cinza não correspondia ao tráfego oficial. Se você continuar a verificar, as pistas geralmente convergem para a mesma coisa: embora o conteúdo do recurso tenha mudado apenas um pouco, a chave de cache, a divisão de pedaços e a entrada compactada tornaram-se um conjunto diferente de coisas, e a camada de transporte é forçada a engolir todo o custo novamente.

Até que o hash do recurso esteja estável, os benefícios da compactação são simplesmente insustentáveis.

Depois que os projetos front-end são lançados em paralelo com múltiplas páginas, múltiplas rotas e múltiplas equipes, o aspecto mais facilmente esquecido é a estabilidade do nome do arquivo. Contanto que a segmentação do pedaço se desvie ligeiramente, mesmo que o código comercial altere apenas a cópia de um botão, o produto final também poderá reescrever o hash de uma série de pacotes públicos. O que o sistema de cache vê é um lote de objetos totalmente novos, e o que o sistema de compactação vê é um lote de entradas que aparecem pela primeira vez.

Neste momento, não importa quão alta seja a taxa de compressão, ela não pode salvar a taxa de acerto do colapso. Os arquivos antigos ainda estão nos nós de borda e os novos arquivos foram recodificados; o cache local do navegador é completamente inválido e o CDN precisa extrair novamente a fonte, compactar novamente e redistribuir. Uma pequena mudança empresarial é ampliada em trabalho repetido para todo o link de transmissão.

A ação realmente útil geralmente não é continuar ajustando o nível de compressão, mas primeiro controlar a estabilidade do produto lançado:

• As dependências públicas são cortadas em camadas separadas para reduzir as mudanças nos negócios e reunir pacotes básicos para alterar o hash.
• Evite misturar alterações de alta frequência, como carimbos de data/hora e números de compilação, diretamente no conteúdo do produto
• Deixe o código próximo à mesma rota cair em pedaços estáveis, tanto quanto possível, em vez de ser reorganizado toda vez que for compilado.

Somente quando a identidade do recurso estiver estabilizada o cache poderá ser reutilizado continuamente e os resultados da compactação terão valor cumulativo.

Conferência de imprensa de alta frequência reescreve o problema de compactação em um problema de versão de dicionário

À medida que os recursos se tornam cada vez mais fragmentados, o arquivo único Brotli ou gzip ainda é importante, mas não é mais tudo. O custo real começa a mudar para peças duplicadas: código de tempo de execução da estrutura, modelos de estilo, declarações de tipo de interface, camadas de empacotamento geradas por empacotadores, muitas vezes são altamente semelhantes entre lotes de versões. Com um ritmo de liberação rápido, esses riffs serão transferidos continuamente.

O problema é que o dicionário de compactação pode facilmente passar de uma otimização para uma interrupção se não for gerenciado junto com a cadência de liberação. Se o dicionário for trocado antecipadamente, o novo dicionário referenciado pela página antiga será incompatível; o dicionário é cortado em muitos pedaços e o número de versões a serem mantidas pelos nós de borda aumenta acentuadamente; a atualização do dicionário não é sincronizada com o recurso online e os objetos que deveriam ter sido atingidos retornam para transmissão completa.

Esta também é uma mudança muito prática na recente entrega de front-end: estratégias de cache e protocolos de compressão não podem mais ser mantidos por equipes diferentes. Versões de recursos, versões de dicionário e espaços de chave de cache são essencialmente o mesmo problema de publicação.

Uma abordagem hierárquica como a seguinte geralmente é mais estável do que “compressão forte e unificada para todo o site”:

const policy = {
  immutableAssets: 'public, max-age=31536000, immutable',
  releaseManifest: 'public, max-age=60, stale-while-revalidate=30',
  sharedDictionary: 'versioned-by-release-train'
}

A chave não é a configuração dessas três linhas em si, mas as restrições que elas expressam: recursos de ciclo de vida longo, lista de ciclo de vida curta e versão compactada do dicionário devem evoluir juntos de acordo com o mesmo ritmo de lançamento.

A pressão de retornar à fonte geralmente não é porque o arquivo é muito grande, mas porque o método de falha é muito difícil.

Outro erro de julgamento muito comum é atribuir o aumento da largura de banda diretamente ao peso da página. As páginas certamente estão ficando mais pesadas, mas os amplificadores online mais perigosos geralmente são a melhor opção.

Se você limpar por diretório, prefixo ou até mesmo o site inteiro toda vez que publicar, a camada de cache perderá memória instantaneamente. Neste momento, mesmo que o tamanho do arquivo não continue a crescer, o valor máximo de retorno à origem aumentará por si só. Assim que a fonte é retornada, as bordas são recompactadas, os objetos são reaquecidos e o navegador é baixado novamente. A janela de publicação mudará de uma pequena mudança para uma realocação completa do site.

Neste tipo de cenário, o mais valioso é o raio de falha controlável:

• Invalida apenas manifesto, HTML e recursos mutáveis que realmente foram alterados
• Tente não limpar arquivos estáticos com hash e entregue-os a novas referências para troca natural.
• Dividir o lançamento na ordem de “primeiro fazer upload de novos recursos, depois cortar referências e depois reciclar recursos antigos” em vez de limpá-los todos de uma vez

O que é realmente sensível no custo de transferência não é apenas o tamanho do arquivo, mas também como o sistema decide qual conteúdo deve ser buscado novamente.

O limite aplicável é determinado juntamente com a escala de recursos e a frequência de liberação.

Este conjunto de co-design não é obrigatório para todos os sites. Para projetos com um pequeno número de páginas estáticas, um pequeno pacote de recursos e uma frequência de lançamento semanal ou mesmo mensal, o uso de nomes de arquivos hash tradicionais mais a pré-compactação Brotli geralmente é estável o suficiente.

O armazenamento em cache e a compactação juntos rapidamente se tornam uma infraestrutura de entrega quando estas características são implementadas:

• Lançado várias vezes ao dia, com escala de cinza, reversão ou lançamentos regionais
• O produto front-end é grande, tem muitas dependências públicas e relacionamentos complexos.
• CDN, armazenamento de objetos, compactação de borda e cache do navegador participam simultaneamente do link de transmissão
• O tráfego é tão alto que a taxa de acerto do cache e o valor de pico de retorno à origem refletirão diretamente o custo e a estabilidade.

Depois que a entrega front-end entra nesse estágio, a compactação não é mais apenas “tornar os arquivos menores” e o cache não é mais apenas “armazenar mais cópias de conteúdo”. O que os dois decidem juntos é: para uma mudança em uma pequena empresa, se é apenas para enviar mais um pedaço ou se todo o link de transmissão precisa ser executado novamente. Quanto mais você publica, mais cara se torna essa diferença.