Acelerando o WooCommerce – O Guia Completo

Para acelerar o WooCommerce, primeiro você precisa entender os componentes do WooCommerce e o que exatamente leva tempo no WooCommerce. Neste artigo, vou guiá-lo por tudo o que você precisa saber para iniciar sua jornada de otimização de desempenho para uma loja WooCommerce mais rápida.

Primeiro, explicarei alguns conceitos básicos que fazem parte da sua loja WooCommerce e, em seguida, explicarei como qualquer página da Web (WooCommerce) está sendo processada ao solicitar que ela seja exibida em seu navegador. Clique aqui se você quiser pular direto e pular o sumário (TOC), pois apenas o sumário já é uma leitura e tanto!

Conceitos Básicos

Para acelerar o WooCommerce, você deve primeiro entender as camadas, os componentes onde você pode fazer a otimização da velocidade. Como a maioria dos sites, e especialmente os sites baseados em WordPress, as camadas com potencial de otimização são:

O código do lado do servidor – PHP

O código do lado do servidor, que no caso do WP e Woo, é principalmente PHP. Com a adoção do Block Editor (Gutenberg), parte desse código também é JavaScript, mas para a maioria das lojas isso ainda não é amplamente utilizado.

O armazenamento de dados do lado do servidor – Banco de dados

O banco de dados é onde todos os seus dados são realmente armazenados. São dados sobre seus produtos, qual imagem pertence a quais produtos, seus pedidos e assim por diante. O código do lado do servidor (PHP) precisará se conectar ao seu banco de dados (onde estão seus dados) para extrair e inserir novos dados o tempo todo.

A marcação de frontend – HTML e CSS

A marcação, o código de front-end ou como você quiser chamá-lo, são os componentes que são interpretados pelo navegador e podem ser renderizados no que seus usuários veem.

Os scripts frontend – JavaScript

O código que inclui lógica e condições geralmente vem na forma de JavaScript e pode ser colocado no colchete “scripts de front-end”. Este é um código que pode ser executado no navegador e ser acionado, por exemplo, pela interação do usuário com seu site.

Os ativos de front-end – Imagens e fontes

Para simplificar, estou chamando os ativos de front-end do último colchete, que incluem ativos estáticos, como imagens, fontes, PDFs e outros tipos de ativos que não mudam. No entanto, eles precisam ser entregues ao cliente para que o site funcione corretamente, tenha uma boa aparência ou para que você alcance seu objetivo.

Então agora conhecemos todos os componentes de um site. O que todas essas camadas têm em comum é que levam tempo para gerar ou executar no servidor, entregar e renderizar no navegador. Tudo leva tempo, e o caminho para uma loja WooCommerce rápida é reduzir a quantidade de tempo que cada um desses componentes gasta.

Então a pergunta é, como você faz isso?

Antes de podermos entrar no como, precisamos entender completamente outro conceito básico. É assim que a web funciona. Especificamente como uma página da web é exibida no navegador. Para simplificar, podemos dividir o processo em cinco etapas:

1. Enviando uma solicitação
   Isso é feito pelo cliente, por exemplo, um navegador, e é acionado por um usuário clicando em um link ou digitando um domínio/URL na barra de endereços do navegador.
   
2. Entregando um pedido
   Uma vez que o navegador enviou uma solicitação do navegador, essa solicitação deve encontrar seu caminho pela Internet. Pode ser uma viagem curta ou longa. E, assim como nas estradas, o caminho da rede de A a B pode sofrer desvios devido à construção ou manutenção.
   
   Possíveis otimizações:
   Encurte o caminho de viagem para o servidor que está processando a solicitação e, posteriormente, entregará a resposta.
   
3. Gerando uma resposta
   Quando a solicitação for recebida pelo servidor web, o servidor web executará o código PHP necessário para lidar com essa solicitação. O que significa que o PHP executará as consultas necessárias para obter as informações do banco de dados. O PHP irá então gerar a resposta, que resulta no HTML para a página solicitada. O tempo necessário para gerar uma resposta, mais o tempo do navegador para o servidor e vice-versa, é geralmente conhecido como Time-To-First-Byte (TTFB).
   
   O que é um TTFB rápido?
   < 250ms bom
   < 500ms OK
   < 1000ms não é bom
   > 1000ms crítico
   
   Possíveis otimizações:
   Conexão de servidor mais rápida (handshake SSL etc)
   Servidor mais rápido
   Código PHP mais rápido
   Execução de código PHP mais rápida
   Menos código PHP
   Banco de dados mais rápido
   Menos e/ou consultas de banco de dados mais rápidas
   
4. Entregando a resposta
   Assim que o servidor web terminar de gerar uma resposta, ele enviará a resposta de volta ao navegador.
   
   Possíveis otimizações:
   Caminho de viagem mais curto de volta ao navegador
   Tamanho de transferência reduzido
   Menos elementos transferidos (cache)
   
5. Processando a resposta
   
   Assim que o navegador receber uma resposta (ou partes dela), ele começará a processá-la. Isso é chamado de renderização. Isso inclui analisar o código (HTML, CSS, JavaScript, imagens) e executá-lo, o que em HTML significa renderizá-lo.
   
   Possíveis otimizações:
   Menos CSS
   Menos JavaScript
   Menos e menores imagens

Equívocos comuns

Antes de prosseguirmos, precisamos esclarecer o ar e explicar alguns equívocos comuns que você pode ter visto compartilhados na Internet em relação ao WooCommerce e ao desempenho.

Errado: o limite de memória afeta a velocidade e quanto mais memória você tiver, mais rápido o site será

Por alguma razão, muitas empresas de hospedagem estão dizendo que a quantidade de memória que o PHP pode usar afeta a velocidade do site. A quantidade de memória disponível por processo PHP não afeta a velocidade . O limite de memória existe para garantir que alguns processos PHP não consumam toda a quantidade de RAM disponível. Ou seja, o limite de memória do PHP afeta apenas a escalabilidade, não a velocidade.

Errado: fragmentos de carrinho Ajax diminui a velocidade da página

Outra das principais dicas que vejo compartilhada pela maioria das empresas de hospedagem, e “experts em velocidade”, é desabilitar os fragmentos de carrinho no WooCommerce. Fragmentos de carrinho é um mecanismo que usa Ajax para atualizar o carrinho em seu site para que você não precise de uma atualização de página para mostrar novos conteúdos e afins. Na maioria dos casos, e em boas configurações de hospedagem, essa dica é um mau conselho. Em alguns casos, no entanto, esta dica está correta. Os fragmentos de carrinho do WooCommerce podem retardar o carregamento completo da página, mas somente se:

1. Seu site não está executando nenhum cache de página/HTML
2. Você tem uma configuração de cache que não é otimizada para WooCommerce
3. Seu site está sendo executado em um servidor lento

Se você não usar os fragmentos de carrinho e usar o cache HTML, não poderá entregar respostas em cache se alguém tiver algo no carrinho. Os fragmentos de carrinho são muito mais fáceis e rápidos de gerar para o servidor e muito mais rápidos de entregar do que a página inteira. Se sua página tiver um carrinho no cabeçalho, por exemplo, é muito melhor e mais rápido atualizar o carrinho usando Ajax (usando fragmentos de carrinho) e entregar o HTML do cache.

Dica
Deixe os Fragmentos de Carrinho ativados e configure seu cache corretamente para maximizar sua eficiência de cache. Como alternativa, acelere seu site com Domínios Acelerados.

Errado: as revisões de posts tornam o WordPress / WooCommerce mais lento

Muitas das dicas que você encontra online são baseadas em otimizações que podem funcionar em alternativas de hospedagem WooCommerce não escaláveis ​​ou mal configuradas. Desativar as revisões de posts é exatamente uma dica nessa categoria. Um banco de dados bem configurado não diminui devido ao tamanho dos dados, e a consulta de uma postagem não diminui devido a revisões de postagem. De jeito nenhum. Os bancos de dados são construídos, em primeiro lugar, para fornecer tempo de acesso linear e previsível a grandes quantidades de informações – em grande parte independente do tamanho dos dados.

O que são revisões de posts?

Quando você atualiza uma postagem no WordPress, o WP armazena automaticamente a versão antiga no banco de dados. Isso é chamado de revisão. Isso é armazenado para que você possa “voltar no tempo” caso precise reverter as alterações ou quando simplesmente quiser ver o que mudou entre as versões. As revisões também são usadas para salvar automaticamente uma alteração na qual você está trabalhando, mas ainda não salvou manualmente. Essas revisões são armazenadas na mesma tabela de banco de dados que todas as outras postagens, e muitos acreditam que isso diminui a velocidade do WP. Em um ambiente de hospedagem bem configurado, isso não é verdade.

Dica
Deixe as revisões de postagem habilitadas, mas reduza a quantidade de revisões a serem armazenadas para um valor sensato. A redução não tem nada a ver com desempenho, mas é sempre bom reduzir mais o desperdício digital e armazenar apenas coisas que possivelmente serão necessárias.

Escolhas e formas de trabalho fundamentalmente importantes

Ter um site WooCommerce rápido e de alto desempenho começa com a compreensão dos componentes que entram no mix, conforme explicado acima. Em seguida, explico as escolhas importantes que são fundamentais para entender como trabalhar para realmente criar um site WooCommerce rápido.

Escolha um tema leve e performático

Primeiro, o que é um tema? Se fôssemos colocar um tema nos componentes acima, pode ser todos os itens acima. O problema é que, com o WordPress, o próprio WordPress Core, temas e plugins podem incluir código do lado do servidor, consultas ao banco de dados, código de front-end, scripts de front-end e ativos de front-end. E é por isso que o trabalho de escolher o tema certo (e plugin) é tão importante. Porque se você não fizer isso, você vai acabar com muita bagunça e coisas que você não precisa ou quer. Todas essas “coisas” desnecessárias são chamadas de inchaço.

A maioria das lojas WooCommerce usa temas pré-construídos com opções de personalização e opções de modificação, e isso significa que você obtém muito código “fora da caixa”. Isso é ótimo e torna muito fácil colocar o site em funcionamento rapidamente. No entanto, a desvantagem é que a maioria dos temas é criada para atender a muitas necessidades e propósitos. E, ao fazer isso, inclua muitos recursos que você usa e não usa. Os recursos em um tema são construídos principalmente pelo código PHP do lado do servidor. Todo o código que precisa ser executado, seja no servidor ou no navegador – como estabelecemos antes – leva um tempo precioso.

Alguns códigos levam um pouco de tempo, e você terá dificuldade em medir o tempo que realmente leva para ser executado. Outro código precisa de muito mais tempo para ser executado. Independentemente de quanto tempo um recurso ou função gaste, tudo se soma .

Portanto, o primeiro passo para obter uma loja WooCommerce mais rápida é escolher um tema rápido e leve. Escolha um tema que tenha os recursos e o design de que você precisa e não exagere na busca por opções em um tema. Mais opções equivalem a mais código que precisa ser executado e a execução do código leva tempo.

Como testar se um tema é leve e performático?

Geralmente é impossível verificar o código de um tema se você comprar um tema, por exemplo, ThemeForest ou MyThemeShop. Mas as lojas temáticas geralmente têm demos que você pode testar no frontend. E há maneiras de testar o desempenho das demos, mas é importante que você faça os testes corretamente e procure as coisas certas. Portanto, você deve testar o site de demonstração da mesma forma que deve testar seu próprio site.

Como testar o desempenho do seu site ou uma demonstração do tema

Existem diferentes maneiras de testar o desempenho, mas as dicas a seguir são aquelas que você deve sempre ter em mente e usar.

Não teste apenas uma página

Um erro que muitos cometem para determinar se o site é rápido ou não é testar apenas a velocidade da primeira página. Este é um erro que geralmente leva a testar a velocidade do cache, e não a velocidade do próprio WooCommerce. É apenas testando um grande volume de páginas, ou mesmo a loja completa, que você terá uma visão completa da velocidade da sua loja. Isso significa que você precisa copiar e colar cada URL do seu site em ferramentas de teste de velocidade como PageSpeed ​​Insights, Pingdom ou GTMetrix? Por sorte, não. Você pode testar facilmente um grande volume de páginas em sua loja WooCommerce usando ferramentas que rastreiam sua loja WooCommerce de maneira semelhante ao que os mecanismos de pesquisa fazem ou usam ferramentas que usam seu mapa do site como entrada.

Meu favorito pessoal para isso é o Sitebulb, pois o Sitebulb é uma ferramenta poderosa para SEO e testes de desempenho. Alguns dos meus colegas aqui da Servebolt têm o Screaming Frog SEO Spider como seu favorito, e eles fazem muitas das mesmas coisas. No entanto, a ferramenta mais fácil que conheço, que deve ser sua primeira ferramenta para começar, é batchspeed.com.

Se você ainda não está pronto para o teste completo do site, você deve, no mínimo, testar todos os diferentes tipos de página que você tem em seu site. Isso inclui vários tipos de produtos, páginas de categorias e assim por diante. Cada um deles executará diferentes partes do código do seu site – o que significa que eles podem ter desempenho variável.

Teste o desempenho sem cache

O cache é uma parte complicada de uma pilha de hospedagem com bom desempenho e é especialmente importante para as lojas WooCommerce. Mas o cache também pode induzi-lo a acreditar que sua loja é mais rápida do que seus clientes realmente experimentam. Como? Primeiro, vamos ver como (a) o cache funciona.

O cache usa a primeira visualização de página para armazenar uma versão temporária da página e, a partir da segunda visualização de página, etc., e até que o cache expire, o servidor pode entregar uma versão da página já gerada e armazenada temporariamente. Existem muitas condições em qualquer loja WooCommerce em que um cache configurado corretamente será ignorado totalmente, como se o cliente estivesse logado.

Portanto, em qualquer loja WooCommerce existem muitas páginas que você não pode , em nenhum cenário, entregar do cache. São páginas como o carrinho e a página de checkout, pois são dinâmicas e geradas especificamente para esse visitante exato, sua localização, conteúdo do carrinho e assim por diante. Exemplos de páginas que você não pode armazenar em cache são:

• Páginas conectadas (ou seja, /my-account/ )
• Página do carrinho
• Página de checkout
• Páginas de favoritos

Como o cache só funciona para páginas e ativos que podem ser entregues inalterados a várias solicitações (visitantes), esses tipos de páginas não terão o desempenho adicional que um mecanismo de cache pode oferecer. No entanto, essas páginas são uma parte fundamental da experiência do usuário para seus clientes. E seus clientes não podem converter de um visitante para um cliente pagante sem visitar seu carrinho ou seu checkout.

Portanto, agora sabemos que o melhor cenário é que o visitante está solicitando uma página que está em cache e que não há motivo para que o cache seja ignorado. E o pior cenário é que seus visitantes não podem ser atendidos com uma versão em cache da página que estão solicitando.

Se você testar apenas o cenário de melhor caso, também poderá otimizar apenas o cenário de melhor caso. Enquanto o pior cenário é deixado intocado e é experimentado por muitos de seus visitantes, todos os dias, em momentos críticos durante a jornada do cliente.

É por isso que você, para poder acelerar o WooCommerce, deve testar suas páginas sem atingir o cache. Isso pode parecer complicado, mas na verdade é bem fácil de fazer. Para a maioria das configurações de cache, tudo o que você precisa fazer é adicionar uma string de consulta ao URL que está testando. A única coisa a lembrar é que essa string de consulta deve ser 100% exclusiva para cada solicitação que você enviar.

Essa técnica pode ser adicionada a qualquer teste de página única, incluindo PageSpeed ​​Insights, Web Core Vitals, teste Lighthouse no Chrome, Pingdom, GT Metrix e WebPageTest.org. Um exemplo dessa string de consulta pode ser https://example.com/?test=1 , onde você altera o número toda vez que faz um novo teste.

Do conhecimento à ação

OK, agora cobrimos as camadas, os componentes onde você pode fazer a otimização de velocidade, falamos sobre como a web funciona e discutimos alguns dos equívocos comuns sobre como acelerar o WooCommerce. Por último, mas não menos importante, expliquei como você deve realmente testar o desempenho para saber como medir o impacto de qualquer uma das recomendações e dicas que descreverei abaixo.

Agora, vamos tornar isso acionável!

Execute sua loja WooCommerce em hospedagem de alto desempenho

Qualquer página da web consiste em “tudo o que acontece no servidor” e “tudo o que acontece no navegador”. Ao executar uma loja WooCommerce, a velocidade da sua loja depende muito da velocidade de “tudo o que acontece no servidor”. Todo o trabalho pesado também começa com o servidor, e se você conseguir um servidor que termine de gerar sua página de produto 1 segundo mais rápido, todo o resto também terminará 1 segundo mais rápido. É por isso que executar o WooCommerce em uma hospedagem de alto desempenho é provavelmente a dica mais importante que posso dar se você quiser acelerar sua loja WooCommerce.

O que procurar nas empresas de hospedagem WooCommerce?

Aqui posso lhe dizer duas coisas;

1. Você já está no lugar certo, pois o Servebolt.com provou ser o mais rápido
2. Verifique wphostingbenchmark.com e seu benchmark WooCommerce e escolha aquele com o desempenho de origem mais rápido

Essas duas dicas levarão você ao mesmo lugar: você se inscrevendo para uma avaliação gratuita da nossa hospedagem WooCommerce. Mas se você decidir fazer a comparação você mesmo, talvez queira saber como comparar as empresas de hospedagem para sua loja WooCommerce:

1. Configure um teste nas empresas de hospedagem que você deseja comparar
2. Faça uma cópia do seu site e configure-a em cada uma das empresas de hospedagem
3. Execute os mesmos testes mencionados acima

A execução dos mesmos testes e a execução de testes que ignoram o cache garantirão que você veja o verdadeiro desempenho da empresa de hospedagem, e não apenas o desempenho que eles podem fornecer quando puderem armazenar em cache o conteúdo que está sendo entregue.

Certifique-se de executar o WP-cron corretamente

WP-cron é um sistema, embutido no WordPress, onde plugins, temas ou seu código podem agendar coisas para serem executadas em segundo plano. No contexto do WooCommerce, isso pode ser atualizar feeds de produtos, buscar status de estoque de integrações e muitas pequenas tarefas necessárias para manter sua loja funcionando sem interação direta de você em /wp-admin .

Por padrão, o WP-cron é acionado pelo tráfego para sua instalação do WordPress. Usar o tráfego para acionar o WP-cron é inteligente quando você não tem a capacidade de executar o WP-cron usando um cron do lado do sistema/servidor e WP CLI. Dito isto, todas as boas plataformas de hospedagem WooCommerce e, honestamente, todas as plataformas de hospedagem WordPress que você deve considerar para sua loja Woo, têm a capacidade de executar o WP-cron a partir do cron do sistema. Ao usar o cron do sistema para acionar o WP-cron, você não precisa usar o tráfego do visitante como o acionador e, portanto, também não diminuirá a experiência desses visitantes – ou limitará a escalabilidade do seu site.

Requisitos:

• WP CLI instalado
• Cron personalizado do lado do servidor disponível e configurável

Para WooCommerce, recomendo executar o cron a cada minuto.

Se você estiver usando o crontab, o comando correto para colocar no crontab é algo assim:

1* * * * * nice -n 15 wp cron event run --due-now --path=/PATH/TO/WP/ --quiet

Desative o WP-cron no wp-config

Quando você configurou o WP-cron corretamente usando o cron do sistema, você também precisa garantir que o WP não o execute da maneira padrão. Isso é feito adicionando esta linha ao seu wp-config.php .

define('DISABLE_WP_CRON', true);

Não execute o WP-cron sobre HTTP

Muitos não sabem que você pode executar WP-cron sem enviar uma solicitação HTTP para WP-cron.php e, portanto, configurar serviços externos para acionar WP-cron.php . Isso pode causar, e provavelmente causará, problemas de escalabilidade e maximizar os soquetes HTTP disponíveis em seu servidor web.

Dica de bônus: Executando o Action Scheduler a partir do cron do sistema

Action Scheduler é um sistema para WordPress que se pode dizer complementa e, em alguns casos, pode substituir completamente o WP-cron quando se trata de processamento em segundo plano de tarefas e ações.

Action Scheduler é uma biblioteca para acionar um gancho do WordPress para ser executado em algum momento no futuro (ou o mais rápido possível, no caso de uma ação assíncrona). Cada gancho pode ser agendado com dados exclusivos, para permitir que os retornos de chamada executem operações nesses dados. O gancho também pode ser programado para ser executado em uma ou mais ocasiões.

Pense nisso como uma extensão para do_action() que adiciona a capacidade de atrasar e repetir um gancho.

Acontece que essa funcionalidade também cria uma fila de tarefas robusta para processamento em segundo plano de grandes filas de tarefas no WordPress. Com a adição de log e uma interface de administração, ele também fornece rastreabilidade em suas tarefas processadas em segundo plano.

Por padrão, o Action Scheduler é iniciado por WP-cron e solicitações de administrador. No entanto, você não precisa executar o agendador de ações por meio do sistema WP-cron para que ele funcione sem interação do usuário.

A primeira coisa que você precisa fazer é instalar o plugin Action Scheduler – Disable Default Queue Runner que você pode encontrar no GitHub.

A próxima coisa é usar o WP CLI para acionar o Action Scheduler via cron. O comando é semelhante a como você acionaria o WP-cron via cron e WP CLI.

* * * * * nice -n 15 wp action-scheduler run --path=/PATH/TO/WP/ --quiet

Estamos planejando incluir isso no Servebolt Optimizer no futuro, então fique atento a isso em versões futuras do Servebolt Optimizer

Use plugins específicos, não plugins de canivete suíço

O núcleo WooCommerce em si tem todas as funcionalidades principais de qualquer loja de comércio eletrônico; produtos, um carrinho, um checkout, formas de pagamento, gerenciamento de pedidos e assim por diante. Então, o que você sempre acaba tendo é uma longa lista de plugins para alcançar o que deseja como extras em sua loja. Existem plugins que podem ajudá-lo a filtrar melhor seus produtos, adicionar gateways de pagamento específicos do país ou até mesmo vender mais usando técnicas inteligentes de upsell. Todas as coisas boas.

Mas, toda essa funcionalidade também tem um custo – mais especificamente o custo do tempo.

Esse tempo é adicionado ao processo de geração de uma página no servidor, ao tempo de transferência de dados do servidor para o navegador ou ao processo de renderização de uma página no navegador. Para cada plug-in que você instalar, mesmo que seja muito leve e fino, ele aumentará o peso do seu site e, portanto, diminuirá a velocidade do seu site. A questão é por quanto, e se vale a pena.

Teste cada plugin

Um passo muito importante para otimizar o desempenho da sua loja WooCommerce é mapear cada impacto no desempenho dos plugins. Isso deve ser feito usando os métodos mencionados acima, com foco no site completo. Comece sem plug-ins além do núcleo do WooCommerce ativado e ative todos os plug-ins que você usa um por um. Depois de ativar um plug-in, execute um teste completo de desempenho do site.

Use a metodologia de desempenho em primeiro lugar

Todos os desenvolvimentos futuros, trocas de temas e instalações e atualizações de plugins devem ser testados quanto ao impacto no desempenho. Um plugin pode deixar o site um pouco mais lento, mas tudo se soma. Para garantir que você não tenha um site cada vez mais lento, recomendo usar a metodologia de desempenho em primeiro lugar, que escrevi há alguns anos.

Base de dados

O desempenho da sua loja WooCommerce depende muito da rapidez com que seu banco de dados pode processar dados. Tanto lê quanto grava. Vamos ver com o que estamos trabalhando aqui.

Mecanismos de banco de dados

Se você administra sua loja WooCommerce há muito tempo ou iniciou sua loja WooCommerce em um banco de dados desatualizado, ainda pode estar usando mecanismos de banco de dados desatualizados. Mecanismos de banco de dados antigos e desatualizados, como MyISAM e ARIA, têm algo chamado bloqueio de tabela. Isso significa que a tabela estará indisponível para leitura e gravação na tabela enquanto uma operação que está gravando no banco de dados estiver ocorrendo. Isso pode causar uma grande lentidão na sua loja WooCommerce.

A correção é, no entanto, muito fácil. A maneira mais simples é instalar nosso plugin Servebolt Optimizer e executar o Performance Optimizer. Isso atualizará seu mecanismo de banco de dados em todas as tabelas de banco de dados para o InnoDB moderno. O InnoDB possui bloqueio de nível de linha. Ou seja, ele só precisa bloquear a linha em que está gravando.

Índices

É um equívoco comum que um tamanho de banco de dados crescente também o tornará mais lento. Se o banco de dados puder usar índices de banco de dados enquanto consulta os dados, o tamanho do banco de dados é quase irrelevante. Assim como índices ou sumários em um livro, um índice de banco de dados torna mais fácil encontrar algo em um grande volume de dados estruturados.

Índice de carregamento automático

A tabela de opções no WordPress contém dados necessários para cada visualização de página. O WordPress acelera o carregamento dessas opções no PHP declarando opções como autoload. Quando uma opção é declarada para carregamento automático, o valor da opção será carregado no PHP automaticamente sem a necessidade de consultas extras ao banco de dados. Ao adicionar um índice à coluna de carregamento automático, você também pode acelerar a consulta obtendo todas as opções de carregamento automático.

índice meta_value postmeta

O WooCommerce faz muitas consultas usando a tabela _postmeta e a coluna metavalue . Ao adicionar um índice à coluna de metavalue , você pode acelerar essas consultas em múltiplos!

Você deve usar o Redis?

Primeiro, o que é Redis? Redis é um banco de dados e cache que vive na memória. Em geral, ler e gravar na memória é mais rápido do que ler e gravar no armazenamento baseado em arquivo. O Redis é comumente usado no contexto do WordPress e WooCommerce como um cache para armazenar dados acessados ​​com frequência na memória - para que os dados possam ser buscados mais rapidamente.

Então isso significa que você deve instalar o Redis, certo? Bem, não é tão simples. Como o Redis é usado principalmente para acelerar a busca de dados usados ​​com frequência, o Redis não fornecerá um aumento de desempenho perceptível para todas as páginas, postagens e produtos em sua loja. E também não acelerará muito seu carrinho ou checkout. Isso é verdade principalmente devido a duas coisas:

1. Se você já seguiu minha dica “Execute sua loja em hospedagem WooCommerce de alto desempenho” verá que com um banco de dados bem configurado e otimizado não são as consultas de banco de dados em si que deixam sua loja mais lenta. É PHP e como você usa os dados armazenados no banco de dados.
2. O Redis, assim como o cache, funciona melhor quando há várias solicitações dos mesmos dados, com frequência.

Ainda não vi o Redis acelerar o desempenho do frontend em uma quantidade notável ainda. O que eu vi é o Redis acelerando o back-end, o gerenciamento de pedidos e assim por diante. Mas devido ao risco de adicionar um único componente de ponto de falha à pilha, geralmente recomendo ficar longe, a menos que você saiba o que está fazendo.

Cache

O cache pode dar a impressão de ser o “santo graal” para todos os problemas de desempenho. O armazenamento em cache é uma técnica para armazenar temporariamente a resposta a uma solicitação, para então poder entregar a mesma resposta exata para a mesma solicitação para o mesmo recurso em um momento posterior. Cada resposta contém instruções sobre por quanto tempo uma resposta deve ser armazenada em cache ou se a resposta deve ser armazenada em cache.

O cache funciona de várias maneiras, como o cérebro humano. Depois de saber que 2 + 2 = 4 e 6 * 6 = 36, você não precisa fazer as contas para chegar ao resultado correto. O fato de você saber que 2 + 2 = 4 pode ser chamado de cache. “2 + 2” é a solicitação e 4 é a resposta. Você sabe que a resposta para “6 * 6” = é 36, então você pode responder 36 mais rápido do que alguém que não sabe que 6 * 6 = 36

O armazenamento em cache, na verdade, não foi originalmente inventado para desempenho, mas com a intenção de permitir que os computadores não usem recursos computando a mesma coisa repetidamente. E, ao fazer isso, aumente a escalabilidade desse sistema.

O Servebolt Optimizer e Accelerated Domains são ajustados e otimizados para WooCommerce e implementam cache seguro para sua loja WooCommerce.

Mas, o cache também é um mecanismo muito difícil de entender completamente, e o impacto se você implementar o cache errado é grande. Você precisa garantir que todas as páginas que não devem ser armazenadas em cache, como carrinho, páginas logadas, checkout e assim por diante, não sejam armazenadas em cache, enquanto as páginas que podem ser armazenadas em cache são. Se você armazenar tudo em cache cegamente, acabará vazando informações pessoais, entregar o carrinho do Cliente A ao Cliente B e assim por diante.

O cache na web moderna é implementado em várias camadas, que são igualmente importantes para o desempenho. Algumas dessas camadas de cache são:

Cache de proxy de CDN

Um cache de proxy CDN é um cache que fica entre o servidor de origem e o navegador. Accelerated Domains e Cloudflare é um tipo de CDN proxy, e todas as solicitações e respostas passam primeiro pelos Accelerated Domains antes de atingir o servidor de origem. Os domínios acelerados armazenam a resposta a uma solicitação e podem servir essa resposta novamente mais tarde se a mesma solicitação aparecer. Isso é muito mais rápido do que percorrer todo o caminho da web até a origem.

Ter um bom CDN servindo seus ativos estáticos (imagens, JavaScript, CSS, etc) é o mínimo para qualquer site WooCommerce. Se você deseja maximizar o desempenho, recomendo que você habilite um serviço de aprimoramento de desempenho, como Accelerated Domains, que inclui um mecanismo de cache sofisticado adaptado ao WooCommerce.

Cache do servidor

O cache do servidor é como qualquer outro cache, mas em comparação com um cache de proxy CDN, o cache do servidor está no servidor e você não economiza tempo de viagem entre o navegador e o servidor, como faz com o Accelerated Domains.

O tempo de cache do servidor geralmente é controlado usando o cabeçalho HTTP Cache-Control , como a maioria dos outros caches. E a maioria dos caches do servidor respeita os valores max-age e s-maxage , além de verificar se a resposta pode ser armazenada em um cache public .

Eu recomendo um tempo de cache entre 8 e 10 horas para WooCommerce, mas você também pode testar com tempos de cache mais longos.

Se você não sabe, ou quer controlar isso sozinho, use o plugin Servebolt Optimizer. O Servebolt Optimizer cuida da configuração dos cabeçalhos de cache corretos.

No cache do aplicativo

In WordPress and WooCommerce you can use plugins for caching as well. This is plugins like W3 Total Cache, WP Rocket, and so on. What these plugins do is store a temporary version of a requested page in files on the server. This is a very inefficient way of caching, and should not be used if you have the ability to cache either on the server itself and/or in a service like Accelerated Domains or Cloudflare which distributes the cache globally.

Cache do navegador

Ever experienced that you change something on your site, but you still don't see the change reflected on the frontend? In many scenarios that is because of browser cache. A temporary version of a page or an asset, stored in the browser, on your computer or phone. It's there so that you don't have to download the same page or asset multiple times. The browser cache is different from server and proxy CDN cache in two ways; it's private – meaning you can store private information in the cache, and it is very hard to control.

Browser cache time is controlled using the Cache-Control HTTP header, like most other cache.

I recommend to set the browser cache time to a high value for all your static assets. If you use version strings in your static asset URLs you can safely have a month cache time (2629800 seconds).

For HTML however, you cannot set an as high value for browser cache. I recommend using 10 minutes (600 seconds), as this will help the experience when a user clicks the back button in the browser or similar, but not so long that the user might see old and outdated content.

If you don't know, or want to control this yourself, use the Servebolt Optimizer plugin. Servebolt Optimizer takes care of setting the correct cache headers.

Cache doesn't solve all your performance problems in WooCommerce

Generally you can cache any GET request. GET requests are, like the name suggests, requests to get some resource. Even though GET requests are often safe to cache, like mentioned above, there are a lot of pages you cannot deliver cache:

• Logged-in pages ( /my-account/ , etc)
• Carts
• Checkouts
• Wishlists

In WooCommerce you also need POST requests. POST requests are requests that POST something to the web server. In WooCommerce this can be “POST that I have added item X to cart” or “POST this order”. And POST requests can never be cached.

How cache works in Accelerated Domains

Accelerated Domains has implemented caching according to best practices and internet standards, and tuned it to work perfectly with WooCommerce. In Accelerated Domains we have also solved a few things that are specific to WooCommerce.

Deliver from but not write to cache when something is in cart

Generally, when you have something in the cart, most servers will bypass the cache. Having something in a cart means you have a cookie set, and that cookie makes the request you send to the server unique. Unique requests do not hit cache. In Accelerated Domains however we have implemented a “no-store” technique to be able to serve HTML from cache, even if your visitor has something in the cart. That means a visitor with an item in cart can get HTML delivered from cache faster, but requests that do not hit cache for some reason are never stored in cache. This ensures faster performance during the full customer journey to complete order.

Frontend code

Your frontend code, the code the browser processes, needs to be optimized and cleaned up to ensure it's being processed fast. These are the most important things to work on.

HTML validation

Validating HTML is a forgotten part of performance optimization. While many think it's no longer needed, the fact is that it's just as important as anything else. And the good news is that it is mostly quite easy.

HTML that validates is parsed and rendered faster than HTML that deviates from the standard and contains errors and warnings. While browsers try their best at parsing and rendering incorrect HTML, it takes more time than validated and correct HTML. Simply making the HTML valid is a simple performance improvement.

W3C has a validation service where you can test your HTML against the open standards. It's easy to use, and the key is to fix all errors and warnings that show up.

Console errors

In the browser console you will find errors in executing JavaScript, parsing and rendering the HTML with attached stylesheets. Just like in PHP and on the web server in general, errors take time. Making sure there are no console errors and warning, or fix the ones that are there, is a key step to easing the browsers workload when parsing and rendering the page.

Critical CSS

Above the fold CSS, Critical CSS, or first view CSS. It has many names, but they all refer to the styling that is needed to render the top of your page in the initial display, called above the fold, correctly. In other words, the styling needed to render the part of the website your visitors will see first when visiting your website. Loading the Critical CSS first in a separate file, and load the rest of your styling at a later time can increase core web vitals, and the experienced speed of your website.

This process can be a tedious one, and it's best done automatically. The best plugin out there so far doing this is CriticalCSS which you can use together with the popular plugin Autoptimize.

Unused CSS

If you buy themes or plugins, and especially “multipurpose themes” or “Swiss army knife plugins”, these come with a lot of CSS that you do not need.

Code that needs to run or parsed, but does not have any impact on the end result is called bloat. Generating code on server, sending that code through the Internet, and making the browser parse code that does not impact the styling, experience or functionality of a WooCommerce store is wasted time, wasted energy, and last but not least, wasted money. Loading speed is one of they key technical factors that impact your conversion rate.

If you want to figure out exactly how much CSS your site does not use but still loads, I highly recommend purifycss.online and similar tools. These tools can tell you how many percent of your CSS is not used, and even generate a cleaner stylesheet file for you.

What to do if the stylesheet is added by the theme or a plugin?

If the CSS is added through a plugin or a theme, the process of optimizing always becomes a bit more complicated. You can have plugins do the work for you, but these plugins usually just improve and do not make perfect. The technique I personally stick to, is determining what parts of the code are in use by using tools like PurifyCSS , remove the styling from the theme or plugin, and add the CSS that is in use to a child theme.

To remove the stylesheet from loading you need to dequeue and optionally deregister the stylesheet in your functions.php of your child theme, or in a custom site plugin.

Exemplo

add_action( 'wp_enqueue_scripts', 'remove_default_stylesheet', 20 );
function remove_default_stylesheet() {
wp_dequeue_style( 'original-enqueue-stylesheet-handle' );
wp_deregister_style( 'original-register-stylesheet-handle' );
}

Frontend assets

The assets that are loaded by your browser, the frontend assets, have a lot of room for optimization for performance. Especially if you're using a lot of and/or large images.

Otimize suas imagens

Images are usually the closest a potential customer gets to a physical product before it's bought and delivered. Images are important, and as a store owner you want the images to be as high quality as possible. On the other hand, you don't want to send larger images than your visitor can view on their screen. Sending more pixels than the screen has, or than the image container has, means superfluous data that only slows down the loading and display of the image – and possibly the page as a whole. Sending more pixels than what will be displayed does not only mean more data to be transferred through the internet to the browser, but the browser must also shrink the image to make it fit. This all takes time.

In WordPress and WooCommerce you have a set of image sizes, and plugins and themes can also register image sizes. These image sizes control what sizes the images you upload should be resized to, so that you can deliver the best fitting image depending on the use. All your images will be duplicated and resized into these image sizes and stored on disk. That is awesome, and as long as you in your theme use the best image size to the container it's being displayed at, you have done the first step of optimizing your images.

Choose the right image quality for your store

Now we have touched sizes, but that is just half of the equation when it comes to the amount of megabytes or kilobytes an image is. The other is image quality or image compression. Image quality simply means the level of accuracy in an image. By default, WordPress uses a quality of 82 out of 100 on intermediate sizes. Which is good for most, but when optimizing images you do not want “good for everyone” you want “good enough for this store”.

Luckily, this setting can be changed. You should therefore play around with the quality setting to find the perfect quality setting for your store. The lower the better. I usually end up with something between 60 and 70. The quality setting does not however change the quality of the full size image, only intermediate sizes. But, luckily there is a fix for that as well!

The next step is to get rid of data in the image that you do not use. If you didn't already know, images can contain data that does not have anything to do with the displaying of the image itself. That data is called metadata or EXIF data. This data can be copyright information, information about where a photo was taken, by who and so on. This information does not provide much value in a regular WooCommerce store and should be removed.

We have written about image optimization before as well as image resize. Both are good resources to check out with regard to this topic.

Changing the default quality and max size, and get rid of EXIF data

One of the few plugins I nearly always install in a WooCommerce store is the Resize Image After Upload plugin from Shortpixel . This is a lightweight plugin that mainly does two very important things:

• Resize and optimize the full size image
• Change the quality of intermediate sizes

In the plugin you can set a maximum size of the full size image, and the plugin will resize the image down to that size if you ever upload larger images. An awesome feature if the people uploading images do not resize the image before they upload it. You can also set a quality setting which changes both the quality of the full size image, and the quality of intermediate sizes.

What this plugin does not do is resize and optimize images that you already have uploaded. For that you should use some simple CLI commands or a separate plugin.

Responsive images

So we have optimized our images, great! That means that the images we have in our WooCommerce store are optimized for speed. Now, the next mission is to optimize what image we deliver to what browser and what screen size. Modern browsers support responsive images, the srcset and size attributes . This enables you to in an <img> tag declare multiple sizes, and the browser will then only download the image it believes will fit that exact screen the best. Most themes and plugins, plus WordPress and WooCommerce itself support responsive images now and you don't have to do anything to make it work.

That does not mean you cannot do anything to optimize your responsive images. Depending on what sizes your theme and plugin already have configured for you, you can also add your own custom sizes to tailor to specific browser and screen sizes. While this is a bit complicated, we have made it easy to do in Accelerated Domains.

Responsive images, resized and optimized on the fly using Accelerated Domains

In Accelerated Domains we have built in automatic image resizing and optimization on the fly. With minimal configuration in our plugin, you can optimize the image delivery and sizes easily. Without storing more images on disk, as we store the resized versions in the Accelerated Domains network instead.

Automatically add half-sizes

Using the Servebolt Optimizer plugin and Accelerated Domains you can, with a flick of a switch, add sizes that are 50% of the size of all your already registered image sizes. That means if you have a 100×100 image size, we will automatically add a 50×50 image size if you don't already have one. This will increase the image sizes that are available to the browser, and automatically optimize for a larger set of screen and browser sizes.

Adjust image quality

In the plugin you can also easily adjust the image quality. In WordPress the default is 85, but like mentioned above, you should experiment with this setting to find the lowest acceptable quality for your WooCommerce store and products. In the Image Resize feature in Accelerated Domains you can do this easily for all images.

Tamanhos de imagem extras

Para permitir que você otimize ainda mais suas imagens com facilidade, adicionamos uma maneira fácil de otimizar seus tamanhos de imagem adicionando uma maneira fácil de adicionar tamanhos de imagem personalizados sem código. Ao analisar quais tamanhos de tela e navegador seu público usa, você pode determinar em quais tamanhos de imagem suas imagens devem estar disponíveis. Digamos que você tenha muitos visitantes visitando seus produtos em um navegador com 1300 pixels de largura. Então você pode descobrir qual é o tamanho exato da imagem das imagens do seu produto em uma tela de 1300 pixels e adicionar esse tamanho. O navegador usará o tamanho perfeito!

Hospedar fontes localmente

Se você usa o Google Fonts ou outras fontes de terceiros, elas provavelmente são carregadas de, por exemplo, fonts.google.com . Isso introduz uma solicitação separada para um novo domínio, que é mais lenta do que carregar ativos do mesmo domínio da solicitação inicial. Isso ocorre porque o navegador precisa fazer uma pesquisa de DNS separada e negociar o SSL com o outro servidor. Quando você está carregando uma fonte do Google usando o método recomendado, ela é diagnosticada como um “recurso de bloqueio de renderização” e adicionará quase um segundo inteiro ao tempo de carregamento.

Resolvido em domínios acelerados

Em vez de hospedar as fontes localmente, configuramos o proxy do Google Fonts em Accelerated Domains. Isso tem o mesmo efeito que hospedar fontes localmente, mas é automático e fácil de usar.

Async e adiar JavaScript

Como o JavaScript é principalmente uma linguagem de script do lado do cliente e o código é executado no navegador, o tempo é fundamental ao carregar e executar o JavaScript. Para entender isso completamente, devemos primeiro entender como e quando os navegadores carregam e executam o JavaScript.

O tempo é fundamental

O analisador HTML nos navegadores funciona de cima para baixo. Uma vez que atinge uma linha de script, por padrão, busca o script imediatamente e o executa, antes de continuar a análise do HTML. Isso significa que o posicionamento da linha de script é fundamental. No WordPress, os posicionamentos padrão para scripts estão em <head> e na parte inferior de <body> .

<html>
<head>
<title>A title</title>
<script src="your-head-script.js"></script>
</head>
<body>
CONTENT
<script src="endof-body-script.js"></script>
</body>
< /html>

Uma observação importante aqui é que há uma diferença entre analisar o HTML e renderizar a página. Você pode ter ouvido falar sobre scripts de bloqueio de renderização e nem scripts de bloqueio de renderização async ou defer , pois isso depende do script e do que aciona o script.

Carregar scripts em <head>

Scripts localizados em head sem defer de async irão “pausar” a análise de HTML durante a busca e execução.

Carregar scripts no final de <body>

Scripts colocados no final da tag <body> também serão buscados e executados no final da tag body.

Carregar scripts com assíncrono

JavaScript carregado com async (de forma assíncrona) informa ao navegador que ele pode continuar analisando a página enquanto o script está sendo baixado. No entanto, o script será executado assim que o download for concluído. Enquanto o defer diz ao navegador para baixar o script e não executá-lo até que a análise do HTML seja concluída.

Carregar scripts com defer

Quando os scripts são carregados com defer , em head, você diz ao navegador que ele deve buscar o script, mas continua a analisar o HTML e espera para executar o script até que o HTML seja totalmente analisado.

Integrações

As integrações são um componente necessário em qualquer loja WooCommerce de sucesso. As integrações podem agilizar o gerenciamento, simplificar o envio ou até mesmo aumentar suas vendas. Mas, as integrações podem ser feitas de uma maneira ruim e de uma maneira boa.

O que torna uma integração ruim?

Algumas integrações vêm na forma de um plugin pesado escrito por pessoas que não entendem completamente como o WordPress funciona internamente. Isso pode resultar na instalação de um plug-in para gerenciamento de pedidos, o que diminui a velocidade do seu frontend, sem qualquer motivo para que isso aconteça.

Muitas vezes encontramos integrações que são de natureza aparentemente direta e devem ter baixo impacto, mas muito pelo contrário. Exemplos dessas integrações ruins são verificações de licença para plugins ou temas em cada carregamento de página ou integrações que usam XML-RPC para conectar seu serviço ao site.

As versões mais óbvias de integrações ruins são integrações pesadas de código, diminuindo a velocidade do seu site simplesmente por causa do inchaço que elas introduzem ou simplesmente pelo carregamento incorreto do código do plug-in e seus ativos. Como quando, onde e como deve ser carregado.

Boas integrações, como exemplos dos exemplos ruins acima, usarão a API Rest para conexões, fique atento ao carregar o que em qual página. Ou, geralmente são apenas plugins muito leves ou não precisam usar um plugin.

Procurar

A pesquisa de produtos é uma parte importante de qualquer loja WooCommerce. O banco de dados é muito bom para lidar com grandes quantidades de dados, mas pesquisar com muitos filtros em metadados, como atributos, pode ser um pouco lento. Felizmente, existem soluções que são muito melhores e mais rápidas nas pesquisas de produtos do que a pesquisa integrada do WooCommerce.

Algolia

Algolia é um banco de dados de pesquisa externo que você pode preencher e pesquisar usando APIs. É incrivelmente rápido e oferece muita personalização. A equipe do WebDevStudios até fez um plugin para você implementar facilmente o Algolia no seu WordPress/WooCommerce.

Pesquisa elástica

O Elastic Search é semelhante ao Algolia, mas baseado na pilha ELK e está disponível como uma solução hospedada (como Algolia) e como uma solução auto-hospedada. O Elastic Search é quase tão rápido quanto o Algolia e oferece um nível mais alto de personalização. No entanto, você não obtém uma GUI de gerenciamento com o Elastic Search pronto para uso. Mas, para necessidades de maior personalização, o Elastic Search é perfeito. A equipe da 10up ainda tem um plugin que o ajudará a começar facilmente e é totalmente suportado por nós. Basta entrar em contato com nossa equipe de suporte e eles terão prazer em ajudá-lo a configurar.

Como lidar com a segurança de uma loja WooCommerce

Em qualquer loja WooCommerce você armazena muitas informações pessoais sobre as pessoas que fazem pedidos. Isso introduz uma série de novas preocupações e ameaças de segurança, pois atores mal-intencionados podem não apenas “hackear” seu site para, por exemplo, direcionar tráfego para o site, mas também obter as informações pessoais que você armazena. Portanto, você precisa reforçar a segurança e garantir que nenhuma pessoa indesejada tenha acesso à sua loja de forma alguma.

Segurança no WooCommerce (ou WordPress para esse assunto) é um tópico sobre o qual poderíamos escrever um livro, pois esse é um tópico complicado com muitas variáveis. No entanto, aqui estão algumas das armadilhas mais importantes que você deve estar ciente.

Não use plugins de segurança para WordPress e WooCommerce

Muitos proprietários de lojas e desenvolvedores, bons e menos bons, confiam em vários plugins de segurança para proteger sua loja. Plugins como Wordfence e iThemes Security. Todos esses plugins fazem coisas boas, mas fazem isso no lugar errado. E fazê-lo no lugar errado pode, em muitos casos, ser pior do que não fazer nada. Além disso, eles vendem você como “a única coisa que você precisa fazer” para proteger sua loja WooCommerce, o que não é correto e é uma segurança falsa.

Plugins de segurança funcionam no WordPress em sua maior parte, e alguns também personalizam o Apache por meio do arquivo de configuração do Apache, .htaccess . Isso é como proteger sua casa com um estilingue. Você não pode fazer muito até que o mau ator esteja dentro de sua casa e, uma vez dentro, pode causar muitos danos antes que você consiga pegá-lo com seu estilingue. E até onde você sabe, eles podem ter pegado aquela importante pilha de papel que você tinha em sua mesa ou deixado a porta dos fundos aberta para que eles pudessem entrar mais tarde.

Além disso, a abordagem que esses plugins têm ao proteger o WordPress e o WooCommerce de dentro introduz muito código ao seu aplicativo. Eles não ajudam você em sua busca para acelerar o WooCommerce. Esse código deve ser executado em todas as solicitações, boas e ruins, e todas elas as tornam lentas. De certa forma, você pode realmente dizer que, usando um plug-in de segurança, você se torna um alvo mais fácil para DDoS, porque um site mais lento usa mais CPU por solicitação, então o invasor precisa de menos solicitações para sobrecarregar seu servidor. Mais sobre como bloquear tráfego indesejado aqui.

O que você deve fazer para proteger seu WooCommerce

Deve ficar claro agora o que não fazer, então vamos destacar as coisas que você deve fazer!

Proteja seu wp-admin com autenticação multifator

A maneira mais fácil de entrar em qualquer WordPress é fazer login com um nome de usuário e senha válidos, e essa é a maneira mais comum de os invasores entrarem também. Ao introduzir um ou mais fatores necessários para fazer login, como um código de segurança (OTP) ou similar, você minimiza o risco de alguém entrar em seus sites WP e Woo.

Obtenha uma cerca de segurança em toda a sua infraestrutura WordPress

A melhor maneira de proteger qualquer site, incluindo uma loja WooCommerce, é parar os maus atores antes mesmo de chegarem à sua infraestrutura de origem. Isso pode ser feito com serviços como Cloudflare e Accelerated Domains. Enquanto você mesmo precisa manter a camada de segurança (WAF, regras de firewall, etc) na Cloudflare, nos Accelerated Domains fazemos isso para você de forma proativa. Tanto automaticamente por meio do aprendizado de máquina quanto manualmente, analisando o tráfego para todos os domínios que executam Accelerated Domains.

Mantenha WordPress, WooCommerce, temas e plugins atualizados

A maioria dos “hacks” do WordPress e WooCommerce são executados por meio de vulnerabilidades de segurança no WordPress, temas ou plugins. E a melhor maneira de garantir que você tenha o mínimo possível de vulnerabilidades de segurança é manter o núcleo do WordPress, WooCommerce, temas e plugins atualizados o tempo todo.

Pare de usar plugins e temas que não são mantidos

Plugins e temas podem ficar subitamente sem manutenção, o que também significa que eles não recebem atualizações para corrigir possíveis vulnerabilidades de segurança. Plugins que não receberam atualizações de nenhum tipo por um ano são sinalizados no repositório de plugins no WordPress.org e por um bom motivo! Simplesmente pare de usar plugins não mantidos.

Não use plugins grandes para pequenas tarefas

Quanto mais código houver em um plugin, mais código haverá para manter. E mais código também significa mais vulnerabilidades de segurança possíveis. Usar um plug-in grande para uma tarefa pequena, na qual você realmente usa e vê valor em uma pequena parte de um plug-in, pode resultar em vulnerabilidades de segurança em partes do código que você nem usa.

Dica extra – Plugins que são úteis para otimizar o desempenho

Em sua busca para otimizar o desempenho, gostaria de destacar dois plugins específicos que podem ajudá-lo a otimizar de duas maneiras diferentes.

Gerenciador de plugins WP

A maioria dos plugins não contém mecanismos para garantir que ele não seja carregado em páginas onde não é necessário. Em muitos casos, isso é difícil para um desenvolvedor de plug-in fazer, pois o desenvolvedor de plug-in não sabe em quais páginas você usará o plug-in especificamente.

Isso torna o WP Plugin Manager muito útil, pois você pode controlar e desabilitar completamente os plugins por página/post e garantir que ele não adicione ativos desnecessários, código PHP e consultas de banco de dados em posts, páginas ou produtos que não estão em uso.

Monitor de consultas

As consultas de banco de dados podem desacelerar sua loja WooCommerce, e o melhor plug-in para identificar quais consultas demoram e de qual plug-in ou parte do tema essas consultas se originam é chamado Query Monitor e é mantido por John Blackbourn.

Você só vai querer ter o Query Monitor ativado para teste. Este não é um plugin que deve estar ativo em produção.

No fechamento

Como você pôde ver pela quantidade de informações que compartilhei neste artigo, acelerar o WooCommerce não é um passo simples. É uma forma de pensar. O desempenho primeiro deve ser o mais importante à medida que você cria e mantém seu site, tema e plugins WooCommerce. Eles estão intimamente interligados e todos podem ter um enorme impacto na velocidade do seu site WooCommerce. Somente a partir dessa base você pode começar a dimensionar o WooCommerce corretamente.

Também mencionei algumas coisas não óbvias que afetam o desempenho de sua loja. Cada tópico relacionado ao desempenho mencionado aqui precisa fazer parte de sua análise constante "como melhorar o desempenho da minha loja WooCommerce" e otimizado de acordo.

Uma coisa que adoraríamos cuidar para você é fornecer hospedagem WooCommerce rápida e, se você precisar de mais, domínios acelerados.

Mesmo que este artigo já seja uma lista muito longa de coisas para fazer, isso não é tudo o que há para fazer. E, como tal, adoraria ver suas recomendações de melhoria de desempenho do WooCommerce também nos comentários abaixo.

Boa otimização!