Carregar JavaScript de terceiros

Addy Osmani

Arthur Evans

Se você otimizou seu código, mas o site ainda carrega muito lentamente, é provável que seja culpa dos scripts de terceiros.

Os scripts de terceiros oferecem uma variedade de recursos úteis que tornam a Web mais dinâmica, interativa e interconectada. Alguns deles podem até ser cruciais para a função ou o fluxo de receita do seu site. No entanto, usá-los é arriscado:

• Eles podem prejudicar o desempenho do site.
• Elas podem causar problemas de privacidade ou segurança.
• Eles podem ser imprevistos e o comportamento deles pode ter consequências imprevistas.

O ideal é garantir que scripts de terceiros não afetem o caminho crítico de renderização do site. Neste guia, você vai saber como encontrar e corrigir problemas relacionados ao carregamento de JavaScript de terceiros e minimizar os riscos para os usuários.

O que são scripts de terceiros?

O JavaScript de terceiros geralmente se refere a scripts que podem ser incorporados a qualquer site diretamente de um fornecedor terceirizado. Por exemplo:

• Botões de compartilhamento em redes sociais (Facebook, X, LinkedIn, Mastodon)

• Incorporações do player de vídeo (YouTube, Vimeo)

• Iframes de publicidade

• Scripts de métricas e análises

• Scripts de testes A/B para experimentos

• Bibliotecas auxiliares, como formatação de data, animação ou bibliotecas funcionais.

Exemplo de incorporação de vídeo do YouTube que pode ser adicionada a uma página usando o código a seguir.

<iframe
  width="560"
  height="315"
  src="https://www.youtube.com/embed/mo8thg5XGV0"
  frameborder="0"
  allow="autoplay; encrypted-media"
  allowfullscreen
>
</iframe>

Infelizmente, a incorporação de scripts de terceiros significa que muitas vezes dependemos deles para serem executados com rapidez e não deixarem nossas páginas lentas. Scripts de terceiros são uma causa comum de lentidão de desempenho causada por recursos fora do controle do proprietário do site, incluindo os seguintes problemas:

• Acionar muitas solicitações de rede para vários servidores. Quanto mais solicitações um site tiver que fazer, mais tempo levará para carregar.

• Envio de excesso de JavaScript que mantém a linha de execução principal ocupada. JavaScript em excesso pode bloquear a construção do DOM, o que atrasa a renderização da página. A análise e a execução de scripts que fazem uso intensivo da CPU podem atrasar a interação do usuário e causar consumo elevado de bateria.

• O envio de vídeos ou arquivos de imagem grandes não otimizados pode consumir dados e gerar custos para os usuários.

• Problemas de segurança que podem atuar como um ponto único de falha (SPOF, na sigla em inglês) se a página carregar um script sem cuidado.

• Armazenamento em cache HTTP insuficiente, forçando o navegador a enviar mais solicitações de rede para buscar recursos.

• A falta de compactação do servidor suficiente faz com que os recursos sejam carregados lentamente.

• Bloquear a exibição do conteúdo até a conclusão do processamento. Isso também pode ser verdadeiro para scripts de teste A/B assíncronos.

• Uso de APIs legadas conhecidas por prejudicar a experiência do usuário, como document.write().

• Excesso de elementos DOM ou seletores de CSS caros.

• Incluir várias incorporações de terceiros pode fazer com que vários frameworks e bibliotecas sejam extraídos várias vezes, desperdiçando recursos e piorando os problemas de desempenho atuais.

• Os scripts de terceiros geralmente usam técnicas de incorporação que podem bloquear window.onload caso os servidores respondam lentamente, mesmo que a incorporação esteja usando assincronia ou adiamento.

A capacidade de corrigir problemas com scripts de terceiros pode depender do seu site e da sua capacidade de configurar o carregamento de códigos de terceiros. Felizmente, existem várias soluções e ferramentas para localizar e corrigir problemas com recursos de terceiros.

Como identificar um script de terceiros em uma página?

O primeiro passo para otimizá-los é identificar scripts de terceiros no seu site e determinar o impacto deles na performance. Recomendamos o uso de ferramentas sem custo financeiro de teste de velocidade da Web, incluindo Chrome DevTools, PageSpeed Insights e WebPageTest, para identificar scripts caros. Essas ferramentas exibem informações de diagnóstico avançadas que podem informar quantos scripts de terceiros seu site usa e quais levam mais tempo para serem executados.

A visualização em hierarquia do WebPageTest pode destacar o impacto do uso intenso de scripts de terceiros. A imagem a seguir de Tags Gone Wild mostra um exemplo de diagrama das solicitações de rede necessárias para carregar o conteúdo principal de um site, em oposição aos scripts de acompanhamento e marketing.

Os scripts nesta página levam mais tempo para carregar do que a página em si.

O detalhamento de domínios do WebPageTest também pode ser útil para visualizar a quantidade de conteúdo que vem de terceiros. Ele divide o valor pelo total de bytes e pelo número de solicitações:

Os gráficos de detalhamento de domínios mostram quanto do conteúdo de uma página vem de terceiros.

Como faço para medir o impacto do script de terceiros na minha página?

Quando você notar que um script está causando problemas, descubra o que ele faz e determine se o site precisa dele para funcionar. Se necessário, faça um teste A/B para equilibrar o valor percebido e o impacto nas principais métricas de engajamento ou desempenho do usuário.

Auditoria do tempo de inicialização do Lighthouse

A auditoria do tempo de inicialização do JavaScript do Lighthouse destaca scripts que têm um alto tempo de análise, compilação ou avaliação. Isso pode ajudar você a identificar scripts de terceiros com uso intensivo da CPU.

A auditoria do tempo de inicialização mostra quais scripts demoram mais para carregar.

Auditoria de payloads de rede do Lighthouse

A auditoria de payloads de rede do Lighthouse identifica solicitações de rede, incluindo solicitações de rede de terceiros que diminuem o tempo de carregamento da página e fazem com que os usuários gastem mais do que esperam em dados móveis.

A auditoria de payloads de rede mostra quais solicitações de rede levam mais tempo e buscam mais dados.

Bloqueio de solicitações de rede do Chrome DevTools

O Chrome DevTools permite ver como sua página se comporta quando um script, folha de estilo ou outro recurso especificado não está disponível. Isso é feito com o bloqueio de solicitações de rede, um recurso que ajuda a medir o impacto da remoção de recursos individuais de terceiros da sua página.

Para ativar o bloqueio de solicitações, clique com o botão direito do mouse em qualquer solicitação no painel "Rede" e selecione Bloquear URL da solicitação. Uma guia de bloqueio de solicitação é exibida na gaveta do DevTools, permitindo que você gerencie quais solicitações foram bloqueadas.

Bloqueie solicitações de rede individuais para ver como sua página se comporta sem elas.

Painel de desempenho do Chrome DevTools

O painel Desempenho no Chrome DevTools ajuda a identificar problemas com o desempenho da sua página na Web.

1. Clique em Gravar.
2. Carregue sua página. O DevTools mostra um diagrama de hierarquia representando o tempo de carregamento do seu site.
3. Navegue até Bottom-up na parte inferior do painel "Performance".
4. Clique em Agrupar por produto e classifique os scripts de terceiros da página pelo tempo de carregamento.

Scripts de terceiros classificados por produto, começando pelo maior tempo de carregamento.

Para saber mais sobre como usar o Chrome DevTools para analisar o desempenho do carregamento de páginas, consulte Introdução à análise do desempenho do ambiente de execução.

Confira a seguir nosso fluxo de trabalho recomendado para medir o impacto de scripts de terceiros:

1. Use o painel "Rede" para medir quanto tempo leva para carregar sua página.
   • Para emular condições reais, recomendamos ativar a limitação de rede e a limitação da CPU. É improvável que seus usuários tenham as conexões de rede rápidas e o hardware de desktop que reduzem o impacto de scripts caros em condições de laboratório.
2. Bloqueie os URLs ou domínios responsáveis por scripts de terceiros que você acredita serem um problema. Consulte o Painel de desempenho do Chrome DevTools para receber orientações sobre como identificar scripts caros.
3. Atualize a página e meça o tempo de carregamento novamente.
   • Para dados mais precisos, meça seu tempo de carregamento pelo menos três vezes. Isso leva em conta alguns scripts de terceiros que buscam recursos diferentes em cada carregamento de página. Para ajudar com isso, o painel de desempenho do DevTools oferece suporte a várias gravações.

Medir o impacto de scripts de terceiros com o WebPageTest

O WebPageTest permite bloquear o carregamento de solicitações individuais para medir o impacto delas em Configurações avançadas > Bloquear. Use esse recurso para especificar uma lista de domínios a serem bloqueados, como domínios de publicidade.

Neste painel, liste os domínios que você quer bloquear.

Recomendamos o fluxo de trabalho a seguir para usar esse recurso:

1. Teste uma página sem bloquear terceiros.
2. Repita o teste com alguns terceiros bloqueados.
3. Selecione os dois resultados do Histórico de testes.
4. Clique em Comparar.

Selecione os resultados do teste de carga para comparar.

A imagem a seguir mostra o recurso de tira de vídeo do WebPageTest comparando as sequências de carregamento das páginas com e sem recursos ativos de terceiros. Recomendamos verificar essa configuração em testes de origens individuais de terceiros para determinar quais domínios afetam mais o desempenho da sua página.

O impacto do bloqueio de recursos de terceiros, de Como usar o WebPageTest para avaliar o impacto das tags de terceiros, de Andy Davies.

O WebPageTest também oferece suporte a dois comandos que operam no nível de DNS para domínios de bloqueio:

• blockDomains usa uma lista de domínios que serão bloqueados.
• blockDomainsExcept usa uma lista de domínios e bloqueia tudo que não estiver na lista.

O WebPageTest também tem uma guia de ponto único de falha (SPOF, na sigla em inglês) que permite simular um tempo limite ou uma falha completa no carregamento de um recurso. Ao contrário do bloqueio de domínio, o SPOF expira lentamente, o que pode ser útil para testar o comportamento das páginas quando os serviços de terceiros estão sobrecarregados ou temporariamente indisponíveis.

Use o recurso de teste SPOF para simular a falha de domínios especificados.

Detectar iframes caros usando tarefas longas

Quando os scripts em iframes de terceiros levam muito tempo para serem executados, eles podem bloquear a linha de execução principal e atrasar outras tarefas. Essas tarefas longas podem fazer com que os manipuladores de eventos funcionem lentamente ou que os frames caiam, piorando a experiência do usuário.

Para detectar tarefas longas no Real User Monitoring (RUM) (em inglês), use a API PerformanceObserver do JavaScript para observar entradas longtask. Essas entradas contêm uma propriedade de atribuição que pode ser usada para determinar qual contexto de frame causou a tarefa longa.

O código a seguir registra entradas de longtask no console, incluindo uma para um iframe "caro":

<script>
  const observer = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      // Attribution entry including "containerSrc":"https://example.com"
      console.log(JSON.stringify(entry.attribution));
    }
  });

  observer.observe({entryTypes: ['longtask']});
</script>

<!-- Imagine this is an iframe with expensive long tasks -->
<iframe src="https://example.com"></iframe>

Para saber mais sobre o monitoramento de tarefas longas, consulte Métricas de desempenho centradas no usuário.

Como carregar scripts de terceiros com eficiência?

Se um script de terceiros estiver diminuindo o carregamento da página, você terá várias opções para melhorar o desempenho:

• Carregue o script usando o atributo async ou defer para evitar o bloqueio da análise do documento.
• Se o servidor de terceiros estiver lento, considere hospedar o script por conta própria.
• Se o script não agregar um valor claro ao site, remova-o.
• Use dicas de recursos, como <link rel=preconnect> ou <link rel=dns-prefetch>, para realizar uma busca DNS em domínios que hospedam scripts de terceiros.

Use async ou defer

A execução do JavaScript bloqueia o analisador. Quando o navegador encontra um script, ele precisa pausar a construção do DOM, transmitir o script ao mecanismo JavaScript e permitir que o script seja executado antes de continuar a construção.

Os atributos async e defer mudam esse comportamento da seguinte maneira:

• async faz com que o navegador faça o download do script de forma assíncrona enquanto continua analisando o documento HTML. Quando o download do script é concluído, a análise é bloqueada enquanto o script é executado.

• defer faz com que o navegador faça o download do script de forma assíncrona enquanto continua analisando o documento HTML e espera executar o script até que a análise do documento seja concluída.

Sempre use async ou defer para scripts de terceiros, a menos que o script seja necessário para o caminho crítico de renderização. Use async se for importante que o script seja executado mais cedo no processo de carregamento, como para alguns scripts de análise. Use defer para recursos menos críticos, como vídeos que são renderizados em uma posição mais baixa na página do que o usuário verá inicialmente.

Se o desempenho for sua principal preocupação, recomendamos que você aguarde para adicionar scripts assíncronos até que o conteúdo essencial da sua página seja carregado. Não recomendamos o uso de async para bibliotecas essenciais, como jQuery.

Observação: no Chrome e em outros navegadores baseados no Blink, async e defer diminuem a prioridade da solicitação de rede para recursos. Assim, ela pode carregar muito mais tarde do que seria com um script de bloqueio. Isso é útil especialmente para scripts de análise.

Alguns scripts precisam ser carregados sem async ou defer, especialmente aqueles que são partes essenciais do site. Isso inclui bibliotecas de interface ou frameworks de rede de fornecimento de conteúdo (CDN) que não funcionam sem seu site.

Outros scripts simplesmente não funcionam se forem carregados de maneira assíncrona. Verifique na documentação se há scripts que você esteja usando e substitua aqueles que não podem ser carregados de forma assíncrona por alternativas que possam. Saiba que alguns terceiros recomendam executar os scripts de maneira síncrona, mesmo que eles funcionem bem de forma assíncrona.

O async não corrige tudo. Se a página incluir um grande número de scripts, como scripts de acompanhamento para fins publicitários, o carregamento assíncrono não vai impedir que o carregamento da página fique mais lento.

Usar dicas de recursos para reduzir o tempo de configuração da conexão

Estabelecer conexões com origens de terceiros pode levar muito tempo, especialmente em redes lentas, porque as solicitações de rede têm vários componentes complexos, incluindo buscas DNS e redirecionamentos. É possível usar Dicas de recursos, como , para realizar buscas DNS em domínios que hospedam scripts de terceiros no início do processo de carregamento de página, para que o restante da solicitação de rede possa prosseguir mais rapidamente posteriormente:

<link rel="dns-prefetch" href="http://example.com" />

Se o domínio de terceiros ao qual você está se conectando usa HTTPS, também é possível usar o , que executa buscas DNS e resolve idas e voltas do TCP e lida com negociações de TLS. Essas outras etapas podem ser muito lentas porque envolvem a verificação de certificados SSL. Portanto, a pré-conexão pode diminuir muito o tempo de carregamento.

<link rel="preconnect" href="https://cdn.example.com" />

Scripts de "sandbox" com um iframe

Se você carregar um script de terceiros diretamente em um iframe, ele não vai bloquear a execução da página principal. A AMP usa essa abordagem para manter o JavaScript fora do caminho crítico. Essa abordagem ainda bloqueia o evento onload. Portanto, tente não anexar recursos essenciais a onload.

O Chrome também oferece suporte à Política de permissões (antiga Política de recursos), um conjunto de políticas que permitem que um desenvolvedor desative seletivamente o acesso a determinados recursos do navegador. Você pode usar isso para evitar que o conteúdo de terceiros introduza comportamentos indesejados em um site.

Auto-hospedar scripts de terceiros

Se você quiser ter mais controle sobre como um script crítico é carregado, por exemplo, para reduzir o tempo de DNS ou melhorar os cabeçalhos de cache HTTP, talvez seja possível hospedá-lo por conta própria.

No entanto, a auto-hospedagem também traz alguns problemas, especialmente quando se trata de atualizar scripts. Os scripts auto-hospedados não receberão atualizações automáticas para alterações de API ou correções de segurança, o que pode levar a perdas de receita ou problemas de segurança até que você possa atualizar seu script manualmente.

Como alternativa, é possível armazenar scripts de terceiros em cache usando service workers para ter mais controle sobre a frequência com que os scripts são buscados na rede. Também é possível usar service workers para criar estratégias de carregamento que limitam solicitações não essenciais de terceiros até que a página alcance um momento importante do usuário.

Faça testes A/B com amostras menores de usuários

O teste A/B (ou teste de divisão) é uma técnica para testar duas versões de uma página e analisar a experiência e o comportamento do usuário. Ela disponibiliza as versões da página para diferentes amostras do tráfego do seu site e determina, com base na análise, qual versão oferece uma taxa de conversão melhor.

No entanto, por padrão, o teste A/B atrasa a renderização para decidir qual experimento precisa estar ativo. Muitas vezes, o JavaScript é usado para verificar se algum dos seus usuários pertence a um experimento de teste A/B e, em seguida, ativar a variante correta. Esse processo pode piorar a experiência mesmo para usuários que não fazem parte do experimento.

Para acelerar a renderização da página, recomendamos enviar os scripts de teste A/B para uma amostra menor da sua base de usuários e executar o código que decide qual versão da página será exibida no lado do servidor.

Carregamento lento de recursos de terceiros

Recursos incorporados de terceiros, como anúncios e vídeos, podem ser os principais contribuidores para a lentidão da página quando construídos mal. O carregamento lento pode ser usado para carregar recursos incorporados somente quando necessário, por exemplo, aguardando para veicular anúncios no rodapé da página até que o usuário role o suficiente para vê-los. Também é possível fazer o carregamento lento do conteúdo de terceiros depois que o conteúdo da página principal for carregado, mas antes que um usuário interaja com a página.

É possível fazer o carregamento lento de recursos que o usuário não verá imediatamente quando a página carregar.

Tenha cuidado ao fazer o carregamento lento de recursos, porque ele geralmente envolve código JavaScript que pode ser afetado por conexões de rede lentas.

Observação: LazySizes é uma biblioteca JavaScript conhecida para carregamento lento de imagens e iframes. O recurso é compatível com incorporações e widgets do YouTube.

A DoubleClick tem orientações sobre o carregamento lento de anúncios na documentação oficial.

Carregamento lento eficiente com o Intersection Observer

Historicamente, os métodos para detectar se um elemento está visível na janela de visualização para fins de carregamento lento são propensos a erros e geralmente deixam o navegador mais lento. Esses métodos ineficientes geralmente detectam eventos de rolagem ou resize e usam APIs DOM, como getBoundingClientRect(), para calcular a relação dos elementos com a janela de visualização.

IntersectionObserver é uma API de navegador que permite que os proprietários de páginas detectem com eficiência quando um elemento observado entra ou sai da janela de visualização do navegador. O LazySizes também tem suporte opcional para IntersectionObserver.

Análise de carregamento lento

Se você adiar o carregamento dos scripts de análise por muito tempo, poderá perder dados de análise valiosos. Felizmente, há estratégias disponíveis para inicializar lentamente a análise e manter os dados iniciais do carregamento de página.

A postagem do blog de Phil Walton, A configuração do Google Analytics que uso em cada site que construo, aborda uma dessas estratégias para o Google Analytics.

Carregar scripts de terceiros com segurança

Esta seção fornece orientações para carregar scripts de terceiros da maneira mais segura possível.

Evite document.write()

Scripts de terceiros, especialmente para serviços mais antigos, às vezes usam document.write() para injetar e carregar scripts. Isso é um problema porque o document.write() se comporta de forma inconsistente e as falhas são difíceis de depurar.

A correção dos problemas de document.write() é não usá-lo. No Chrome 53 e versões mais recentes, o Chrome DevTools registra avisos no console para uso problemático de document.write():

O Chrome DevTools sinaliza o uso do document.write().

Se você receber esse erro, verifique o uso de document.write() no seu site procurando os cabeçalhos HTTP enviados ao navegador. O Lighthouse também pode destacar scripts de terceiros que ainda usam document.write() (link em inglês).

Um relatório do Lighthouse mostrando quais scripts usam document.write().

Use os Gerenciadores de tags com cuidado

Uma tag é um snippet de código que permite que as equipes de marketing digital coletem dados, definam cookies ou integrem conteúdo de terceiros, como widgets de mídias sociais, em um site. Essas tags adicionam solicitações de rede, dependências de JavaScript e outros recursos à página que podem afetar o desempenho. Assim, é mais difícil minimizar esse impacto para os usuários à medida que mais tags são adicionadas.

Para manter o carregamento da página rápido, recomendamos o uso de um gerenciador de tags, como o Gerenciador de tags do Google (GTM). Com o GTM, você pode implantar tags de maneira assíncrona para que elas não impeçam o carregamento umas das outras, reduzir o número de chamadas de rede de que um navegador precisa para executar tags e coletar dados das tags na IU da Camada de dados.

Riscos do uso de gerenciadores de tags

Embora os gerenciadores de tags sejam projetados para simplificar o carregamento de página, o uso deles pode desacelerar o carregamento das seguintes maneiras:

• Com o número excessivo de tags e listeners de eventos automáticos no gerenciador de tags, o navegador faz mais solicitações de rede do que o necessário e reduz a capacidade do código de responder aos eventos rapidamente.
• Qualquer pessoa com credenciais e acesso pode adicionar JavaScript ao seu Gerenciador de tags. Além de aumentar o número de solicitações de rede caras necessárias para carregar a página, isso também pode apresentar riscos de segurança e outros problemas de desempenho devido a scripts desnecessários. Para reduzir esses riscos, recomendamos limitar o acesso ao Gerenciador de tags.

Evitar scripts que poluam o escopo global

Os scripts de terceiros podem se comportar de várias maneiras que podem corromper sua página de forma inesperada:

• Os scripts que carregam dependências de JavaScript podem poluir o escopo global com códigos que interagem mal com ele.
• Atualizações inesperadas podem causar alterações interruptivas.
• O código de terceiros pode ser modificado em trânsito para se comportar de maneira diferente entre o teste e a implantação da página.

Recomendamos realizar auditorias regulares dos scripts de terceiros que você carrega para verificar se há usuários de má-fé. Também é possível implementar os autotestes, a integridade de sub-recursos e a transmissão segura de código de terceiros para manter sua página segura.

Estratégias de mitigação

Confira algumas estratégias em grande escala para minimizar o impacto de scripts de terceiros no desempenho e na segurança do seu site:

• HTTPS: os sites que usam HTTPS não podem depender de terceiros que usam HTTP. Para saber mais, consulte Conteúdo misto.

• Sandbox: considere executar scripts de terceiros em iframes com o atributo sandbox para restringir as ações disponíveis aos scripts.

• Política de Segurança de Conteúdo (CSP, na sigla em inglês): use cabeçalhos HTTP na resposta do servidor para definir comportamentos de scripts confiáveis no site, além de detectar e reduzir os efeitos de alguns ataques, como o scripting em vários locais (XSS).

Confira a seguir um exemplo de como usar a diretiva script-src da CSP para especificar as fontes JavaScript permitidas de uma página:

// Given this CSP header Content-Security-Policy: script-src
https://example.com/ // The following third-party script will not be loaded or
executed

<script src="https://not-example.com/js/library.js"></script>

Leia mais

Para saber mais sobre como otimizar o JavaScript de terceiros, recomendamos que você leia:

• Desempenho e resiliência: testes de estresse de terceiros (em inglês)
• Adicionar interatividade com o JavaScript
• Possíveis perigos com scripts de terceiros
• Como scripts de terceiros podem melhorar o desempenho na Web
• Por que é importante: magia de CSS
• O paradoxo da cadeia de suprimentos do JavaScript: SRI, CSP e confiança em bibliotecas de terceiros (em inglês)
• O CSS de terceiros não é seguro

Um agradecimento a Kenji Baheux, Jeremy Wagner, Pat Meenan, Philip Walton, Jeff Posnick e Cheney Tsai pelas avaliações.