Muitos artigos sobre otimização focam em como você pode acelerar seu site WordPress, através  de otimização de imagens ou migração para uma hospedagem mais rápida. Embora tudo isso seja importante, hoje queremos discutir o impacto do desempenho de terceiros e como isso afeta seu site WordPress. Basicamente, tudo o que você consulta externamente em seu site apresenta consequências no tempo de carregamento. O que torna esse problema ainda pior é que alguns deles são lentos apenas intermitentemente, dificultando ainda mais sua identificação. Hoje, vamos explorar formas de identificar e analisar serviços de terceiros e problemas de desempenho.

O Que São Serviços Externos de Terceiros?

Um serviço externo de terceiros pode ser considerado tudo aquilo que se comunica com seu site WordPress e que está fora do seu servidor. Aqui estão alguns exemplos comuns que encontramos com frequência:

  • Plataformas de mídias sociais como Twitter, Facebook e Instagram (widgets ou pixels de conversão)
  • Redes de publicidade de terceiros como Google AdSense, Media.net, BuySellAds e Amazon Associates
  • Análise de websites como Google Analytics, Crazy Egg e Hotjar
  • Ferramentas de teste A/B como Optimizely, VWO e Unbounce
  • Sistemas de comentários para WordPress como Disqus, Jetpack e Facebook Comments
  • Backup e ferramentas de segurança como VaultPress, Sucuri e CodeGuard
  • Ferramentas de compartilhamento social como SumoMe e HelloBar
  • Redes CDN como KeyCDN, Amazon CloudFront, CDN77 e StackPath
  • Javascript hospedado externamente

Como Serviços Externos Causam Problemas

Serviços externos costumam carregar consigo dois problemas. Um é relacionado ao volume absoluto, enquanto o outro é o tempo de espera até que eles carreguem.

  • Se você tem muitos serviços externos, precisa carregar todos eles e aguardar que as informações sejam carregadas em cada página. Quando mais conexões você tiver, maior será a espera, a carga em seu servidor e as chances de se deparar com o segundo problema.
  • Em alguns casos, o carregamento da página aguardará até que a transferência de dados seja concluída entre seu site e o serviço externo. Se o serviço for chamado no cabeçalho e houver uma interrupção nele, sua página simplesmente se recusará a ser carregada.

Obviamente, existem ações que podem ser tomadas para acelerar os processos, como por exemplo carregar scripts de maneira assíncrona, mas entraremos em maiores detalhes mais adiante. Na maioria dos casos, o volume absoluto é um dos maiores desafios que você enfrentará quando estiver depurando problemas de desempenho de terceiros.

Identificando Serviços Externos

Identificar esses serviços não é muito difícil. Uma das formas mais fáceis é acessar uma ferramenta de teste de velocidade de websites, como Pingdom, GTmetrix, WebPageTest ou Chrome Devtools, e analisar seu site através dela. Você deverá ser capaz de observar uma lista de recursos que foram carregados. Passe o mouse por cima de um recurso e se ele não apresentar o nome do seu domínio no início, trata-se de um serviço ou ativo externo que está sendo conectado ao seu site.

Abaixo, é possível observar que a versão minificada do jQuery foi carregada a partir de uma fonte externa (https://ajax.googleapis.com).

Serviço externo – Javascript

Se você não sabe para que serve um serviço externo, pode tentar acessar o domínio principal ou pesquisar por seu nome no Google, pois um desenvolvedor ou empresa responsável deverá aparecer. Essa é uma boa forma de determinar se o serviço é legítimo. Como é possível observar abaixo, pesquisar por “arquivo jQuery” traz resultados sobre empresas conhecidas, como jQuery e o próprio Google, que descreve a hospedagem desse arquivo. Portanto, provavelmente se trata de uma fonte segura.

Script jQuery externo
Script jQuery externo

Analisando Problemas Contínuos de Desempenho de Terceiros

Se seu website está sempre lento, você precisa descobrir o que está reduzindo sua velocidade. Se ele apresentar problemas intermitentes será um pouco mais difícil. Vamos começar com lentidão contínua. Estamos presumindo que seu site está lento em virtude dos serviços externos. Embora muitos problemas de velocidade possam ser causados por eles, há uma grande quantidade de outros tipos de problemas, portanto pode ser que isso não resolva sua situação.

Primeiro, é necessário determinar se há um serviço que está levando muito tempo para carregar e como isso afeta o desempenho do seu site. Assim, configuramos um site de testes hospedado na Kinsta e que contém:

  • 2 Anúncios do Google AdSense
  • Facebook Like Box
  • Widget do Instagram
  • Comentários Disqus
  • Pixel de rastreamento de conversão do Facebook
  • Google Analytics
Site de testes no WordPress
Site de testes no WordPress

Isso nos permitirá remover cada serviço um por um e mostrar o quanto cada um deles afeta o carregamento geral do seu site. Também vamos compartilhar algumas estratégias de formas alternativas para carregá-los. Você pode aplicar as mesmas estratégias em seu próprio site WordPress. Rodamos o site de testes no Pingdom e alguns dos primeiros detalhes que você pode observar são o “tamanho do conteúdo por domínio” e as “solicitações por domínio”. Se estiver visualizando solicitações que não tiverem o nome do seu domínio, tenha em mente que provavelmente se tratam de serviços ou ativos externos. Esse é um bom ponto de início. Como você pode observar abaixo, static.xx.fbcdn.net tem 37 solicitações, o que é muito ruim!

Serviços externos no Pingdomv
Serviços externos no Pingdom – (teste de velocidade)

O tempo de carregamento do site também foi de 1,94 segundo, o que não é nada bom, porque o site de teste não tem nenhum conteúdo. Esse é um teste de menor escala para ajudá-lo a analisar melhor o desempenho de terceiros. Quanto maior o site WordPress, maiores se tornam os problemas. Mas a maioria deles pode ser fundamentalmente resolvida de formas similares.

Abordagem com o Google AdSense

O primeiro fator que queremos abordar é o Google AdSense. Em geral, quando executamos um teste de velocidade, é possível passar o mouse sobre cada barra para observar quanto tempo cada parte do processo de carregamento levou para ser executado. Você deve procurar pelas barras mais longas (comparadas ao restante) e locais onde elas só começam a carregar após uma barra particular ser concluída – esses são seus gargalos. Após encontrar um elemento específico que leve mais tempo ou que impeça outros recursos de carregarem, você precisa descobrir por que ele está lá e de onde vem.

Isso pode ser um pouco difícil, pois a chamada para o serviço pode estar codificada em seu tema ou vir de um plugin. Entretanto, conforme mencionamos antes, também há o problema do volume absoluto. Se observarmos as solicitações abaixo originadas de pagead2.googlesyndication.com e tpc.googlesyndication.com, podemos notar que as barras são relativamente curtas, o que significa que elas não estão causando muito atraso. Porém algumas possuem um maior tempo de recebimento (barra verde), que é o quanto o navegador leva para receber dados do servidor. O grande problema aparece quando você soma todas as solicitações juntas.

Gostamos de chamar o Google AdSense de serviço variável de terceiros. Isso porque cada vez que uma página é carregada, uma quantidade diferente de solicitações e ativos é carregada. Isso dificulta determinar o que está causando os problemas de desempenho, uma vez que ele é diferente cada vez que você roda um teste. Abaixo, temos um pequeno fragmento de algumas solicitações de terceiros que os anúncios estavam gerando. Eles também criam redirecionamentos que possuem seus próprios atrasos.

Solicitações externas do Google AdSense
Solicitações externas do Google AdSense

Você pode pensar que é loucura que apenas dois anúncios gerem tantas solicitações, mas é assim que eles funcionam.

Opção 1 – Carregamento Assíncrono

Sua primeira opção é garantir que eles sejam carregados de forma assíncrona. O atributo async basicamente informa ao navegador para começar a fazer o download do recurso imediatamente, sem retardar a análise do HTML. Quando o recurso estiver disponível, a análise do HTML é pausada para que ele possa ser carregado. Códigos gerados recentemente no Google AdSense possuem esse atributo por padrão, mas se você tem um código há alguns anos, recomendamos que o verifique.

<script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
<!-- nogluten-top-right-page-300x250 -->
<ins class="adsbygoogle" style="display: block;" data-ad-client="ca-pub-xxxxxxxxxxx" data-ad-slot="9805695044" data-ad-format="auto"></ins>
<script>
(adsbygoogle = window.adsbygoogle || []).push({});
</script>

Certifique-se de ler nosso outro post sobre eliminação de blocos de renderização de JavaScript e CSS. Ele poderá te ajudar a entender melhor como scripts carregam e funcionam em seu site WordPress.

Opção 2 – Removê-los

Outra opção é remover totalmente o Google AdSense. Obviamente, para alguns sites que dependem da receita de anúncios de terceiros, essa não é uma alternativa válida. Mas já vimos alguns sites de eCommerce que colocaram alguns anúncios AdSense em suas páginas para tentar receber uma renda extra. Você deve estar atento aos problemas de desempenho que isso acarreta. Se estiver vendendo produtos ou serviços, um anúncio do Google AdSense talvez atrapalhe mais do que ajude e pode acabar prejudicando sua fonte principal de receita. Para blogueiros, é possível fazer a comparação entre anúncios de afiliados e Google AdSense. Muitas vezes, os anúncios de afiliados podem ser carregados em sua CDN e requerem uma única solicitação.

Neste exemplo, vamos fazer sua remoção para mostrar como apenas dois pequenos anúncios podem afetar o desempenho do seu site WordPress. Assim, rodamos outro teste de velocidade após retirá-los e, como você pode observar, nossos tempos de carregamento caíram de 1,94 segundo para 909ms! As solicitações foram de 185 para 138 e o tamanho geral de nossa página foi reduzido de 2 MB apara 1,7 MB.

Após remover Google AdSense
Após remover Google AdSense (teste de velocidade)

É isso mesmo! Dois pequenos anúncios adicionaram cerca de um segundo ao nosso tempo de carregamento geral. Por isso, a menos que seu modelo de receita gire em torno da publicidade de terceiros, não recomendamos que os coloque em seu site WordPress. Se você tem um problema com uma rede de anúncios e possui um plugin que cuide dessa rede para você, são grandes as chances de chegar a uma solução ao desabilitá-lo. Se ele estiver codificado no próprio tema, você precisará modificar os arquivos do tema em questão. Recomendamos fazer as duas coisas se for um desenvolvedor (se não for, você pode saber mais sobre como encontrar um bom desenvolvedor WordPress).

Abordagem com o Facebook Like Box

O próximo local a observar foi o Facebook Like Box, que estava causando todas aquelas solicitações static.xx.fbcdn.net e scontent.xx.fbcdn.net. Podemos ver que as barras são relativamente curtas, o que significa que elas não estão causando tanta lentidão. No entanto, quando somadas elas revelam o problema. Novamente, se trata de uma questão de volume absoluto.

Solicitações do widget do Facebook
Solicitações do widget do Facebook

Recomendamos que todos os proprietários de sites fiquem longe do Facebook Like Box! Ele não só gera muitas solicitações para Javascript externo, como também carrega muitas imagens. Aqui estão três recomendações para lidar com isso.

Opção 1 – Carregamento Assíncrono

Para usar o Facebook Like Box, você ou um desenvolvedor precisaria adicionar o seguinte código ao cabeçalho do seu site WordPress. Existem alguns widgets do WordPress que também adicionam uma caixa automaticamente.

<script>(function(d, s, id) {
 var js, fjs = d.getElementsByTagName(s)[0];
 if (d.getElementById(id)) return;
 js = d.createElement(s); js.id = id;
 js.src = "//connect.facebook.net/en_US/sdk.js#xfbml=1&version=v2.9&appId=1697897870426976";
 fjs.parentNode.insertBefore(js, fjs);
}(document, 'script', 'facebook-jssdk'));</script>

O problema com o código acima é que ele não está carregando de forma assíncrona. O atributo async basicamente informa ao navegador para começar a fazer o download do recurso imediatamente, sem retardar a análise do HTML. Quando o recurso estiver disponível, a análise do HTML é pausada para que ele possa ser carregado. Não temos certeza do motivo pelo qual o Facebook não adicionou esse atributo ao script, mas você pode ver a versão modificada abaixo, que será carregada de forma assíncrona.

<script>(function(d, s, id) {
 var js, fjs = d.getElementsByTagName(s)[0];
 if (d.getElementById(id)) return;
 js = d.createElement(s); js.id = id;
 js.async=true; js.src = "//connect.facebook.net/en_US/sdk.js#xfbml=1&version=v2.9&appId=1697897870426976";
 fjs.parentNode.insertBefore(js, fjs);
}(document, 'script', 'facebook-jssdk'));</script>

Você provavelmente não perceberá muita diferença nos tempos de carregamento se fizer a verificação no Pingdom, mas seus visitantes com certeza notarão, já que isso afeta como/quando os scripts e ativos são carregados.

Opção 2 – Use Um Banner de Imagem em seu Lugar

A próxima recomendação é substituir o Facebook Like Box por um banner de imagem que simplesmente aponte para sua página do Facebook. Isso reduziria instantaneamente mais de 40 solicitações para apenas uma e você não teria mais nenhuma dependência externa. É possível ser muito criativo e ter um bom equilíbrio entre design e desempenho.

Opção 3 – Livre-se Dele

Por fim, a última opção seria se livrar dele completamente. Como você pode observar abaixo, fizemos isso em nosso site de testes e nosso tempo de carregamento caiu de 909 ms para 786 ms. O tamanho geral da página foi reduzido de 1,7 MB para 1,0 MB e o número total de solicitações foi de 138 para 78. Um detalhe que realmente merece ser destacado é a redução do peso da página. O Facebook Like Box adicionava 700 KB! Isso era muito ruim.

Após remover o Facebook Like Box
Após remover o Facebook Like Box ( teste de velocidade )

Abordagem com o Widget do Instagram

O próximo passo é olhar o widget do Instagram. Em nosso exemplo, usamos o plugin gratuito Instagram Feed. Na verdade, o plugin em si não é o problema, mas as solicitações geradas a partir de scontent.cdninstagram.com são as culpadas. Como é possível observar, as barras são curtas, o que significa que não estavam causando muito atraso. No entanto, o problema aparece quando elas são somadas. Novamente, trata-se de um problema de volume absoluto. É possível notar um padrão sendo formado aqui. Muitos problemas de desempenho de terceiros nos sites WordPress não são decorrentes de atrasos de uma única solicitação, mas sim de desenvolvedores que sequer se preocupam com desempenho.

Solicitações externas do Instagram
Solicitações externas do Instagram

Também recomendamos que as pessoas fiquem longe do widget do Instagram, a menos que ele realmente seja necessário, pois gera muitas solicitações. Aqui estão algumas recomendações para lidar melhor com a situação.

Opção 1 – Use Um Banner de Imagem em seu Lugar

Assim como no caso do Facebook Like Box, a menos que você realmente precise de um widget dinâmico do Instagram, crie um banner que direcione os visitantes para sua página no Instagram. Isso reduziria instantaneamente as mais de 20 solicitações para apenas uma e você não teria mais nenhuma dependência externa. É possível ser muito criativo e ter um bom equilíbrio entre design e desempenho.

Opção 2 – Livre-se Dele

É claro que você pode simplesmente se livrar dele completamente. Como você pode observar abaixo, fizemos isso em nosso site de testes e nosso tempo de carregamento caiu de 786 ms para 690 ms. O tamanho geral da página foi reduzido de 1,0 MB para 814,3 MB e o número total de solicitações foi de 78 para 57.

Após remover o widget do Instagram
Após remover o widget do Instagram (teste de velocidade)

Abordagem com os Comentários Disqus

O próximo fator a observar são os comentários no Disqus. Em nosso exemplo, usamos o plugin gratuito Disqus Comment System. O grande problema com o Disqus é que ele gera muitas solicitações, além de precisar carregar um gravatar para cada pessoa individual que estiver comentando. Entramos em maiores detalhes sobre isso em nosso post sobre como acelerar os comentários no WordPress.

Você também pode querer desativar completamente os comentários no WordPress.

Se você tem um grande site comercial, também precisa pagar para remover os anúncios no Disqus, do contrário ainda mais solicitações acabarão sendo geradas. É possível ver abaixo um pequeno fragmento de algumas solicitações que estão sendo geradas.

Solicitações externas do Disqus
Solicitações externas do Disqus

Aqui estão algumas recomendações para lidar com comentários.

Opção 1 – Lazy Load com Comentários Disqus

Lazy loading é o processo de não carregar ativos e scripts até que a pessoa role a página para baixo. Isso garante que a primeira página carregue mais rapidamente. Você pode usar lazy loading com facilidade nos comentários Disqus usando o plugin gratuito Disqus Conditional Load, de Joel James. Nós o usamos aqui no blog da Kinsta. Instalamos o plugin em nosso site de testes e, como pode ser observado abaixo, ele reduziu nossos tempos de carregamento de 690 ms para 603 ms. Diminuiu o tamanho geral da página de 814 KB para 366,1 KB e o número total de solicitações foi de 57 para 24. Um detalhe a destacar é a grande redução no peso da página!

lazy loading com Disqus
Após lazy loading com Disqus (teste de velocidade)

Opção 2 – Lazy Load com Comentários Nativos do WordPress

Uma opção ainda melhor seria usar lazy loading com os comentários nativos do WordPress. Joel James, o desenvolvedor do plugin de lazy load para Disqus, também possui um plugin gratuito chamado Lazy Load for Comments. Ele funciona de uma forma similar à opção mencionada acima. Fizemos sua instalação em nosso site de testes e, como é possível ver abaixo, ele resultou basicamente na mesma redução no tempo de carregamento.

Após lazy loading com os comentários nativos do WordPress
Após lazy loading com os comentários nativos do WordPress (teste de velocidade)

Abordagem com o Pixel de Rastreamento de Conversão do Facebook

Por fim, vamos dar uma olhada no pixel de rastreamento de conversão do Facebook. Obviamente, a maioria das pessoas o utiliza para coletar dados sobre os visitantes de seus websites ou para rastrear conversões enquanto divulgam anúncios no Facebook. Portanto, sua remoção nem sempre é uma opção viável e não há nada que possa ser feito para melhorar seu desempenho. Como você pode observar abaixo, ele é responsável por gerar cinco solicitações HTTP diferentes e, infelizmente, elas não são muito rápidas.

Solicitações externas do pixel de rastreamento de conversão do Facebook
Solicitações externas do pixel de rastreamento de conversão do Facebook

Simplesmente o removemos para mostrar a você o quanto ele afeta o desempenho do seu site. Após dispensá-lo, os tempos de carregamento foram reduzidos de 611 ms para 429 ms. O tamanho total da página foi reduzido de 367,5 KB para 343,2 KB e o número total de solicitações foi de 27 para 22.

Após remover o pixel do FB
Após remover o pixel do FB (teste de velocidade)

Os exemplos acima são apenas alguns dos milhares de serviços externos que podem estar sendo executados em seu site WordPress. É importante observar cada um deles e determinar o quanto afetam o desempenho do seu site. Como vimos, uma única maçã podre pode ser capaz de causar grandes problemas!

Serviços Externos Podem Ajudar no Desempenho

Embora a maioria dos serviços externos prejudique o desempenho do seu site, existem alguns que podem ajudá-lo. Uma CDN, como KeyCDN ou Cloudflare, pode acelerar drasticamente seu site com uma instalação mínima envolvida. Verifique nosso tutorial sobre como configurar KeyCDN e como instalar Cloudflare. No exemplo abaixo, adicionamos KeyCDN ao nosso site de testes. Como é possível observar, ele reduziu nosso tempo de carregamento em 100 ms.

Após configurar a CDN
Após configurar a CDN (teste de velocidade)

Outras Otimizações

Em seguida, fizemos algumas otimizações adicionais no site WordPress para conseguirmos alcançar uma classificação de desempenho de 100 pontos e um tempo de carregamento de 270 ms. Tais otimizações incluíram:

  • Certificarmos que tudo estivesse carregando a partir da CDN. Isso significa hospedar fontes do Google localmente e resulta em uma única solicitação HTTP/2.
  • Remover ativos adicionais que geravam solicitações HTTP desnecessárias, como emojis, embeds, migrações jQuery, etc. Para isso, usamos o plugin perfmatters.

Aqui estão tutoriais mais aprofundados para algumas das otimizações:

Após as otimizações
Após as otimizações (teste de velocidade)

Como é possível observar, fomos de tempos de carregamento de 1,94 segundo para 270 ms! Obviamente, talvez você precise de alguns serviços externos, afinal todos os negócios precisam. Mas é importante não se esquecer de analisar cada um deles. Se você notar grandes tempos de carregamento, contate o desenvolvedor ou a empresa responsável pelo serviço e informe o problema.

Prevenindo Stalled Loading

O maior problema ocorre quando um script impede o carregamento da página enquanto ele termina de carregar a si mesmo. Se um script como esse estiver presente no cabeçalho, ele é capaz de manter seu website em branco indefinidamente. Por isso, tudo que não for absolutamente necessário no cabeçalho deve ser posicionado rodapé. Isso permitirá que seu website carregue completamente antes que o script problemático comece a ser carregado. Se você usa a função wp_enqueue_script()(e deveria usar), é possível utilizar o quinto parâmetro para indicar que ele deve ser carregado no rodapé.

Caso perceba que um plugin carrega um ativo no cabeçalho sem nenhum motivo, você pode usar a função wp_dequeue_script()para removê-lo do cabeçalho e, em seguida, usar wp_enqueue_script() para registrá-lo da mesma forma, mas dessa vez no rodapé.

Utilizando o Google Tag Manager

Outra forma de ajudar a resolver problemas de desempenho de terceiros é utilizar uma ferramenta gratuita como Google Tag Manager. Ela permite que você gerencie todos os seus scripts e tags em um só lugar. Alguns benefícios de fazer isso são o carregamento assíncrono, a facilidade de gerenciamento e a possibilidade de ativar gatilhos para as páginas em que os scripts são carregados.

Ativando gatilhos no Google Tag Manager
Ativando gatilhos no Google Tag Manager

Entretanto, existem algumas desvantagens ao fazer isso também.

O Google Tag Manager não reduz o número de tags em seu site ou aplicativo, mas ele simplifica a tarefa de gerenciá-los. Para websites, o Google Tag Manager é executado de forma assíncrona e pode ser configurado para ativar tags somente quando elas são necessárias, ajudando suas páginas a carregarem mais rapidamente. (fonte)

Se você usa o Google Tag Manager, saiba que também haverá outra solicitação HTTP e consulta DNS de googletagmanager.com, mesmo que ela seja insignificante.

Solicitação googletagmanager.com
Solicitação googletagmanager.com

Recomendamos que verifique o Google Tag Manager para sites grandes sem otimização que possuem muitos serviços e integrações de terceiros. Para sites menores que possuem desenvolvedores, é provável que você não observe um aumento significativo de desempenho usando o GTM.

Analisando Problemas Intermitentes de Desempenho de Terceiros

A forma que você resolve problemas intermitentes é a mesma usada para solucionar problemas contínuos, mas a identificação do culpado é mais complexa. Implementar as soluções acima pode ajudar, mas ainda assim seria bom descobrir o que está causando o problema. Uma ferramenta que gostamos de usar para essa finalidade é New Relic e se você for um usuário Kinsta, todos os dias monitoramos com New Relic o seu site ou permitimos que você utilize sua própria chave de licença New Relic. Abaixo, é possível observar um exemplo de algumas redes de anúncios de terceiros e grandes tempos de carregamento associados a elas durante um determinado período.

rede de anúncios externa
Monitoramento com New Relic – rede de anúncios externa

Ironicamente, no entanto, o próprio New Relic pode causar problemas de desempenho. Nesse caso, recomendamos usá-lo apenas para resolver problemas e esporadicamente para monitoramento, não para uma utilização contínua. Você também pode usar uma ferramenta como GTmetrix para agendar horários de verificação de velocidade em seu site. Após alguns dias, você pode verificar novamente e observar os resultados em um pequeno gráfico:

GTmetrix relatando tempos de carregamento
GTmetrix relatando tempos de carregamento

Ele informa quando seu site esteve mais lento que a média. Clicamos no pico do lado direito primeiro para ir ao relatório criado para aquele período. Em seguida, visualizamos a lista em cascata para observar quais recursos criaram o problema. Lembre-se de verificar nosso post aprofundado sobre como usar GTmetrix para diagnosticar problemas em seu site.

Tabela em cascata do GTmetrix
Tabela em cascata do GTmetrix

Há um ativo que parece bloquear os demais. Veja a barra verde no meio. Ela é do Google Recaptcha. 632 ms pode parecer um piscar de olhos, mas na verdade é muito tempo. Uma página deve carregar na faixa de dois segundos. Mais de um terço desse tempo está sendo utilizado por um único ativo. Ele deve ser carregado no final ou simplesmente ser trocado por outros métodos de verificação de autenticidade.

Resumo

Como é possível observar, apenas alguns serviços externos são capazes de causar um grande impacto. O desempenho de terceiros não deve ser ignorado e anda de mãos dadas com otimizações dentro no site e no back-end. Felizmente existem muitas ações que podem ser tomadas, especialmente se envolvermos um desenvolvedor. Descartar serviços, fazer alterações neles para que carreguem de formas diferentes (como carregamento assíncrono), oferecer o mesmo conteúdo em uma maneira alternativa (como um banner), tudo isso pode desempenhar um papel importante para tornar seu site muito mais rápido!

Brian Jackson

Brian tem uma enorme paixão pelo WordPress, e tem utilizado há mais de uma década e até desenvolve alguns plugins premium. Brian gosta de blogs, filmes e caminhadas. Conecte-se com Brian no Twitter.