Como Acelerar o seu Site WordPress (O Melhor Guia)

Publicamos muitos tutoriais de otimização da velocidade do WordPress ao longo dos anos com formas de otimizar e acelerar o WordPress. Mas, por vezes, pode ser confuso encontrar tudo o que você precisa em um só lugar. Hoje iremos compartilhar com você tudo o que sabemos sobre como melhorar o WordPress, com base em mais de 15 anos de experiência e lições difíceis aprendidas, tudo compilado em um grande guia. Se você está começando a utilizar o WordPress, ou se já é um desenvolvedor expRead more in our web server showdown: NGINX vs Apache.eriente, prometemos que encontrará algo útil nesse guia!

Mais de 43.6% da web é agora alimentada pelo WordPress. Ainda que isso seja incrível, significa também que existem milhares de temas, plugins e tecnologias diferentes, sendo que todos precisam de coexistir. Para o usuário que utiliza diariamente WordPress, isso pode se tornar rapidamente um pesadelo, quando o site começa ficando mais afunilado, desconhecendo a razão para isso ou até mesmo a solução para o problema.

No nosso guia anterior sobre velocidade de página, examinamos muitas das bases do desempenho e como ele pode ter um grande impacto no sucesso do seu negócio. Mas, hoje, iremos detalhar as etapas aplicáveis que você pode usar para ver melhorias nos seus sites WordPress. Também compartilharemos alguns recursos que consideramos essenciais.

Tipos de Sites WordPress: Estáticos ou Dinâmicos

Antes de entrarmos na otimização da velocidade do WordPress, precisamos primeiro de entender que nem todos os sites do WordPress são idênticos. É por isso que muitos usuários encontram problemas, já que não tem uma solução uniforme para os problemas. Sempre classificamos os sites WordPress de acordo com um critério: estático ou dinâmico. Então, vamos primeiro explorar as diferenças entre esses dois tipos de sites.

Sites Maioritariamente Estáticos

A categoria estática normalmente inclui sites como blogs, sites de pequenas empresas, sites de notícias com menor volume, sites pessoais, sites de fotografia, etc. Por categoria estática, queremos dizer que os dados nesses sites do WordPress não mudam com grande frequência (talvez apenas algumas vezes por dia). Até mesmo a maioria do nosso site Kinsta seria considerado um site estático de acordo com essa perspetiva.

Isso é muito importante, já que muitas das solicitações podem ser respondidas diretamente pelo cache no servidor em velocidades muito altas! Não se preocupe; iremos falar sobre isso no capítulo dedicado ao cache mais adiante. Isso significa que esses sites exigirão menos solicitações à base de dados e não serão necessários tantos recursos para atingir o desempenho exigido pelo Google.

Sites Altamente Dinâmicos

Por outro lado, temos também os sites altamente dinâmicos. Esses incluem sites como eCommerce (WooCommerce ou Easy Digital Downloads), sites de comunidade, sites de filiação, fóruns (bbPress ou BuddyPress) e sistemas de gerenciamento de aprendizado (LMS). Por dinâmico, queremos dizer que os dados nesses sites do WordPress são alterados frequentemente (as transações do servidor ocorrem em um curto espaço de minutos ou até mesmo a cada segundo). Isso significa que nem todas as solicitações para o servidor podem ser facultadas diretamente a partir do cache e, então, são necessários recursos adicionais do servidor e consultas à base de dados.

Esses sites normalmente também têm grande número de visitantes e sessões simultâneas. Em um site WordPress informativo ou corporativo, que seja essencialmente estático, um visitante pode permanecer por cinco ou dez minutos até encontrar aquilo de que necessita (e esse é um número alto, habitualmente as taxas de rejeição são muito maiores). Em sites dinâmicos, acontece o oposto. Normalmente, os visitantes entram no site para interagir com algo ou com alguém. Se eles estão fazendo um curso online, permanecer online durante horas não é algo raro.

Você já está entendendo qual o ponto por detrás disso. Os visitantes simultaneamente conectados ao seu host WordPress se acumulam rapidamente. Para piorar a situação, você tem um grande número de visitantes simultâneos, juntamente com um problema de “conteúdo não armazenável em cache”.

Escolha a Hospedagem WordPress de Alto Desempenho

Um host WordPress é uma empresa que armazena todos os dados do seu website. Você subscreve um plano e todas as suas imagens, conteúdo, vídeos, etc., passam a ficar colocados em um servidor localizado no centro de dados do host. O host WordPress providencia uma forma simples de aceder, gerenciar e encaminhar os dados para os seus visitantes. Muito simples, certo? Bom, nem tanto assim.

Existem três tipos bem distintos de hosts WordPress que encontrará em toda a web. Iremos analisar os prós e contras de cada. É importante que você escolha o caminho certo desde o início, caso contrário irá ter muitas dores de cabeça e tempo perdido.

1. Hospedagem Compartilhada do WordPress

O primeiro e mais popular tipo de hospedagem WordPress é aquilo que designamos por “hospedagem compartilhada”. Esses incluem os maiores hosts desse setor, empresas EIG como Bluehost e HostGator, assim como fornecedores como o Siteground, GoDaddy e InMotion Hosting. Normalmente esses sites utilizam o cPanel, e o cliente médio habitualmente paga entre $3 e $25 por mês.

Qualquer pessoa que utiliza esse tipo de hospedagem enfrentará problemas com uma velocidade lenta, é só uma questão de tempo até isso acontecer. Porquê? É que os hosts compartilhados tendem a sobrecarregar seus servidores, o que então pode afetar o desempenho do seu site. Sites suspensos, ou erros 500 que surgem com frequência, são coisas comuns que irá vivenciar, pois eles colocam limites em tudo e consolidam os recursos para poderem sobreviver. Ou, pior do que isso, terá de lidar com tempo de inatividade do site. Apesar de você desconhecer essa realidade, seu site WordPress provavelmente está no mesmo servidor com mais outras 200 pessoas. Qualquer problema que surja com outros sites pode alcançar o seu.

Independentemente da forma como você faz as contas, $3 por mês não gera receita para a empresa de hospedagem. Especialmente quando você também tem direito a apoio técnico. Basta abrir um ticket de suporte e eles já estão tendo com prejuízo com você. Eles lucram com upselling e taxas escondidas. Esses upsells incluem migrações, registros de domínio, certificados SSL, etc. Outra tática habitual é oferecer descontos enormes para a subscrição. Mas, quando chega o momento da renovação, você é confrontado com o preço real.

A maioria desses hosts oferecem aquilo que eles designam como o seu plano de “recursos ilimitados”. Você provavelmente já encontrou isso. Bom, temos de falar que no mundo real não existe algo como recursos ilimitados. O que os hosts fazem nos bastidores é asfixiar os clientes utilizando muitos recursos. Por sua vez, isso faz com que os clientes irritados abandonem o barco, abrindo espaço para mais clientes que não utilizam tantos recursos. No final, é criado um ciclo vicioso onde a empresa de hospedagem tenta vender planos baratos e atrair clientes que eles esperam que não usem muitos recursos e comprem extras.

O atendimento e o apoio ao cliente com hospedagem compartilhada ficam quase sempre abaixo das expetativas devido ao grande volume de sites em comparação com os funcionários disponíveis para facultar apoio. Os hosts compartilhados têm de ser distribuídos por muita gente para terem lucro e isso geralmente provoca a uma experiência desagradável para o cliente.

Certifique-se de verificar um artigo aprofundado do nosso CFO sobre as verdades chocantes por trás como funciona barato WordPress hospedagem realmente funciona.

2. Hospedagem WordPress VPS Faça-Você-Mesmo

O segundo tipo de hospedagem WordPress é a VPS DIY ou “Faça você mesmo em um servidor privado virtual”. Esse público é normalmente composto por start-ups bootstrap e usuários que entendem um pouco mais de desenvolvimento e de gerenciamento de servidor, tendo maior experiência com WordPress. São eles o grande núcleo do DIY. Essas pessoas muitas vezes estão tentando ainda poupar dinheiro, mas geralmente também estão preocupadas com o desempenho e percebem a sua importância no sucesso empresarial. As configurações mais comuns podem incluir o uso de um provedor de VPS de terceiros, como o Digital Ocean, Linode ou Vultr; juntamente com uma ferramenta como o ServerPilot para garantir um gerenciamento mais fácil.

Uma pequena VPS da DigitalOcean começa com um preço de $5 por mês e o plano popular no ServerPilot começa em $10 por mês. Então, dependendo da sua configuração, pode ter um custo entre $5 a $15 ou mais por mês. A abordagem DIY pode reduzir custos, mas também significa que você é o responsável quando algo corre mal e terá de otimizar o desempenho do seu servidor.

A abordagem DIY pode ser ótima, mas também pode descarrilar se você não for cuidadoso. Não aposte nesse caminho se você não é um especialista em tecnologia ou se quiser apenas fazer alterações! Seu tempo vale dinheiro e deve gastá-lo para fazer crescer o seu negócio.

3. Hospedagem WordPress Gerenciada

O terceiro tipo de hospedagem é aquilo que oferecemos na Kinsta e isso é a hospedagem gerenciada do WordPress. Esses tipos de hosts lidam com todas as tarefas relacionadas com o servidor back-end, além de facultar apoio quando você necessita dele. Normalmente eles estão ajustados pormenorizadamente para funcionarem no WordPress e incluem recursos como ambientes de teste de um só clique e backups automáticos. As suas equipes de suporte ficarão muito mais informadas em relação ao CMS, já que estão focadas em uma só plataforma diariamente.

Se pretende poupar tempo, a hospedagem WordPress gerenciada é o caminho certo! 👍

Os planos para a hospedagem WordPress gerenciada normalmente variam entre $25 e $150 por mês ou mais, dependendo do tamanho do seu website e necessidades. Grandes empresas como jQuery, Intuit, Plesk, Dyn, NGINX e até mesmo a Casa Branca estão usando o WordPress para hospedar seu site. Alguns hosts populares WordPress gerenciados, que você provavelmente também conhece, podem estar usando essa opção, como o WP Engine, Flywheel, Pressable, Media Temple, Pressidium e o Pagely.

Kinsta Adota uma Abordagem Diferente

Kinsta, no entanto, leva a hospedagem do WordPress para o próximo nível. Nossa plataforma de hospedagem não se enquadra em nenhuma das categorias tradicionais de hospedagem. Toda nossa infraestrutura é construída sobre o Google Cloud Platform e é diferente da tradicional infraestrutura compartilhada, VPS, ou dedicada, tornando uma das mais rápidas soluções de hospedagem WordPress disponíveis.

Cada site WordPress na nossa plataforma é executado em um container de software isolado que integra todos os recursos de software necessários para executar o site (Linux, NGINX, PHP, MySQL). Ou seja, o software que executa cada site é totalmente privado e não é compartilhado nem mesmo entre seus próprios sites.

Cada container de site é executado em máquinas virtuais em um dos vários centros de dados GC. Cada máquina tem até 96 CPUs e centenas de GB de RAM. OS recursos de hardware (RAM/CPU) são automaticamente alocados em cada container de site pelas nossas máquinas virtuais, obedecendo àquilo que +é necessário.

Thank you @kinsta for handling today's traffic spike without issue. It's comforting to know your site can handle surges. #webperf #webhosting #wordpress pic.twitter.com/fplO87LIu0

— Adam Lundeen (@adam_lundeen_) January 29, 2019

A Review Signal publica anualmente os seus benchmarks de desempenho do alojamento WordPress, e estamos orgulhosos pelo fato de o Kinsta ser, há cinco anos consecutivos, a melhor empresa em todos os patamares! E não apenas em um ou dois dos nossos planos, mas em todos, desde o Starter até ao Enterprise. 🤘

Kinsta registrou pontuações perfeitas nos testes LoadStorm e Blitz. Os outros testes também não identificaram qualquer falha. Estou sem palavras para elogiar seu desempenho.

Também não temos representantes de suporte de nível 1 ou de nível 2. Toda a nossa equipe de suporte é construída por desenvolvedores do WordPress e engenheiros de hospedagem Linux, muitos dos quais gerenciaram seus próprios servidores, criaram temas e plugins e contribuíram para o core. Isso fará com que você tenha aconselhamento de especialistas que usam e desenvolvem ativamente no WordPress.

Você poderá conversar com os mesmos membros da equipe de suporte que também oferecem apoio aos nossos clientes da Fortune 500 e aos clientes enterprise. A nossa exigência em relação à qualidade da nossa equipe de suporte é tão alta que contratamos menos de 1% dos candidatos. Você não encontrará melhor suporte em outro lugar!

Para saber mais razões que devem fazer você escolher  Kinsta para uma hospedagem gerenciada do WordPress, leia o artigo porquê nós – como Kinsta é diferente. Mas, independentemente de quem você escolher como o seu provedor de hospedagem, deve sempre procurar esses recursos de servidor para garantir que seu site é executado o mais rapidamente possível.

PHP 7 ou Acima para ter um Melhor Desempenho

O PHP é uma linguagem open-source de programação e de script do lado do servidor, utilizada principalmente para o desenvolvimento web. A maior parte do core do software WordPress está escrita em PHP, juntamente com seus plugins e temas, o que torna o PHP uma linguagem muito importante para a comunidade WordPress. Você deve assegurar que seu host WordPress oferece pelo menos o PHP 7 ou superior.

Existem diferentes versões do PHP que seu host irá facultar para você no seu servidor, sendo que o recente PHP 7.3 oferece grandes melhorias de desempenho.

De fato, nos nossos mais recentes benchmarks de PHP, se você decidir comparar o PHP 7.3 com PHP 5.6, o primeiro consegue lidar com 3x mais pedidos (transações) por segundo! O PHP 7.3 também é em média 9% mais rápido do que o PHP 7.2. Isso pode afetar também a capacidade de resposta do painel de administração do WordPress.

Velocidades mais rápidas e segurança melhorada, é por isso que o Kinsta sempre disponibiliza as versões mais recentes do PHP. Você pode alterar as versões do PHP com um só clique.

E fique de olho em qualquer host WordPress que ofereça o HHVM como alternativa ao PHP. O HHVM deixou de ser uma solução adequada para a hospedagem em WordPress.

Escolha um Host que Utilize o Nginx

Nos bastidores, cada host WordPress utiliza um servidor web para alimentar os seus sites do WordPress. As escolhas mais comuns são o NGINX e o Apache.

Recomendamos escolher um host com NGINX devido aos seus alicerces na otimização de desempenho em escala. O Nginx geralmente supera outros servidores web renomados em testes de benchmark, particularmente em situações com conteúdo estático ou elevadas solicitações simultâneas, e é por isso que Kinsta utiliza o NGINX.

Algumas empresas de grandes dimensões utilizam o NGINX, entre elas Autodesk, Atlassian, Intuit, T-Mobile, GitLab, DuckDuckGo, Microsoft, IBM, Google, Adobe, Salesforce, VMWare, Xerox, LinkedIn, Cisco, Facebook, Target, Citrix Systems, Twitter, Apple, Intel e muitas mais. (fonte)

Segundo a W3Techs, o Apache alimenta 44.0% de todos os sites, sendo por isso a opção mais usada. Mas, se você olhar para o servidor web mais popular entre os sites com tráfego elevado (top 10.000), o NGINX alimenta 41.9% delesenquanto o Apache potencia apenas 18,1%. Ele é utilizado por alguns dos sites de maiores recursos, incluindo Netflix, NASA e até WordPress.com.

Leia mais no nosso showdown do servidor web: NGINX vs Apache.

A Rede do seu Host é Importante

Quando escolhe um host WordPress, você pode nem pensar em questionar ou procurar saber que rede ele está usando, mas deveria fazer isso. A rede pode ter um impacto enorme no desempenho do seu site e até mesmo na rapidez do seu painel WordPress. Muitos hosts excluirão isso dos seus esforços de marketing, pois optarão pela rede mais barata para diminuir custos.

Eis algumas perguntas que você deve colocar:

• Quais são as redes através das quais vocês transmitem os dados?A maioria da transmissão é feita através de redes públicas de ISPs ou por infraestruturas privadas, como Google ou Microsoft? Esses provedores de grandes dimensões possuem redes que são construídas e otimizadas para baixa latência e velocidade. Eles têm até seus próprios cabos de internet debaixo do oceano!
• As redes que vocês estão usando são redundantes?O que acontece se um cabo for acidentalmente cortado? Isso acontece com mais frequência do que você

Em 2017, o Google anunciou sua rede de nível standard, que é uma rede mais lenta, mas com um custo mais barato. Na Kinsta, utilizamos a rede de nível premium deles para todos os nossos planos de hospedagem. Embora isso represente um custo extra para nós, é algo que garante que você tem velocidades extremamente rápidas.

De acordo com o Google, a rede de nível premium consegue melhorar o desempenho da rede ao diminuir a duração do percurso na Internet pública; os pacotes entram (e saem) da rede do Google no ponto mais próximo possível do usuário e depois viajam ao longo da estrutura principal do Google antes de chegarem à VM. A camada standard leva o tráfego de saída do GCP (Plataforma Google Cloud) para a internet através de redes de trânsito público (ISP) em vez da fazer isso na rede Google.

Explicando de uma outra forma, que pode ser mais simples de entender:

• Os pacotes de nível Premium passam mais tempo na rede do Google, com menos desvios e garantindo assim um melhor desempenho (mas custam mais).
• Os pacotes de nível standard passam menos tempo na rede do Google e mais tempo tentando entrar nas redes públicas e, portanto, têm um desempenho pior (mas custam menos).

Que impacto isso tem? Bom, para dados que viajam entre continentes, a sua rede de nível premium será em média 41% mais rápida do que a rede de nível standard. Para dados que viajam para uma região próxima (mesmo continente), o nível premium é 8% mais rápido. Embora a rede apenas represente uma fração do seu tempo total de carregamento da página, cada milésimo de segundo é importante!

A redundância também é muito importante, e é por isso que o Google utiliza pelo menos três caminhos independentes (redundância N+2) entre dois locais na rede do Google, ajudando a garantir que o tráfego continua fluindo entre os locais, mesmo em caso de interrupção.

Como você provavelmente já sabe, muita coisa acontece nos bastidores em relação às redes. Garanta que seu host WordPress está usando uma rede reputada e que não reduz os custos para os patamares inferiores.

HTTP/2 é uma Obrigação

O HTTP/2 é um protocolo web lançado em 2015 que foi desenhado para acelerar a forma como os sites são apresentados. Devido ao suporte ao navegador, ele exige HTTPS (SSL). Se seu host WordPress não suporta HTTP/2, deve começar por procurar um novo provedor. Com a mudança de toda a web para HTTPS, isso já não é só um ótimo recurso; é uma necessidade.

A melhoria no desempenho com o HTTP/2 é explicada por vários motivos, como melhor suporte à multiplexação, paralelismo, compressão HPACK com codificação Huffman, a extensão ALPN e o push de servidor. Antigamente existia uma ligeira sobrecarga de TLS na execução de HTTPS, mas agora isso diminui muito devido ao HTTP/2 e ao TLS 1.3. O Kinsta suporta HTTP / 2 e TLS 1.3 em todos os nossos servidores e CDN.

Outra grande vitória do HTTP/2 é que agora, com a maioria dos sites WordPress, você não precisa mais se preocupar com a concatenação (combinação de arquivos) ou com o sharding do servidor. Essas otimizações estão agora obsoletas.

Escolha um Servidor Mais Próximo aos Seus Visitantes

Uma das primeiras coisas que deve fazer quando hospeda seu site WordPress é saber a localização da maioria de seus visitantes ou clientes. Por que motivo isso é importante? Porque o local em que você hospeda seu website tem um fator significativo na determinação da latência geral da rede e do TTFB. Isso afeta também suas velocidades de SFTP e a capacidade de resposta do painel administrativo WordPress.

Latência da rede: Isso diz respeito ao tempo e/ou atraso na transmissão de dados por uma rede. Dito de outra forma, o tempo necessário para um pacote de dados ir de um ponto a outro. Hoje em dia isso é normalmente medido em milissegundos; contudo, podem ser segundos dependendo da rede. Quanto mais próximo de zero melhor.

Confira nossa postagem detalhada sobre latência de rede.

TTFB: É o tempo até ao primeiro byte. Simplificando, é uma medida de tempo que mede a duração que o navegador deve aguardar antes de receber seu primeiro byte de dados do servidor. Quanto mais tempo demorar para obter esses dados, mais tempo levará para exibir sua página. Aqui, novamente, quanto mais próximo de zero melhor.

Confira nossa postagem detalhada sobre TTFB.

Não iremos continuar aborrecendo você com todos os detalhes técnicos nesse artigo, tudo que você precisa saber é que vai querer que a sua latência de rede e TTFB sejam os mais baixos possíveis. Uma das formas mais fáceis de conseguir isso é escolher um servidor mais próximo de seus visitantes. Você pode determinar a melhor localização seguindo as dicas abaixo.

Dica 1 – Verificar a Geolocalização dos Seus Visitantes no Google Analytics

Uma das primeiras coisas que você pode fazer é identificar a geolocalização de seus visitantes no Google Analytics. Você pode encontrar isso em “Público → Geo → Localização”.

No exemplo abaixo, você pode ver que mais de 90% do tráfego provém dos Estados Unidos. Então, na maioria dos casos, você vai querer colocar seu site WordPress em um servidor nos Estados Unidos. Você também pode filtrar os dados ainda mais para as cidades. Isso é especialmente importante se tiver uma empresa local. Mas normalmente recomendamos uma localização central como Iowa, EUA.

Dica 2 – Verificar Dados do Ecommerce

Se tiver uma loja eCommerce, verifique também de onde vêm seus clientes. É claro que isso é a forma como você gera receita, então esses são os seus visitantes mais importantes. Isso deve coincidir com o seu tráfego acima; contudo, isso nem sempre acontece. Se você tiver uma configuração de dados eCommerce ou metas no Google Analytics, poderá facilmente sobrepor essas informações aos dados de geolocalização para tomar uma decisão mais fundamentada. Ou então verifique as informações de localização armazenadas na base de dados da sua plataforma eCommerce.

Dica 3 – Faça um Rápido Teste de Latência

Existem muitas ferramentas gratuitas e úteis para medir a latência da sua localização atual para diferentes provedores da cloud. Isso pode ajudar você a avaliar rapidamente a região potencialmente melhor para seu site.

• GCP Ping (mede a latência para as regiões da Plataforma Google Cloud, incluindo os servidores Kinsta)
• CloudPing.info (mede a latência para as regiões do Amazon Web Services)
• Azure Latency Test (mede a latência para regiões do Azure)

No exemplo abaixo, podemos ver que o Oregon, EUA (us-west1) é a opção mais rápida tendo em conta a nossa localização. Contudo, se você estiver servindo clientes em toda a área dos Estados Unidos, talvez seja melhor escolher Iowa, EUA (us-central1) para garantir uma baixa latência para os visitantes da costa oeste e leste.

Na Kinsta, disponibilizamos 37 centros de dados diferentes em todo o mundo. Você pode facilmente escolher um site que tenha baixa latência e baixo TTFB! Isso também ajuda a reduzir os saltos de rede.

Outras Formas de Reduzir a Latência e o TTFB

Além de escolher um local de servidor próximo, ficam abaixo algumas outras formas de reduzir a latência.

• Use cache no seu site WordPress.Nos nossos testes, o cache reduziu o nosso TTFB em uns impressionantes 90%!
• Utilize uma rede de entrega de conteúdo (CDN) para apresentar ativos colocados em cache a partir de POPs em todo o mundo.Isso ajuda a negar a latência da rede para visitantes que podem não estar próximos do servidor do seu host.
• Tire partido do protocolo HTTP/2 para minimizar o número de viagens de ida e volta, graças à paralelização.O HTTP/2 está ativado em todos os servidores Kinsta.
• Reduza o número de solicitações externas HTTP.Cada uma pode ter sua própria latência adicional com base na localização de seu servidor.
• O DNS tem um papel no TTFB, então você deve usar um provedor de DNS premium com rápidos tempos de consulta.
• Utilize o prefetch e o prerender para executar tarefas nos bastidores enquanto a página é carregada.

Não se preocupe; falaremos de todas recomendações acima na continuação desse artigo.

Velocidades de SFTP e Painel de Administrador WordPress

Os seus visitantes e clientes devem ser a sua prioridade em todos os momentos. Mas outro aspeto relacionado com o desempenho de que muita gente não fala é como algumas dessas decisões afetam seu trabalho diário. A localização do centro de dados afeta a velocidade de download e de upload do SFTP (transferência de arquivos usando um cliente FTP), assim como a capacidade de resposta do painel de administração do WordPress.

Você precisa escolher a melhor opção para os visitantes, já que isso pode afetar o gerenciamento do site. Tarefas como o upload de arquivos para a biblioteca de mídia do WordPress serão mais rápidas se o site estiver hospedado em um centro de dados mais próximo de você.

Sempre ouvimos os clientes da Kinsta falarem que ficaram surpreendidos com a rapidez do seu painel de administração. Existem imensos fatores que influenciam esse aspeto, mas ter 37 centros de dados diferentes é um dos principais! Escolha um local que funcione para os visitantes e para você! Afinal, você é a pessoa que provavelmente gastará milhares de horas trabalhando no seu site.

DNS Premium É Melhor do que DNS Gratuito

O DNS, abreviação de Domain Name System, é um dos componentes mais comuns, porém incompreendidos, na web. Simplificando, o DNS ajuda a direcionar o tráfego na Internet, conectando nomes de domínio a servidores reais na web. De forma sucinta, ele responde ao pedido humano – um nome de domínio como kinsta.com – e traduz isso para um endereço IP de servidor compreendido pelo computador – como 216.58.217.206.

Você tem o DNS gratuito e o DNS premium. Todos os clientes da Kinsta têm acesso ao DNS premium através da Amazon Route 53. E, de forma geral, acreditamos que o DNS premium é uma necessidade no mundo atual.

Um grande motivo que deve levar você a escolher o DNS premium é a rapidez e a fiabilidade. Buscar registros DNS e direcionar o tráfego leva tempo, mesmo que seja somente milissegundos.

Normalmente, o DNS gratuito que você recebe do registrador de nomes de domínio é relativamente lento, mas o DNS premium oferece por norma um melhor desempenho. Por exemplo, em nossos testes, vimos que o DNS gratuito NameCheap é 33% mais lento do que o DNS premium Amazon Route 53. Além disso, o DNS premium consegue oferecer melhor segurança e disponibilidade, especialmente quando você sofre um ataque DDoS.

Você pode usar uma ferramenta como o teste de velocidade SolveDNS para verificar os seus tempos de pesquisa de DNS. O DNSPerf também oferece excelentes dados de desempenho em todos os principais provedores de DNS.

Para um bom meio-termo entre o DNS gratuito dado pelo registrador de domínios e o DNS premium, o DNS Cloudflare é um serviço gratuito que oferece também muitas das vantagens do DNS premium. E eles são muito rápidos com tempos médios de resposta inferiores a 20 ms em todo o mundo (como vemos abaixo).

A integração do Cloudflare vem com todos os planos Kinsta. Se você estiver servindo principalmente aos visitantes nos Estados Unidos, o DNS Made Easy é outro grande provedor de DNS premium que você pode querer conferir. Eles têm a reputação de fornecer algum do melhor tempo de funcionamento do DNS durante a última década.

Nos últimos 30 dias, o DNSPerf registrou o seguinte tempo de atividade para esses provedores:

• DNS Made Easy: 99.99%, que equivale a 4m 23.0s de inatividade mensal.
• Amazon Route 53: 99.88%, que equivale a 52m 35.7s de inatividade mensal.
• Cloudflare: 99.85%, que equivale a 1h 5m 44.6s de inatividade mensal.

Mas será que o tempo de inatividade é tão importante assim para os provedores de DNS? A resposta para isso, no fundo, é sim e não. O DNS é normalmente armazenado em cache com os ISPs usando o valor do time-to-value (TTL) no registro DNS. Ou seja, se um provedor de DNS ficar inativo por 10 minutos, você provavelmente não notará nada. Ainda assim, o tempo de inatividade é importante se o provedor tiver interrupções frequentes e mais longas ou se os seus registros de ISP e DNS estiverem usando valores TTL bem baixos.

O Tema do Seu WordPress É Importante

Todo mundo sempre adora um novo tema WordPress, mas tome precauções antes de pegar um que tenha todos aqueles recursos bem atrativos. Antes de fazer qualquer coisa, deve conferir nosso artigo sobre as diferenças entre temas gratuitos vs. pagos. Em relação ao desempenho, todos os elementos que você vê em um tema têm impacto na velocidade geral do seu site. E, infelizmente, com milhares de temas sendo disponibilizados por aí, existem bons e maus.

Como escolher? Recomendamos uma dessas duas opções:

• Um tema WordPress rápido e leve que tenha apenas os recursos que você precisa, nada mais.
• Um tema WordPress com mais recursos, mas onde você pode desabilitar os recursos que não estão sendo utilizados.

Elementos como o Google Fonts, ícones do Font Awesome, controles deslizantes, galerias, scripts de vídeo e paralaxe, etc. Essas são apenas algumas das várias coisas que pode querer desativar se não estiver usando elas. É muito melhor do que ficar tentando fazer alterações de forma manual. E não iremos mostrar 50 maneiras diferentes de reduzir o peso desses extras. Em vez disso, você deve trocar para um tema do WordPress que seja leve ou para um que ofereça para você essas opções.

Abaixo ficam alguns temas do WordPress que recomendamos e com os quais terá sucesso! Confie, você irá nos agradecer mais tarde. 😉

Todos os temas referidos abaixo são compatíveis com o WooCommerce e com o Easy Digital Downloads, WPML, BuddyPress e bbPress. Executamos alguns testes de velocidade em cada tema usando a seguinte configuração:

• Alojamento na Kinsta, executando o WordPress 4.9.8
• PHP 7.3 e SSL (HTTPS)
• CDN da Kinsta
• O Imagify foi utilizado para comprimir imagens automaticamente.

GeneratePress

O GeneratePress é um tema para WordPress rápido e leve (menos de 1MB quando comprimido), móvel, desenvolvido tendo em conta a velocidade, SEO e usabilidade. Foi desenhado por Tom Usborne, um desenvolvedor do Canadá. É atualizado constantemente e tem bom suporte. Alguns membros da equipe Kinsta usam o GeneratePress em seus projetos.

Existe uma versão gratuita e uma premium. Se você der uma olhada no repositório WordPress, a versão gratuita tem atualmente mais de 200,000 instalações ativas, mais de 2 milhões de downloads e uma impressionante classificação de 5 em 5 estrelas (mais de 850 pessoas deram 5 estrelas para ele).

Uma das melhores coisas do GeneratePress é que todas as opções utilizam o WordPress Customizer nativo, ou seja, você pode ver todas as alterações instantaneamente antes de pressionar o botão Publicar. Isso também significa que você não precisa aprender a trabalhar com um novo painel de controle para esse tema.

E a velocidade? Instalámos novamente o GeneratePress, executámos cinco testes de velocidade no Pingdom e obtivemos a média. O tempo total de carregamento foi 305 ms com um tamanho total de página de somente 16.8 KB. É sempre bom ter teste inicial para ver o que o tema consegue fazer do ponto de vista do desempenho em bruto.

Executámos outro conjunto de testes com um dos temas pré-construídos da biblioteca de sites GeneratePress. Contém imagens, fundos, novas seções, etc. Uma vantagem do GeneratePress é que ele tem muitos temas pré-construídos que não exigem um plugin construtor de páginas. Você pode ver que continua ficando abaixo dos 400 ms.

Obviamente, em um contexto real, você pode ter outras coisas funcionando como o Google Analytics, o pixel de remarketing do Facebook, o Hotjar, etc. Mas deve garantir facilmente que fica abaixo da marca de 1 segundo. Veja essa avaliação aprofundada do GeneratePress no woorkup.

Abaixo iremos mostrar mais formas de você otimizar e acelerar o WordPress.

OceanWP

O tema OceanWP é leve e muito extensível. Permite que você crie praticamente qualquer tipo de site, como um blog, portfólio, site de negócios ou loja WooCommerce, apresentando um design bonito & profissional. Construído por Nicolas Lecocq, também é ativamente atualizado e bem suportado.

Assim como no GeneratePress, existe uma versão gratuita e premium. Se você der uma olhada no repositório WordPress, a versão gratuita tem atualmente mais de 400,000 instalações ativas e uma notável avaliação de 5 em 5 estrelas (mais de 2,600 pessoas deram 5 estrelas para ele).

Qual a sua rapidez? Fizemos uma nova instalação do OceanWP, executámos cinco testes de velocidade em Pingdom e obtivemos a média. O tempo total de carregamento foi 389 ms com um tamanho de página de apenas 230.8 KB. Os scripts no OceanWP são ligeiramente maiores, mas nada que mereça uma ênfase particular.

Depois fizemos outro conjunto de testes com um dos temas de demonstração da biblioteca do site OceanWP. Contém imagens, planos de fundo, novas seções e exige o plugin construtor de páginas Elementor. Você pode ver que continua abaixo dos 600 ms.

Você pode ver a avaliação mais detalhada do OceanWP no nosso blog.

Astra

O Astra é um tema rápido, totalmente personalizável e belo, apropriado para blogs, portfólios pessoais, sites de negócios e vitrines da WooCommerce. É muito leve (front-end com menos de 50 KB) e tem uma velocidade inigualável. Criado pela equipe da Brainstorm Force, está atualizado e tem um bom suporte. Foi a mesma equipa que criou o plugin famoso All In One Schema Rich Snippets, que existe há muitos anos.

Assim como com o GeneratePress e o OceanWP, tem uma versão gratuita e outra premium. Se der uma olhada no repositório WordPress, a versão gratuita tem atualmente mais de 400,000 instalações ativas, mais de 1,6 milhões de downloads e novamente uma impressionante classificação 5 rm 5 estrelas (mais de 2500 pessoas avaliaram ele com 5 estrelas).

E a velocidade? Fizemos uma nova instalação do Astra, executámos cinco testes de velocidade no Pingdom e obtivemos a média. O tempo total de carregamento foi 243 ms com um tamanho total de página de apenas 26.6 KB.

Depois executámos outro conjunto de testes com um dos temas de demonstração da biblioteca do site de kits Astra Starter. Contém imagens, fundos, novas seções e exige o plugin construtor de páginas Elementor. Você pode ver que se mantém abaixo dos 700 ms. Nota: as imagens nesta demonstração foram totalmente comprimidas, mas eles escolheram imagens de resolução muito alta logo de início.

É importante encarar as diferenças entre os testes de velocidade entre estes três temas com moderação. O problema é que é quase impossível executar uma comparação totalmente precisa. A coisa mais importante que queremos mostrar para você é que todos esses temas WordPress têm uma alta velocidade, seja na sua versão completa ou na demo! 🚀

Aviso sobre Construtores de Páginas

Como já deve ter percebido, o OceanWP e o Astra exigiram que os construtores de páginas usassem seus temas das bibliotecas de sites. Aqui ficam algumas coisas que deverá ter em consideração quando utiliza um plugin construtor de páginas:

• Alguns construtores de páginas podem aumentar o tempo de carregamento do seu site. Isso acontece porque eles precisam carregar CSS e JS adicionais para que as coisas funcionem sem código. É aí que a mágica acontece! Sempre recomendamos fazer um teste de velocidade ao seu site WordPress antes e depois de instalar um construtor de páginas.
• Você está se comprometendo com esse construtor de páginas em relação ao design. Tenha a certeza que escolhe um que é atualizado regularmente e que tenha tudo o que você precisa a longo prazo.

Tendo dito isso, somos ainda grandes fãs de construtores de páginas como o Elementor e o Beaver Builder. Na maioria das vezes, são desenvolvidos tendo em conta o desempenho e aumentam apenas ligeiramente a sobrecarga. Para a maioria, a funcionalidade e a usabilidade compensam, já que esses plugins permitem criar qualquer coisa que você possa imaginar! Em alguns casos, eles também podem ser mais rápidos, já que poderão ser um substituto para outros 5 e mais plugins que você teria de usar em substituição.

Contudo, se não precisar de um plugin construtor de páginas, não instale apenas porque sim. Também será interessante ver o papel que o novo editor Gutenberg terá no design de sites nos próximos dois anos.

Toda a Informação Sobre os Plugins WordPress

Vejamos agora os plugins WordPress. Você já pode ter sido avisado de que não deve instalar muitos plugins ou que isso irá tornar o seu site WordPress mais lento. Apesar de isso às vezes ser verdade, não é o fator mais importante. O número de plugins não é tão importante quanto a qualidade deles. Pronto, é isso. 😜

Assim como acontece com os temas, o importante é saber como o plugin é desenvolvido e se foi construído tendo em mente o desempenho. Temos muitos clientes na Kinsta que têm 30-40 plugins ativos e seus sites continuam carregando em velocidades inferior a um segundo.

Ainda que seja divertido adicionar código ao seu site, isso nem sempre é prático pelas seguintes razões:

1. Você terá de cuidar do código por conta própria, mantendo ele atualizado à medida que os standards se alteram. As nossas vidas são ocupadas, então por que não confiar nos desenvolvedores fantásticos que conhecem mais aprofundadamente os standards?
2. Na maioria das vezes, um plugin bem codificado não irá provocar muito mais sobrecarga do que o código.
3. Você precisa lembrar que grande parte da comunidade WordPress não é tão experiente em tecnologia quanto os desenvolvedores. Os plugins são soluções que ajudam a resolver problemas.

Claro que existem plugins cuja qualidade fica abaixo da média e que você deve evitar. Confie; já vimos as piores situações de sempre na Kinsta. Conhecemos os problemas de desempenho provocados por muitos, ainda quem nem todos, dos plugins que banimos na Kinsta. Também iremos falar sobre a forma como pode encontrar plugins ruins no seu site, mais abaixo.

Francesco tem um post interessante no qual ele mergulha em plugins WordPress de teste de carga para ver como eles se comportam no back-end de um site WordPress, que na maioria dos casos, não é armazenado em cache. Vamos mergulhar em como encontrar plugins ruins no seu site mais abaixo.

Contudo, é impossível ignorar que uma das coisas que as pessoas adoram no WordPress é sua enorme biblioteca de plugins feitos por terceiros. Mas, com mais de 56,000 plugins listados apenas no WordPress.org, e outros milhares encontrados em outros lugares, pode ser difícil descobrir o plugin de que você precisa. É que nem encontrar uma agulha no palheiro! Confira a lista que compilamos com apenas os melhores plugins do WordPress no mercado.

Tentamos compartilhar coisas que usamos diariamente. E, sim, usamos plugins WordPress em nosso site tal como vocês usam também. Muitos dos membros da equipe Kinsta desenvolvem e vendem plugins.

Um Grande Problema com os Plugins WordPress

Um grande problema com os plugins WordPress é o processo de desinstalação. Sempre que você instala um plugin ou tema WordPress, ele armazena os dados na base de dados. O problema é que, quando você exclui um plugin usando um dos métodos standard, ele normalmente deixa para trás tabelas e linhas no seu base de dados. Com o tempo, isso pode acumular muitos dados, começando até mesmo a diminuir a velocidade do seu site. No nosso exemplo, desinstalámos o plugin de segurança Wordfence, e ele deixou para trás 24 tabelas em nossa base de dados (como visto abaixo). É ainda pior se colocarem dados na tabela wp_options.

E, além da base de dados, muitos plugins têm também pastas e arquivos adicionais. De acordo com a nossa experiência, isso é algo habitualmente visto com plugins de segurança e de cache que criam diretórios adicionais para registros. Por exemplo, depois de o plugin Wordfence ter sido excluído, ficámos com uma pasta “wflogs” no nosso diretório wp-content. E não estamos criticando o Wordfence, a maioria dos plugins e temas funciona dessa forma.

Por Que Os Desenvolvedores Fazem Isso?

Está se questionando sobre o porquê de os desenvolvedores não terem opções de limpeza quando você desinstala e apaga um plugin? Bom, essas opções existem. Mas ficam aqui algumas razões pelas quais elas provavelmente não são tão óbvias assim.

1. Eles querem manter as configurações do usuário.Se você excluir um plugin do WordPress e quiser experimentar ele mais tarde, todas as suas configurações e dados continuarão lá. Embora isso seja super conveniente, não é a opção mais eficiente.
2. Eles não se importam com o desempenho.Alguns desenvolvedores dizem que manter tabelas não afeta o desempenho. Mas imagine um site, que, ao longo de dez anos, já depois de usar centenas de plugins, tenha possivelmente gerado milhares de linhas ou tabelas. As consultas à base de dados têm um impacto significativo no desempenho do seu site WordPress e os plugins podem fazer muitas dessas solicitações se o desenvolvedor não tiver tomado precauções. Geralmente, um plugin bem codificado deve apenas consultar as tabelas ou as linhas às quais ele está vinculado, mas isso nem sempre acontece. Já vimos aqui em Kinsta extensas consultas às base de dados que levam o site a perder desempenho devido aos dados carregados automaticamente na tabela wp_options, a qual foi deixada para trás.
3. Eles cometeram um erro. O manual de plugins WordPress fala que até mesmo “os desenvolvedores menos experientes por vezes cometem o erro de usar o gancho de desativação para essa finalidade”.

As boas notícias? Existem formas de limpar e de se livrar corretamente de um plugin. 👏 Confira nossos tutoriais:

• Como Desinstalar um Plugin do WordPress (o método apropriado)
• Como Limpar Manualmente as Tabelas Deixadas Para Trás

Configurações Ideais para WordPress

Chegou o momento de entrarmos nas configurações ideais do WordPress. Aqui ficam algumas alterações que você pode fazer para ajudar a acelerar o seu site WordPress. Muitas dessas mudanças são bem discretas, mas tudo ajuda!

Altere seu URL de login no WordPress

Por padrão, o URL de login do seu site WordPress é domain.com/wp-admin/. Um dos problemas com isso é que todos os bots, hackers e scripts por aí sabem disso também. Quando altera o URL, você pode se tornar um alvo menor, aumentando sua proteção contra os ataques de força bruta e diminuir a largura de banda usada pelos bots que entram repetidamente nesse URL.

Quando altera seu URL de login do WordPress isso também pode ajudar a evitar erros comuns como o “429 Too Many Requests”. Não resolve tudo, é apenas um pequeno truque que pode ajudar você a ficar protegido e a diminuir a carga nessa página.

Para alterar seu URL de login no WordPress, recomendamos utilizar um dos seguintes plugins:

• WPS Hide Login (grátis)
• Perfmatters (premium, mas inclui outras configurações de otimização de desempenho. Desenvolvido por um membro da Kinsta)

Desativar ou Ajustar Plugins e Atualizações de Temas

Os painéis de administrador WordPress que sejam lentos podem ser afetados pela rede, pela localização do centro de dados e até mesmo pelas versões do PHP. Mas outro fator pouco mencionado é o verificador de atualizações do WordPress que é executado em segundo plano. Essa é uma daquelas situações onde ter muitos plugins e temas do WordPress podem prejudicar você. O WeFoster tem um ótimo artigo sobre isso, onde eles cunham a frase “Síndrome de Verificação de Atualização de Plugins de Terceiros” ou o acrônimo inglês TPPUCS.

De forma resumida, o problema é que o verificador de atualizações integrado no WordPress faz uma solicitação GET externa nos bastidores (https://third-party-plugin/update-check.php).

Isso pode ser periódico ou então bem frequente. Se isso acontecer o tempo todo, o seu painel de administração pode acabar por ficar lento.

Esse problema tem mais que ver com a forma como o verificador de atualizações no WordPress está construído. Se você está encontrando lentidão nos tempos de carregamento do painel de administrador WordPress, experimente fazer isso. A solução é desabilitar as atualizações automáticas. Aviso: faça isso apenas se você pretende verificar as atualizações manualmente. Muitas atualizações são de segurança e correções de bugs.

Para desativar as atualizações, recomendamos o uso de um dos seguintes plugins:

• Disable All WordPress Updates: Totalmente gratuito sem configurações. Cumpre o que promete.
• Easy Updates Manager: Oferece maior controle sobre atualizações seletivas.A versão principal é gratuita.

Você pode facilmente adicionar um lembrete, desativar o plugin uma vez por semana, verificar se há atualizações e reativá-lo.

Desativar Pingbacks

Um pingback é um comentário automatizado que é criado quando outro blog coloca um link que redireciona para o seu site. Também pode haver auto-pingbacks, criados quando você linka um artigo dentro do seu próprio blog.

A nossa recomendação é desativar os pingbacks, pois eles são inúteis e apenas aumentam o número de consultas e spam no seu site. Vale a pena recordar que quanto menos solicitações o seu site WordPress tiver de fazer, melhor, particularmente em websites de tráfego elevado. Sem falar que um pingback no seu próprio site é simplesmente chato. Siga os passos abaixo para desativar os pingbacks.

Passo 1 – Desativar Pingbacks De Outros Blogs

No seu painel WordPress, clique em “Configurações → Discussão.” Na seção Configurações de discussão, desmarque a opção “Permitir notificações de link de outros blogs (pingbacks e trackbacks) em novos artigos”.

Passo 2 – Desativar os Auto-Pingbacks

Para desabilitar os auto-próprios, você tem algumas opções. Você pode usar o plugin gratuito No Self Pings. Ou você pode usar um plugin premium como o Perfmatters.

Em alternativa, você também pode desabilitar os auto-pingbacks adicionando o seguinte código ao functions.php. do seu tema WordPress. Cuidado, editar a fonte de um tema WordPress pode quebrar o seu site se não isso não for feito corretamente. Dica: você pode facilmente adicionar excertos de PHP como esse, usando o plugin gratuito Code Snippets. Ou seja, você não precisa nunca de mexer no seu tema.

function wpsites_disable_self_pingbacks( &$links ) {
  foreach ( $links as $l => $link )
        if ( 0 === strpos( $link, get_option( 'home' ) ) )
            unset($links[$l]);
}

add_action( 'pre_ping', 'wpsites_disable_self_pingbacks' );

Limite de Artigos no Feed do Seu Blog

Se o feed do seu blog está definido como sendo a homepage ou como outra página do seu site, você não necessita de carregar 50 miniaturas ao mesmo tempo. Para aqueles que gerenciam blogs de tráfego elevado, a sua homepage é a página mais importante do seu site e você deseja que ela seja rapidamente carregada. Quanto menos pedidos e mídia, melhor será o desempenho.

A paginação foi inventada para isso mesmo (como podemos ver abaixo). A paginação é o que você encontra no final dos feeds dos blogs, uma opção que permite navegar até à próxima página. Normalmente, são números ou então podem usar postagens do estilo “próximo/anterior”. Seu tema WordPress provavelmente já terá uma paginação personalizada embutida.

Por padrão, o WordPress define o limite nas novas instalações do WordPress para 10, mas isso já mudou vezes infindáveis. Então, verifique o valor que você está usando. Recomendamos algo entre 8 e 12. Se você tem curiosidade, a homepage do blog Kinsta usa 12.

Você pode encontrar essa opção no painel de controle do WordPress em “Configurações → Leitura”. Você pode alterar o valor para “Mostrar as páginas do blog no máximo”.

Por que o Cache É Tão Importante

O cache é de longe uma das formas mais importantes e fáceis de acelerar o WordPress! Mas, antes de mostrarmos como você pode o cache, primeiro precisa entender como ele funciona e os diferentes tipos de cache disponíveis.

O que é o Cache?

De forma resumida, cada página visitada em seu site WordPress exige uma solicitação ao servidor, processando por ele (incluindo consultas à base de dados) e, depois, um resultado final é enviado desde servidor até ao navegador do usuário. O resultado apresentado é o seu site, completo com todos os arquivos e elementos.

Por exemplo, você poderá ter um cabeçalho, imagens, um menu e um blog. Como o servidor necessita processar todas essas solicitações, demora algum tempo até que a página web seja apresentada na íntegra ao usuário, especialmente com sites grandes ou bagunçados.

É aí que um plugin de cache do WordPress entra em jogo! O armazenamento em cache diz ao servidor para armazenar alguns arquivos em disco ou RAM, dependendo da configuração. Ou seja, ele pode recordar e duplicar o mesmo conteúdo que tem apresentado no passado. Basicamente, isso reduz a quantidade de trabalho necessária para gerar uma exibição de página. Como consequência, as suas páginas web carregam muito mais rápido, diretamente a partir do cache.

Alguns outros benefícios do armazenamento em cache incluem:

• Seu servidor utiliza menos recursos– Isso está associado à velocidade, já que menos recursos geram um site mais rápido. Contudo, também coloca menos pressão no seu servidor. Isso é muito importante quando para sites altamente dinâmicos, como sites de filiação, e determina o que você pode e não pode servir a partir do cache.
• Você terá um TTFB mais baixo – O cache é uma das formas mais fáceis de diminuir o TTFB.De fato, nos nossos testes, o cache normalmente reduz o TTFB em até 90%!

Tipos de cache

Em relação aos tipos de cache, existem duas abordagens diferentes que são habitualmente utilizadas

1. Cache no nível do servidor
2. Cache através de um Plugin

1. Cache no no Nível do Servidor

O armazenamento em cache no nível do servidor é claramente uma das abordagens mais simples para o usuário final. Isso é o mesmo que dizer que será que o provedor de hospedagem WordPress a lidar com o assunto. Na Kinsta, somente utilizamos esses quatro tipos de cache, que são todos feitos automaticamente no software ou no nível do servidor:

• Bytecode cache
• Object cache
• Page cache
• CDN cache

Ou seja, você não precisa de se preocupar em ficar ajustando com qualquer plugin de cache mais complicado.  Você pode parar de ficar buscando os “melhores plugins de cache”, em vez disso se concentre em tarefas mais produtivas. 👏

An instant 37% reduction in the loading time after moving @WPColt to @kinsta! (NO CACHING PLUGINS) 🚀🚀🚀

— WPColt (@WPColt) January 3, 2018

O cache de páginas está configurado para funcionar imediatamente com o WordPress padrão. Você não precisa fazer nada! Basta iniciar seu site WordPress e o cache de páginas entrará em atividade.
Temos também regras de armazenamento em cache para sites de eCommerce como o WooCommerce e Easy Digital Downloads. Por padrão, existem páginas que nunca devem ser armazenadas em cache, como o carrinho de compras, minha-conta e checkout, as quais são excluídas do armazenamento em cache. Os usuários pulam automaticamente o cache quando o cookie woocommerce_items_in_cart ou edd_items_in_cartsão detetados para garantir um processo de checkout simples e sincronizado.

Você pode facilmente limpar o cache do seu site WordPress a qualquer momento na barra de ferramentas do administrador.

Também está integrado no nosso painel MyKinsta. Basta clicar em Ferramentas e depois em “Limpar Cache”.

2. Cache através de um Plugin

Se o seu provedor de hospedagem não oferece a opção de cache, você pode usar um plugin de cache de terceiros para WordPress. Com base na nossa experiência, recomendamos um desses:

1. WP Rocket (premium)
2. Cache Enabler (gratuito)
3. W3 Total Cache (gratuito)

Também pode consultar algumas opções adicionais no nosso artigo aprofundado sobre os plugins de cache do WordPress.

Também suportamos totalmente o WP Rocket na Kinsta! De uma forma geral, não permitimos a utilização de plugins de cache, já que eles entram em conflito com nossa solução de cache integrado. Contudo, a funcionalidade de cache de páginas do WP Rocket 3.0 será automaticamente desativada quando os servidores da Kinsta forem utilizados.

Isso permite que os clientes da Kinsta utilizem nosso cache rápido no nível do servidor, aproveitando ao mesmo tempo os fantásticos recursos de otimização que o WP Rocket tem a oferecer.

Sem Cache vs Com Cache

Quão útil é o cache? A prova está no pudim.

Executámos alguns testes de velocidade com o cache no nível do servidor da Kinsta para que possa ver a diferença, tanto em velocidade geral como em TTFB.

Sem Cache

Primeiro fizemos cinco testes no Pingdom sem o cache ativado e obtivemos a média.

TTFB sem cache

Também é importante ver a diferença no TTFB com e sem cache. O TTFB no Pingdom é representado pela barra amarela de “espera”. Como você pode ver, o TTFB sem cache é de 192 ms. Você pode notar que o cache não está sendo usado, já que o cabeçalho intitulado x-kinsta-cache é designado por MISS.

Com o cache ativado

Depois, ativámos o cache no nível do servidor e fizemos cinco testes no Pingdom e obtivemos a média.

Como pode ver o cache no nível do servidor diminuiu o tempo de carregamento da nossa página em 33.77%! E isso sem qualquer trabalho extra. Esse site que testámos também está bem otimizado, ou seja, sites maiores e não otimizados irã ver diferenças ainda maiores.

TTFB com Cache Ativado

Se virmos agora o TTFB com o cache ativado, notamos que ele está abaixo de 35 ms. Você pode ver também que o cache está sendo usado, já que o cabeçalho x-kinsta-cache é designado por HIT.

O cache do CDN é também tão importante quanto o cache do seu host WordPress. Abaixo daremos mais detalhes sobre os CDNs.

Problemas com Cache e Sites de Filiação

Os sites de filiação têm muito conteúdo não cacheável e páginas que mudam constantemente. Elementos como página de login para membros da comunidade (que podem ser ter acessos constante dependendo do tamanho do site), páginas de checkout para produtos ou cursos digitais e fóruns de discussão são os culpados e problemas comuns, já que normalmente não podem ser armazenados em cache.

Contudo, o problema não fica por aí. Em sites WordPress normais, o painel WordPress também não é armazenado em cache para usuários “logados”. Isso é positivo quando você tem apenas alguns autores e administradores, mas, quando tem subitamente milhares de membros usando o painel, os problemas de desempenho surgem de imediato, já que nenhum deles pode ser exibido a partir do cache no servidor. Isso é o mesmo que dizer que você precisará de ter a capacidade e a arquitetura certa nos bastidores para garantir o backup. Os provedores de hospedagem compartilhada ficam normalmente paralisados nessas circunstâncias.

Cache de Objetos para Sites Altamente Dinâmicos

Para sites de filiação WordPress, suas configurações de cache habituais geralmente são insuficientes, já que raramente tiram total partido disso. É aqui que o cache de objetos entra em jogo.

O cache de objetos armazena os resultados das consultas à base de dados para que, na próxima vez em que esse dado específico seja necessário, ele possa ser entregue a partir do cache sem consultar novamente a base de dados. Isso acelera os tempos de execução do PHP e reduz a carga no seu base de dados. Isso é muito extremamente em sites de filiação! Com o WordPress, você pode implementar o cache de objetos de duas formas diferentes:

1. Uma solução de cache de terceiros como o W3 Total Cache
2. Redis (recomendado)
3. Memcached

Oferecemos o Redis como complemento na Kinsta, para que possa aproveitar ao máximo o armazenamento em cache de objetos persistentes em seus sites de associação.

Analisando o Cache

Você lembra do cabeçalho x-kinsta-cache que mencionámos acima? Dependendo do seu provedor de hospedagem ou da solução de cache, o cabeçalho poderá apresentar um nome ligeiramente diferente. Sempre que uma solicitação é feita a partir do seu site WordPress, esse cabeçalho tem um valor, como HIT, BYPASS, MISS e EXPIRED. Isso permite que você veja o desempenho do seu cache.

Aumentar a taxa de acertos de cache do seu site WordPress é importante, já que você quer que que o seu site seja apresentado a partir do cache tanto quanto possível. Na Kinsta você pode analisar os dados através das nossa ferramenta de análise MyKinsta e os registros de cache kinsta para determinar se existem solicitações GET em BYPASS no cache que podem ser depositadas no cache ou solicitações POST que podem ser eliminadas.

A pilha do componente de cache (como exibida abaixo) permite ver o estado de cada solicitação, seja HIT, BYPASS, MISS ou EXPIRED. Você pode filtrar os dados nas últimas 24 horas, 7 dias ou 30 dias.

O gráfico dos componentes de cache oferece para você uma perspetiva da sua taxa de armazenamento em cache. Quanto mais solicitações você servir a partir do cache, melhor. Como você pode ver no exemplo abaixo, esse site WordPress tem em uma taxa de cache de 96.2% HIT. O que é bom!

A seção dedicada aos principais bypasses de cache permite que você veja quais solicitações não estão sendo apresentadas a partir do cache. Geralmente, podem incluir tarefas CRON, solicitações admin-ajax, páginas de checkout de eCommerce, cadeias de consulta e parâmetros UTM, etc.

A Otimização de Imagens é Uma Obrigação

A otimização de imagens é outra coisa simples que você pode fazer e que tem um impacto significativo nos tempos totais de carregamento da página. Isso não é algo opcional; qualquer site deveria estar fazendo isso!

As imagens de grandes dimensões diminuem a velocidade das suas páginas web, o que cria uma experiência de usuário inferior ao ideal. Otimizar imagens é o processo que diminui o tamanho do arquivo, usando um plugin ou script, o que depois acelera o tempo de carregamento da página. A compressão com perdas e sem perdas são dois métodos habitualmente utilizados.

De acordo com o HTTP Archive, em novembro de 2018 as imagens perfazem, em média, 21% do peso total de uma página web. Então, depois dos vídeos, que são bem mais complicados de otimizar, as imagens são claramente o primeiro lugar onde deve começar! Isso é mais importante que o JavaScript, CSS e Fonts. E, ironicamente, um bom fluxo de trabalho de otimização de imagens é uma das coisas mais fáceis de implementar, mas muitos proprietários de sites ignoram esse passo.

Em dezembro de 2017, as imagens, em média, constituíam 54% do peso total de uma página. Como podemos ver, parece que a web como um todo está melhorando na otimização de imagens! Mas 21% ainda é um número que não pode ser ignorado. Se você não tiver qualquer conteúdo em vídeo no seu website, as imagens continuarão sendo o seu principal problema.

Encontrando o Equilíbrio (Tamanho e Qualidade do Arquivo)

O principal objetivo da formatação de suas imagens é descobrir o ponto de equilíbrio entre o menor tamanho de arquivo e uma qualidade aceitável. Existe mais do que um método para executar quase todas essas otimizações. Uma das maneiras mais simples é comprimir as imagens antes de fazer o upload para o WordPress. Geralmente, isso pode ser feito através de uma ferramenta como o Adobe Photoshop ou o Affinity Photo. Ou usando utilizando o novo aplicativo Squoosh do Google. Contudo, essas tarefas também podem ser executadas automaticamente através de plugins, das quais falaremos mais abaixo.

As duas principais coisas a ter em consideração são o formato de arquivo e o tipo de compressão que você usa. Ao escolher a combinação certa entre formato de arquivo e tipo de compressão, poderá reduzir o tamanho da sua imagem em até 5 vezes. Terá de experimentar cada imagem ou formato de arquivo para ver o que funciona melhor.

Antes de sair modificando as suas imagens, verifique se escolheu o melhor tipo de arquivo. Existem vários tipos de arquivos que pode usar:

• PNG – produz imagens de qualidade superior, mas também tem um tamanho de arquivo maior. Foi criado como um formato de imagem sem perdas, embora também possa ser usado com perdas.
• JPEG – utiliza uma otimização com perdas e sem perdas. Você pode ajustar o nível de qualidade para obter um bom equilíbrio entre qualidade e tamanho do arquivo.

Idealmente, você deve usar JPEG (ou JPG) para imagens com muita cor e PNG para aquelas imagens mais simples.

Você também deve considerar o uso de imagens WEBP em seu website.

E os GIFs? Os GIFs animados são sempre divertidos, mas aniquilam o desempenho web. Muitos GIFs têm mais de 1 MB. Recomendamos que mantenha esses nas redes sociais e Slack. Se tiver um que seja essencial para a sobrevivência do seu blog, dê uma olhada em como comprimir GIFs animados.

Qualidade vs. Tamanho de Compressão

Eis um exemplo do que pode acontecer quando você comprime demais uma imagem. A primeira está usando uma taxa de compressão muito baixa, o que resulta em qualidade mais alta (mas também em um tamanho de arquivo maior). A segunda usa uma taxa de compressão muito alta, o que resulta em uma imagem de baixa qualidade (mas com tamanho de arquivo menor). Nota: A imagem original é de 2.06 MB.

Como você pode ver, a primeira imagem tem 590 KB. Isso é muito grande para uma foto! Você deve manter o peso total de uma página da web inferior a 1 ou 2 MB. 590 KB já representaria um quarto disso. A segunda imagem parece horrível, mas tem apenas 68 KB. O que você pretende é um bom equilíbrio entre a sua taxa de compressão (qualidade) e o tamanho do arquivo.

Então o que fizemos foi pegar na imagem novamente e aplicar uma taxa de compressão média e como, pode ver abaixo, a qualidade parece boa, e o tamanho do arquivo é de 151 KB, aceitável para uma foto de alta resolução. Isso é quase 4x menor do que a foto original com baixa compressão. Tentamos manter a maioria das nossas imagens abaixo da marca de 100 KB para garantir o melhor desempenho.

Otimização Com Perdas vs. Sem Perdas

É igualmente importante compreender que existem dois tipos de compressão que poderá usar, com e sem perdas.

A compressão com perdas passa por eliminar alguns dos dados na sua imagem. Por causa disso, você pode notar degradação (redução na qualidade ou o que alguns chamam de imagem pixelizada). Então você precisa tomar cuidado com o quanto você está reduzindo sua imagem. Não só devido à qualidade, mas também porque não pode reverter o processo. Obviamente, uma das grandes vantagens da compressão com perdas, e o porquê de ser um dos métodos de compressão mais populares, é que você pode reduzir consideravelmente o tamanho do arquivo.

A compressão sem perdas, ao contrário daquela com perdas, não reduz a qualidade da imagem. Como isso é possível? Normalmente isso é feito removendo metadados desnecessários (dados gerados automaticamente pelo dispositivo que capturou a imagem). Contudo, a maior desvantagem desse método é não terá uma redução significativa no tamanho do arquivo. Ou seja, vai ocupar muito espaço em disco ao longo do tempo.

Vale a pena experimentar aquilo que funciona melhor com você. Mas, para a maioria dos usuários, recomendamos usar a compressão com perdas pois permite facilmente comprimir uma imagem bem acima de 70% (às vezes até acima de 90%!) sem muita perda de qualidade. Multiplique isso por 15 imagens em uma página e isso terá um papel importante na redução do tempo de carregamento do seu site.

Plugins de Compressão de Imagens

A boa notícia é que existem alguns plugins de compressão de imagem para WordPress que pode usar para automatizar todo o processo. Aqui ficam alguns plugins que recomendamos:

• Imagify (com perdas e sem perdas – otimiza imagens externamente)
• WP Smush (com perdas e sem perdas – otimiza imagens externamente)
• Optimole (com perdas e sem perdas – otimiza imagens externamente)

O mais importante no momento em que você escolhe um plugin de otimização de imagem é usar um que comprima e otimize imagens externamente nos seus servidores. Isso, por sua vez, reduz a carga no seu site. Todos os plugins acima fazem isso.

Se você tem curiosidade sobre isso, Usamos o plugin Imagify no site da Kinsta. Ele comprime imagens automaticamente quando as carregamos para a biblioteca de mídia do WordPress. Então a gente nem precisa de se preocupar com nada. Com o tempo, você pode perceber o nível de compressão da imagem que pretende usar. Ele oferece as opções Normal, Agressivo e Ultra.

Utilizamos o modo Agressivo na Kinsta e isso garante normalmente uma poupança de 60-70% dependendo da imagem. Nota: Utilizamos muito mais PNGs do que JPEGs, já que a maioria das nossas imagens são ícones e ilustrações, e não fotos.

Quão mais rápido ficará seu site WordPress se você usar a compressão de imagem? Tudo depende dos tamanhos das suas imagens originais e de como elas ficam após a compressão. Contudo, efetuámos alguns testes de velocidade e descobrimos que uma solução de compressão de imagem de qualidade pode diminuir os tempos de carregamento da página em mais de 80%!

Carregamento Lento

Se você tem muitas imagens, pode considerar optar pelo carregamento lento. Essa é uma técnica de otimização que carrega apenas o conteúdo visível ao usuário, mas atrasa o download e a renderização do conteúdo que aparece abaixo da dobra.

Confira nosso guia sobre como implementar o carregamento lento no WordPress. Pode ser uma técnica importante em posts de blog com muitos ícones gravatar em comentários. O Google também acaba de lançar sua recomendações para carregamento lento.

Dicas Adicionais de Otimização de Imagens

Ficam aqui algumas dicas finais de otimização de imagens.

• O tempo em que fazia o upload de imagens dimensionadas apenas para a largura da coluna ou DIV terminaram. As imagens responsivas estão além disso (desde a versão 4.4) e exibirão automaticamente os tamanhos de imagem menores para usuários móveis.
• Os SVGs podem ser outra excelente alternativa à utilização de imagens.Todas as ilustrações desenhadas à mão que você vê no site da Kinsta são SVGs (vetores). Os SVGs são normalmente muito menores em tamanho, embora nem sempre. Confira nosso tutorial sobre como usar SVGs no seu site WordPress.
• Use fontes de ícones em vez de colocar texto nas imagens –elas ganham um melhor aspeto quando dimensionadas e ocupam menos espaço.E, se você usar um gerador de fontes, poderá ganhar ainda mais na otimização. Confira a forma como diminuímos o tamanho das nossas fontes de ícones em uns fantásticos 97.59% utilizando um gerador de fontes.

Ajuste Sua Base de Dados

Chegou o momento de ver algumas dicas sobre como ajustar sua base de dados WordPress. Assim como acontece com um carro, sua base de dados precisa de manutenção, já que com o tempo ela pode aumentar de tamanho.

Os sites de filiação são particularmente complicados, já que normalmente geram consultas mais complexas, o que, por sua vez, acrescenta latência na recuperação das informações da base de dados MySQL. Muito disso se deve a todas as partes móveis adicionais e às grandes quantidades de sites de dados como esses costumam ter. Isso também pode ser provocado por sites que dependem muito de consultas de busca para navegação ou que utilizam o WP_Query.

Isso sem falar que você também pode ter grandes quantidades de usuários consultando em simultâneo e de forma contínua a base de dados.

Utilize o Motor de Armazenamento InnoDB para o MySQL

Muitos sites antigos seguem usando o mecanismo de armazenamento MyISAM para sua base de dados. Nos últimos anos, o InnoDB demonstrou um melhor desempenho e é mais confiável.

Aqui ficam algumas vantagens do InnoDB em relação ao MyISAM:

• O InnoDB permite bloquear linhas.O MyISAM apenas garante o bloqueio total de tabelas. Isso permite que suas consultas sejam processadas mais rapidamente.
• O InnoDB tem aquilo que é designado por integridade referencial, que envolve o suporte a chaves externas(RDBMS) e restrições de relacionamento, o que não acontece com o MyISAM (DMBS).
• O InnoDB suporta transações, o que significa que você pode usar os comandos commit e rollback.O MyISAM não possibilita isso.
• O InnoDB é mais fiável, já que utiliza registros transacionaispara recuperação automática. O MyISAM não.

Eis a pergunta que pode estar passando na sua cabeça nesse momento: vocês estão executando o InnoDB ou o MyISAM? Se você estiver comandando um site relativamente novo em WordPress, provavelmente já estará usando o motor de armazenamento InnoDB para MySQL. Mas, com sites mais antigos do WordPress, o melhor é você fazer uma verificação rápida. Alguns sites podem até ter misturado e combinado as tabelas MyISAM e InnoDB, situação na qual você pode ter melhorias se decidir converter tudo.

Siga esses simples abaixo para verificar a situação.

Passo 1

Entre no phpMyAdmin e clique na sua base de dados MySQL.

Passo 2

Faça uma análise rápida ou organize de acordo com a coluna “Tipo” e você poderá ver os tipos de Motores de Armazenamento que as suas tabelas estão usando. No exemplo abaixo, você pode ver que duas das tabelas ainda estão usando o MyISAM.

Excluir e Limitar as Revisões de Páginas e Artigos

Sempre que você salva uma página ou um artigo no WordPress, ela cria aquilo que é designado por revisão. Isso acontece em rascunhos e postagens já publicadas que foram atualizadas. As revisões podem ser úteis caso você precise reverter para uma versão anterior do seu conteúdo.

Contudo, as revisões podem também prejudicar o desempenho do seu site WordPress. Em grandes sites, isso poderá rapidamente adicionar milhares de linhas à sua base de dados que não são necessariamente necessárias. E, quanto mais linhas você tiver, maior será o tamanho da sua base de dados, que ocupa espaço de armazenamento. Embora os índices tenham sido criados para esse propósito, percebemos que esse problema continua prejudicando os sites WordPress. Existem algumas coisas que você pode fazer.

1. Excluir Revisões Antigas

Se você possui um site WordPress antigo com muitas páginas e artigos, talvez tenha chegado o momento de fazer uma limpeza rápida e excluir essas revisões antigas. Você pode fazer isso com o MySQL, mas com todos os fragmentos de código flutuando por aí na web, recomendamos fazer um backup do seu site e utilizar um plugin gratuito como o WP-Sweep.

Outro dos nossos plugins favoritos, o WP Rocket, tem também um recurso de otimização de base de dados para excluir as revisões.

Se você sabe como mexer no WP-CLI, existem alguns comandos que pode usar para isso.

Entre no seu servidor via SSH e execute o seguinte comando para obter e ver o número de revisões atualmente na base de dados.

wp revisions list

Se encontrar um erro, talvez seja necessário instalar primeiro o wp-revisions-cli package  com o seguinte comando:

wp package install trepmal/wp-revisions-cli

Você depois pode executar o seguinte comando para limpar as revisões:

wp revisions clean

2. Limite de revisões

Outra boa estratégia, que usamos na Kinsta, é limitar o número de revisões que pode ser armazenado por postagem ou página. Mesmo que você configure para um valor como dez, isso já será suficiente para manter as revisões sob controle, especialmente se você fizer muitas atualizações.

Para limitar as revisões, você pode adicionar o seguinte código ao seu arquivo wp-config.php. O código abaixo precisa de ser inserido acima do ‘ABSPATH’, caso contrário não funcionará. Você pode alterar o número para de revisões para qualquer um que deseja armazenar na base de dados.

define('WP_POST_REVISIONS', 10);

Ou pode utilizar um plugin como o Perfmatters para limitar as revisões.

3. Desativar Revisões

E, por último, mas igualmente importante, pode também desativar por completo as revisões em seu site. Se você optar por isso, é altamente recomendável seguir a primeira opção acima para excluir as revisões e, depois disso, fazer a sua desativação. Assim, sua base de dados ficará totalmente livre de todas as revisões antigas e nenhuma nova será adicionada daqui para frente.

Para desabilitar as revisões, você pode adicionar o seguinte código ao seu arquivo wp-config.php O código abaixo precisa de ser inserido acima do ‘ABSPATH’, caso contrário não funcionará.

define('WP_POST_REVISIONS', false);

Ou pode utilizer um plugin como o Perfmatters para desativar as revisões.

Limpar a Sua Tabela wp_options e Dados carregados automaticamente

A tabela wp_options muitas vezes cai em esquecimento quando o assunto é o desempenho geral do WordPress e da base de dados. Especialmente em sites antigos e grandes, esse questão pode ser facilmente a culpado por tempos de consulta lentos devido aos dados que são carregados automaticamente provocados por plugins e temas de terceiros. Confie; a gente encontra situações dessas todos os dias!

A tabela wp_options contém todos os tipos de dados para o seu site WordPress, como:

• URL do site, URL inicial, email do administrador, categoria padrão, postagens por página, formato de hora,
• Configuraçõespara plugins, temas, widgets
• Dados temporariamente armazenados em cache

Essa tabela contém os seguintes campos (colunas):

• option_id
• option_name
• option_value
• autoload(esse é aquele que valorizamos em relação ao desempenho)

Uma das coisas importantes que você deve entender sobre a tabela wp_options é o campo autoload. Isto contém um valor sim ou não (sinalização). Isso resumidamente controla se isso é ou não carregado pela função wp_load_alloptions(). Os dados carregados automaticamente são dados que são carregados em todas as páginas do seu site WordPress. Assim como mostrámos para você como pode desativar determinados scripts do carregamento em todo o site, a mesma ideia se aplica aqui. O atributo carregamento automático está definido como “sim” por padrão para os desenvolvedores, mas nem todos os plugins devem teoricamente carregar seus dados em todas as páginas.

O problema que os sites do WordPress podem encontrar é quando existe uma grande quantidade de carregados na tabela wp_options. Isso normalmente é o resultado de uma das causas seguintes:

• Os dados estão sendo carregados automaticamente por um plugin quando deveria estar definidos como “não”. Um bom exemplo disso seria um plugin de formulário de contato. Será que ele precisa de carregar dados em todas as páginas ou apenas na página de contato?
• Os pllugins ou temas foram removidos do site WordPress, mas suas opções seguem existindo na mesa wp_options. Isso pode significar que os dados são carregados automaticamente de forma desnecessária em cada solicitação.
• Os desenvolvedores de plugins e de temas estão carregando dados para a tabela wp_options em vez de utilizarem suas próprias tabelas. Existem argumentos para quem é a favor e contra, já que alguns desenvolvedores preferem plugins que não criam tabelas adicionais. No entanto, a tabela wp_options  não foi desenhada para armazenar milhares de linhas.

Quando é que os dados carregados automaticamente são demasiados? É claro que isso pode variar, mas, idealmente, você quer que o valor se situe entre 300 KB e 1 MB. Quando você começa a se aproximar da faixa de 3 a 5 MB ou mais, provavelmente existem coisas que podem ser otimizadas ou removidas para não serem carregadas automaticamente. E qualquer coisa acima de 10 MB deve ser resolvida imediatamente. Isso nem sempre significa vai causar um problema, mas é um bom ponto de partida.

Tendo em conta a importância do problema, temos um tutorial separado que você vai querer ler sobre como solucionar problemas de dados carregados automaticamente da melhor forma e também como fazer a sua limpeza.

Limpar Transientes

A menos que você esteja usando um cache de objetos, o WordPress armazena registros na tabela wp_options. Normalmente, eles recebem um prazo de validade e desaparecem com o tempo. Contudo, isso nem sempre acontece. Já encontrámos algumas bases de dados onde existem milhares de registros temporários antigos. Na verdade, em um site, encontrámos registros transitórios corruptos em que mais de 695.000 linhas foram geradas na tabela wp_options. Credo!

É também importante notar que os transientes não são carregados automaticamente por padrão. Você pode usar uma consulta como essa abaixo para saber se existem dados transitórios carregados automaticamente.

SELECT * 
FROM `wp_options` 
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%transient%'

Uma opção melhor e mais segura seria utilizar um plugin gratuito como o Transient Cleaner ou o Delete Expired Transients que podem limpar somente os transientes expirados da sua tabela wp_options. Ainda assim, parece que existe agora uma função em WordPress, adicionada no 4.9, que limpa os transientes expirados. Esperamos que isso já esta acontecendo automaticamente no se usite.

O WP Rocket também possui a capacidade de limpar transientes nas suas opções de otimização para a base de dados.

Limpar Sessões WordPress

Outro problema comum que por vezes encontramos são as tarefas cron não sincronizadas ou que não são acionadas corretamente e, devido a isso, as sessões não podem ser limpas. Você pode acabar por acumular toneladas de linhas da _wp_session_ na sua base de dados. No exemplo abaixo, o site tinha mais de 3 milhões de linhas na tabela wp_options. E a tabela aumentou para mais de 600 MB.

Você pode usar uma consulta como essa abaixo para saber se está tendo esse problema:

SELECT *
FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'

Na maioria das situações, você pode excluir essas linhas com segurança (o que deveria ser feito pela tarefa cron) com o seguinte comando:

DELETE FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'

Após limpar todos os restos em _wp_session_ rows a tabela ficou com menos de 1,000 linhas e foi reduzida para 11 MB de tamanho.

Também corrigiu os picos que o site estava tendo no MySQL.

Adicionar um Índice ao Carregamento Automático

Se limpar a sua table wp_options não foi suficiente, você pode tentar adicionar um “índice” no campo de carregamento automático. Isso pode ajudar você a ser encontrado de forma mais eficiente. A incrível equipe da 10up criou alguns cenários de teste em uma tabela wp_options com um número típico de registros carregados automaticamente para mostrar como adicionar um índice de carregamento automático às consultas wp_options pode aumentar o desempenho.

Também recomendamos verificar esses dois recursos adicionais do WP Bullet:

• Como Adicionar o Índice MySQL à tabela wp_options
• Limpar a tabela wp_options utilizando o WP-CLI

Utilizar Redis como um Cache de Objetos Persistentes para o WordPress

O Redis é um armazenamento open-source de estruturas de dados colocadas em memória. No contexto do WordPress, o Redis pode ser usado para armazenar os valores gerados persistentemente pelo cache de objetos nativos do WordPress, para que os objetos em cache possam ser reutilizados entre os carregamentos de página.

Utilizar um cache de objeto persistente como o Redis permite a reutilização de objetos em cache em vez de exigir que a base de dados MySQL seja consultada uma segunda vez para o mesmo objeto. O resultado é que o Redis pode reduzir a carga na base de dados do MySQL de um site, diminuindo ao mesmo tempo o tempo de resposta do site e aumentando a capacidade do site para dimensionar e manipular tráfego adicional.

Sites altamente dinâmicos (WooCommerce, sites de filiação, fóruns, fóruns de discussão, blogs com sistemas de comentários muitos ativos) que não podem fazer bom uso do cache de páginas são potenciais candidatos para uma opção de cache de objeto persistentes como o Redis.

Se você é um cliente Kinsta, oferecemos um add-on Redis. Veja como adicionar o Redis ao seu plano de hospedagem.

Utilize o Elasticsearch para Acelerar A Busca no WordPress

O Elasticsearch é um motor de busca open-source para texto. É utilizado para indexar dados e buscar esses mesmos dados de forma incrivelmente rápida.

No contexto do WordPress, o Elasticsearch pode ser utilizado para acelerar a consulta da base de dados do WordPress. Isso é feito criando um índice do conteúdo da base de dados do seu site e, depois, usando o Elasticsearch para procurar nesse índice muito mais rapidamente do que aquilo que aconteceria com uma consulta MySQL.

Se você tiver tempo e capacidade, o Elasticsearch pode ser integrado em um website WordPress por um desenvolver altamente qualificado em WordPress e Elasticsearch. Se o seu site utiliza de forma relativamente standard o WP_Query, então o Elasticsearch também pode ser integrado instalando o ElasticPress, um plugin gratuito para WordPress da 10up, disponível no WordPress.org, que é integrada automaticamente no objeto WP_Query para gerar resultados de consulta com o Elasticsearch em vez do MySQL.

Qualquer site que utiliza o WP_Query pode beneficiar do Elasticsearch. Exemplos de sites que podem se beneficiar do Elasticsearch:

• Sites onde a busca é o principal meio de navegação.
• Sites de WooCommerce com um elevado número de pedidos onde os administradores do site precisam de procurar regularmente a lista de pedidos.
• Qualquer site com um elevado número de posts onde as consultas do MySQL estão produzindo resultados demasiado lentos.

Desativar Recursos Não Críticos que Exigem Muito da Base de Dados

Isto pode parecer um pouco óbvio, mas pode fazer uma grande diferença se você desativar plugins não críticos e recursos de temas que são intensivos em banco de dados.

• Widgets e plugins populares e ou relacionados são horríveis. Eles normalmente têm consultas pesadas em todo o site.
• Plugins de otimização de imagens que comprimem imagens usando o seu servidor. Você deve sempre usar um plugin de otimização de imagem que otimize as imagens externamente.

Se visitar o blog Kinsta e deslizar para baixo até ao fim de uma postagem, você notará que temos aquilo que designamos por artigos relacionados “escolhidos a dedo”. Esses são selecionados por nós manualmente e atribuídos à postagem em específico. Isso reduz a consulta a quase nada e não prejudicará o desempenho de todo o site. Demora mais? Sim, mas pode ser ainda melhor, já que você pode escolher o que pretende que os leitores vejam.

Então, como conseguimos fazer isso? Utilizamos o fantástico plugin Advanced Custom Fields e depois atribuímos esses campos ao nosso tipo de postagem no blog. Isso permite que a gente busque e atribua qualquer conteúdo relacionado que quisermos a cada uma das postagens do nosso blog (como podemos ver abaixo).

Recomendamos também ficar longe de plugins que adicionem um contador de visualizações/postagens ao seu site, a menos que você precise disso. Por exemplo, evite coisas como “792 postagens”, que fica aparecendo do lado do avatar de um usuário em postagens no fórum, ou “5.243 visualizações” ao listar as postagens no fórum. Quando você tem uma longa discussão, esses contadores terão um enorme impacto na sua base de dados. De forma geral, minimize a utilização de contadores e apenas os utilize quando for estritamente necessário.

Isso também serve para contadores sociais. Por exemplo, no site abaixo você pode ver que o tempo de resposta do conhecido plugin Social Warfare é 30 vezes maior do que o plugin seguinte. O cache está ativado, mas, obviamente, esse plugin tem uma considerável quebra de desempenho. Depois de desativar o plugin no site, os tempos de carregamento melhoraram instantaneamente e a capacidade de resposta do painel de administração do WordPress melhorou também.

Utilizar uma Rede de Entrega de Conteúdo (CDN)

CDN é a abreviação para rede de entrega de conteúdo. São redes de servidores (também conhecidos como POPs) localizados em todo o mundo. Estão desenhados para hospedarem e distribuírem cópias do conteúdo estático (e por vezes dinâmico) do seu site WordPress, como imagens, CSS, JavaScript e transmissões de vídeo.

Antes de qualquer outra coisa, você não deve confundir o CDN com seu host WordPress. São serviços totalmente separados. Um CDN não é um substituto para o seu provedor de hospedagem, mas sim uma forma adicional de aumentar a velocidade do seu site. Enquanto nossa hospedagem aqui na Kinsta é bem rápida, um CDN pode tornar seu site ainda mais veloz.

Como Funciona um CDN

Como um CDN funciona exatamente? Bom, por exemplo, quando você hospeda seu site com Kinsta, você precisa escolher a localização do centro de dados, como EUA, Europa, Ásia-Pacífico ou América do Sul.

Partamos do princípio que você escolhe a área central dos EUA. Isso significa que seu site está fisicamente localizado em um “servidor de alojamento” em Council Bluffs, Iowa. Quando as pessoas na Europa visitam o seu site, elas demorarão mais tempo para fazer o carregamento do que alguém que o visite, por exemplo, a partir de Dallas, Texas.

Porquê? Porque os dados necessitam percorrer uma distância maior. Isso é a latência. A latência diz respeito ao tempo e/ou atraso que está envolvido na transmissão de dados através de uma rede. Quanto mais distante a distância, maior a latência.

Tipos de CDNs

Existem dois tipos diferentes de redes de distribuição de conteúdo:

1. CDN pull tradicional
2. CDN de Proxy Reverso

Os CDNs pull tradicionais colocam em cache uma cópia de todo o seu conteúdo e mídia, mas uma solicitação do cliente continua sendo feita diretamente ao seu provedor de hospedagem. O KeyCDN e o CDN77 são exemplos de CDNs tradicionais.

Um CDN de proxy reverso é um pouco diferente. Apesar de agir também como um CDN, ele intercepta todos os pedidos recebidos e atua como um servidor intermediário entre o cliente e seu host. Cloudflare e Sucuri são exemplos de CDNs de proxy reverso. Essa é uma das razões pelas quais você precisa direcionar seu DNS para esses provedores em vez de fazer isso para o seu host.

A vantagem nisso é que eles agem como um servidor intermediário, podem facultar fortes firewalls para aplicativos web que podem ajudar a impedir que tráfego ruim entre no seu site WordPress ou no provedor de hospedagem. Uma desvantagem é que eles têm um pouco de sobrecarga adicional em termos de desempenho em comparação com um CDN pull tradicional. Mas com recursos adicionais de desempenho e segurança, isso pode ser insignificante.

Abaixo você tem um exemplo do que aconteceu após a ativação do Sucuri no site de um cliente. Como você pode ver, isso teve um impacto enorme na quantidade de tráfego ruim que entrou no site. No final, esses tipos de serviços podem ajudar você a economizar nos seus custos de hospedagem.

Testes de Velocidade CDN

Já falámos sobre as grandes vantagens do cache WordPress. Bom, o cache do CDN também é muito potente. Isso ocorre porque os CDNs normalmente têm um número de localizações de servidor muito superior aos provedores de hospedagem. Isso significa que eles podem colocar em cache todos os seus recursos (imagens, JS, CSS) em um local mais perto de seus visitantes e fazer com que sejam apresentados em velocidades extremamente rápidas.

Façamos alguns testes rápidos para ver quanto mais rápido seu site pode ficar com um CDN.

Sem CDN

O nosso website de teste está hospedado na Kinsta e localizado fisicamente no centro de dados de Iowa, EUA. Primeiro efetuámos cinco testes de velocidade no Pingdom (sem o CDN ativado) e obtivemos a média. Importante: Estamos usando a localização Europa – Reino Unido – Londres no Pingdom para demonstrar o verdadeiro poder de um CDN. O tempo total de carregamento foi de 1.03 s.

Com CDN

Depois ativámos o nosso CDN e fizemos cinco testes de velocidade adicionais no Pingdom. O nosso tempo total de carregamento é agora de 585 ms para a localização de teste em Europa – Reino Unido – Londres no Pingdom. Então, quando usámos o CDN, fomos capazes de diminuir os nossos tempos de carregamento da página por 43.2%! Isso é algo enorme.

A razão para essa enorme diferença é que o CDN tem um centro de dados em Londres. Isso significa que todos os ativos são armazenados em cache nesse local e prontos para serem mostrados com latência mínima.

TTFB sem CDN

Você lembra que a barra amarela no Pingdom significa tempo de espera, que é o tempo até ao primeiro byte (TTFB). Nos nossos testes de velocidade sem o CDN, a execução do TTFB médio em ativos estava próxima a 98 ms.

TTFB com CDN

Após ativarmos o CDN, o TTFB médio dos ativos caiu para uma média de 15 ms. Então, com um CDN, o nosso TTFB médio caiu 84,69%. Isso ocorre principalmente porque os ativos estavam sendo apresentados diretamente a partir do cache do CDN.

Como Ativar um CDN

Ativar um CDN no seu site WordPress não precisa ser algo complicado, é bem fácil até! Apenas siga esses passos.

Passo 1

Selecione um provedor de CDN e subscreva o serviço. Normalmente a cobrança é feita mensalmente ou com base na utilização de dados. A maioria dos provedores terá uma calculadora para estimar seus custos.

• Se quiser implementar o KeyCDN, recomendamos a leitura desse artigo CDN para principiantes. Cada provedor de CDN também deve ter documentação para ajudar você a começar.
• Temos tutoriais detalhados sobre como instalar o Cloudflare e como instalar o Sucuri.

Passo 2

Se você estiver usando um CDN pull tradicional, pode utilizar o plugin gratuito como o CDN Enabler, WP Rocket ou Perfmatters para integrar no seu site WordPress. Esse plugins ligam automaticamente os seus ativos ao CDN. Você não precisa fazer mais nada para ter o seu conteúdo no CDN; pode descansar! Os CDNs de proxy reverso normalmente não exigem plugins, embora por vezes tenham alguns que permitem ativar recursos adicionais.

Como Ativar o CDN da Kinsta

Você gostou dos testes de velocidade CDN que mostrámos acima? Nós estávamos usando o KeyCDN nesses testes. A grande notícia é que o nosso CDN da Kinsta é alimentado por KeyCDN. É uma rede de entrega de conteúdo habilitada para HTTP/2 e IPv6 com 200+ localizações, para turbinar seus ativos e mídia em todo o mundo. As regiões atualmente servidas incluem América, América do Sul, Europa, África, Ásia e Austrália.

Se você é um cliente Kinsta, temos largura de banda gratuita para CDN em todos os nossos planos de hospedagem. Você pode ativar o CDN da Kinsta em dois passos simples.

Passo 1

Primeiro, faça o login no seu Painel MyKinsta. Clique no seu site e depois no separador CDN Kinsta.

Passo 2

Depois clique em “Ativar o CDN da Kinsta”. Após alguns minutos, o CDN é implantado automaticamente e seus recursos serão apresentados a partir do cache para todo o mundo. É só isso. 😄

Otimizações de CDN Adicionais

Aqui ficam algumas otimizações de CDN adicionais que você pode querer verificar ou refletir sobre.

• Se você tiver muitos comentários, os gravatars podem gerar muitos pedidos.Eles são carregados a partir de secure.gravatar.com. Confira este tutorial sobre como carregar gravatars do seu CDN. Fazemos isso no site da Kinsta. 👍
• Você pode hospedar suas fontes personalizadas da web a partir do seu CDN ou até mesmo as fontes do Google em seu CDN.Confira nosso aprofundado tutorial sobre fontes locais.
• Garanta que carrega o seu favicon a partir do CDN.Mesmo sendo pequeno, tudo é importante!

Descarregar Mídia e Emails Quando Necessário

Tudo o que provoca uma solicitação causa um impacto no desempenho do seu website. Para websites que hospedam milhares de arquivos ou mídia de grandes dimensões, é inteligente descarregar totalmente essa parte. Fazer o descarregamento é diferente de apresentar o conteúdo através de um CDN. Com um CDN, os dados permanecem no seu host, sendo que o CDN simplesmente tem várias cópias dele.

Quando o cache expira nos seus ativos CDN, ele consulta novamente o seu host para ter as cópias mais recentes dos arquivos. Os CDNs armazenam arquivos em cache por longos períodos de tempo. Mas por terem tantos POPs, pode haver muita reexame quando o cache expira em diferentes regiões.

Descarregar mídia ou arquivos significa movimentar a localização física original desses arquivos para um local externo ao seu provedor. Então, embora possa parecer que os arquivos estão sendo exibidos a partir do seu site, eles estão localizados em outro lugar. Além de reduzir o número de consultas pedidas ao seu host, a razão número um é obviamente economizar espaço em disco.

Descarregar Mídia para o Amazon S3

Uma das mais conhecidas soluções de descarregamento é a Amazon S3. A Amazon S3 é uma solução de armazenamento e um dos muitos produtos do Amazon Web Services. Normalmente é utilizado para sites de grandes dimensões que precisam de backups adicionais ou que estão apresentando arquivos grandes  (downloads, software, vídeos, jogos, arquivos de áudio, PDFs, etc.). A Amazon tem um histórico de fiabilidade comprovado e, devido à sua enorme infraestrutura, pode oferecer custos de armazenamento muito baixos.  Alguns dos clientes do S3 incluem Netflix, Airbnb, SmugMug, Nasdaq, etc.

Tendo em consideração que eles lidam exclusivamente com armazenamento em massa, quase dá para garantir que o preço será mais barato do que o seu host WordPress. O descarregamento de mídia para a AWS pode ser uma ótima forma de poupar dinheiro e é gratuito durante o primeiro ano (até 5 GB de armazenamento). Além disso, como os pedidos de mídia são apresentados diretamente a partir da Amazon, isso sobrecarrega menos o site do WordPress, o que significa tempos de carregamento mais rápidos.

Confira nosso tutorial detalhado sobre como descarregar mídia WordPress para o Amazon S3. Você pode também usar um CDN com a mídia descarregada para ter o melhor dos dois mundos.

Transferir Mídia para o Google Cloud Storage

Outra solução bem conhecida para fazer o descarregamento é usar o Google Cloud Storage. Tendo em conta que Kinsta é desenvolvido pela Plataforma Google Cloud, somos grandes fãs de sua tecnologia e infraestrutura. Devido à enorme infraestrutura do Google, e considerando o fato de que eles lidam com armazenamento em massa, a empresa consegue oferecer custos de armazenamento muito baixos. Alguns de seus clientes incluem Spotify, Vimeo, Coca-Cola, Philips, Evernote e Motorola.

Veja o nosso tutorial detalhado sobre como descarregar mídia WordPress para o Google Cloud Storage.

Descarregamento Transacional e Email Marketing

Independentemente da sua opinião, os emails têm um pacto no seu servidor e respetivos recursos. Com alguns hosts, especialmente hosts compartilhados, abusar desse elemento pode até fazer com que você seja suspenso. Isso é um problema ainda maior quando está tentando enviar emails em massa. Essa é a razão da existência de provedores de email transacionais de terceiros e também o porquê de muitos provedores de hospedagem bloquearem a entrega de emails em portas standard. Nunca recomendamos usar seu provedor de hospedagem para o email.

Se está enviando newsletters ou emails em massa, recomendamos as seguintes alternativas para ter os melhores resultados:

• Utilize um software profissional de emails de marketing criado por de terceiros que não faça parte do WordPress
• Utilize um provedor de serviços de email transacionais (HTTP API ou SMTP) junto com o WordPress

Eis outras vantagens de usar um serviço de terceiros:

• Melhor eficácia no envio de emails.Deixe os provedores de email fazerem aquilo em que eles são especialistas!
• Menor probabilidade de ficar na lista negra.
• Talvez não seja sempre possível configurar registros DMARC com seu provedor de hospedagem.

Ferramentas de Email Marketing

Alguns exemplos de email marketing incluem newsletters, anúncios de produtos e recursos, vendas, convites para eventos, lembretes de integração, etc. Veja algumas ferramentas de mail marketing que recomendamos:

• MailChimp– Usamos o MailChimp na Kinsta.
• MailerLite
• Drip

Serviços de Email Transacional

Alguns exemplos de emails transacionais incluem recibos de compra do WooCommerce ou EDD, notificações sobre a criação de conta, notificações de envio, mensagens de erro de aplicativos, redefinições de senha, etc. Se você for um cliente Kinsta, temos um provedor SMTP de terceiros que assegura uma elevada capacidade de entrega. Mas, dependendo do seu volume, recomendamos sempre que você mude isso para um local externo. Eis alguns serviços de email transacional que recomendamos:

• SendGrid – Utilizamos o SendGrid na Kinsta.
• Mailgun– Veja como configurar o Mailgun no WordPress.
• SparkPost

Como Encontrar Áreas Problemáticas e Plugins Lentos

Iremos conferir agora algumas dicas sobre como encontrar áreas problemáticas no seu site WordPress e o que você pode fazer quanto a isso.

Utilize o New Relic para Identificar Plugins e Consultas à Base de Dados Lentas

Existem excelentes ferramentas no mercado que podem ajudar você a identificar consultas à base de dados lentos e também plugins que estão consumindo muito tempo. Gostamos muito do New Relic na Kinsta e usamos ele diariamente. O New Relic é uma ferramenta de monitoramento do PHP que pode usar para obter estatísticas detalhadas de desempenho no seu site.

Se você é um cliente Kinsta, pode até adicionar sua própria chave de licença do New Relic no nosso painel MyKinsta.

Mas sempre use o New Relic com cuidado, já que ele afeta o desempenho do site, ao adicionar JavaScript. Recomendamos que o ative quando você precisar solucionar problemas de desempenho, desativando ele logo de seguida.

Descobrir Plugins Lentos

Quando um plugin do WordPress está sendo o responsável por uma grande lentidão, os sintomas variam de acordo com a atividade que o plugin está efetuando. Ainda assim, em muitos casos, você verá que um plugin lento afetará todas as páginas de um site WordPress. No caso do site cujos dados você encontra na imagem abaixo, a lentidão geral foi notada em todas as páginas front-end do site. Vejamos o relatório do New Relic sobre o desempenho dos plugins no site.

Você pode ver de imediato que o plugin adinjector está sendo 15 vezes mais lento do que o seguinte.

Quando você encontra dados como esse, pode ser tentador classificar imediatamente o plugin como mal codificado ou ineficaz. Embora esse seja o caso pro vezes, não sempre o é. A configuração incorreta de um plugin, a lentidão da base de dados ou recursos externos que demoram a responder podem fazer com que um plugin consuma muito tempo.

Então, quando você encontrar um plugin que está respondendo lentamente, deve verificar as outras telas do New Relic para encontrar informações adicionais. Todas as transações, bases de dados e recursos externos devem ser verificados antes de achar que desativar o plugin é a melhor ou a única solução.

Lentidão Geral Provocada por uma Base de Dados Sobrecarregado

Um base de dados cuja otimização seja fraca pode provocar lentidão geral em um site WordPress. Vimos várias formas que lhe permitem resolver essa situação. No New Relic, a lentidão relacionada com a base de dados surgirá provavelmente em dois sítios:

• Primeiro, você verá uma grande atividade do MySQL na tela da visão geral.
• Segundo, encontrará uma ou mais tabelas da base de dados consumindo muito tempo no separador dedicado às bases de dados.

Começando com a tela da visão geral, um site com uma base de dados em dificuldades pode ter esse aspeto:

Para saber com melhor precisão que tabela da base de dados ou consulta está provocando o problema, entre no separador das bases de dados.

O separador das bases de dados identificará a tabela e o tipo de consulta que consome mais tempo. Se você selecionar uma das entradas na lista, poderá ver mais detalhes, incluindo algumas consultas de amostra.

Nesse caso acima, os dados identificam a causa como sendo os dados carregados automaticamente na tabela wp_options. Vale a pena lembrar que nesse artigo já solucionámos esse problema. Com certeza, uma análise rápida da tabela wp_options confirmará que quase 250 MB de dados são carregados automaticamente a partir dela, tornando esse site um candidato óbvio para a manutenção e otimização da base de dados.

Veja o nosso tutorial detalhado sobre como usar o New Relic para depurar problemas de desempenho no seu site WordPress.

Utilizando o Plugin Gratuito Query Monitor

Você pode também usar o plugin gratuito Query Monitor para WordPress. Use ele para identificar e depurar consultas lentas à base de dados, chamadas AJAX, solicitações da API REST e muito mais. Além disso, o plugin diz os detalhes do site, como dependências e dependentes do script, ganchos do WordPress que foram acionados durante a geração da página, detalhes do ambiente de hospedagem, tags condicionais de consulta apresentadas pela página atual e muito mais.

O plugin foi desenvolvido por John Blackbourn, um participante do core do WordPress que atualmente é desenvolvedor da Human Made e que anteriormente havia sido funcionário do WordPress.com VIP – dito de outra forma, alguém que conhece o WordPress com grande profundidade. O Query Monitor foi adicionado ao diretório de plugins do WordPress em 2013 e possui atualmente mais de 10.000 instalações ativas – uma soma impressionante para um plugin de desenvolvimento. A classificação do plugin de cinco em cinco estrelas ajuda a explicar sua popularidade entre os desenvolvedores.

Confira nosso tutorial completo sobre como usar o Query Monitor.

Utilize Staging Sites Without Touching Production

Não conseguimos imaginar como seria a nossa vida sem ambientes de teste. São inestimáveis quando o assunto é solucionar problemas de desempenho. Felizmente, Kinsta tem ambientes de teste de um só clique. Se o seu host WordPress não oferece ambientes de teste, você também pode usar um plugin como o WP Staging, embora não seja tão fácil.

Após você ter um de teste instalado e em funcionamento, a primeira coisa que pode fazer é desativar todos os seus plugins. Tendo em conta que isso é uma cópia do sue site ao vivo, não precisa de se preocupar em quebrar nada. É de longe uma das formas mais fáceis de resolver problemas. Simplesmente entre em Plugins, selecione todos eles e escolha “Desativar” nas opções em massa.

Depois de fazer isso, pode monitorar os tempos de resposta no New Relic ou no Query Monitor e ver o que acontece. No exemplo abaixo, os tempos de resposta caíram imediatamente para os níveis normais, por isso sabíamos que um dos plugins era aquilo que que causava o problema. Você pode reativar eles um por um, repetindo o mesmo processo até encontrar o culpado.

Eis um exemplo do que aconteceu quando ativámos o plugin que estava causando o problema. Os tempos de carregamento (tempos de transação da web) foram imediatamente aumentados.

Tempos de resposta maiores novamente

O que deve fazer quando encontra o plugin causador da lentidão? Eis o que aconselhamos:

1. Atualize seus plugins e temas para a versão mais recente, se ela ainda não estiver instalada.
2. Entre em contato com o desenvolvedor do plugin ou tema e peça ajuda.
3. Encontre um plugin alternativo que possa oferecer a mesma funcionalidade.
4. Talvez o problema seja causado pela sua versão do PHP. Reduza o seu mecanismo PHP para uma versão inferior e veja se o plugin ou tema funciona.

Pode também encontrar um desenvolvedor WordPress para corrigir o problema. Se estiver relacionado com o desempenho, precisamos mencionar Mike Andreason do WP Bullet. Ele é um desenvolvedor a tempo inteiro na Codeable, especializado em otimização de desempenho, que ajudou muitos clientes aqui na Kinsta com instalações complexas que fazem com seu site atinja um nível superior.

Verifique Seus Registros de Erro

Verificar os registros de erro nunca é algo divertido, mas pode revelar muito sobre os problemas de desempenho com plugins WordPress. Se você for um cliente Kinsta, poderá visualizar facilmente seus registros de erro, registros de cache e registros de acesso diretamente no painel do MyKinsta.

Pode também ativar os registros de erro adicionando algum código ao seu arquivo wp-config.php.  Primeiro, terá de se conectar ao seu site via SFTP. Então baixe seu arquivo wp-config.php para que o possa editar. Nota: Faça sempre um backup desse arquivo antes de mexer!

Encontre a linha /* That's all, stop editing! Happy blogging. */ e imediatamente antes adicione isso (como visto abaixo):

define( 'WP_DEBUG', true );

Se o código acima já existir no seu arquivo wp-config.php, mas está definido como “false”, basta alterá-lo para “true”. Isso habilitará o modo de depuração. Nota: Você também verá avisos ou erros no seu painel de administrador WordPress, se existirem.

Você depois pode habilitar o registro de depuração para enviar todos os erros para um arquivo, adicionando o seguinte código logo após a linha WP_DEBUG (como visto abaixo):

define( 'WP_DEBUG_LOG', true );

Salve suas alterações e faça novamente o upload para o seu servidor. Os erros serão então registrados no arquivo debug.log dentro da sua pasta /wp-content/. Se por algum motivo você não encontrar esse arquivo, poderá criar um.

Utilize o MyKinsta Analytics

Se você for um cliente Kinsta, aproveite as informações de desempenho que temos na nossa ferramenta MyKinsta Analytics.

Na seção de monitoramento de desempenho, você pode ver seu tempo médio de resposta do PHP + MySQL, o rendimento do PHP, a utilização do AJAX, o maior tempo médio de upstream e o maior tempo máximo de upstream.

Tempo Médio de Resposta PHP + MySQL

Sempre que você entra no seu site WordPress, o PHP e o MySQL são utilizados para compilar e consultar os dados que você observa nessa página. Esse gráfico mostra o tempo médio de resposta do mecanismo PHP e do mecanismo MySQL para cada solicitação dinâmica que não é armazenada em cache. Quando você sabe esses tempos de resposta, isso pode ajudar a solucionar problemas de lentidão.

Rendimento do PHP

O rendimento indica o número de transações por segundo que um aplicativo consegue gerenciar e, nesse relatório, isso diz respeito ao rendimento do PHP do seu site WordPress. Dito de outra forma, mostra quantas vezes um recurso do PHP foi solicitado.

Utilização do AJAX

O AJAX é um script da parte do cliente que comunica para e a partir de um servidor/base  de dados sem a necessidade de um postback ou de uma atualização total da página. No WordPress, muitos de vocês provavelmente já encontrar isso nos testes de velocidade. Os dois principais problemas com o AJAX incluem plugins que fazem com que ele dispara e problemas de CPU no back-end.

Consulte o nosso artigo detalhado sobre diagnosticar uma elevada atualização do AJAX por parte do Admin no seu site WordPress.

O relatório de utilização do AJAX no MyKinsta Analytics pode ser uma ótima forma de ajudar você a solucionar esses tipos de problemas, como pode perceber se estiver encontrando determinados picos de utilização do AJAX durante períodos específicos. Esse gráfico exibe a contagem das solicitações do AJAX por parte de administrador. Você pode depois usar algumas das dicas no artigo que mencionámos acima para perceber de elas estão surgindo.

Tempo Médio Superior de Resposta do PHP + MySQL

Essa lista exibe os maiores tempos médios de resposta do PHP e do MySQL. Esses números podem ser picos que só acontecem uma vez, por isso a sugestão é comparar essa lista com o “Maior Tempo Máximo de Upstream”.

Maior Tempo Máximo de Upstream

O tempo de upstream é o tempo total gasto pelo NGINX (e servidores upstream) para processar uma solicitação e enviar uma resposta. O tempo é medido em segundos, com resolução de milissegundos. Leia mais sobre as métricas do NGINX.

O Seu Site Pode Estar Sendo Pirateado

Se você está tendo problemas para encontrar um problema de desempenho, é muito provável que o site esteja sendo invadido, infetado por malware ou submetido a um ataque DDoS. Isso pode ter um impacto na velocidade do seu site e até mesmo na capacidade de resposta do seu painel de administrador WordPress. Nesses casos, recomendamos o seguinte:

1. Implementar um servidor proxy e WAF, como o Cloudflare ou o Sucuri.
2. Bloquear endereços IP incorretos utilizando os serviços acima ou, se você for um cliente Kinsta, bloquear também endereços IP no nosso painel MyKinsta.
3. Pode também implementar um bloqueio geográfico. Alguns países são bem ruins quando se trata da qualidade do tráfego que eles geram. Se você estiver sob ataque, talvez seja necessário bloquear todo o país, temporariamente ou permanentemente.

Resolução de Problemas com Códigos de Erro (Códigos de Estado HTTP)

Os códigos de estado HTTP atuam um aviso que o servidor web coloca em cima da ágina. Não faz parte da página web em si mesmo. Em vez disso, é uma mensagem do servidor informando sobre aquilo que aconteceu quando a solicitação para visualizar a página foi recebida pelo servidor. Essas mensagens podem ser muito valiosas quando se trata de resolver problemas!

Embora existam mais de 40 códigos de estado diferentes, abaixo ficam os comummente encontrados por usuários WordPress.

429: “Too Many Requests” Esse erro é gerado pelo servidor quando o usuário enviou muitas solicitações em um determinado período de tempo (limitação de taxa). Isso por vezes pode ser provocado por bots ou scripts que tentam entre no seu site. Neste caso, você pode tentar alterar seu URL de login do WordPress.

500: “There was an error on the server and the request could not be completed.” Um código genérico que simplesmente significa “erro interno do servidor”. Algo no servidor deu errado e o recurso solicitado não foi entregue. Esse código é gerado normalmente por plugins de terceiros, PHP com defeito ou até mesmo por uma quebra na conexão com a base de dados. Confira nossos tutoriais sobre como corrigir o erro ao estabelecer uma conexão com a base dados e outras formas de resolver um erro interno do servidor número 500.

502: “Bad Gateway.” Esse código de erro significa normalmente que um servidor recebeu uma resposta inválida de um outro servidor. Por vezes, uma consulta ou solicitação demora demasiado tempo e, por isso, é cancelada ou interrompida pelo servidor e a conexão com a base de dados é interrompida. Confira nosso tutorial detalhado sobre como corrigir o erro 502 Bad Gateway.

503: “The server is unavailable to handle this request right now.” Não é possível concluir o pedido nesse momento. Esse código pode ser retornado por um servidor sobrecarregado que não consegue gerenciar solicitações adicionais.

504: “The server, acting as a gateway, timed out waiting for another server to respond.” Esse código é apresentado quando existem dois servidores envolvidos no processamento de uma solicitação, e o primeiro servidor expira enquanto aguarda pelo segundo. Leia mais sobre como corrigir o erro número 504.

Você pode igualmente procurar esses códigos de resposta HTTP na nossa ferramenta MyKinsta Analytics. O nosso relatório de identificação de códigos de resposta permite que você tenha uma visão geral da distribuição dos códigos de estado HTTP exibidos para os recursos solicitados.

O relatório de estatísticas de resposta permite que você veja o número total de redirecionamentos, erros, taxa de sucesso e taxa de erros. Cada site WordPress tem normalmente uma pequena taxa de erro; isso é totalmente normal.

Existem depois relatórios de identificação para cada código de erro, como erros 500, erros 400, redirecionamentos, etc.

Recomendações Sobre Otimização de Back-End

Vejamos agora com maior detalhe algumas formas através das quais você pode acelerar o WordPress, otimizando o back-end. O back-end envolve tudo o que é gerenciado inteiramente pelo servidor, como PHP, cabeçalhos de cache HTTP, compressão GZIP, etc.

Crie uma Página 404 Leve

Já vimos que sites bem dinâmicos geram normalmente muitos erros 404. Seu site pode estar gerando mais desses erros do que aquilo que você pensa! A nossa ferramenta MyKinsta Analytics  pode ajudar você a determinar a quantidade exata de erros (como visto abaixo).

A razão pela qual esses erros são bem negativos é que muitas páginas 404 existem imensos recursos. Para um site WordPress altamente dinâmico, você vai querer uma página 404 pesada. Crie um modelo simples para 404 que evite consultar reiteradamente a base de dados, se possível. E, claro, perca algum tempo e corrija os erros 404, já isso não é apenas algo que exige muitos recursos, é simplesmente ruim para a experiência do usuário.

Além de utilizar uma página 404 leve, recomendamos também a implementação de uma regra especial de cache de páginas para páginas 404. Na Kinsta, armazenamos automaticamente páginas 404 em cache por 15 minutos. Se nosso servidor web detectar que uma nova página com a mesma URL de uma página 404 em cache foi criada, limparemos automaticamente o cache. Se o seu site WordPress não tiver páginas em cache 404, recomendamos que você trabalhe com o seu host para adicionar esta capacidade ao seu servidor web.

Aumentar os Operadores PHP

Operadores PHP pode até ser um termo que você desconhece por completo, mas isso diz respeito aos hosts, incluindo Kinsta, que lidam com solicitações limitantes (em vez de limitar você com base na CPU ou pela RAM, algo normalmente é o que os provedores de hospedagem compartilhada fazem).

Os operadores PHP determinam quantas solicitações simultâneas seu site pode gerenciar em um determinado momento. Para simplificar, cada solicitação ao seu site não colocada em chace é manipulada por um Operador PHP. Por exemplo, se você tiver 4 solicitações que chegam ao seu site exatamente no mesmo momento e seu site tiver 2 funcionários PHP, duas dessas solicitações serão processadas, enquanto as outras duas terão de esperar na fila até o processamento das duas primeiras tenham sido concluídas. Vale a pena lembrar o que discutimos anteriormente.

Um dos maiores problemas com os sites de filiação em WordPress são todas as solicitações não armazenadas em cache. É por isso que os operadores PHP são muito importantes, já que eles gerenciam cada solicitação. Ou seja, esses sites normalmente exigem operadores PHP adicionais para garantir que cada solicitação é processada sem qualquer atraso e concluída com êxito.

O que acontece se você atingir continuadamente a capacidade máxima dos seus operadores PHP? Basicamente, a fila começa a ignorar as solicitações mais antigas, o que pode provocar em erros 500 em seu site. Cada um dos planos de hospedagem da Kinsta inclui um número predefinido de operadores PHP. Se você tiver dificuldade em estimar aquilo que seu site pode precisar, você pode sempre conversar com nossa equipe de vendas ou suporte.

Utilize GZIP Compression

GZIP é um formato de arquivo e um aplicativo de software utilizado para comprimir e descompactar arquivos. A compactação GZIP é ativada no servidor e permite uma redução adicional no tamanho dos seus arquivos HTML, folhas de estilos e JavaScript.

Quando um navegador web visita um site, ele verifica se o servidor web tem o GZIP ativado, verificando se o cabeçalho HTTP content-encoding: gzip existe. Se o cabeçalho for encontrado, ele exibe os arquivos comprimidos e de menor dimensão. Caso contrário, ele mostra os arquivos descomprimidos. Se você não tiver o GZIP ativado, encontrará provavelmente avisos e erros nas ferramentas de teste de velocidade, como o Google PageSpeed Insights e o GTmetrix.

Habilitar a compactação GZIP pode ajudar a reduzir o tamanho da sua página da Web, o que pode reduzir significativamente o tempo para baixar o recurso, reduzir o uso de dados para o cliente e melhorar o tempo para a primeira renderização de suas páginas. Isso é bastante normal agora na maioria dos provedores de hospedagem, mas nada nos surpreende mais neste momento.

Ativar Proteção Hotlink

O conceito de hotlinking é muito simples. Você encontra uma imagem na internet em algum lugar e utiliza o URL da imagem diretamente no seu site. Essa imagem será exibida no seu site, mas a partir do local original. Isso é muito conveniente para o hotlinker, mas na verdade é um roubo, pois está usando os recursos do site para onde aponta o hotlink. É como se o nosso carro usasse o combustível que roubámos do vizinho

O hotlinking pode ser uma atividade que consome muitos recursos no servidor-alvo. Imagine que o seu site está em um host de WordPress compartilhado e o Huffington Post subitamente passa a linkar as suas imagens. Você poderia passar de uma situação em que tem apenas algumas centenas de consultas por hora no seu site para várias centenas de milhares. Isso pode até resultar na suspensão da sua conta de hospedagem. Essa é uma razão para não só usar um host de alto desempenho (que pode lidar com questões como essa), mas também para ativar a proteção hotlink, para que isso não aconteça.

Confira nosso tutorial sobre como evitar o hotlinking.

Minimize os Redirecionamentos e Adicione Eles no Servidor

Você precisa ficar muito atento aos redirecionamentos. Os redirecionamentos simples como um único redirecionamento 301, HTTP para HTTPS ou www para não-www (e vice-versa) são bons. E muitas vezes são necessários em determinadas áreas do seu site. Contudo, cada um deles representa um custo para o desempenho do seu site. E se você começar acumulando redirecionamentos, importa entender como eles afetam o seu site. Isso se aplica a redirecionamentos de página e postagens, redirecionamentos de imagem, tudo.

Um redirecionamento gerará um 301 ou um 302 no estado do cabeçalho de resposta.

Qual a dimensão do impacto dos redirecionamentos no seu site? Façamos um pequeno teste. Primeiro, executemos um teste de velocidade na nossa página de contato: https://perfmatters.io/contact/. Como você pode ver abaixo, temos um tempo total de carregamento de 417 ms.

Depois alteramos ligeiramente o URL e executamos outro teste de velocidade para vermos o impacto de vários redirecionamentos http://www.perfmatters.io/contact. Como você pode ver, a mesma página agora demora 695 ms para carregar. Isso é um aumento de 66%. Credo!

Utilizar plugins gratuitos WordPress para implementar redirecionamentos pode por vezes provocar problemas no desempenho, já que a maioria utiliza a função wp_redirect, que exige a execução de código e recursos adicionais. Alguns também adicionam dados carregados automaticamente à sua tabela wp_options, o que aumenta o tamanho da base de dados. Eles devem ser adicionados no nível do servidor. Permitimos que você faça isso no MyKinsta com a nossa ferramenta de regras de redirecionamento.

Você também pode ver um relatório completo de quantos redirecionamentos estão acontecendo nos seus sites com a nossa ferramenta de análise MyKinsta. Veja o número total de 301, 302 e 304.

Confira nosso artigo aprofundado sobre os redirecionamentos de WordPress e as melhores práticas para ter um desempenho mais rápido.

Não Perca o Controle Sobre as Tarefas Cron

As tarefas CRON (WP-Cron) são utilizadas para agendar tarefas repetitivas no seu site WordPress. Só que, com o avançar do tempo, elas podem escapar do seu controle e provocar problemas de desempenho. Você pode usar utilizar o plugin WP Crontrol para verificar um identificador todas as tarefas Cron que estão sendo executadas em seu site.

Também já vimos problemas de desempenho com o gerenciador interno do WordPress para Cron: o WP-Cron. Se um site não tiver operadores PHP suficientes, por vezes surgirá uma solicitação, o WordPress gerará o cron, mas o cron precisa aguardar pelo operador e, portanto, permanecerá no mesmo lugar. Uma melhor abordagem passa por desativar o WP-Cron e usar o cron do sistema em vez dele. Isso é até recomendado manual de plugins oficial.

Para desativar o WP-Cron, adicione o seguinte ao seu arquivo wp-config.php pouco antes da linha que diz “That’s all, stop editing! Happy blogging.” Nota: Isso desativa a execução dele no carregamento da página, e não altera o que acontece quando você o aciona diretamente via wp-cron.php.

define('DISABLE_WP_CRON', true);

Depois precisará de agendar o wp-cron.php a partir do seu servidor. Se você for um cliente Kinsta, os sistemas crons já estarão ativados à partida e serão executados a cada 15 minutos, de acordo com as definições padrão. Você também pode aumentar a frequência entrando em contato com nossa equipe de suporte. Se estiver familiarizado com o SSH, você pode gerenciar os crons do servidor na linha de comandos.

Adicionar os Cabeçalhos Cache-Control e Expires (Determinar a Dimensão do Cache)

Cada script no seu site WordPress necessita de um cabeçalho de cache HTTP anexado (ou deveria ter um). Isso determina o momento em que o cache no arquivo expira. Para corrigir isso, garanta que o seu host WordPress tem os cabeçalhos cache-control e expires configurados. Se você não fizer isso, provavelmente encontrará avisos acerca da necessidade de adicionar cabeçalhos expires ou aproveitar o cache do navegador em ferramentas de teste de velocidade.

Se o cabeçalho cache-control ativa o cache do lado do cliente e define a duração máxima de um recurso, o cabeçalho expires é utilizado para especificar um ponto específico no tempo em que o recurso deixa de ser válido. Apesar de os cabeçalhos poderem ser usados em conjunto, você não precisa necessariamente de adicionar os dois cabeçalhos. O cache-control é mais novo e geralmente é o método recomendado.

Kinsta adiciona automaticamente cabeçalhos de cache HTTP em todas as solicitações do servidor e, se você estiver usando um CDN, eles provavelmente também adicionarão esses cabeçalhos para você.

Se o seu servidor não tiver esses cabeçalhos, você poderá adicionar eles manualmente.

Adicionar o Cabeçalho Cache-Control no Nginx

Você pode adicionar o cabeçalho cache-controlno Nginx adicionando o que esta abaixo à localização do servidor ou bloco na configuração do seu servidor.

location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico)$ {
 expires 30d;
 add_header Cache-Control "public, no-transform";
}

Adicionar o Cabeçalho Expires no Nginx

Você pode adicionar os cabeçalhos expires no Nginx adicionando o seguinte ao seu bloco de servidor. Nesse exemplo, você pode ver como pode especificar tempos de expiração diferentes com base nos tipos de arquivo.

    location ~*  \.(jpg|jpeg|gif|png|svg)$ {
        expires 365d;
    }

    location ~*  \.(pdf|css|html|js|swf)$ {
        expires 2d;
    }

Adicionar o Cabeçalho Cache-Control no Apache

Você pode adicionar os cabeçalhos cache-control adicionando o seguinte ao seu arquivo .htaccess. Os pedaços de código podem ser adicionados na parte superior ou inferior do arquivo (antes de # BEGIN WordPress ou depois de # END WordPress).

<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|svg|js|css|swf)$">
Header set Cache-Control "max-age=84600, public"
</filesMatch>

Adicionar o Cabeçalho Expires no Apache

Você pode adicionar os cabeçalhos expires no Apache adicionando o seguinte ao seu arquivo .htaccess.

## EXPIRES HEADER CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType image/svg "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 2 days"
</IfModule>
## EXPIRES HEADER CACHING ##

Vale a pena falar também que você só pode adicionar cabeçalhos de cache HTTP aos recursos em seu servidor. Se você está recebendo um aviso sobre isso, talvez precise aproveitar o cache do navegador em uma solicitação de terceiros, não há nada que possa fazer, já que você não pode fazer uma solicitação a um servidor de terceiros.  Os culpados mais comuns incluem o script do Google Analytics e os pixels de marketing, como aqueles do Facebook e do Twitter.

Se está tentando consertar isso com o script do Google Analytics, você pode hospedar ele localmente ou no seu CDN (embora isso não seja oficialmente suportado) com um plugin como o Perfmatters ou o WP Rocket.

Adicionar Cabeçalhos Last-Modified e ETag (Validar Cache)

Agora temos mais dois cabeçalhos, last-modified and etag.

Os cabeçalhos cache-control e expires ajudam o navegador a determinar se o arquivo foi alterado desde a última vez que foi solicitado (ou melhor, eles validam o cache). Os cabeçalhos last-modified e etag validam e definem o comprimento do cache e devem ser incluídos em todas as respostas do servidor de origem. Se eles não estiverem definidos corretamente, você poderá ver um aviso de que precisa “especificar um validador de cache“.

Se os cabeçalhos não forem encontrados, isso gerará constantemente uma nova solicitação para o recurso, o que aumentará a carga sobre o seu servidor. A utilização de cabeçalhos de cache garante que as solicitações posteriores não necessitam de serem carregadas do servidor, poupando largura de banda e melhorando o desempenho do usuário.

Kinsta automaticamente adiciona os cabeçalhos acima em todas as solicitações do servidor e, se você estiver usando um CDN, eles provavelmente também adicionarão esses cabeçalhos para você. Assim como acontece com o cache-control e expires, você não pode definir manualmente esses cabeçalhos HTTP em recursos externos.

Cabeçalho Last-Modified

O cabeçalho last-modified normalmente é enviado automaticamente a partir do servidor. É um cabeçalho que geralmente você não precisará de adicionar manualmente. É enviado para verificar se o arquivo no cache do navegador foi modificado desde a última vez em que foi solicitado. Você pode consultar a solicitação do cabeçalho no Pingdom ou usar o Chrome DevTools para ver o valor do cabeçalho last-modified.

Cabeçalho ETag

O cabeçalho ETag também é muito parecido com o cabeçalho last-modified. É igualmente utilizado para validar o cache de um arquivo. Se você estiver executando o Apache 2.4 ou uma versão acima, o cabeçalho ETag é adicionado automaticamente usando a diretiva FileETag. E, no que em relação ao NGINX, o cabeçalho ETag tem estado ativo por padrão desde 2016.

Você pode ativar o cabeçalho ETag manualmente no Nginx usando o seguinte código.

etag on

Adicionar um cabeçalho Vary: Accept-Encoding

Ovary: Accept-Encodingdeve ser incluído em todas as respostas do servidor de origem, já que ele informa o navegador se o cliente consegue ou não manipular versões compactadas do conteúdo. Se isso não estiver corretamente definido, você poderá ver um aviso de que precisa de “especificar um cabeçalho Vary: Accept-Encoding“.

Por exemplo, partamos do princípio que você tem um navegador antigo sem compressão gzip e um navegador moderno com essa opção. Se você não utilizar o cabeçalho vary: Accept-Encoding, seu servidor web ou CDN poderiam armazenar em cache a versão descomprimida e entregar isso ao navegador moderno por engano, o que por sua vez prejudicaria o desempenho do seu site WordPress. Ao utilizar cabeçalho você garante que o seu servidor web e/ou CDN entrega a versão correta.

Kinsta adiciona automaticamente os cabeçalhos acima em todas as solicitações do servidor e, se estiver usando um CDN, eles provavelmente também adicionarão esses cabeçalhos para você. Assim com acontece com os cabeçalhos de cache que discutimos acima, você não pode definir manualmente esse cabeçalho em recursos externos.

Adicionar o Cabeçalho Vary: Accept-Encoding no Apache

Você pode adicionar o cabeçalho vary: Accept-Encoding no Apache adicionando o seguinte ao seu arquivo .htaccess.

<IfModule mod_headers.c>
  <FilesMatch ".(js|css|xml|gz|html)$">
    Header append Vary: Accept-Encoding
  </FilesMatch>
</IfModule>

Adicionar o Cabeçalho Vary: Accept-Encoding no Nginx

Você pode adicionar o cabeçalho vary: Accept-Encoding no Nginx ao acrescentar o código abaixo ao seu arquivo de configuração. Todos os arquivos de configuração do Nginx estão localizados no diretório /etc/nginx/. O arquivo de configuração principal é /etc/nginx/nginx.conf.

gzip_vary on

Alterar o Limite de Memória do WordPress no wp-config.php

Como explicitado no WordPress Codex, no WordPress versão 2.5 a opção WP_MEMORY_LIMIT permite que você especifique a quantidade máxima de memória que pode ser consumida pelo PHP. Essa configuração pode ser necessária caso você receba uma mensagem como “Tamanho da memória permitida de xxxxxx bytes esgotado”.

De acordo com as definições padrão, o WordPress tentará aumentar a memória alocada para o PHP em 40MB para um site único e 64 MB para vários sites. Eles definem os limites de memória no arquivo ./wp-includes/default-constants.php, nas linhas 32 – 44 (fonte).

Você tem também o memory_limit do PHP no servidor facultado seu provedor de hospedagem. São duas coisas diferentes. Na Kinsta, definimos o memory_limit para 256M como padrão. Se você está encontrando várias vezes o erro de tamanho de memória esgotado, você pode tentar aumentar o limite de memória do PHP no WordPress.

Adicione o seguinte ao seu arquivo wp-config.php file, imediatamente antes da linha que diz “That’s all, step editing! Happy blogging.”

define( 'WP_MEMORY_LIMIT', '256M' );

Jan Reilink tem também um ótimo artigo no blog que descreve o problema de limite de memória do WordPress em maior detalhe. Ele também oferecer uma variação no código que você poderia usar. Em vez de definir o valor manualmente, você pode configurar ele para valor memory_limit do PHP.

define( 'WP_MEMORY_LIMIT', ini_get( 'memory_limit' ) );

Dicas Para a Otimização de Front-end e Serviços Externos

Vejamos agora algumas formas através das quais pode acelerar o WordPress ao otimizar o front-end. Tipicamente, o front-end diz respeito a tudo o que é tratado exclusivamente pelo navegador do lado do cliente, como CSS, JavasScript, imagens, etc. Isso também inclui a análise de serviços externos que você carrega em seu site e como eles estão afetando seu tempo de carregamento no geral.

Eis dois dos objetivos mais importantes que deve ter em consideração na otimização de front-end:

• Reduzir o tamanho geral da página web.O tamanho do seu CSS, JavaScript ou imagens é importante. Um site de 4 MB normalmente vai carregar muito mais lentamente do que um site de 1 MB. Contudo, Paul Calvano tem um ótimo artigo sobre o impacto do peso da página no tempo de carregamento e como é importante garantir que não é a única coisa que você está rastreando, já que por vezes pode ser enganador.
• Reduzir solicitações HTTP e serviços externos. Com o HTTP/2, várias solicitações e respostas podem agora ser enviadas ao mesmo tempo utilizam uma única conexão TCP. Apesar de isso ser fantástico para o desempenho, a redução de solicitações HTTP pode também ajudar a acelerar o seu site WordPress. Isso inclui também a redução do número total de solicitações e serviços externos. Cada um deles acrescenta mais atrasos, como pesquisas DNS, conexões TLS e latência de rede .

Faça Um Teste de Velocidade ao Seu Site Para Saber Qual é o Ponto de Partida

Quando você quer otimizar o front-end de seu site, é sempre bom definir o ponto de partida. Isso geralmente significa executar um teste de velocidade. Existem várias formas de fazê-lo, confira nossa lista de 15 fantásticas ferramentas para testar a velocidade do seu site.

Veja os nossos guias sobre como como usar o Pingdom e como usar o GTmetrix. Aqui ficam algumas coisas que deve ter em consideração quando testa a velocidade:

1. Escolha Uma Ferramenta e Seja Fiel a Ela

Adoramos o Pingdom, GTmetrix, WebPageTest, PageSpeed Insights e o Chrome DevTools. Ainda assim, não importa muito qual ferramenta para teste de velocidade que você usa, desde que ela seja consistente. Todas essas têm diferentes formas de medir e quantificar a velocidade, por isso escolha uma ferramenta e seja fiel a ela em todos os seus testes e otimizações. Até o Google diz para escolher uma apenas.

2. Não Fique Obcecado com um Resultado Perfeito

Muitas das ferramentas, como o Google PageSpeed Insights, têm algum tipo de velocidade ou pontuação de desempenho. É importante lembrar que a pontuação nem sempre é tão importante quanto a velocidade e o desempenho que o usuário perceciona no site. A pontuação existe para ajudar a avaliar o seu desempenho. Mas ficar obcecado em conseguir um perfeito 100/100 ou uma pontuação A pode ser uma perda de tempo em alguns casos. E sites maiores, com muitos scripts e anúncios externos, jamais obterão uma pontuação perfeita, o que é perfeitamente aceitável.

3. A Localização do Seu Teste é Importante

O local que você escolhe quando efetua o teste de velocidade é importante. Como falámos em uma seção anterior, a razão é que tudo isso tem que ver com a localização do centro de dados que você escolhe. O TTFB, a latência de rede, tudo isso entra em jogo. Então teste o seu site em um local próximo ao seu centro de dados e também em um local distante. Isso também ajudará você a identificar o impacto que um CDN pode ter no seu site WordPress.

4. Faça Vários Testes Devido ao Cache

Como referimos anteriormente na seção sobre o cache, se ele tiver sido recentemente limpo, se tiver expirado no seu host WordPress ou CDN, ele irá registrar um “MISS” no cabeçalho HTTP. Isso significa que seu site ou recurso não está sendo apresentado a partir do cache.

Para ver corretamente a velocidade de todo o seu site, você precisa ver tudo o que é carregado a partir do cache, a sua página inicial e todos os recursos sendo identificados com um “HIT”. Isso por vezes exige a aplicação do teste de velocidade várias vezes. Você então calcula a média.

Vejamos agora algumas das otimizações front-end que você pode fazer no seu WordPress.

Eliminar JavaScript e CSS de Bloqueio de Renderização

Pode surgir um aviso sobre JavaScript e CSS de bloqueio de renderização quando você tem arquivos impedindo que a página seja carregada o mais rápido possível. O JS e CSS específicos são por vezes condicionais, o que significa que eles não precisam exibir conteúdo acima da dobra. Você pode impedir que eles se tornem elementos de bloqueio de renderização usando os atributos async e defer.

Confira este vídeo para saber mais sobre como eliminar os recursos render-blocking:

Para eliminar JavaScript e CSS de bloqueio de renderização, deve fazer o seguinte:

Limpar o JS do Caminho de Renderização Crítico

Retirar o JavaScript do caminho de renderização crítico é algo que é normalmente feito quando se adiciona o atributo defer ou async aos elementos HTML do script que acionam os recursos JavaScript.

• O atributo async informa o navegador para este começar a baixar o recurso imediatamente sem diminuir a análise de HTML. Quando o recurso estiver disponível, a análise de HTML será colocada em pausa para que o recurso possa ser carregado.
• O atributo defer diz ao ao navegador para adiar o download do recurso até que a análise HTML esteja concluída. Quando o navegador tiver concluído a parte do HTML, ele fará o download e renderizará todos os scripts adiados na ordem em que eles surgem no documento.

Otimizar a Entrega de Recursos CSS

Otimizar a entrega de CSS basicamente quer dizer que você precisa descobrir como transformar isso um bloqueio sem renderização.

• Identifique os estilos necessário para renderizar o conteúdo acima da dobra e apresente esses estilos em linha com o HTML.
• Utilize o CSS condicionalmente em dispositivos apenas quando necessário.
• Carregue o CSS restante de forma assíncrona.

Pode ser complicado fazer tudo o que foi dito acima e é algo que exige requer alguns ajustes baseados nos scripts que você carrega no seu site. Eis alguns plugins do WordPress que podem ajudar:

• Autoptimize
• Async JavaScript
• Hummingbird

Para uma explicação e um guia mais detalhados, recomendamos que confira nosso artigo sobre como eliminar JavaScript e CSS de bloqueio de renderização.

Combinar CSS e JavaScript Externos no WordPress

O aviso acerca sobre a combinação de CSS externos é normalmente encontrado ao usar um CDN, já você está hospedando seus arquivos CSS em um domínio externo, como cdn.domain.com. No passado, uma forma rápida de corrigir isso era concatenar seus arquivos CSS ou combiná-los para que eles fossem carregados em uma única solicitação.

Contudo, se você estiver executando o HTTPS com um provedor que oferece suporte para HTTP/2, esse aviso não é tão relevante como antigamente. Com o HTTP/2, vários arquivos CSS podem agora ser carregados em paralelo em uma única conexão. E mais de 86% dos navegadoé reconfigurar seu site WordPress pres suportam HTTP/2.

Mas isso não significa obrigatoriamente que essa otimização esteja totalmente obsoleta. Em alguns casos, notámos que isso acelera ainda os sites do WordPress. Depende do tamanho dos arquivos e quantos existem. Então, é uma otimização que deve ser ainda feita por você no seu site.

Uma das formas mais fáceis de combinar seus arquivos externos de CSS e JavaScript é usar o plugin gratuito Autoptimize. Depois de combinar os arquivos, você verá um arquivo “autoptimize_xxxxx.css” ou “autoptimize_xxxxx.js”. Também permite que você os carregue a partir do seu CDN. Você também pode fazer isso com o plugin WP Rocket.

Confira nosso artigo detalhado sobre como combinar CSS e JavaScript externos no WordPress.

Utilizar a Minificação em HTML, CSS e JavaScript

É possível reduzir a quantidade de dados que o navegador necessita de baixar, diminuindo os recursos HTML, CSS e JavaScript. A minificação é o processo que remove caracteres desnecessários, como comentários e espaços em branco, do código-fonte. Esses caracteres são bem úteis no desenvolvimento, mas são inúteis para o navegador renderizar a página.

HTML Não Minificado

Eis um exemplo de código HTML não minificado.

Você pode utilizar o plugin gratuito Autoptimize ou WP Rocket para facilmente minimizar seus arquivos.

Se você é um cliente Kinsta, então você tem acesso ao recurso de minificação de código embutido diretamente no painel MyKinsta. Isto permite aos clientes ativar rápida e facilmente a minificação automática de CSS e JavaScript com o clique de um botão e irá efetivamente acelerar seu site com zero esforço de trabalho manual.

Utilizar Domínios Sem Cookies

De uma forma geral, quando você está apresentando conteúdo como imagens, JavaScript, CSS, não existe qualquer razão para que haja um cookie HTTP no meio disso, pois cria sobrecarga adicional. Depois de o servidor definir um cookie para um domínio específico, todas as solicitações HTTP subsequentes para esse domínio devem incluir o cookie. Esse aviso é normalmente encontrado em sites com um grande número de solicitações.

Temos um artigo detalhado sobre como lidar com o aviso da apresentação de conteúdo estático a partir de um domínio sem cookies. Muitas vezes você pode ignorar esse aviso, já que novos protocolos como o HTTP/2 diminuíram a sua relevância. O custo de uma nova conexão é geralmente mais oneroso do que transmitir tudo através da mesma conexão.

Uma forma fácil de corrigir esse aviso é utilizar um provedor CDN que consegue ignorar e remover os cookies, o que impedirá totalmente que o cliente receba o cabeçalho de resposta Set-Cookie. O KeyCDN é um provedor de CDN que oferece esse recurso. Por padrão, você pode ver as duas opções seguintes como ativadas. Essa é uma forma fácil onde não precisa de mexer na colocação e na configuração do seu site para apresentar ativos estáticos de um subdomínio separado.

Se estiver correndo o Cloudflare, você não pode desativar os cookies nos recursos apresentados através da sua rede. CloudFlare coloca o seu próprio cookie de segurança no seu cabeçalho. Uma vez mais, esses cookies são muitos pequenos e a influência no desempenho é mínima. Mas, se você usar o CloudFlare, não tem como evitar esse aviso.

Uma segunda forma de contornar isso é reconfigurar seu site WordPress para entregar os ativos estáticos a partir de um novo domínio ou subdomínio.

Desativar Incorporações no WordPress

Quando eles lançaram o WordPress 4.4,  uniram o recurso oEmbed ao core. Isso permite aos usuários incorporarem vídeos do YouTube, tweets e muitos outros recursos em seus sites, bastando para isso colarem um URL, que o WordPress converte automaticamente em uma incorporação e apresenta uma visualização ao vivo no editor visual. Com a atualização, o próprio WordPress passou a ser um provedor de oEmbed.

Esse recurso é útil para muitas pessoas e é melhor você manter ele ativo. No entanto, isso também gera uma solicitação HTTP adicional para o seu site WordPress a fim de carregar o arquivo wp-embed.min.js. E isso é carregado em todo o site. Apesar de esse arquivo ter apenas 1.7 KB, coisas como essas vão se acumulando ao longo do tempo. A solicitação em si mesma, por vezes, é mais importante do que o tamanho do conteúdo baixado.

Você pode facilmente evitar que esse arquivo seja carregado. Aqui ficam três opções diferentes:

• Opção 1 – Desativar incorporações com um Plugin
• Opção 2 – Desativar incorporações com o Código
• Opção 3 – Mover o JavaScript Inline

Desativar Emojis no WordPress

Semelhante às incorporações no WordPress 4.2, eles adicionaram suporte para emojis no core para os navegadores mais antigos. O grande problema com isso é que isso provoca uma solicitação HTTP adicional no seu site WordPress para carreg wp-emoji-release.min.js. E isso é carregado em todo o site. Embora esse arquivo tenha apenas 10.5 KB, é inútil se você não estiver usando emoticons em seu site.

Existem algumas maneiras diferentes para desativar os Emojis no WordPress. Você pode fazer isso com um plugin grátis ou com código.

• Desativar Emojis com um Plugin
• Desativar emojis com Código

Como Acelerar os Comentários do WordPress ou Desative-os

Uma seção de comentários com muita participação em um site pode causar muitos problemas no desempenho. Você só precisa pensar nos recursos que são exigidos para fazer com que os comentários funcionem:

• Uma base de dados é consultada para que sejam apresentados os comentários existentes.
• As entradas na base de dados são criadas para cada novo comentário.
• Os comentários e os metadados dos comentários são recebidos e processados pelo navegador de um visitante.
• Os recursos externos, como Gravatars, são solicitados, baixados e carregados (exigindo uma pesquisa de DNS separada).
• Em muitos casos, recursos de grande dimensão de JavaScript e jQuery precisam ser baixados e processados para que o sistema de comentários funcione como suposto.

Aqui ficam quatro opções diferentes que pode fazer para acelerar os comentários do WordPress:

Opção 1 – Desativar Comentários

Se o seu site não está tendo muitos comentários e você acha que isso não traz qualquer valor para o seu website, a melhor opção pode ser desativar os comentários completamente. Vale a pena lembrar que os comentários podem afetar seu SEO, já que o Google normalmente rastreia esses itens como conteúdo adicional na página, por isso você deve apenas aprovar comentários de alta qualidade. Confira estas três formas simples de desativar os comentários:

• Desativar comentários dentro das opções do WordPress
• Desativar comentários com um Plugin
• Desativar comentários com código

Opção 2 – Otimizar Comentários Nativos do WordPress

A segunda opção é otimizar o sistema nativo de comentários do WordPress. Uma das formas seria reduzir o número de comentários carregados no carregamento inicial da página.

1. Entre em Configurações → Discussão na área de administração do WordPress.
2. Procure pela seção Configurações de outros comentários.
3. Marque a caixa de seleção ao lado de Quebrar comentários em páginas com e adicione um valor para o número de comentários que você deseja exibir com o carregamento inicial da página.

Também pode alojar os Gravatars que você utiliza no seu CDN. Essa é a nossa abordagem na Kinsta.

Por padrão, quando os comentários do WordPress são carregados, cada Gravatar único exige uma solicitação HTTP. Então, se uma página for carregada com comentários de 50 pessoas diferentes, 50 solicitações HTTP serão necessárias para baixar todos esses Gravatars. Como você pode imaginar, isso pode ter um impacto velocidade da página. Sem falar que já vimos que a pesquisa de DNS externa no gravatar.com pode por vezes ser lenta, em alguns casos, até mesmo atingir o tempo limite.

Se procurar pelos Gravatars no blog da Kinsta, você pode ver que eles estão carregados a partir da Kinsta.com (incluindo o nosso CDN). Confira a forma como pode carregar gravatars a partir do seu CDN.

Opção 3 – Utilize um Sistema de Comentários de Terceiros

A sua terceira opção é utilizar um sistema de comentários de terceiros. Se o seu site estiver alojado em um servidor compartilhado barato e sem recursos, utilizar um sistema de comentários de terceiros pode acelerar páginas que possuam muitos comentários. Essas ideias são as mesmas que já encontrámos na otimização de imagens, permitem diminuir a carga de trabalho. Contudo, se o seu alojamento for feito na Kinsta, ou em outro host de qualidade, a mudança para uma terceira entidade não será muito útil para acelerar a velocidade de carregamento do seu site e poderá até mesmo ter o efeito contrário.

Faça sempre um teste de velocidade ao sistema de comentários de terceiros que você está experimentando. Dê uma olhada em todas as solicitações que o Disqus gera (como mostramos abaixo). Apesar de a maioria dessas solicitações ser carregada de forma assíncrona, você continuará vendo algum tempo de carregamento adicional se estiver usando o Disqus.

Opção 4 – Comentários em Lazy Load

Sua quarta opção é apresentar os comentários seguindo o modelo lazy load, para que eles não atrasem a renderização inicial da página. Aqui ficam alguns plugins que você pode querer conferir:

• Lazy Load for Comments: Esse plugin permite a você fazer o lazy load dos comentários nativos do WordPress.
• Disqus Conditional Load: Se quiser usar o sistema de comentários Disqus, esse é um plugin obrigatório para fazer o lazy load dos comentários.

Desativar os Feeds RSS do WordPress

Se não estiver usando a seção de blog do WordPress no seu site, poderá desativar os feeds RSS do WordPress. Embora isso não tenha grande impacto no desempenho, tudo é útil. E também será menos uma coisa para preocupar.

Confira essas duas formas de desativar os feeds RSS no WordPress:

• Desativar o feed RSS com um Plugin
• Desativar o feed RSS com Código

Utilizar Prefetch e Preconnect

Pistas e diretivas de recursos como prefetch e preconnect podem ser uma excelente forma de acelerar o WordPress nos bastidores. O KeyCDN tem um ótimo artigo e perspetiva sobre a sugestões de recursos.

Prefetch

O prefetch de DNS permite que você solucione nomes de domínio (efetua uma pesquisa de DNS em segundo plano) antes que um usuário clique em um link o que, por sua vez, pode ajudar a melhorar o desempenho. Isso é feito adicionando uma tag rel=”dns-prefetch” no cabeçalho do seu site WordPress.

<link rel="dns-prefetch" href="//domain.com">

O URL do seu CDN, as fontes do Google ou o Google Analytics são alguns elementos onde pode aplicar o prefetch de DNS.

 <link rel="dns-prefetch" href="//cdn.domain.com/">
 <link rel="dns-prefetch" href="//fonts.googleapis.com/">
 <link rel="dns-prefetch" href="//www.google-analytics.com">

O prefetch também é suportado pela maioria dos navegadores modernos. Veja o nosso tutorial sobre como adicionar código ao seu cabeçalho do WordPress.

Ou pode facilmente implementar o prefetch de DNS usando um plugin como o Perfmatters. Só precisa de clicar no separador “Extras” no plugin Perfmatters e adicionar domínios. Formato:  //domain.tld (um por linha)

Preconnect

O preconnect permite que o navegador configure conexões antes de uma solicitação HTTP, eliminando a latência de ida e volta e poupando tempo para os usuários.

O preconnect é uma ferramenta importante na sua caixa de ferramentas de otimização… ela consegue retirar muitos percursos dispendiosos do caminho da sua solicitação – em alguns casos, reduz até a latência da solicitação em centenas ou mesmo milhares de milissegundos. – lya Grigorik (fonte)

Isso é feito adicionando uma tag rel=”preconnect” no cabeçalho do seu site WordPress.

<link rel="preconnect" href="//domain.com">

Pode querer utilizar isso no URL do seu CDN ou no Google Fonts.

 <link rel="preconnect" href="https://cdn.domain.com">
 <link rel="preconnect" href="https://fonts.gstatic.com">

O preconnect é suportado pela maioria dos navegadores modernos, com exceção do Internet Explorer, Safari, IOS Safari e Opera Mini. Confira nosso tutorial sobre como adicionar código ao cabeçalho do WordPress.

Ou pode implementar facilmente o preconnect usando um plugin como o Perfmatters. Só precisa clicar no separador “Extras” no plugin Perfmatters e adicionar domínios. Formato: scheme://domain.tld (um por linha).

Desativar Scripts com Base em Páginas/Artigos

Outro método muito eficaz para acelerar o WordPress é investigar cada solicitação que está sendo carregada em suas páginas e artigos. Você provavelmente acabará encontrando scripts que estão sendo carregados em todo o site e que não deveriam fazer isso.

Você pode utilizar um plugin premium como o Perfmatters, que possui um recurso “Gerenciador de Scripts” embutido. Isso permite a você desativar scripts (CSS e JavaScript) com base em páginas/artigos ou até mesmo em todo o site com um só clique. Novamente, este plugin foi desenvolvido por um membro da equipe da Kinsta.

Alguns exemplos das suas finalidades:

• O conhecido pluginContact Form 7 é carregado em todas as páginas e artigos. Você pode facilmente desativar esse plugin em todos esses lugares com um clique e ativar apenas na sua página de contato.
• Os plugins de compartilhamento para redes sociais só devem ser carregados nos seus artigos.Você pode facilmente desativar esses plugins em todos os lugares para que seja carregado em postagens ou até mesmo em tipos de postagem personalizados.
• O plugin Table of Contents(TOC) é carregado em todas as páginas e artigos. Com o gerenciador de scripts, você pode controlar facilmente onde deseja que ele seja carregado.

Por Que Razão Alguns Plugins São Codificados Dessa Forma?

Você pode estar se questionando sobre o porquê de todos os desenvolvedores de plugins não terem simplesmente feito as coisas para que seus scripts sejam apenas carregados quando o plugin é detetado na página? Bom, as coisas são mais complicadas do que isso. Por exemplo, se você tiver um plugin como o Contact Form 7, ele também tem códigos de acesso que permitem que você o coloque em qualquer lugar. Isso inclui a sua colocação em um widget. Com o WordPress, é muito mais difícil consultar os dados deles quando você remove scripts, em vez de consultar os dados a partir dos metadados de artigos ou páginas.

Por conseguinte, muitas vezes isso tem que ver com problemas de usabilidade. Quanto menor for a probabilidade de um plugin quebrar, menor será o número de tickets e apoio necessários. Contudo, com muitos plugins no mercado, existem formas de contornar isso e codificar o desempenho, se eles quisessem fazer isso. Infelizmente, por vezes o grande número de downloads e usuários torna a codificação de usabilidade uma prioridade.

Navegando pelo Gerenciador de Scripts

Vamos agora fazer uma curta visita ao Gerenciador de Scripts. Depois de clicar nele na sua barra de ferramentas, você verá todos os scripts que estão sendo carregados no URL atual, nos arquivos JavaScript e CSS. Você depois pode escolher entre essas seguintes opções:

1. Estado On (configuração padrão)
2. Estado Off: Desativar em Todos os Lugares (você pode escolher em que tipos de posts quer que ele esteja ativo, junto com o URL atual)
3. Estado Off: Desativar apenas no URL atual (isso é muito útil para usar em sua página inicial)
4. Estado Off: Exceções (URL atual, tipo de postagem ou arquivo)

Tudo é agrupado pelo plugin ou pelo nome do tema. Isso faz com que seja muito fácil desativar um plugin inteiro de uma só vez. Normalmente, um plugin do WordPress terá um arquivo JavaScript e outro de CSS. Um tema do WordPress pode ter mais de 10 arquivos.

Depois de selecionar e modificar as configurações, clique em “Salvar” na parte inferior. Depois pode fazer um teste com uma ferramenta de velocidade para websites a fim de garantir que os scripts não estão mais sendo carregados na página ou na postagem. Primeiro, deve limpar o seu cache! E, se algo der errado em seu site do ponto de vista visual, você poderá reativar tudo nas configurações para regressar normal.

Em um teste de velocidade do woorkup, eles foram capazes de diminuir os tempos de carregamento total em 20.2%. Apenas na sua homepage, eles conseguiram reduzir o número de solicitações HTTP de 46 para 30. O tamanho da sua homepage diminuiu de 506.3 KB para 451.6 KB.

Para saber outras formas de desativar os scripts, confira nossa postagem no blog sobre como desativar plugins WordPress para que não sejam carregados.

Analisando o Desempenho de Terceiros

De forma sucinta, qualquer coisa que você solicite externamente, para lá do seu site, tem consequências no tempo de carregamento. O que agrava esse problema é que algumas coisas são lentas de forma intermitente, dificultando ainda mais a identificação do problema.

Um serviço externo de terceiros pode ser qualquer coisa que se comunica com o seu site WordPress em um local externo ao seu próprio servidor. Aqui ficam alguns exemplos comuns que encontramos habitualmente:

• Plataformas de redes sociais como Twitter, Facebook e Instagram (widgets ou pixels de conversão)
• Redes de publicidade de terceiros, como o Google Adsense,net, BuySellAds, Amazon Associates
• Análise de sites e scripts de rastreamento, como o Google Analytics, Crazy Egg, Hotjar, AdRoll
• Ferramentas de teste A/B, como Optimizely, VWO, Unbounce
• Sistemas de comentários do WordPress, como Disqus, Jetpack, comentários no Facebook
• Backup e ferramentas de segurança, como VaultPress, Sucuri, CodeGuard
• Ferramentas de compartilhamento social, como SumoMe, HelloBar
• Redes CDN como KeyCDN, Amazon CloudFront, CDN77 e StackPath
• Javascript externamente alojado

Qual o impacto que alguns desses rastreadores de terceiros têm no desempenho? No nosso estudo de caso, vimos scripts de terceiros aumentarem os tempos de carregamento da página em 86.08%.

O Ghostery também mediu os 500 principais domínios dos EUA no Alexa, e os resultados foram surpreendentes, apesar de não termos ficado admirados. Os sites ficaram 2x mais lentos quando nenhum rastreador foi bloqueado. O que significa que esses scripts de acompanhamento de terceiros são um dos principais fatores para a diminuição da velocidade do carregamento de uma página web.

Você tem de ter muito atenção no seu site WordPress. Basta uma má solicitação por parte de uma API de terceiros pode fazer com que todo o seu site atinja o timeout! Sim, as coisas não deveriam ser assim, mas, em muitos casos, acontece. Já vimos isso acontecer imensas vezes.

O New Relic oferece uma excelente e fácil forma de monitorar seus serviços externos ao longo do tempo. No exemplo abaixo, podemos ver chamadas externas sendo feitas para o twitcount.com, graph.facebook.com e widgets.pinterest.com.

Sempre que você adiciona um novo recurso ou plugin ao seu site, deve investigar os recursos externos que estão sendo carregados a partir dele. Quanto menos, melhor!

Otimize Sempre Colocando os Aplicativos Móveis em Primeiro Lugar

O Google lançou seu primeiro índice móvel em 26 de março de 2018. Antes disso, os sistemas de crawling, indexação e rastreamento do Google usavam a versão desktop dos sites. A indexação para dispositivos móveis significa que o Googlebot irá agora usar a versão móvel do site do WordPress para fazer a indexação e a classificação. Isso ajuda a melhorar a experiência de busca para usuários que estão em dispositivos móveis.

Quando o assunto é otimizar o seu site para dispositivos móveis em primeiro lugar, a velocidade é um dos fatores mais importantes. A velocidade tem um papel importante em tudo, da usabilidade até as taxas de rejeição e à compreensão sobre se os possíveis compradores retornarão ou não ao seu site. De fato, a velocidade é agora um fator para classificar a página de entrada para o Google Search e Ads para buscas em dispositivos móveis.

As experiências móveis negativas farão com que a maioria jamais regresse. De acordo com o último relatório de velocidade de páginas do Google, o tempo médio que um site levou para carregar em dispositivos móveis no de 2018 foi 15 segundos. Você consegue imaginar ter de esperar tanto tempo para carregar uma só página? Surpreendente.

Os usuários exigem (e merecem) melhor. De acordo com o mesmo relatório de velocidade de página, 53% dos visitantes de um site em dispositivos móveis abandonam páginas que demoram mais do que três segundos a serem carregadas.

As experiências lentas em dispositivos móveis não estão matando as conversões. Estão impedindo você de ter uma oportunidade de converter potenciais clientes. À medida que os tempos de carregamento da página aumentam em apenas alguns segundos, a probabilidade de alguém sair sobe exponencialmente. Aqui ficam algumas coisas que deve considerar ao fazer a otimização para dispositivos móveis.

Confira O Seu Tráfego Móvel

É sempre importante dar uma olhada no tráfego móvel que você está recebendo, já que isso pode alterar um pouco as suas prioridades. Você pode ver quantos dispositivos móveis estão acedendo o seu site no Google Analytics em “Público → Móvel → Visão geral”. Como você pode ver nesse site, mais de 67% de todo o tráfego é proveniente de dispositivos móveis. Isso é muito!

Se você é um cliente Kinsta, também é possível conferir o tráfego em dispositivos móveis vs. Tráfego em computadores no MyKinsta Analytics. Como você pode ver nesse site, mais de 88% do tráfego provém de computadores. É sempre importante verificar e não apenas assumir algo sem dados. Só porque todo mundo está dizendo que o futuro é o móvel, isso nem sempre significa que tal seja válido para o seu site. Veja os dados.

Garanta que o Seu Site é Responsivo

Em 2019, é bom que o seu website seja responsivo! Isso significa que utiliza consultas de mídia para reduzir automaticamente a escala para os dispositivos móveis. Se você ainda não fez isso, provavelmente já está a trás da sua concorrência. Todos os temas do WordPress que mencionámos anteriormente nesse artigo são totalmente responsivos e têm um visual fantástico em todos os dispositivos.

Utilize a ferramenta do Mobile-Friendy do Google para testar e garantir que seu site cumpre todos os requisitos.

Verifique Duplamente para Garantir que o srcset está Funcionando

Antigamente, era muito importante que você fizesse o upload de imagens em escala, sem permitir que o CSS fizesse o redirecionamento. Contudo, isso deixou de ser tão importante assim, já que o WordPress 4.4 agora suporta imagens responsivas (cuja dimensão não é reduzida pelo CSS). O WordPress cria automaticamente vários tamanhos de cada imagem carregada na biblioteca de mídia. Ao incluir os tamanhos disponíveis de uma imagem em um atributo srcset, os navegadores podem agora optar por baixar o tamanho mais apropriado e ignorar os outros. Veja um exemplo de como é o seu código.

Tendo em consideração todos os plugins e personalizações de imagens de terceiros que existem por aí, já encontrámos muitas situações onde isso não funciona corretamente. É importante verificar novamente se suas imagens estão recebendo corretamente o atributo srcset adicionado com diferentes versões para diferentes tamanhos de tela. A otimização de imagem é agora para sempre e continuará sendo.

O Google AMP Pode Ser Solução Para Você

O Google AMP (Projeto Accelerated Mobile Pages) foi originalmente lançado em outubro de 2015. O projeto assenta no AMP HTML, um novo framework open-source construído inteiramente a partir de tecnologias web já existentes, que permite que os websites construam páginas web leves. Simplificando, oferece uma forma de apresentar uma versão simples da sua página web atual.

A nossa relação com o Google AMP é de amor e ódio, e muita da comunidade também acha o mesmo. Nós testámos isso e não encontrámos bons resultados. No entanto, isso não significa que você não tenha resultados positivos. Cada site é diferente e o Google AMP está sendo constantemente melhorado.

Você pode começar usando rapidamente o Google AMP no seu site WordPress com um dos seguintes plugins:

• AMP para WordPress
• AMP para WP

Confira o nosso tutorial detalhado sobre como obter a configuração do Google AMP. E, se você precisar, como desativar o Google AMP. Não é apenas algo que você possa desativar e pronto.

Resumo

Como você provavelmente conseguirá perceber, somos obcecados com todas as formas diferentes que permitem a você acelerar o WordPress. Ter um site rápido ajuda a aumentar sua classificação, melhora a capacidade de rastreamento dos mecanismos de busca, melhora as taxas de conversão, aumenta o tempo no site e diminui sua taxa de rejeição. Sem mencionar o fato de que todo mundo adora visitar um site rápido!

Esperamos que esse guia de aceleração tenha sido útil e que você tenha conseguido tirar boas ideias para que as possas aplicar no seu site WordPress. Se sim, por favor compartilhe com a gente.

Deixámos algo importante de fora? Se sim, gostaríamos de saber o quê. Use os comentários abaixo para falar sobre as suas dicas para acelerar o WordPress.