O que é conteúdo estático?

O conteúdo estático é servido a partir de uma representação armazenada que normalmente permanece idêntica entre requisições. Ele só muda quando o recurso subjacente é atualizado, em vez de ser gerado a cada requisição.

O conteúdo estático é uma propriedade da entrega: o servidor pode retornar bytes que já existem, como um arquivo em disco ou um objeto em um bucket, sem executar a lógica da aplicação para a requisição. O arquivo pode ter sido escrito manualmente, gerado por um build ou exportado por um pipeline de mídia, portanto “estático” não significa que ele nunca muda. Significa que o conteúdo muda quando o arquivo armazenado é substituído, não quando uma requisição chega. Por isso, dois mecanismos HTTP fazem a maior parte do trabalho. A validade, definida com Cache-Control, informa aos navegadores e às CDNs por quanto tempo podem reutilizar uma cópia sem consultar o servidor. Os validadores, um ETag ou uma data Last-Modified, permitem que um cache consulte se sua cópia ainda está atualizada e receba uma resposta 304 sem corpo quando estiver. Imagens, segmentos de vídeo, fontes, folhas de estilo, scripts e páginas HTML pré-geradas são exemplos típicos de conteúdo estático; uma resposta montada a cada requisição com base no estado da aplicação é conteúdo dinâmico.

Um arquivo estático é armazenado em cache automaticamente? Não de forma confiável, nem por um período previsível. Sem validade explícita definida por Cache-Control ou Expires, o HTTP permite que um cache aplique uma validade heurística: a RFC 9111 permite estimar um prazo de validade com base em Last-Modified e apresenta 10% do tempo desde a última modificação como uma configuração típica. Por esse motivo, a MDN recomenda um cabeçalho Cache-Control explícito em cada resposta. As CDNs acrescentam seus próprios padrões. A Cloudflare, por exemplo, armazena em cache com base na extensão do arquivo, e não no tipo MIME, não armazena HTML nem JSON em cache por padrão e não armazena em cache uma resposta que contenha Set-Cookie.
Um arquivo estático deve manter sua URL quando seu conteúdo muda? Decida para cada arquivo. Um arquivo cuja URL muda com o conteúdo, como um bundle com um hash no nome, pode ser servido com um max-age longo (o exemplo da MDN usa um ano) junto com immutable, porque uma nova versão chega em uma nova URL. Um arquivo que precisa manter sua URL, como uma página HTML, não deve ter um tempo de validade longo: atualizar o arquivo no servidor não substitui uma cópia ainda válida que o navegador já armazenou, porque, como observa a MDN, as requisições desse arquivo deixam de chegar ao servidor, então o navegador pode continuar usando essa cópia até que sua validade expire. Uma CDN que oferece purga de cache pode remover sua própria cópia, mas essa purga não alcança as cópias já armazenadas nos navegadores. Sirva esses arquivos com no-cache e validadores, para que cada reutilização seja verificada e um arquivo sem alterações custe apenas uma resposta 304.
Servir uma resposta a partir de um arquivo a torna segura para um cache compartilhado? Não. A possibilidade de armazenar uma resposta em cache depende da requisição e dos cabeçalhos da resposta, não de como o corpo foi produzido. A RFC 9111 proíbe um cache compartilhado de reutilizar uma resposta a uma requisição que continha Authorization, a menos que a resposta permita isso com public, s-maxage ou must-revalidate. Ela não tem uma regra equivalente para uma requisição que continha um cabeçalho Cookie, e a MDN observa que um cookie, por si só, não torna uma resposta privada. A RFC também observa que Set-Cookie não impede o armazenamento em cache, então um arquivo estático enviado com um cookie pode ser armazenado e reutilizado em requisições posteriores por um cache que siga o padrão. Uma CDN pode aplicar uma regra própria: a Cloudflare, como mencionado acima, não armazena esse tipo de resposta em cache por padrão. Prefira não definir cookies em caminhos estáticos. Quando uma resposta precisar incluir um cookie ou for personalizada por um cookie, marque-a com private: um cache compartilhado, como uma CDN, não poderá armazená-la, de modo que esse arquivo fique em cache apenas nos navegadores.
O que muda quando os arquivos são pré-comprimidos? Os arquivos comprimido e não comprimido são duas representações disponíveis na mesma URL, então as respostas precisam de Vary: Accept-Encoding, e a RFC 9110 estabelece que um ETag forte para uma representação com codificação de conteúdo deve ser diferente daquele da representação sem essa codificação, para evitar conflitos durante atualizações de cache e requisições de intervalos. Os servidores diferem no quanto fazem disso por você. O gzip_static do nginx envia um arquivo .gz existente no lugar do arquivo normal, mas só adiciona Vary: Accept-Encoding quando gzip_vary está ativado, o que não é o padrão. Nenhuma das duas páginas dos módulos do nginx explica como o ETag de uma resposta .gz é formado, então solicite um arquivo com e sem Accept-Encoding: gzip, confirme em Content-Encoding que apenas a primeira resposta está comprimida e compare os cabeçalhos Vary e ETag das duas respostas. Repita a verificação pela CDN: gzip_static também leva gzip_proxied em conta, e seu padrão, off, desativa a compressão para requisições que contêm um cabeçalho Via, então uma requisição encaminhada por uma CDN pode receber o arquivo não comprimido. O mod_deflate do Apache, que comprime durante o processamento, acrescenta o método de compressão ao ETag por padrão, e sua documentação diz que isso impede respostas 304 a requisições condicionais de conteúdo comprimido.

Use tempos de validade longos para o cache quando cada revisão do conteúdo tiver uma URL exclusiva, reduzindo a latência e a carga no servidor de origem. Um tempo de cache mais curto ou a revalidação são opções mais seguras quando uma URL estável pode receber atualizações.

Os arquivos que uma Assembly exporta com um Robot de armazenamento passam a ser conteúdo estático: ficam no seu bucket, no caminho que você escolheu, e seu serviço de armazenamento ou sua CDN os serve. O Robot /s3/store recebe um objeto headers que é definido no arquivo armazenado, e /video/adaptive atribui um relative_path a cada segmento e playlist para que a estrutura armazenada corresponda ao que as playlists referenciam. O Smart CDN é a alternativa sob demanda: um resultado é gerado quando solicitado pela primeira vez e depois armazenado em cache, e o Robot /file/serve define o cabeçalho Cache-Control que os navegadores e a CDN recebem, com cache_duration para alterá-lo.

Um player no navegador que carrega arquivos HLS ou MPEG-DASH de uma origem diferente da página, como um bucket ou um nome de host de CDN, precisa de cabeçalhos CORS no servidor que serve os arquivos; a página /video/adaptive lista esses cabeçalhos. Os cabeçalhos de cache dos arquivos exportados são responsabilidade do seu serviço de armazenamento ou da sua CDN depois que os arquivos são armazenados.

Explore os recursos de entrega da Transloadit

O que é conteúdo estático?

Como funciona o conteúdo estático

Informações essenciais

Quando o conteúdo estático é relevante

Como a Transloadit ajuda com conteúdo estático

Fontes

Transforme conhecimento sobre mídia em um pipeline funcional