Entendendo o cache no WordPress, parte 1
Em maio, escrevi um artigo sobre o uso da API do WordPress Transients. Eu resumi o artigo assim:
Para simular cookies e seu recurso de expiração, usar transientes do WordPress pode ser uma solução viável.
https://wordpress.mediadoma.com/pt-pt/usando-transitorios-do-wordpress-em-vez-de-cookies/
Embora o objetivo do artigo fosse estabelecer uma base de como podemos projetar uma classe para trabalhar com a API Transients para simular o comportamento de cookies, um dos efeitos colaterais do artigo é que ele não fez um bom trabalho de explicar como a API Transients (e, por proxy, como o MySQL) funciona.
Isso foi trazido à minha atenção por e-mail por David no UpDraft Plus.
Então eu achei útil falar sobre o conceito de cache de um nível prático, como ele é implementado no WordPress, então talvez veja como utilizar plugins ou tecnologias mais recentes para melhorar nossos sites e aplicativos, bem como ter um melhor entendimento.
Entendendo o cache: o básico
O conceito de cache é relativamente fácil. Mas acho que é melhor demonstrado falando sobre serialização e recuperação de dados sem armazenamento em cache, primeiro.
Sem cache
Gravando dados
Sempre que você grava informações no banco de dados subjacente, está gravando um registro – ou uma série de registros – no banco de dados.
Por exemplo, ao publicar uma postagem, você gravará um registro na tabela para postagens e na tabela para metadados de postagem, cada um relacionado por um ID de postagem.
Como eles estão relacionados não é importante para este post.
Em vez disso, o que devemos entender nesta parte é que, quando os dados são gravados no banco de dados, pelo menos um registro, se não vários, é criado.
Lendo dados
Quando um visitante chega ao site para ler esse post específico, todas as informações desse post serão solicitadas do banco de dados, fornecidas ao aplicativo WordPress e renderizadas no front-end.
Pense em todo esse processo como uma viagem:
- ❓o visitante solicita a página,
- 🔍 o servidor web identificou qual página carregar,
- 📂 a página é solicitada do banco de dados de várias tabelas,
- 🏗 os dados são reunidos e enviados para o aplicativo principal,
- 🖥 os dados são apresentados ao usuário.
Assim, a viagem começa quando o usuário solicita uma página e termina quando a informação é apresentada a ele em seu navegador.
É uma viagem
E, sem cache, isso acontece para todos os usuários. Ou seja, para cada usuário que visita seu site, uma viagem deve ser feita.
Isso pode ficar muito caro em termos de recursos e tempo (especialmente dependendo do tamanho do seu banco de dados).
Mas é aqui que o cache pode entrar em jogo.
Antes de entrar em cache
A ideia por trás do cache é tornar todo esse processo mais rápido. Ou seja, se sabemos que uma viagem está prestes a acontecer, podemos manter a informação em um local que já esteja montada e mais rápida de recuperar.
Antes de falar, porém, que farei no próximo post, observe que isso é como fazer uma viagem ao disco rígido do servidor em que o site está hospedado cada vez que o site é visitado.
Porque, em última análise, o banco de dados, os arquivos e todos os ativos necessários para alimentar o site residem em um disco rígido. E sim, coisas como unidades de estado sólido podem tornar esse processo mais rápido, ainda não é o melhor possível.
E é aí que o cache entra em cena. Para entender melhor a API Transients, é importante entender o cache, que primeiro requer uma compreensão básica de como as coisas funcionam sem o cache.
É um Primer
Portanto, considere isso uma cartilha básica sobre como funciona um site baseado em banco de dados sem armazenamento em cache. E então vamos construir mais sobre isso no próximo post.