Não que planejássemos uma série, mas este é o terceiro artigo consecutivo que publicamos sobre ferramentas de cache para WordPress. Os anteriores foram Hyper Cache: instalando corretamente e Ferramentas de cache agressivas para WordPress, nos quais falamos sobre ferramentas que fazem cache das páginas do blog como arquivos estáticos.
Hoje um de nossos clientes enviou uma consulta envolvendo dois assuntos importantes relacionados a plugins para blogs em WordPress: se o plugin DB-Cache amenizaria o consumo de CPU ocasionado pelo Related Posts.
Não temos como dar uma resposta definitiva a esta questão, contudo podemos levantar alguns pontos que merecem ser discutidos.
Em primeiro lugar, o Related Posts (sem link propositalmente) — aquele plugin que encontra posts com conteúdo relacionado analisando o conteúdo de cada post ao que está sendo exibido no momento — não é uma boa alternativa para sites em Português, e nem é (só) pelo fato de ele fazer o MySQL consumir muita CPU por basear-se na sua capacidade de comparação de textos, mas sim porque este recurso só funciona bem para textos escritos em Inglês.
Em vez dele sugiro que se usem plugins de posts relacionados baseados nas tags do WordPress, sendo que o meu favorito é o Simple Tags, que além de introduzir diversas facilidades para a atribuição de tags aos posts tem um recurso que funciona muito bem para inclusão de links para posts relacionados.
Em segundo lugar, a ideia por trás do plugin DB Cache é fazer cache dos resultados das consultas feitas ao banco de dados num determinado período, visando diminuir a carga do servidor e servir páginas mais rapidamente para o visitante. O autor do plugin diz que ele é o melhor plugin de cache da atualidade, mas isso é extremamente questionável.
Para começar, plugins como o Hyper Cache (ver links no primeiro parágrafo) também evitam consultas ao banco de dados, tendo o diferencial de, além de economizarem acesso ao banco, economizarem todo o processamento de cada página: uma vez que uma página (post) tenha sido requisitada uma vez, ela será gravada integralmente no cache, e todas as requisições subsequentes farão com que o visitante receba exatamente aquela página que foi salva anteriormente, evitando todo e qualquer processamento posterior.
E mais: o Hyper Cache tem a habilidade de salvar uma versão compactada com gzip de cada página, o que além de implicar a entrega mais rápida do conteúdo para o navegador do visitante, economiza banda.
Em terceiro lugar, mas não menos importante (OK, talvez seja menos importante), blogs que façam o registro dos visitantes (para fins de comentário, por exemplo, ou de autoria colaborativa) ficarão bastante prejudicados, pois os novos usuários ficarão impossibilitados de se autenticarem no blog.
Além disso, o plugin não parece estar maduro o suficiente: na página do DB Cache no WordPress.org há vários relatos de pessoas que se deram mal com ele, e vários pedidos para implementar um recurso imprescindível: a limpeza dos objetos de cache correspondentes no momento que um comentário ou um novo post forem publicados.
Por tudo isto, reiteramos que de todos os plugins de cache que já experimentamos para o WordPress o melhor é o Hyper Cache, tanto pela performance, quanto pela facilidade de instalação e configuração. Talvez o DB Cache possa ser adequado para alguma situação, mas não parece que em termos de redução de processamento ele seja o mais eficaz.
Estou usando o wp-super-cache… sabe se é preciso deixar a pasta wp-content/cache escrevível?
Naturalmente que sim.
Por que você não usa o Hyper Cache, que é muito melhor?
Vc falou mal do related posts, mas e o Yet Another Related Posts 3.0.6, é ruim tb?
Não conheço esse plugin, mas se ele for baseado no texto do post e não nas tags, ele é tão ruim quanto o outro.
Twitter Comment
Update no post: Vale a pena usar o DB-Cache no WordPress? -> [link to post]
-