Performance em horário de pico: por que sites de resultado precisam ser rápidos

Por que o acesso chega em ondas

Sites de resultado, como os de loterias, do jogo do bicho ou de competições esportivas, não recebem visitas distribuídas de forma uniforme pelo dia. O conteúdo muda em horários conhecidos, e o interesse se concentra nos minutos seguintes à publicação: quem acompanha uma extração quer conferir o número assim que ele sai.

O resultado é um tráfego em ondas, com picos curtos, previsíveis no horário e imprevisíveis no tamanho. Este artigo não traz números de audiência de nenhum site; explica o mecanismo técnico e as soluções que valem para qualquer volume.

Uma página de resultados com consulta por data, estado e horário resume o desafio: a mesma URL é lida por muita gente, mas só muda quando uma nova extração é publicada. É o perfil ideal para cache, desde que a atualização chegue a tempo.

O que acontece no servidor quando todos chegam juntos

Sem cache, cada visita repete o mesmo trabalho: consultar o banco de dados, montar o HTML e enviar a resposta. Quando muitos pedidos idênticos chegam de uma vez, eles disputam processador, memória e conexões com o banco, formam fila, e o tempo de resposta cresce justamente para quem mais precisa da informação.

Há um agravante conhecido como cache stampede, ou estouro de cache: um tipo de falha em cascata que pode ocorrer em sistemas com cache sob carga muito alta. O caso típico é um item expirar e vários processos tentarem recalcular o mesmo conteúdo ao mesmo tempo. Num site de resultado, esse momento tende a coincidir com o pico, porque a página precisa ser renovada exatamente quando sai o número novo.

Entre as saídas descritas estão travar a regeneração para que só um processo recalcule o item, delegar a recomputação a um processo externo ou renovar o item pouco antes de expirar. No nginx, a diretiva proxy_cache_lock aplica a primeira ideia: só um pedido por vez preenche um novo elemento do cache, e os demais esperam a resposta aparecer.

Cache HTTP: reaproveitar sem servir resultado velho

O cabeçalho Cache-Control diz por quanto tempo uma resposta pode ser reaproveitada. A diretiva max-age define esse prazo em segundos; s-maxage vale só para caches compartilhados, como CDNs e proxies reversos, e é ignorada pelo navegador, o que permite um prazo no aparelho e outro na borda.

Duas extensões, definidas na RFC 5861 em maio de 2010, fazem diferença no pico. A stale-while-revalidate permite entregar a cópia vencida enquanto a nova é buscada em segundo plano, sem bloquear quem pediu. A stale-if-error autoriza servir a cópia antiga quando a origem responde com erro 500, 502, 503 ou 504.

Arquivos estáticos pedem outra estratégia. A MDN recomenda incluir versão ou hash no endereço de CSS e JavaScript e servi-los com max-age=31536000, immutable, o equivalente a um ano sem revalidação. Quando o arquivo muda, muda o endereço.

CDN: servir de perto e proteger a origem

Pela definição da MDN, uma CDN é um grupo de servidores espalhados por vários locais que guardam cópias dos dados e atendem cada pedido a partir do ponto mais próximo do usuário, o que torna o serviço rápido e menos afetado por tráfego alto. Cada acerto de cache na borda é um pedido que não chega à origem.

Um detalhe pega muita gente: a documentação da Cloudflare informa que sua CDN não armazena HTML nem JSON por padrão, e é preciso criar uma regra de cache para isso. Sem ela, a página de resultado continua indo à origem a cada visita, e só imagens, CSS e scripts são aliviados.

O outro lado é a atualização. Em vez de esperar o prazo vencer, o sistema de publicação pode purgar a URL assim que um novo resultado é gravado. Na purga por arquivo da Cloudflare, a cópia sai de todos os data centers, e o pedido seguinte busca a versão nova na origem. Combinar purga e trava de regeneração reduz o risco de a própria atualização provocar o estouro.

Página leve: o que o celular precisa carregar

O cache protege a origem; o peso da página decide a experiência no aparelho. O guia web.dev, do Google, define três Core Web Vitals: LCP, de carregamento, em até 2,5 segundos; INP, de resposta à interação, em até 200 milissegundos; e CLS, de estabilidade visual, em até 0,1. A recomendação é medir no percentil 75 das visitas, separando celular e computador.

Numa página de resultado, o conteúdo que importa é o número sorteado. Se ele depende de JavaScript para aparecer, só é exibido depois que o script carrega e executa. O guia de LCP recomenda que o recurso do LCP possa ser descoberto já no HTML inicial e aponta a renderização no servidor como forma de o conteúdo não depender de requisições extras de JavaScript para aparecer. Antes vem o TTFB, o tempo até o primeiro byte, com meta de até 0,8 segundo; é nele que servidor sobrecarregado aparece primeiro.

O restante é disciplina: comprimir HTML, CSS e JavaScript com gzip ou Brotli, sem recomprimir imagens, que já chegam comprimidas; declarar largura e altura das imagens; reservar espaço fixo para blocos que carregam depois, como anúncios; e tratar as fontes web, cuja troca pode deslocar o texto.

Como se preparar antes do próximo pico

Como o horário do pico é conhecido, dá para ensaiar. Um bom teste de carga simula muitos acessos à mesma URL no instante em que o cache expira ou é purgado, e não só com o cache já quente. Vale acompanhar a proporção de acertos de cache, o TTFB e os erros 5xx da origem.

Este conteúdo sobre jogo do bicho se destina a maiores de 18 anos. O jogo do bicho não é modalidade autorizada pela legislação federal e é tratado como contravenção penal pelo art. 58 do Decreto-Lei nº 3.688/1941.