Como Configurar o W3 Total Cache para Seu Site WordPress

Com mais de 1 milhão de instalações ativas, o W3 Total Cache é um dos plugins de cache e otimização mais populares no repositório WordPress. Ao contrário de outros plugins de otimização do WordPress que oferecem uma interface relativamente mais simples e simplificada, o W3 Total Cache dá controle completo sobre a configuração de cache de seu site WordPress.

A granularidade das configurações do W3TC faz dele um plugin ideal para usuários avançados e desenvolvedores que desejam o controle máximo sobre seus sites WordPress. Neste artigo, analisaremos em profundidade as configurações do W3 Total Cache, e lhe daremos nossa configuração recomendada para aumentar o desempenho de seu site WordPress.

Se você é um usuário Kinsta, não precisará configurar certas configurações no W3 Total Cache porque nossa pilha de hospedagem já tem muitas otimizações incorporadas.

Por exemplo, como parte da nossa integração com o Cloudflare, o Edge Caching salva o cache do seu site/página Kinsta em qualquer uma das redes globais de 260+ centros de dados do Cloudflare.

O Edge Caching está incluído gratuitamente em todos os planos Kinsta, não requer um plugin separado e reduz o tempo necessário para servir o HTML do WordPress em cache em uma média de mais de 50%!

Como instalar o W3 Total Cache

Se você não tiver o W3 Total Cache instalado em seu site, você pode instalá-lo diretamente em seu painel de controle do WordPress. Basta procurar por “W3 Total Cache” na página “Adicionar Plugins” e instalá-lo.

Há também uma versão Pro do W3 Total Cache, que pode ser adquirida no site da BoldGrid. A versão Pro vem com alguns recursos adicionais como o caching REST API, caching Google Maps e extensões adicionais. Neste artigo, estaremos usando a versão gratuita do repositório de plugins do WordPress.

Onde são armazenadas as Configurações de Cache W3 Total?

Após instalar o W3 Total Cache, você verá uma aba “Performance” na barra lateral de seu painel de administração do WordPress. Clicando na aba “Performance”, você verá uma variedade de submenus como “General Settings”, “Page Cache”, “Minify”, e muito mais.

Você também pode acessar as configurações do W3 Total Cache usando a guia “Performance” em sua barra de ferramentas de administração do WordPress.

Como Purgar W3 Cache Total

Antes de entrarmos em como configurar o W3 Total Cache, vamos rever rapidamente como purgar ou limpar seu cache. Se você pairar sobre a guia “Performance” na barra de ferramentas de administração, você verá duas opções de purga.

1. Purge All Caches – purgue todas as caches de uma só vez.
2. Módulos de purga – purga um cache individual (por exemplo, ativos minerados, cache de páginas, cache de objetos, etc.).

W3 Cache Total Configurações Gerais

Vamos mergulhar no menu “General Settings” do W3 Total Cache para configurar algumas configurações básicas.

Página Cache

Por padrão, cada solicitação ao seu site WordPress é feita em tempo real. Para certos tipos de sites como lojas de eCommerce ou fóruns de discussão, a renderização dinâmica é ideal. Entretanto, para blogs, sites de notícias e outros sites que não requerem conteúdo dinâmico, adicionar uma camada de cache de página pode melhorar o desempenho e reduzir a carga do servidor.

Se seu site está hospedado em Kinsta, você não precisa se preocupar com o cache de páginas. Temos uma configuração de alto desempenho em nível de servidor que automaticamente faz o cache das páginas de seu site em arquivos HTML estáticos. Se seu host não oferece cache de páginas, você pode ativar o cache de páginas no plug-in W3 Total Cache.

Minify

Minimizar seus recursos HTML, CSS e JavaScript pode reduzir o tamanho geral das páginas de seu site, removendo espaços em branco desnecessários. Para a maioria dos sites WordPress, habilitar o recurso “Minify” do W3 Total Cache e selecionar a opção “Auto” para “Minify Mode” será muito bom.

Em alguns casos, a mineração de ativos pode causar a quebra do código CSS ou JavaScript, o que muitas vezes resulta em erros visíveis no frontend. Se você notar problemas incomuns em seu site após a mineração de ativos, recomendamos trabalhar com um desenvolvedor para identificar os ativos que causam problemas. Depois disso, você pode usar o recurso “Minificar” no modo manual, que permite contornar a minificação para arquivos CSS e JavaScript específicos.

Opcode Cache

O WordPress é um CMS dinâmico, o que significa que os trabalhadores de PHP estão constantemente executando o código em segundo plano. cache Opcode ajuda a acelerar seu site armazenando o código PHP compilado, o que torna as solicitações subsequentes que requerem o mesmo código mais rápido.

Se seu site está hospedado em Kinsta, você não precisa se preocupar em habilitar uma camada de cache opcode em W3 Total Cache. Nós ativamos o OPcache, um cache opcode, em todos os ambientes ao vivo. OPcache é desativado em ambientes de encenação para garantir que o código PHP compilado não esteja em cache e não interfira no desenvolvimento e depuração do site.

Se seu host não oferece cache opcode, recomendamos ativá-lo em W3 Total Cache. Tenha em mente que o recurso de cache de opcode só está disponível na versão Pro do W3TC.

Cache do banco de dados

O banco de dados do W3TC armazena os resultados das consultas ao banco de dados MySQL. Embora este recurso pareça útil, recomendamos mantê-lo desativado e usar um cache de objetos em seu lugar.

Descobrimos que em alguns casos, o recurso de cache do banco de dados pode resultar em alta utilização da CPU. Isto significa que a quantidade de CPU economizada pelo armazenamento dos resultados da consulta ao banco de dados pode acabar sendo compensada pelo aumento da CPU necessária para este recurso.

Objeto Cache

No contexto do WordPress, um cache de objetos armazena os resultados de consultas completas ao banco de dados. Na verdade, o WordPress tem um cache de objetos incorporado, mas ele retém os dados apenas para uma única página. Isto permite uma renderização mais eficiente da página, pois garante que uma carga de página não precisará desperdiçar recursos da CPU executando consultas idênticas ao banco de dados.

Enquanto o cache de objetos padrão do WordPress é sem dúvida benéfico para o desempenho, um cache de objetos que retém dados através da carga de páginas é ainda melhor! O recurso “Object Cache” do W3TC adiciona um script de cache personalizado em seu diretório de /wp-content, e muda o comportamento do cache de objetos do WordPress para reter dados de forma persistente (através de cargas de múltiplas páginas).

Recomendamos ativar o recurso de cache de objetos do W3TC em seu site WordPress para acelerar as solicitações que utilizam consultas de banco de dados se seu site não estiver hospedado no Kinsta.

Se seu site for hospedado em Kinsta, oferecemos uma camada de cache de objetos de alto desempenho, alimentada por nosso add-on Redis. Redis é um armazenamento de estrutura de dados em memória de código aberto que é freqüentemente usado para aplicações de banco de dados e corretor de mensagens.

Uma vez que a Redis armazena dados na RAM, ela permite que o WordPress acesse dados em cache a partir de um cache de objetos persistentes que é muito mais rápido do que as configurações tradicionais de cache de objetos.

Navegador Cache

O cache do navegador pode acelerar consideravelmente seu site WordPress ao armazenar ativos estáticos como CSS, JavaScript, imagens e fontes localmente. O cache do navegador usa um período de expiração para determinar por quanto tempo os ativos serão armazenados em cache. Na web moderna, a maioria dos desenvolvedores especifica um período de expiração de 1 ano para ativos estáticos.

Para sites hospedados em Kinsta, aplicamos um período de 1 ano de cache para arquivos estáticos. Isto pode ser verificado verificando o cabeçalho de cache-control para um arquivo estático hospedado em Kinsta. Se o seu web host não aplicar um “tempo de expiração futuro” para o cache do navegador, você pode ativar o recurso “Cache do navegador” no W3 Total Cache e configurar o período de expiração.

CDN (Content Delivery Network)

Se você estiver usando um CDN, ou rede de entrega de conteúdo, para descarregar arquivos estáticos para centros de dados em todo o mundo, você pode configurar o W3 Total Cache para reescrever URLs para “theme files, media library attachments, CSS, JS” e muito mais com seu hostname CDN.

Se seu site estiver hospedado em Kinsta, recomendamos o uso do Kinsta CDN, nossa rede de entrega de conteúdo de alto desempenho alimentada pela Cloudflare. Quando o Kinsta CDN for ativado, as URLs dos arquivos estáticos serão automaticamente reescritas para serem servidas a partir do Kinsta CDN.

Você também tem acesso a outros recursos embutidos, incluindo o recurso de minificação de código que permite aos clientes Kinsta ativar a minificação automática CSS e JavaScript diretamente no painel MyKinsta com o clique de um botão.

Se você preferir usar outro provedor CDN ou se seu site não estiver hospedado no Kinsta, você pode habilitar o recurso “CDN” no W3 Total Cache e adicionar seu URL CDN.

Proxy Reversa

Um proxy reverso fica entre seu servidor web e o WordPress, e pode ser usado para executar várias manipulações baseadas em lógica nas solicitações recebidas. O W3TC suporta Verniz, que é um popular “acelerador HTTP” para o cache e o serviço de dados com o objetivo de reduzir a carga do backend.

Para utilizar o Verniz, o pacote de Verniz deve primeiro ser instalado por seu anfitrião. Se você for um cliente Kinsta, não ative a opção de proxy reverso, pois nossa infra-estrutura não foi projetada para funcionar com o Verniz.

Experiência do usuário

A otimização da “Experiência do Usuário” do W3TC permite que você permita o carregamento preguiçoso, desabilite emojis e desabilite o script wp-embed.js. Recomendamos ativar o carregamento preguiçoso em seu site WordPress para acelerar o carregamento de páginas. Se você ainda não estiver usando o carregamento preguiçoso baseado em navegador ou plugin, recomendamos o uso do W3 Total Cache para carregamento preguiçoso.

No mundo de hoje, a maioria dos sistemas operacionais tem suporte integrado para emojis. Assim, você pode querer desativar o WordPress’ incluído no script emoji se você não for um usuário de emoji pesado. Usar o W3TC para remover o wp-emoji-release.min.js ajudará você a raspar uma solicitação HTTP e remover ~10KB da carga de sua página.

Da mesma forma, se você não incorporar posts do WordPress, você pode desativar o wp-embed.js com W3 Total Cache. A desativação deste script não afetará a funcionalidade oEmbed para embutir vídeos do YouTube, streams SoundCloud, etc.

Diversos

W3 Total Cache tem algumas configurações diversas que você também pode configurar. Se você quiser exibir um widget do painel de Google Page Speed no WordPress, você pode inserir sua chave API de velocidade de página. Há também uma opção para exibir a classificação da Velocidade de Página na barra de menu para cada página em seu site WordPress.

Para outras configurações como “NGINX server configuration file path”, “enable file locking”, “optimize disk enhanced page and minify disk caching for NFS”, recomendamos deixá-los em suas configurações padrão, a menos que você tenha um motivo específico para alterá-los.

Debug

Se você estiver solucionando um problema em seu site, W3 Total Cache tem um prático menu “Debug” que lhe permite desativar camadas de cache específicas e configurações de otimização. Por exemplo, se você notar uma falha visual em seu site, você pode ativar o modo de depuração para a opção “Minify”, que irá inserir comentários HTML no código fonte de sua página para ajudá-lo a solucionar problemas.

Uma vez que o recurso de depuração coloca carga adicional nos recursos de seu servidor, recomendamos usá-lo apenas em um ambiente de encenação ou durante as horas de pouco tráfego. Além disso, certifique-se de desativar o modo de debug depois de terminar sua solução de problemas!

Configurações de importação/exportação

Depois de terminar de configurar suas configurações, você pode usar a função “Import/Export” do W3TC para criar um backup de sua configuração. O W3 Total Cache tem muitas configurações, portanto, ser capaz de exportar um backup completo é ótimo para a paz de espírito. Além disso, ele permite que você replique facilmente sua configuração personalizada do W3TC em vários locais sem ter que configurar nada manualmente.

W3 Total Cache Configurações – Página Cache

Vamos mergulhar nas configurações “Page Cache” do W3 Total Cache. Lembre-se que se seu site estiver hospedado em Kinsta, você não precisa se preocupar com o cache de páginas – portanto, sinta-se à vontade para pular esta seção.

• Cache Front Page – Para a maioria dos sites, a primeira página é tipicamente a página que recebe mais tráfego. Portanto, recomendamos habilitar esta configuração.
• Cache Feeds – O WordPress gera vários feeds RSS, que permitem que aplicativos e serviços externos como o Feedburner exibam o conteúdo de seu site. Embora o RSS não seja tão popular hoje em dia como costumava ser, ainda assim recomendamos habilitar esta configuração.
• Cache SSL (Solicitações HTTPS) – Se seu servidor web não forçar HTTPS para todas as solicitações recebidas, permitir esta configuração pode ter um impacto positivo no desempenho. Se você já estiver forçando o HTTPS no nível de servidor web, não há necessidade de habilitar isto.
• Cache URIs com Query String Variables – Uma query string é um parâmetro que é adicionado no final da URL (por exemplo, /?version=123). As strings de consulta são freqüentemente usadas para solicitar e exibir dados específicos de seu banco de dados WordPress. Em geral, o objetivo de uma query string é solicitar uma versão única de uma página, por isso recomendamos manter isso desativado a menos que você tenha strings de consulta específicas que gostaria de armazenar.
• Cache 404 (Não encontrado) Páginas – Por padrão, o W3TC mantém esta opção desativada. A razão para isto é provavelmente devido ao comportamento de cache se você estiver usando o método de cache de páginas “Disk Enhanced”. Com essa opção selecionada, 404 páginas retornam um código de resposta de 200. Idealmente, 404 páginas devem retornar 404 códigos de resposta, portanto recomendamos testar esta configuração com sua configuração de cache para ver se ela é compatível.
• Don’t Cache Pages for Logged In Users – Recomendamos habilitar esta opção. Usuários logados normalmente estão trabalhando na atualização de páginas. Com o cache ativado, os usuários precisariam limpar o cache constantemente a fim de ver as atualizações das páginas.
• Don’t Cache Pages for Certain User Roles – Esta opção permite que você ignore o cache para certas funções do usuário do WordPress. Se a opção “don’t cache pages for logged users” já estiver ativada, esta opção não terá efeito sobre o comportamento do cache.

Aliases

O recurso “Aliases” do W3 Total Cache permite o cache de conteúdo WordPres idêntico que está disponível em diferentes domínios. Não recomendamos a ativação deste recurso. Se seu site WordPress estiver acessível em diferentes domínios (por exemplo, domain.com e www.domain.com), é melhor configurar uma regra de redirecionamento 301 para encaminhar solicitações ao seu domínio principal para evitar penalidades de conteúdo duplicado do Google e outros mecanismos de busca.

Pré-carga de Cache

O recurso “Cache Preload” rastreia através de seu mapa do site e faz pedidos às páginas de seu site para pré-carregar o cache da página. Para a maioria dos sites, recomendamos desativar a pré-carga do cache porque ela pode causar picos de recursos no servidor que compensam os benefícios potenciais de desempenho.

Se você quiser ativar a pré-carga do cache, o W3TC permite especificar uma URL do mapa do site, intervalo de atualização e páginas por intervalo. Certifique-se de não definir o “intervalo de atualização” e “páginas por interno” muito alto para reduzir a chance de picos de CPU.

Política de purga

A “Política de purga” do W3TC permite especificar as páginas e feeds que você deseja purgar automaticamente após a publicação ou edição dos posts. Para a maioria dos sites, as configurações padrão (página inicial, página de posts e feed do blog) devem ser suficientes. Se você quiser adicionar páginas adicionais à política de purga, há uma variedade de opções que você pode configurar.

REST API

WordPress’ incluiu REST API que permite a consulta de dados em formato JSON. O REST API é usado por uma variedade de plugins, e é crucial para configurações de WordPress sem cabeça. Dependendo de seu caso exato de uso para a API REST, o cache dos resultados da consulta pode ser uma boa idéia. O cache da API REST se enquadra na categoria “se você precisar, você saberá”, portanto, se você não tiver certeza se deve ou não ativar o cache da API REST, recomendamos deixá-lo em “Don’t Cache”.

Avançado

Nas opções de cache de página “Avançado” do W3TC, você pode personalizar uma variedade de configurações incluindo “cadeias de consulta aceitas”, “agentes de usuário rejeitados”, configurações de desvio de cache granular, e muito mais. Por exemplo, se você precisar configurar seu W3 Cache Total para nunca colocar em cache posts sob uma determinada categoria ou tag, você poderá fazê-lo nas opções “Avançado”.

Como estas configurações podem ser muito específicas do local, não há “configurações recomendadas” que possamos fornecer. Dito isto, se você estiver procurando personalizar um aspecto muito específico do comportamento de cache da página de seu site, definitivamente dê uma olhada nas opções avançadas.

Configurações do W3 Total Cache — Minify

A seguir, vamos rever as configurações “Minify” do W3 Total Cache.

• Reescrever estrutura URL – Este ajuste afeta a estrutura URL dos ativos minerados. Recomendamos mantê-la ativada para que suas URLs pareçam “bonitas”.
• Desativar Minify para usuários logados – Se você estiver fazendo alguma solução de problemas ou depuração, desativar a minificação para usuários logados pode ser útil. Caso contrário, recomendamos manter esta opção desativada.

HTML & XML

Na seção “HTML & XML”, você pode configurar as configurações de minificação HTML.

• Mineração de CSS em linha – Recomendamos habilitar esta opção para remover espaços em branco no CSS em linha.
• Mineração JS em linha – Recomendamos habilitar esta opção para remover espaços em branco no JavaScript em linha. Em alguns casos, a minificação do JS pode resultar em um erro de código. Se ativar esta opção quebrar a funcionalidade de seu site, desative-o.
• Não minify feeds – Recomendamos manter esta opção desativada. Os feeds são utilizados apenas por leitores RSS e outros serviços similares, portanto, não é necessário minicar feeds.
• Remoção de quebra de linha – Esta opção é desativada por padrão, e não recomendamos ativá-la para garantir que seu site seja renderizado corretamente.

JS

Na seção “JS”, você pode configurar as configurações de minificação JavaScript.

• Operações em Áreas – Esta opção permite selecionar o “tipo de incorporação” para JavaScript minificado. Para arquivos JS de antes </head> e depois de <body>, você pode escolher entre “bloqueio”, “não-bloqueio”, “não-bloqueio usando async” e “não-bloqueio usando adiamento”. Embora os métodos de carregamento sem bloqueio normalmente resultem em melhor desempenho, eles nem sempre são 100% compatíveis com todos os códigos JavaScript. Além disso, “async” e “defer” têm casos de uso muito diferentes. Assim, recomendamos usar o método padrão de “bloqueio” a menos que você esteja ciente das peculiaridades do JavaScript não-bloqueio.
• Minify ou Combine Only – Você pode escolher entre dois modos de otimização para JavaScript. Quando “Minificar” é selecionado, seus arquivos JS serão combinados e minificados. Se você selecionar “Combine Only”, então o arquivo JS combinado resultante não será minificado. Se você estiver enfrentando problemas relacionados à minificação e não quiser depurar para descobrir qual script está causando o problema, selecionar a opção “Combine Only” pode corrigir o erro.
• HTTP/2 Push – Se seu servidor suporta HTTP/2 Server Push, ativar esta opção pode ajudá-lo a reduzir o tempo de carregamento da página. O HTTP/2 Server Push empurra os arquivos para os visitantes antes que eles sejam solicitados. Recomendamos fazer testes adequados antes de habilitar esta opção em um ambiente de produção, porque o Server Push é freqüentemente mal utilizado. O Server Push não é ideal para arquivos JavaScript maiores, e você vai querer ter certeza de que os benefícios superam o carregamento de arquivos JS diretamente do cache do navegador de um visitante.

CSS

Na seção “CSS”, você pode configurar as configurações de minificação do CSS.

• Combine Only – Ao contrário dos arquivos JavaScript, o CSS normalmente não sofre de problemas relacionados à minificação. Portanto, não recomendamos habilitar “Combine Only”.
• Remoção de Comentários Preservados – Esta configuração remove comentários dos arquivos CSS. Recomendamos ativar esta opção para reduzir ao máximo o tamanho do arquivo.
• Remoção de quebra de linha – Esta configuração remove as quebras de linha dos arquivos CSS. Recomendamos habilitar esta opção também. Se você notar qualquer problema de exibição após ativar a “Remoção de Quebra de Linha”, desative-a.

Avançado

A seção “Avançado” contém algumas configurações adicionais para personalizar o comportamento de minificação.

• Atualizar arquivos externos Todo – O W3TC permite especificar a quantidade de tempo entre as atualizações de arquivos CSS e JS. Com a configuração padrão de 86400 segundos, seus ativos serão baixados e minerados a cada 24 horas. Se seu site não mudar com freqüência, sinta-se à vontade para definir um período de tempo mais longo.
• Intervalo de coleta de lixo – Este período de tempo especifica com que freqüência os dados de cache expirados são excluídos. A configuração padrão é 24 horas. Se seu site tiver pouco espaço de armazenamento, recomendamos baixar o “Intervalo de Coleta de Lixo”.

O restante da seção “Avançado” inclui campos de entrada que permitem especificar arquivos de bens que nunca devem ser minerados. Há também um campo “Agentes de Usuário Rejeitados” que permite servir arquivos não minerados a certos agentes de usuário. Finalmente, você pode adicionar arquivos de ativos externos para serem incluídos no processo de minificação do W3 Total Cache.

Configurações do W3 Total Cache – Objeto Cache

A seguir, na lista, estão as configurações “Object Cache” do W3TC. Para a maioria dos sites, as configurações padrão funcionarão muito bem, mas vamos repassar independentemente delas.

• Default Lifetime of Cache Objects – O tempo de expiração para itens de cache inalterados. Um período de tempo maior resulta em um cache de objetos maior. Se você estiver preocupado com a capacidade de armazenamento de seu servidor, recomendamos manter o valor padrão ou baixá-lo.
• Intervalo de coleta de lixo – Esta configuração especifica a freqüência com que os dados do cache expirados são descartados. O valor padrão de 3.600 segundos (1 hora) deve ser suficiente para a maioria dos locais.
• Grupos Globais – Esta configuração permite configurar grupos de cache compartilhados entre sites em uma única rede com vários sites. Recomendamos deixar esta configuração em seu estado padrão, a menos que você tenha um motivo específico para alterá-la.
• Grupos Não-Persistentes – Esta configuração permite selecionar quais grupos de objetos nunca devem ser armazenados. Mais uma vez, recomendamos manter a configuração padrão.
• Habilitar Caching para solicitações wp-admin – Esta opção é desabilitada por padrão, e não recomendamos habilitá-la porque pode causar efeitos colaterais. Além disso, os visitantes da maioria dos sites WordPress nunca interagem com o painel de controle wp-admin.

Configurações do W3 Total Cache – Cache do Browser

A maioria dos hosts WordPress, incluindo o Kinsta, já implementam cabeçalhos de cache apropriados no nível de servidor web. Se seu host não o faz, ou se você quiser personalizar ainda mais o comportamento de cache do navegador, você pode fazer isso com o W3 Total Cache.

Nas configurações “Cache do navegador”, as configurações padrão para as seções “Geral”, “CSS & JS”, e “HTML & XML” e “Mídia e outros arquivos” são adequadas para a maioria dos sites WordPress. Como há tantas configurações nesta página, recomendamos consultar um desenvolvedor antes de fazer qualquer mudança no comportamento de cache do navegador. Dito isto, abaixo estão algumas configurações chave para prestar atenção no que diz respeito ao cache do navegador.

• Expira a vida útil dos cabeçalhos – Configurar uma longa “expiração da vida útil dos cabeçalhos” é importante para o cache eficiente do navegador. Na Kinsta, aplicamos uma vida útil de 1 ano para ativos estáticos como CSS, JS, imagens e fontes. Se você estiver usando o W3TC para configurar o cache do navegador, certifique-se de definir este valor para 31536000 (1 ano).
• Política de Controle de Cache – Para garantir que seus ativos estáticos possam ser armazenados em cache pelos navegadores, certifique-se de que a “política de controle de cache” esteja definida para “public, max_age=EXPIRES SECONDS”.
• Habilitar compressão HTTP (gzip) – A compressão GZIP reduz drasticamente o tamanho do arquivo de páginas HTML e ativos antes que eles sejam enviados aos visitantes, portanto, certifique-se de habilitar esta opção se a configuração do servidor de seu host suportar GZIP. Se seu site estiver hospedado em Kinsta, não há necessidade de ativar a compressão GZIP no W3TC, pois ela já está ativada como parte de nossa configuração padrão.
• Remover cadeias de consulta de recursos estáticos – Uma cadeia de consulta é uma cadeia adicional que é adicionada ao final de um caminho URL para especificar parâmetros de solicitação ou forçar um servidor web a fornecer um novo ativo. As strings de consulta começam com um ?, e a maioria dos servidores web são configurados para contornar o cache para solicitações com strings de consulta. A remoção de strings de consulta das solicitações de página é útil para reduzir a carga do servidor porque essas solicitações usam PHP para renderizar páginas. Não recomendamos remover strings de consulta de recursos estáticos no W3 Total Cache porque eles ajudam a garantir que a última versão dos arquivos CSS e JS seja entregue aos seus visitantes.

A página de configurações do “Browser Cache” também contém uma variedade de configurações relacionadas aos cabeçalhos de segurança como Política de Segurança de Conteúdo (CSP) e Proteção X-XSS. Recomendamos sempre trabalhar com um desenvolvedor qualificado para passar por estas configurações, pois configurações incorretas podem afetar diretamente a experiência do usuário de seu site. Por exemplo, habilitar o cabeçalho HSTS sem um certificado SSL e configuração HTTPS adequados pode tornar seu site inacessível.

Configurações do W3 Total Cache – Grupos de Agentes de Usuário

O recurso “User Agent Groups” do W3 Total Cache é muito poderoso se você precisar redirecionar o tráfego com base em um tipo de dispositivo do usuário. Por exemplo, você pode configurar seu site para renderizar com um tema diferente se um usuário visitar seu site a partir de um telefone celular. Da mesma forma, você pode redirecionar usuários para um site completamente diferente se seu site móvel viver em um subdomínio único.

Na era do web design receptivo, não vemos muitos casos de uso para esta característica em particular. Atualmente, a melhor prática é fazer com que seu site reaja desde o início, em vez de depender de múltiplos temas ou de um subdomínio apenas móvel.

Configurações do W3 Total Cache – Grupos de referência

Um HTTP referrer é um cabeçalho HTTP opcional que fornece informações sobre a origem de uma solicitação. Por exemplo, se um visitante clicar em seu site a partir de uma listagem do Google Search, o referenciador HTTP seria google.com.

No W3 Total Cache, você pode definir o comportamento de cache personalizado com base em um referrer HTTP de uma solicitação com “Referrer Groups”. Por exemplo, você pode criar um grupo de referência que consiste de mecanismos de busca e personalizar o comportamento de cache apenas para solicitações desses domínios.

Similar aos “Grupos de Agentes de Usuários” mencionados acima, você também pode redirecionar as solicitações para um domínio diferente com o recurso “Grupos de Referências”. A maioria dos sites WordPress não precisará configurar grupos de referência, portanto não recomendamos a configuração de nenhum.

Configurações do W3 Total Cache – Grupos de Cookie

O último grupo de caching que a W3 Total Cache apoia é o “Cookie Groups”. Este recurso permite criar baldes e comportamentos de cache exclusivos com base nos cookies de uma solicitação. Semelhante aos “Grupos de Agentes de Usuário” e “Grupos de Referências”, a maioria dos sites não precisará criar uma configuração de cache personalizada baseada em cookies. Se seu site requer o cache baseado em cookies, recomendamos trabalhar com um desenvolvedor para configurá-lo corretamente.

Configurações do W3 Total Cache – CDN

Agora, vamos passar para as configurações CDN do W3 Total Cache.

• Host Attachments – Habilite isto para servir ativos em sua biblioteca de mídia WordPress a partir de seu CDN.
• Host wp-includes/ Files – Habilite isto para servir arquivos na pasta wp-includes do seu CDN.
• Host Theme Files – Habilite isto para servir seus arquivos temáticos a partir de seu CDN.
• Hospedar arquivos CSS e JS minificados – Habilite isto para servir os arquivos CSS e JS minificados do W3TC a partir de seu CDN.
• Host Custom Files – Se você tem arquivos que não estão em sua biblioteca de mídia ou em sua pasta temática, você pode adicionar os caminhos dos arquivos no W3TC para servi-los a partir de seu CDN.
• Adicionar cabeçalho canônico – Uma etiqueta rel="canonical" ajuda os mecanismos de busca a identificar a fonte original ou URL. Como os CDNs normalmente usam um domínio diferente, a adição de uma tag canônica notifica aos mecanismos de busca a localização do ativo original. Com isto dito, não há problema em manter este ajuste desativado porque os mecanismos de busca modernos são inteligentes o suficiente para identificar CDNs sem impactar a classificação SEO de seu site.

Avançado

• Somente Purge CDN Manually – Recomendamos manter esta opção desativada para deixar o W3TC lidar com a purga automática do cache.
• Desabilitar CDN em páginas SSL – Mantenha esta configuração desabilitada. Se você estiver usando um CDN, é melhor tê-lo ativo tanto nas páginas HTTP como HTTPS.
• Use os links CDN para a biblioteca de mídia nas páginas de administração – Não recomendamos ativar esta opção porque ela reescreverá URLs em sua biblioteca de mídia.
• Adicionar cabeçalho CORS – Mantenha esta configuração ativada para permitir que seus ativos CDN sejam exibidos em outros domínios.
• Desativar CDN para as seguintes funções – Esta opção permite desativar CDN para certas funções do usuário do WordPress. Na maioria dos casos, é melhor manter esta opção desativada.
• wp-inclui tipos de arquivo a serem carregados – Este campo especifica os formatos de arquivo no wp-includes que serão servidos a partir de seu CDN. A lista padrão de formatos de arquivo deve ser boa para a maioria dos sites. Se você tiver arquivos personalizados em sua pasta wp-includes, sinta-se à vontade para adicionar formatos adicionais, conforme necessário.
• Tipos de arquivo temático a ser carregado – Este campo especifica os formatos de arquivo em sua pasta temática WordPress que serão servidos a partir de seu CDN. A lista padrão contém todos os recursos populares, formatos de imagem e fontes. Sinta-se à vontade para adicionar formatos adicionais, se necessário.
• Custom File List – Se você habilitou “Host Custom Files”, você pode adicionar uma lista de arquivos neste campo para servir a partir de seu CDN.
• Agentes de usuário rejeitados – Este campo permite que você especifique os agentes de usuário que não serão atendidos a partir de seu CDN. Recomendamos manter este campo vazio para garantir que seu CDN esteja sendo utilizado adequadamente.
• Arquivos rejeitados – Este campo permite que você especifique arquivos que não devem ser ser servidos a partir de seu CDN. Se um serviço que você está usando requer que os ativos sejam servidos a partir de seu domínio principal, você pode adicionar o caminho do arquivo ao campo “Arquivos Rejeitados”.

Configurações do W3 Total Cache – Experiência do usuário

A seguir, vamos personalizar a “Experiência do Usuário”, ou carregamento preguiçoso, em W3 Total Cache.

• Processar etiquetas de imagem HTML – Habilite isto para garantir que as imagens sejam carregadas preguiçosamente.
• Process Background Images – Se você estiver utilizando `background` para exibir uma imagem em CSS, habilitando esta opção permitirá que essas imagens sejam carregadas preguiçosamente.
• Excluir Palavras – Neste campo, você pode especificar texto para contornar a carga preguiçosa. Por exemplo, se você adicionar no-lazy-load a este campo, uma imagem exibida com <img src="image.jpg"> não será carregada preguiçosamente.
• Script Embed Method – Esta configuração permite personalizar o método de carregamento para o script de carregamento preguiçoso. O método padrão de async é a melhor opção para a maioria dos sites. Se seu site consiste apenas de uma única página de destino, o método inline pode ser usado para reduzir o número de solicitações HTTP para carregar a página.

Extensões disponíveis para W3 Total Cache

W3 Total Cache oferece várias extensões para integração com serviços de terceiros. O W3TC possui atualmente extensões para os seguintes serviços.

• AMP
• Cloudflare
• Google Feedburner
• Fragment Cache
• Genesis Framework
• New Relic
• Swarmify
• Yoast SEO
• WPML

Se você estiver utilizando algum destes serviços em seu site, recomendamos a criação da extensão relevante para garantir a compatibilidade adequada com o W3 Total Cache. Nesta seção, daremos uma olhada na extensão Cloudflare para o W3 Total Cache.

Como configurar o W3 Total Cache com a Extensão do Cloudflare

Para integrar o Cloudflare com o W3 Total Cache, você precisará de duas peças de informação de seu painel de controle do Cloudflare – e-mail de conta e chave API. O e-mail da conta é o endereço de e-mail que você usa para fazer o login no Cloudflare. Vamos dar uma olhada em como configurar uma chave de API do Cloudflare.

No painel do Cloudflare, clique na guia “Overview” (Visão Geral). A seguir, role para baixo e clique em Get Your API Token na barra lateral direita.

Role para baixo e clique em View ao lado de “Global API Key” para obter sua chave API Cloudflare. Tenha cuidado para não compartilhar esta chave API em nenhum lugar fora do W3 Total Cache porque ela pode ser usada para controlar sua conta Cloudflare.

Em seguida, ative a extensão Cloudflare na página “Extensões” do W3 Total Cache e clique em “Configurações”. Na seção “Credenciais”, clique no botão “Autorizar“.

No popup subseqüente, insira seu e-mail de conta Cloudflare e a chave API. Se você receber uma mensagem de erro, verifique se o seu endereço de e-mail e a chave API estão corretos. Após as credenciais serem autorizadas, você deve ver as configurações adicionais do Cloudflare na página.

Vamos rever as configurações do Cloudflare em W3 Total Cache.

• Widget Statistics Interval – Especifica o período de tempo coberto para o widget Cloudflare do W3TC. A configuração padrão é de 30 minutos. Se você gostaria de ver um período de tempo mais longo, sinta-se à vontade para aumentá-lo.
• Cache Time – Especifica a quantidade de tempo que os dados widget do Cloudflare são armazenados em cache. Se você não planeja usar muito o widget, recomendamos aumentar este número para reduzir o número de solicitações ao Cloudflare a partir de seu site.
• Cache de páginas – Se você configurou o Cloudflare para cache de páginas HTML para seu site WordPress, habilite esta opção para limpar automaticamente o cache do Cloudflare após modificações e atualizações posteriores.

Caching Cloudflare

Esta seção permite que você personalize as configurações de cache do Cloudflare.

• Modo Desenvolvimento – Mantenha esta opção desativada a menos que você precise colocar o Cloudflare no Modo Desenvolvimento. Quando o Cloudflare está no Modo de Desenvolvimento, o edge caching, a minificação e a otimização da imagem são desativados por três horas. Isto permite que você veja as atualizações dos arquivos CSS e JS imediatamente e é útil para a solução de problemas.
• Nível de cache – Para a maioria dos sites, recomendamos o uso do nível de cache “Padrão”, que serve um recurso diferente cada vez que a cadeia de consulta muda. Se você estiver 100% certo de que seu site WordPress não faz uso de strings de consulta para servir conteúdo dinâmico, você também pode usar a configuração “Ignorar String de Consulta”.
• Browser Cache TTL – Recomendamos configurar o cache do navegador Cloudflare TTL para 31536000 segundos, que é igual a 1 ano.
• Challenge TTL – O Cloudflare oferece uma variedade de serviços relacionados à segurança, e os desafios do visitante é um deles. Se o Cloudflare detectar um usuário malicioso ou um comportamento estranho, ele servirá como uma mensagem de desafio na forma de um Captcha. A configuração “Challenge TTL” especifica por quanto tempo um usuário terá acesso ao seu site após completar um desafio. Com a configuração padrão de 3600 segundos, um visitante que foi sujeito a um desafio poderá usar seu site por 1 hora antes de outro desafio.
• Edge Cache TTL – Esta configuração controla quanto tempo os ativos serão armazenados em cache nos servidores edge do Cloudflare. Recomendamos configurar isto para o valor máximo de 31536000 segundos, ou 1 ano.

Processamento de conteúdo de Cloudflare

Vamos mergulhar nas configurações de processamento de conteúdo do Cloudflare em W3 Total Cache.

• Rocket Loader – O Rocket Loader da Cloudflare acelera o carregamento do JavaScript para seu site WordPress. Recomendamos habilitar o Rocket Loader se seu site tiver muito JS.
• Minify JS/CSS/HTML – Se você já ativou a minificação para HTML, CSS e JavaScript no W3 Total Cache, sinta-se à vontade para manter estas opções nas configurações de extensão do Cloudflare desativadas, pois não há necessidade de minificar ativos que já foram minerados.
• Server Side Exclude (SSE) – Esta opção permite que você esconda informações sensíveis de visitantes suspeitos (considerados pelo Cloudflare). As exclusões do lado do servidor são úteis para ocultar informações como endereço de e-mail, números de telefone e outras informações pessoais em seu site. Para usar SSE, habilite-o e embrulhe informações sensíveis em <!--sse--><!--/sse--> taga em seu código HTML ou template temático PHP.
• Ofuscação de e-mail – Quando esta opção é ativada, o Cloudflare ofusca automaticamente endereços de e-mail em seu site WordPress com JavaScript. Embora a ofuscação não vá se livrar completamente do spam de e-mail, recomendamos ativar esta opção porque ela impede que bots básicos raspem endereços de e-mail de seu site.

Processamento de imagem de Cloudflare

Vamos rever as configurações de processamento de imagem do Cloudflare.

• Proteção Hotlink – A ativação da proteção Hotlink impedirá que outros sites incorporem suas imagens. Se você estiver se deparando com limites de largura de banda devido a incrustações externas não autorizadas, ativar a “Hotlink Protection” pode ajudá-lo a reduzir o uso da largura de banda.
• Mirage (Somente Pro) – Mirage otimiza a entrega de imagens para dispositivos e redes de baixa largura de banda. Esta característica está disponível apenas no plano Cloudflare Pro e acima.
• Polonês (Somente Pro) – O polonês otimiza as imagens de seu site, e pode ser configurado para servir imagens WEBP aos navegadores suportados. Este recurso está disponível apenas no plano Cloudflare Pro e acima.

Proteção contra as nuvens

A principal característica do Cloudflare é um sofisticado firewall que pode ajudar a protegê-lo contra ataques DDoS e atores maliciosos. Vamos rever as configurações de segurança do Cloudflare.

• Nível de Segurança – Esta configuração controla a sensibilidade do firewall e das regras de segurança do Cloudflare. Recomendamos configurar o “Nível de Segurança” para “Médio” para a maioria dos sites.
• Verificação de Integridade do Navegador – Este recurso procura por mau comportamento e agentes de usuários suspeitos. Se ele detectar um usuário potencialmente malicioso ou um spammer, o Cloudflare servirá automaticamente como um desafio. Recomendamos ativar este recurso.
• Always Online – Esta opção servirá para páginas HTML estáticas de seu site se sua origem cair. Recomendamos ativá-la se você configurou o Cloudflare para o cache de HTML.
• Web Application Firewall – O WAF do Cloudflare, ou firewall de aplicações web, verificará o tráfego de entrada e filtrará o “tráfego ilegítimo” de chegar ao seu site. Recomendamos habilitar este recurso.
• Proteção avançada DDoS – Este recurso é ativado por padrão, e não pode ser desativado enquanto o proxy do Cloudflare estiver ativo. A proteção DDoS ajuda a proteger seu site contra ataques de “negação distribuída de serviço”.
• Max Upload – Isto estabelece o tamanho máximo permitido de arquivo para uploads em seu site. Você vai querer ter certeza de que esta configuração é igual ou maior do que a configuração do tamanho do arquivo de upload no WordPress.

Cloudflare SSL

Finalmente, você vai querer ter certeza de que suas configurações SSL Cloudflare estão configuradas corretamente. Vamos rever a configuração correta nesta seção.

• SSL – Se seu site estiver hospedado em Kinsta, recomendamos o uso da opção “Full” ou “Full (Strict)” SSL. A opção “Flexível” não é compatível com nossa infra-estrutura. A opção “Full Strict” requer um SSL de uma autoridade certificadora válida, enquanto a opção “Full” também suporta SSLs autoassinados. A opção “Flexível” não requer um certificado SSL no servidor de origem – não recomendamos esta opção porque é a mais insegura.
• Somente TLS 1.2 – TLS, ou Transport Layer Security, é um protocolo seguro para transferência de dados através de uma rede. Algumas normas de conformidade PCI exigem um suporte de queda para o TLS 1.1 e abaixo. Se isso for um requisito para seu site, você pode ativar a configuração “TLS 1.2 Only” no Cloudflare para definir a versão mínima do TLS para 1.2.

Leitura sugerida: Como Configurar o Cloudflare APO para WordPress

W3 Total Cache WooCommerce Configurações

WooCommerce é a plataforma mais popular de comércio eletrônico para sites WordPress. Se você estiver usando W3 Total Cache com sua loja WooCommerce, você vai querer ter certeza de que sua configuração está correta para evitar o cache dos detalhes do cliente.

Biscoitos Bypass WooCommerce

Para contornar o cache de páginas para páginas que têm cookies específicos do WooCommerce, vá para as configurações de “Page Cache” do W3TC, desça para “Rejeitados Cookies”, e adicione os quatro itens abaixo.

• woocommerce_items_in_cart
• woocommerce_cart_hash
• wp_woocommerce_session_
• wordpress_logged_in

Para segurança, também recomendamos contornar URLs específicas do WooCommerce como a página do carrinho, a página de checkout e a página de conta. Para contornar estas páginas do cache, vá para as configurações “Page Cache” do W3TC e adicione os URLs à seção “Never Cache the Following Pages”.

Como reinicializar todas as configurações no W3 Total Cache

Em alguns casos, você pode precisar começar de novo com sua configuração do W3TC. Veja como reverter o W3 Total Cache para as configurações padrão. Vá ao menu “General Settings” do W3TC, desça até a seção “Import/Export Settings”, e clique em Restore Default Settings.

Resumo

Como você pode ver, o plug-in W3 Total Cache está repleto de recursos e configurações. Desde o cache de páginas, à mineração de ativos, até a integração do Cloudflare, o W3TC tem tudo o que você precisa para aumentar o desempenho de seu site WordPress!

Neste artigo, passamos por nosso plugin de configuração recomendado para o W3TC. Você tem um plugin de otimização WordPress favorito? Informe-nos nos comentários abaixo!