Este artigo foi publicado originalmente no Laravel News por Eric L. Barnes.

Eu me reuni com JMac para a série Laravel Creator para falar sobre algo que acabamos de finalizar: o cache do Laravel News na borda (edge caching) usando seu curso Fast Laravel e a Cloudflare. Tratamos o site como um estudo de caso e, agora que está implementado, queríamos compartilhar o que fizemos e onde encontramos dificuldades.

O ponto interessante é que o Laravel News é um site de alto tráfego cujo conteúdo muda constantemente. Novos artigos, novos links, novos patrocinadores, a notificação no topo. Muita gente assume que uma página assim não pode ter cache. O objetivo desta conversa é mostrar que pode.

Comece pelas suas páginas principais

Jason adotou uma abordagem sistemática. Você analisa o tráfego de requisições, encontra as páginas mais acessadas e faz o cache delas primeiro, descendo na lista até que as requisições principais sejam apenas subpáginas de baixo tráfego. Para nós, isso se resumiu a cerca de cinco páginas:

• A página inicial
• A página do blog
• A página de detalhes do artigo (os posts em si)
• A página de links da comunidade
• A página de links recentes

Três desafios que tivemos que resolver

O site é majoritariamente estático, mas dinâmico em alguns pontos específicos, o que gerou três desafios principais.

Remover o Livewire onde não era necessário. O site foi construído de forma que quase tudo era um componente Livewire, mas apenas o formulário da newsletter realmente usava a natureza reativa do Livewire. Todo o resto eram apenas templates Blade. Converter isso de volta para componentes Blade puros foi uma refatoração direta que isolou as poucas áreas que realmente precisam ser dinâmicas.

Manter as partes dinâmicas, dinâmicas. Algumas peças não podem ser congeladas em uma página em cache: a notificação de topo, a newsletter e os espaços de patrocinadores que rotacionam por requisição. Como já usávamos Alpine para o Livewire, adicionamos o Alpine AJAX e o usamos para trocar esses componentes no carregamento da página.

Duas camadas de cache competindo. O Laravel News roda no Laravel Cloud, que oferece cache na borda nativo usando Cloudflare por baixo. Como já estávamos na Cloudflare diretamente, as duas camadas competiam. No fim, foi mais simples ignorar as regras do Cloud e usar nossa Cloudflare diretamente, obtendo os mesmos benefícios.

Limpando o cache quando o conteúdo muda

Limpamos o cache no deploy, mas o trabalho real é limpá-lo quando um artigo é publicado ou links são aprovados. A maior parte disso roda através de eventos de model do Laravel. Quando um artigo é atualizado, ouvimos o evento updated e limpamos aquele artigo específico, além da home e do blog.

O caso mais complexo era o de artigos agendados. Escrevemos artigos à noite para publicar às 9h, então não há um evento disparando no momento em que o post vai ao ar. A solução mais simples foi aproveitar um comando que já executamos para compartilhar novos posts nas redes sociais. Esse comando agora também limpa a home, o blog, o artigo e as páginas de links.

Funciona em qualquer lugar

Jason deixou claro que nada disso é específico do Laravel Cloud. Desde que você tenha a Cloudflare na frente da sua aplicação, funciona em qualquer servidor. Ele roda o Laravel Shift em uma instância da DigitalOcean de $5 por mês que lida com cerca de 50.000 requisições por dia com todo o lado público em cache, obtendo tempos de resposta de cerca de 20 milissegundos.

Para nós, os resultados foram imediatos. O Laravel News passou de uma taxa de cache baixa para a maioria das requisições cacheadas, com picos de até 70%, e o site simplesmente parece mais rápido.

Confira

Dê uma olhada no Fast Laravel. Como Jason disse, o edge caching é uma daquelas práticas esquecidas que vale a pena revisitar, e uma vez que você aprende, pode aplicar em cada site que construir.