Como definir as configurações de cache total do W3 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 oferece controle total sobre a configuração de cache do seu site WordPress.

A granularidade das configurações do W3TC o torna um plugin ideal para usuários avançados e desenvolvedores que desejam controle total sobre seus sites WordPress. Neste artigo, examinaremos detalhadamente as configurações do W3 Total Cache e forneceremos nossa configuração recomendada para aumentar o desempenho do seu site WordPress.

Se você for um usuário Kinsta, não precisará definir certas configurações no W3 Total Cache porque nossa pilha de hospedagem já possui muitas otimizações incorporadas. Por exemplo, o cache de página no nível do servidor via NGINX é ativado por padrão em todos os sites Kinsta , então você não precisará habilitá-lo no W3 Total Cache. Se você estiver configurando o W3TC em um site hospedado pela Kinsta, apenas preste atenção extra às instruções de configuração abaixo. Garantiremos que você saiba se uma configuração específica não for necessária ou compatível com Kinsta.

Como instalar o W3 Total Cache

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

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

Onde as configurações de cache total do W3 são armazenadas?

Depois de instalar o W3 Total Cache, você verá uma guia “Desempenho” na barra lateral do painel de administração do WordPress. Clicar na guia “Desempenho” revelará uma variedade de submenus como “Configurações gerais”, “Cache de página”, “Minify” e muito mais.

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

Como limpar o cache total do W3

Antes de entrarmos em como configurar o W3 Total Cache, vamos ver rapidamente como limpar ou limpar seu cache. Se você passar o mouse sobre a guia “Desempenho” na barra de ferramentas do administrador, verá duas opções de limpeza.

1. Purgar todos os caches – purgue todos os caches de uma vez.
2. Limpar módulos – limpar um cache individual (por exemplo, ativos minificados, cache de página, cache de objeto, etc.).

Configurações gerais do W3 Total Cache

Vamos mergulhar no menu “Configurações gerais” do W3 Total Cache para definir algumas configurações básicas.

Cache de página

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

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

Minimizar

Minimizar seus recursos HTML, CSS e JavaScript pode reduzir o tamanho geral das páginas do 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 “Modo Minify” será suficiente.

Em alguns casos, a redução de ativos pode causar falhas no código CSS ou JavaScript, o que geralmente resulta em erros visíveis no frontend. Se você notar problemas incomuns em seu site após a redução de recursos, recomendamos trabalhar com um desenvolvedor para identificar os recursos que estão causando problemas. Depois disso, você pode usar o recurso “Minify” no modo manual, que permite ignorar a minificação para arquivos CSS e JavaScript específicos.

Cache Opcode

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

Se seu site estiver hospedado em Kinsta, você não precisa se preocupar em habilitar uma camada de cache de opcode no W3 Total Cache. Habilitamos o OPcache, um cache de opcode, em todos os ambientes ativos. O OPcache é desabilitado em ambientes de teste para garantir que o código PHP compilado não seja armazenado em cache e não interfira no desenvolvimento e na depuração do site.

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

Cache de banco de dados

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

Descobrimos que, em alguns casos, o recurso de cache do banco de dados pode resultar em alto uso da CPU. Isso significa que a quantidade de CPU economizada pelo armazenamento dos resultados da consulta do banco de dados pode acabar sendo compensada pelo aumento da CPU necessária para esse recurso.

Cache de Objetos

No contexto do WordPress, um cache de objeto armazena os resultados de consultas de banco de dados concluídas. Na verdade, o WordPress tem um cache de objetos embutido, mas só retém dados para um único carregamento de página. Isso permite uma renderização de página mais eficiente, pois garante que o carregamento de uma página não precise desperdiçar recursos da CPU executando consultas de banco de dados idênticas.

Embora o cache de objetos padrão do WordPress seja, sem dúvida, benéfico para o desempenho, um cache de objetos que retém dados em carregamentos de página é ainda melhor! O recurso “Object Cache” do W3TC adiciona um script de cache personalizado em seu diretório /wp-content e altera o comportamento do cache de objetos do WordPress para reter dados de forma persistente (em vários carregamentos de página).

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

Se o seu site estiver hospedado na Kinsta, oferecemos uma camada de cache de objetos de alto desempenho desenvolvida pelo nosso complemento Redis. O Redis é um armazenamento de estrutura de dados na memória de código aberto que é frequentemente usado para aplicativos de banco de dados e agente de mensagens.

Como o Redis armazena dados em cache na RAM, ele permite que o WordPress acesse dados em cache de um cache de objeto persistente que é muito mais rápido do que as configurações tradicionais de cache de objeto.

Cache do navegador

O cache do navegador pode acelerar consideravelmente seu site WordPress armazenando 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 devem ser 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 na Kinsta, aplicamos um período de cache de 1 ano para arquivos estáticos. Isso pode ser verificado verificando o cabeçalho cache-control para um arquivo estático hospedado em Kinsta. Se o seu host não impõe um “tempo de expiração de futuro distante” para o cache do navegador, você pode habilitar o recurso “Cache do navegador” no W3 Total Cache e configurar o período de expiração.

CDN (Rede de Entrega de Conteúdo)

Se você estiver usando uma CDN, ou rede de entrega de conteúdo, para descarregar arquivos estáticos para data centers em todo o mundo, poderá configurar o W3 Total Cache para reescrever URLs para “arquivos de tema, anexos de biblioteca de mídia, CSS, JS” e muito mais com seu Nome de host CDN.

Se o seu site estiver hospedado na Kinsta, recomendamos o uso da Kinsta CDN, nossa rede de entrega de conteúdo de alto desempenho alimentada por KeyCDN. Quando a Kinsta CDN está habilitada, os URLs de arquivos estáticos serão automaticamente reescritos para serem servidos a partir da Kinsta CDN.

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

Proxy reverso

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

Para usar o Varnish, o pacote do Varnish deve primeiro ser instalado pelo seu host. Se você é um cliente Kinsta, não habilite a opção de proxy reverso, pois nossa infraestrutura não foi projetada para funcionar com o Varnish.

Experiência de usuário

A otimização da “Experiência do Usuário” do W3TC permite habilitar o carregamento lento, desabilitar emojis e desabilitar o script wp-embed.js . Recomendamos ativar o carregamento lento em seu site WordPress para acelerar o carregamento da página. Se você ainda não estiver usando o carregamento lento nativo do navegador ou baseado em plug-ins, recomendamos o uso do W3 Total Cache para carregamento lento.

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

Da mesma forma, se você não incorporar postagens do WordPress, poderá desativar o wp-embed.js com o W3 Total Cache. Desabilitar este script não afetará a funcionalidade oEmbed para incorporar vídeos do YouTube, streams do SoundCloud, etc.

Diversos

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

Para as outras configurações, como “caminho do arquivo de configuração do servidor NGINX”, “habilitar bloqueio de arquivo”, “otimizar página aprimorada de disco e minimizar cache de disco para NFS”, recomendamos deixá-las em suas configurações padrão, a menos que você tenha um motivo específico para alterá-las.

Depurar

Se você estiver solucionando um problema em seu site, o W3 Total Cache tem um prático menu “Debug” que permite desabilitar camadas específicas de cache e configurações de otimização. Por exemplo, se você notar uma falha visual em seu site, você pode habilitar 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.

Como o recurso de modo de depuração sobrecarrega os recursos do servidor, recomendamos usá-lo apenas em um ambiente de teste ou durante o horário de baixo tráfego. Além disso, certifique-se de desabilitar o modo de depuração depois de terminar a solução de problemas!

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

Após terminar de configurar suas configurações, você pode usar a função “Importar/Exportar” do W3TC para criar um backup de sua configuração. O W3 Total Cache tem muitas configurações, portanto, poder exportar um backup completo é ótimo para sua tranquilidade. Além disso, permite replicar facilmente sua configuração personalizada do W3TC em vários sites sem precisar configurar nada manualmente.

Configurações de cache total do W3 — Cache de página

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

• Cache Front Page – Para a maioria dos sites, a primeira página é normalmente a página que recebe mais tráfego. Assim, 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 do seu site. Embora o RSS não seja tão popular hoje em dia quanto costumava ser, ainda recomendamos habilitar essa configuração.
• Cache SSL (solicitações HTTPS) – Se o seu servidor web não forçar HTTPS para todas as solicitações recebidas, habilitar essa configuração pode ter um impacto positivo no desempenho. Se você já está forçando HTTPS no nível do servidor web, não há necessidade de habilitar isso.
• URIs de cache com variáveis ​​de string de consulta – Uma string de consulta é um parâmetro adicionado no final da URL (por exemplo, /?version=123). As strings de consulta são frequentemente usadas para solicitar e exibir dados específicos do seu banco de dados WordPress. Em geral, a finalidade de uma string de consulta é solicitar uma versão exclusiva de uma página, portanto, recomendamos manter isso desativado, a menos que você tenha strings de consulta específicas que gostaria de armazenar em cache.
• Páginas de cache 404 (não encontradas) – Por padrão, o W3TC mantém essa opção desabilitada. A razão para isso é provavelmente devido ao comportamento de cache se você estiver usando o método de cache de página “Disk Enhanced”. Com essa opção selecionada, 404 páginas retornam um código de resposta de 200. Idealmente, as páginas 404 devem retornar códigos de resposta 404, portanto, recomendamos testar essa configuração com sua configuração de cache para ver se ela é compatível.
• Não armazene páginas em cache para usuários conectados – recomendamos habilitar esta opção. Os 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 para ver as atualizações da página.
• Não armazene páginas em cache para determinadas funções de usuário – Esta opção permite que você ignore o cache para determinadas funções de usuário do WordPress. Se a opção “não armazenar páginas em cache para usuários logados” já estiver habilitada, esta opção não terá efeito no comportamento do cache.

Apelido

O recurso “Aliases” do W3 Total Cache permite armazenar em cache o conteúdo WordPres idêntico que está disponível em diferentes domínios. Não recomendamos ativar esse recurso. Se o seu site WordPress estiver acessível em domínios diferentes (por exemplo, domínio.com e www.domínio.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 de outros mecanismos de pesquisa.

Pré-carregamento de cache

O recurso "Pré-carregamento de cache" rastreia o mapa do site e faz solicitações às páginas do site para pré-carregar o cache da página. Para a maioria dos sites, recomendamos desabilitar o pré-carregamento de cache porque isso pode causar picos de recursos do servidor que compensam os benefícios potenciais de desempenho.

Se você deseja habilitar o pré-carregamento de cache, o W3TC permite especificar uma URL de 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 limpeza

A “Política de Limpeza” do W3TC permite que você especifique as páginas e feeds que deseja limpar automaticamente depois que as postagens forem publicadas ou editadas. Para a maioria dos sites, as configurações padrão (página inicial, página de postagens e feed do blog) devem ser suficientes. Se você quiser adicionar páginas adicionais à política de limpeza, há várias opções que podem ser configuradas.

API REST

A API REST incluída no WordPress permite consultar dados formatados em JSON. A API REST é usada por uma variedade de plugins e é crucial para configurações sem cabeça do WordPress. Dependendo do seu caso de uso exato para a API REST, armazenar em cache os resultados da consulta pode ser uma boa ideia. 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 habilitar o cache da API REST, recomendamos deixá-lo em “Não armazenar em cache”.

Avançado

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

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

W3 Total Cache Settings — Minimizar

Em seguida, vamos ver as configurações de “Minify” do W3 Total Cache.

• Reescrever estrutura de URL – essa configuração afeta a estrutura de URL de ativos minificados. Recomendamos mantê-lo ativado para que seus URLs fiquem “bonitos”.
• Desabilitar a minificação para usuários logados – Se você estiver resolvendo algum problema ou depurando, desabilitar a minificação para usuários logados pode ser útil. Caso contrário, recomendamos manter esta opção desabilitada.

HTML e XML

Na seção "HTML & XML", você pode definir as configurações de minificação de HTML.

• Minificação de CSS embutido – Recomendamos habilitar esta opção para remover espaços em branco no CSS embutido.
• Minificação de JS embutido – Recomendamos habilitar esta opção para remover espaços em branco em JavaScript embutido. Em alguns casos, a minificação de JS pode resultar em um erro de código. Se a ativação desta opção interromper a funcionalidade do seu site, desative-a.
• Não minifique feeds – Recomendamos manter esta opção desativada. Os feeds são usados ​​apenas por leitores de RSS e outros serviços semelhantes, portanto, não é necessário reduzir os feeds.
• Remoção de quebra de linha – essa opção está desabilitada por padrão e não recomendamos habilitá-la para garantir que seu site seja renderizado corretamente.

JS

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

• Operações em Áreas – Esta opção permite selecionar o “tipo de incorporação” para JavaScript minificado. Para arquivos JS antes e depois , você pode escolher entre "bloquear", "não bloquear", "não bloquear usando assíncrono" e "não bloquear usando adiar". Embora os métodos de carregamento sem bloqueio geralmente resultem em melhor desempenho, eles nem sempre são 100% compatíveis com todo o código 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 bloqueante.
• Minify ou Combine Only – Você pode escolher entre dois modos de otimização para JavaScript. Quando “Minify” é selecionado, seus arquivos JS serão combinados e reduzidos. Se você selecionar “Somente Combinar”, o arquivo JS combinado resultante não será reduzido. 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 o seu servidor suportar HTTP/2 Server Push, habilitar esta opção pode ajudar a reduzir o tempo de carregamento da página. O HTTP/2 Server Push envia arquivos aos visitantes antes de serem solicitados. Recomendamos fazer testes adequados antes de habilitar essa opção em um ambiente de produção, pois o Server Push geralmente é mal utilizado. O Server Push não é ideal para arquivos JavaScript maiores, e você deve garantir que os benefícios superem o carregamento de arquivos JS diretamente do cache do navegador de um visitante.

CSS

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

• Combine Only – Ao contrário dos arquivos JavaScript, o CSS normalmente não sofre de problemas relacionados à minificação. Assim, não recomendamos habilitar “Somente Combinar”.
• Remoção de comentários preservados – essa configuração remove comentários de arquivos CSS. Recomendamos habilitar essa opção para reduzir o tamanho do arquivo o máximo possível.
• Remoção de quebra de linha – Esta configuração remove quebras de linha de arquivos CSS. Recomendamos habilitar essa opção também. Se você notar algum 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 a cada – W3TC permite especificar a quantidade de tempo entre as atualizações de arquivos CSS e JS. Com a configuração padrão de 86.400 segundos, seus ativos serão baixados e reduzidos a cada 24 horas. Se seu site não muda com frequência, fique à vontade para definir um período de tempo maior.
• Intervalo de coleta de lixo – Essa configuração de período especifica com que frequência os dados de cache expirados são excluídos. A configuração padrão é 24 horas. Se o seu site estiver com pouco espaço de armazenamento, recomendamos diminuir o “Intervalo de coleta de lixo”.

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

W3 Total Cache Settings — Object Cache

Em seguida na lista estão as configurações de “Cache de Objetos” do W3TC. Para a maioria dos sites, as configurações padrão funcionarão bem, mas vamos analisá-las de qualquer maneira.

• Tempo de vida padrão dos objetos de cache – o tempo de expiração para itens de cache inalterados. Um período de tempo mais longo resulta em um cache de objeto maior. Se você estiver preocupado com a capacidade de armazenamento do seu servidor, recomendamos manter o valor padrão ou reduzi-lo.
• Intervalo de coleta de lixo – essa configuração especifica com que frequência os dados de cache expirados são descartados. O valor padrão de 3.600 segundos (1 hora) deve ser adequado para a maioria dos sites.
• Grupos Globais – Esta configuração permite configurar grupos de cache compartilhados entre sites em uma única rede multisite. Recomendamos deixar essa configuração em seu estado padrão, a menos que você tenha um motivo específico para alterá-la.
• Grupos não persistentes – essa configuração permite selecionar quais grupos de objetos nunca serão armazenados em cache. Novamente, recomendamos manter a configuração padrão.
• Habilitar cache para solicitações wp-admin – Esta opção está 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 wp-admin.

W3 Total Cache Settings — Cache do navegador

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

Nas configurações de “Cache do navegador”, as configurações padrão para as seções “Geral”, “CSS e JS” e “HTML e XML” e “Mídia e outros arquivos” são adequadas para a maioria dos sites WordPress. Como há muitas configurações nesta página, recomendamos consultar um desenvolvedor antes de fazer qualquer alteração no comportamento do cache do navegador. Com isso dito, abaixo estão algumas configurações importantes para prestar atenção em relação ao cache do navegador.

• Expires Headers Lifetime – Configurar um longo “expires headers lifetime” é importante para um 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 esse valor para 31536000 (1 ano).
• Política de controle de cache – Para garantir que seus ativos estáticos sejam armazenados em cache pelos navegadores, certifique-se de que a “política de controle de cache” esteja definida como “public, max_age=EXPIRES SECONDS”.
• Ativar compactação HTTP (gzip) – A compactação GZIP reduz drasticamente o tamanho do arquivo de páginas e recursos HTML antes de serem enviados aos visitantes, portanto, certifique-se de ativar essa opção se a configuração do servidor do seu host suportar GZIP. Se o seu site estiver hospedado na Kinsta, não há necessidade de habilitar a compactação GZIP no W3TC porque ela já está habilitada como parte de nossa configuração padrão.
• Remover strings de consulta de recursos estáticos – Uma string de consulta é uma string adicional que é adicionada ao final de um caminho de URL para especificar parâmetros de solicitação ou forçar um servidor web a entregar um novo ativo. As strings de consulta começam com um ? , e a maioria dos servidores da Web é configurada para ignorar o cache para solicitações com strings de consulta. A remoção de strings de consulta de 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 a remoção de strings de consulta de recursos estáticos no W3 Total Cache porque eles ajudam a garantir que a versão mais recente dos arquivos CSS e JS seja entregue aos visitantes.

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

W3 Total Cache Settings — Grupos de User Agents

O recurso “User Agent Groups” do W3 Total Cache é muito poderoso se você precisar redirecionar o tráfego com base no 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 de um telefone celular. Da mesma forma, você pode redirecionar os usuários para um site completamente diferente se seu site móvel estiver em um subdomínio exclusivo.

Na era do web design responsivo, não vemos muitos casos de uso para esse recurso específico. Atualmente, a prática recomendada é tornar seu site responsivo desde o início, em vez de depender de vários temas ou de um subdomínio somente para dispositivos móveis.

W3 Total Cache Settings — Grupos de referência

Um referenciador HTTP é 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 da Pesquisa Google, o referenciador HTTP será google.com .

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

Semelhante aos “Grupos de agentes do usuário” mencionados acima, você também pode redirecionar solicitações para um domínio diferente com o recurso “Grupos de referência”. A maioria dos sites WordPress não precisa configurar grupos de referência, portanto, não recomendamos configurar nenhum.

W3 Total Cache Settings — Grupos de Cookies

O último grupo de cache que o W3 Total Cache suporta é “Cookie Groups”. Esse recurso permite criar buckets e comportamentos de cache exclusivos com base nos cookies de uma solicitação. Semelhante aos “Grupos de agentes do usuário” e “Grupos de referência”, a maioria dos sites não precisará definir uma configuração de cache personalizada baseada em cookies. Se o seu site requer cache baseado em cookies, recomendamos trabalhar com um desenvolvedor para configurá-lo corretamente.

W3 Total Cache Settings — CDN

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

• Host Attachments – Habilite isso para servir ativos em sua biblioteca de mídia WordPress a partir de seu CDN.
• Host wp-includes/ Files – Habilite isso para servir arquivos na pasta wp-includes do seu CDN.
• Host Theme Files – Habilite isso para servir seus arquivos de tema do seu CDN.
• Hospedar arquivos CSS e JS minificados – Habilite isso para servir os arquivos CSS e JS minificados do W3TC a partir do seu CDN.
• Hospedar arquivos personalizados – Se você tiver arquivos que não estão na sua biblioteca de mídia ou na pasta do tema, você pode adicionar os caminhos dos arquivos no W3TC para servi-los a partir do seu CDN.
• Adicionar cabeçalho canônico – Uma rel=”canonical” ajuda os mecanismos de pesquisa a identificar a fonte ou URL original. Como as CDNs normalmente usam um domínio diferente, adicionar uma tag canônica notifica os mecanismos de pesquisa sobre a localização do ativo original. Com isso dito, não há problema em manter essa configuração desativada porque os mecanismos de pesquisa modernos são inteligentes o suficiente para identificar CDNs sem afetar as classificações de SEO do seu site.

Avançado

• Somente limpar CDN manualmente – Recomendamos manter esta opção desabilitada para permitir que o W3TC lide com as limpezas de cache automaticamente.
• Desabilitar CDN em Páginas SSL – Mantenha esta configuração desabilitada. Se você estiver usando um CDN, é melhor tê-lo ativo nas páginas HTTP e HTTPS.
• Use links CDN para biblioteca de mídia em páginas de administração – não recomendamos habilitar essa opção porque ela reescreverá URLs em sua biblioteca de mídia.
• Adicionar cabeçalho CORS – Mantenha essa configuração habilitada para permitir que seus ativos CDN sejam exibidos em outros domínios.
• Desabilitar CDN para as seguintes funções – Esta opção permite que você desabilite a CDN para certas funções de usuário do WordPress. Na maioria dos casos, é melhor manter essa opção desativada.
• wp-includes Tipos de arquivo para upload – Este campo especifica os formatos de arquivo no wp-includes que serão servidos a partir de sua CDN. A lista padrão de formatos de arquivo deve ser adequada 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 de tema para upload – Este campo especifica os formatos de arquivo em sua pasta de tema do WordPress que serão servidos a partir de seu CDN. A lista padrão contém todos os formatos populares de ativos, imagens e fontes. Sinta-se à vontade para adicionar formatos adicionais, se necessário.
• Lista de arquivos personalizados – Se você ativou “Host Custom Files”, você pode adicionar uma lista de arquivos neste campo para servir de seu CDN.
• Agentes do usuário rejeitados – Este campo permite que você especifique os agentes do usuário que não receberão ativos da sua CDN. Recomendamos manter este campo vazio para garantir que seu CDN esteja sendo utilizado corretamente.
• Arquivos Rejeitados – Este campo permite especificar arquivos que não devem ser servidos a partir de sua CDN. Se um serviço que você estiver usando exigir que os ativos sejam servidos a partir de seu domínio raiz, você poderá adicionar o caminho do arquivo ao campo “Arquivos Rejeitados”.

Configurações de cache total do W3 — Experiência do usuário

Em seguida, vamos personalizar as configurações de “Experiência do usuário”, ou carregamento lento, no W3 Total Cache.

• Processar tags de imagem HTML – Habilite isso para garantir que as imagens sejam carregadas lentamente.
• Processar imagens de fundo – Se você estiver usando `background` para exibir uma imagem em CSS, habilitar esta opção permitirá que essas imagens sejam carregadas lentamente.
• Excluir palavras – Neste campo, você pode especificar o texto para ignorar o carregamento lento. Por exemplo, se você adicionar no-lazy-load a este campo, uma imagem exibida com <img src="image.jpg"> não será carregada lentamente.
• Método de incorporação de script – Esta configuração permite que você personalize o método de carregamento para o script de carregamento lento. O método async padrão é a melhor opção para a maioria dos sites. Se seu site consiste apenas em 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

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

• AMP
• Cloudflare
• Google Feedburner
• Fragmento de Cache
• Estrutura de Gênesis
• Nova relíquia
• Enxamear
• Yoast SEO
• WPML

Se você estiver usando algum desses serviços em seu site, recomendamos configurar a extensão relevante para garantir a compatibilidade adequada com o W3 Total Cache. Nesta seção, veremos a extensão Cloudflare para W3 Total Cache.

Como configurar o W3 Total Cache com a extensão Cloudflare

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

No painel da Cloudflare, clique na guia “Visão geral”. Em seguida, role para baixo e clique em Obter seu token de API na barra lateral direita.

Scroll down, and click View next to “Global API Key” to get your Cloudflare API key. Be careful not to share this API key anywhere outside W3 Total Cache because it can be used to control your Cloudflare account.

Next, activate the Cloudflare extension in W3 Total Cache's “Extensions” page and click “Settings”. In the “Credentials” section, click on the Authorize button.

In the subsequent popup, input your Cloudflare account email and API key. If you receive an error message, double-check to make sure your email address and API key are correct. After the credentials are authorized, you should see additional Cloudflare settings on the page.

Let's go over the Cloudflare settings in W3 Total Cache.

• Widget Statistics Interval – This specifies the time period covered for W3TC's Cloudflare widget. The default setting is 30 minutes. If you'd like to see a longer time period, feel free to increase it.
• Cache Time – This specifies the amount of time that widget data from Cloudflare is cached. If you don't plan on using the widget much, we recommend increasing this number to reduce the number of requests to Cloudflare from your site.
• Page Caching – If you've configured Cloudflare to cache HTML pages for your WordPress site, enable this option to automatically clear the Cloudflare cache after post modifications and updates.

Cloudflare Caching

This section lets you customize Cloudflare's caching settings.

• Development Mode – Keep this option disabled unless you need to put Cloudflare in Development Mode. When Cloudflare is in Development Mode, edge caching, minification, and image optimization is disabled for three hours. This allows you to see updates to CSS and JS files immediately and is useful for troubleshooting.
• Cache Level – For most sites, we recommend using the “Standard” cache level, which serves a different resource each time the query string changes. If you're 100% sure that your WordPress site does not make use of query strings to serve dynamic content, you can also use the “Ignore Query String” setting as well.
• Browser Cache TTL – We recommend setting Cloudflare's browser cache TTL to 31536000 seconds, which is equal to 1 year.
• Challenge TTL – Cloudflare offers a variety of security-related services, and visitor challenges is one of them. If Cloudflare detects a malicious user or strange behavior, it will serve a challenge message in the form of a Captcha. The “Challenge TTL” setting specifies how long a user will have access to your site after completing a challenge. With the default setting of 3600 seconds, a visitor who was subject to a challenge will be able to use your site for 1 hour before another challenge.
• Edge Cache TTL – This setting controls how long assets will be cached at Cloudflare's edge servers. We recommend setting this to the maximum value of 31536000 seconds, or 1 year.

Cloudflare Content Processing

Let's dive into the Cloudflare content processing settings in W3 Total Cache.

• Rocket Loader – Cloudflare's Rocket Loader speeds up JavaScript loading for your WordPress site. We recommend enabling Rocket Loader if your site has a lot of JS.
• Minify JS/CSS/HTML – If you've already enabled minification for HTML, CSS, and JavaScript in W3 Total Cache, feel free to keep these options in the Cloudflare extension settings disabled, as there is no need to minify assets that have already been minified.
• Server Side Exclude (SSE) – This option allows you to hide sensitive information from suspicious visitors (deemed by Cloudflare). Server-side excludes are useful for hiding information like email address, phone numbers, and other personal information on your site. To use SSE, enable it and wrap sensitive information in <!--sse--><!--/sse--> tags in your HTML code or PHP theme template.
• Email Obfuscation – When this option is enabled, Cloudflare will automatically obfuscate email addresses on your WordPress site with JavaScript. While obfuscation is not going to get rid of email spam completely, we recommend enabling this option because it does deter basic bots from scraping email addresses from your site.

Cloudflare Image Processing

Let's go over Cloudflare's image processing settings.

• Hotlink Protection – Enabling hotlink protection will prevent other sites from embedding your images. If you're running into bandwidth limits due to unauthorized external embeds, enabling “Hotlink Protection” can help you reduce bandwidth usage.
• Mirage (Pro Only) – Mirage optimizes image delivery to low-bandwidth devices and networks. This feature is only available on Cloudflare Pro plan and above.
• Polish (Pro Only) – Polish optimizes your site's images, and can be configured to serve WEBP images to supported browsers. This feature is only available on Cloudflare Pro plan and above.

Cloudflare Protection

Cloudflare's primary feature is a sophisticated firewall that can help protect you against DDoS attacks and malicious actors. Let's go over Cloudflare's security settings.

• Security Level – This setting controls the sensitivity of Cloudflare's firewall and security rules. We recommend setting the “Security Level” to “Medium” for most sites.
• Browser Integrity Check – This feature looks out for bad behavior and suspicious user agents. If it detects a potentially malicious user or spammer, Cloudflare will automatically serve a challenge. We recommend enabling this feature.
• Always Online – This option will serve static HTML pages of your site if your origin goes down. We recommend enabling it if you've configured Cloudflare to cache HTML.
• Web Application Firewall – Cloudflare's WAF, or web application firewall, will scan incoming traffic and filter out “illegitimate traffic” from reaching your site. We recommend enabling this feature.
• Advanced DDoS Protection – This feature is enabled by default, and cannot be disabled as long as Cloudflare's proxy is active. DDoS protection helps shield your site from “distributed denial of service” attacks.
• Max Upload – This sets the maximum allowed file size for uploads to your site. You'll want to make sure that this setting is either equal to or greater than your upload file size setting in WordPress.

Cloudflare SSL

Lastly, you'll want to make sure your Cloudflare SSL settings are configured correctly. Let's go over the right configuration in this section.

• SSL – If your site is hosted on Kinsta, we recommend using either the “Full” or “Full (Strict)” SSL option. The “Flexible” option is not compatible with our infrastructure. “Full Strict” requires an SSL from a valid certificate authority, while the “Full” option also supports self-signed SSLs. The “Flexible” option does not require an SSL certificate on the origin server – we don't recommend this option because it is the most insecure.
• TLS 1.2 Only – TLS, or Transport Layer Security, is a secure protocol for transferring data over a network. Some PCI compliance standards require dropping support for TLS 1.1 and below. If that is a requirement for your site, you can enable the “TLS 1.2 Only” setting in Cloudflare to set the minimum TLS version to 1.2.

Leitura sugerida: Como configurar o Cloudflare APO para WordPress.

Configurações do W3 Total Cache WooCommerce

WooCommerce é a plataforma de comércio eletrônico mais popular para sites WordPress. Se você estiver usando o W3 Total Cache com sua loja com WooCommerce, verifique se sua configuração está correta para evitar armazenar em cache os detalhes do cliente.

Ignorar cookies WooCommerce

Para ignorar o cache de páginas que possuem cookies específicos do WooCommerce, vá para as configurações de “Cache de Página” do W3TC, role para baixo até “Cookies Rejeitados” e adicione os quatro itens abaixo.

• woocommerce_items_in_cart
• woocommerce_cart_hash
• wp_woocommerce_session_
• wordpress_logged_in

Para estar seguro, também recomendamos ignorar URLs específicos do WooCommerce, como a página do carrinho, a página de checkout e a página da conta. Para evitar o armazenamento em cache dessas páginas, vá para as configurações de “Cache de Página” do W3TC e adicione os URLs à seção “Nunca armazene em cache as seguintes páginas”.

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

Em alguns casos, pode ser necessário recomeçar com a configuração do W3TC. Veja como reverter o W3 Total Cache para as configurações padrão. Vá para o menu “Configurações gerais” do W3TC, role para baixo até a seção “Configurações de importação/exportação” e clique em Restaurar configurações padrão .

Resumo

Como você pode ver, o plugin W3 Total Cache está repleto de recursos e configurações. Do cache de página à minificação de ativos e à integração da Cloudflare, o W3TC tem tudo o que você precisa para aumentar o desempenho do seu site WordPress!

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