Carregar JavaScript de terceiros

Addy Osmani

Arthur Evans

Se você otimizou o código, mas o site ainda carrega muito lentamente, provavelmente a 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 o funcionamento ou o fluxo de receita do seu site. No entanto, o uso deles é arriscado:

• Eles podem reduzir a performance do site.
• Eles podem causar problemas de privacidade ou segurança.
• Eles podem ser imprevisíveis, e o comportamento deles pode ter consequências indesejadas.

O ideal é garantir que os scripts de terceiros não afetem o caminho de renderização crítico do site. Neste guia, vamos mostrar 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 de players de vídeo (YouTube, Vimeo)

• Iframes de publicidade

• Scripts de análise e métricas

• Scripts de teste A/B para experimentos

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

Um exemplo de incorporação de vídeo do YouTube que pode ser adicionado 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, incorporar scripts de terceiros significa que muitas vezes dependemos deles para que sejam executados rapidamente e não deixem nossas páginas mais lentas. Os scripts de terceiros são uma causa comum de lentidão no desempenho causada por recursos fora do controle do proprietário do site, incluindo os seguintes problemas:

• Disparar muitas solicitações de rede para vários servidores. Quanto mais solicitações um site precisa fazer, mais tempo ele pode levar para carregar.

• Envio de muito JavaScript, o que mantém a linha de execução principal ocupada. O excesso de JavaScript 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 consomem muita CPU podem atrasar a interação do usuário e causar o consumo da bateria.

• O envio de arquivos de imagem ou vídeos grandes e não otimizados pode consumir dados e custar dinheiro aos usuários.

• Problemas de segurança que podem atuar como um ponto único de falha (SPOF, na sigla em inglês) se o carregamento de 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 faz com que os recursos sejam carregados lentamente.

• Bloqueio da exibição de conteúdo até que o processamento seja concluído. Isso também pode acontecer com scripts de teste A/B assíncronos.

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

• Elementos DOM excessivos 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.

• Os scripts de terceiros costumam usar técnicas de incorporação que podem bloquear window.onload se os servidores responderem lentamente, mesmo que a incorporação use async ou defer.

A capacidade de corrigir problemas com scripts de terceiros pode depender do seu site e da sua capacidade de configurar como você carrega o código de terceiros. Felizmente, existem várias soluções e ferramentas para encontrar e corrigir problemas com recursos de terceiros.

Como identificar scripts de terceiros em uma página?

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

A visualização em cascata 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 vez dos scripts de acompanhamento e marketing.

Os scripts nesta página levam mais tempo para carregar do que a própria página.

A divisão de domínios do WebPageTest também pode ser útil para visualizar quanto conteúdo vem de origens de terceiros. Ele divide isso pelo total de bytes e pelo número de solicitações:

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

Como posso medir o impacto do script de terceiros na minha página?

Quando um script estiver causando problemas, descubra o que ele faz e determine se ele é necessário para o funcionamento do site. Se necessário, faça um teste A/B para equilibrar o valor percebido em relação ao impacto no engajamento do usuário ou nas métricas de performance.

Auditoria de tempo de inicialização do Lighthouse

A auditoria de tempo de inicialização do JavaScript do Lighthouse destaca scripts que têm um tempo de análise, compilação ou avaliação de script caro. Isso pode ajudar a identificar scripts de terceiros que usam muita CPU.

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

Auditoria de payloads de rede do Lighthouse

A auditoria de payloads de rede do Lighthouse identifica solicitações de rede, incluindo as de terceiros, que deixam o tempo de carregamento da página mais lento e fazem os usuários gastarem mais do que o esperado 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 que você veja como sua página se comporta quando um script, uma 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 pode ajudar 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 Network e selecione Bloquear URL de solicitação. Uma guia de bloqueio de solicitações é 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 "Performance" no Chrome DevTools ajuda a identificar problemas com a performance da Web da sua página.

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

Scripts de terceiros classificados por produto, começando com o tempo de carregamento mais longo.

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

Este é o fluxo de trabalho recomendado para medir o impacto de scripts de terceiros:

1. Use o painel Network para medir o tempo de carregamento da página.
   • Para emular condições reais, recomendamos ativar a limitação de rede e a limitação de CPU. É improvável que seus usuários tenham as conexões de rede rápidas e o hardware de computador 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 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 o tempo de carregamento pelo menos três vezes. Isso ocorre porque alguns scripts de terceiros buscam recursos diferentes em cada carregamento de página. Para ajudar com isso, o painel "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.

Liste os domínios que você quer bloquear neste painel.

Recomendamos o seguinte fluxo de trabalho 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 no 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 miniatura do WebPageTest comparando as sequências de carregamento de páginas com e sem recursos de terceiros ativos. Recomendamos verificar isso para testes de origens de terceiros individuais, 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 medir o impacto de tags de terceiros, por Andy Davies.

O WebPageTest também é compatível com dois comandos que operam no nível do DNS para bloquear domínios:

• blockDomains recebe uma lista de domínios para bloquear.
• blockDomainsExcept recebe uma lista de domínios e bloqueia tudo que não está nela.

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 ao carregar um recurso. Ao contrário do bloqueio de domínio, o SPOF expira lentamente, o que pode ser útil para testar como suas páginas se comportam quando os serviços de terceiros estão sob carga pesada ou temporariamente indisponíveis.

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

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 sejam descartados, piorando a experiência do usuário.

Para detectar tarefas longas para o Monitoramento de usuários reais (RUM), use a API JavaScript PerformanceObserver para observar as 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 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 performance centradas no usuário.

Como carregar scripts de terceiros de forma eficiente?

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

• Carregue o script usando o atributo async ou defer para evitar o bloqueio da análise de documentos.
• Se o servidor de terceiros estiver lento, considere hospedar o script por conta própria.
• Se o script não agregar valor ao seu 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 para o mecanismo JavaScript e permitir que o script seja executado antes de continuar com a construção do DOM.

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

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

• defer faz com que o navegador baixe o script de forma assíncrona enquanto continua a analisar o documento HTML e aguarde para 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 de renderização crítico. Use async se for importante que o script seja executado no início do processo de carregamento, como em alguns scripts de análise. Use defer para recursos menos críticos, como vídeos que são renderizados mais abaixo na página do que o usuário verá inicialmente.

Se a performance for sua principal preocupação, recomendamos que você aguarde para adicionar scripts assíncronos até que o conteúdo crítico da 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, o que pode fazer com que eles sejam carregados significativamente mais tarde do que seriam como um script de bloqueio. Isso é útil para saber, em especial, sobre scripts de análise.

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

Outros scripts não funcionam se forem carregados de forma assíncrona. Verifique a documentação de todos os scripts que você está usando e substitua os que não podem ser carregados de forma assíncrona por alternativas que podem. Alguns terceiros recomendam executar os scripts de forma síncrona, mesmo que eles funcionem igualmente bem de forma assíncrona.

Lembre-se de que o async não corrige tudo. Se a página incluir um grande número de scripts, como scripts de acompanhamento para fins de publicidade, o carregamento assíncrono não vai impedir que eles deixem o carregamento da página 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 da página, para que o restante da solicitação de rede possa prosseguir mais rapidamente depois:

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

Se o domínio de terceiros ao qual você está se conectando usar HTTPS, também será possível usar , que realiza buscas DNS e resolve idas e voltas de TCP e processa negociações TLS. Essas outras etapas podem ser muito lentas porque envolvem a verificação de certificados SSL. Portanto, a pré-conexão pode reduzir bastante 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 críticos a onload.

O Chrome também é compatível com a Política de permissões (antiga Política de recursos), um conjunto de políticas que permite que um desenvolvedor desative seletivamente o acesso a determinados recursos do navegador. Você pode usar isso para impedir que 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 armazenamento em cache HTTP, hospede-o por conta própria.

No entanto, a auto-hospedagem tem seus próprios problemas, especialmente quando se trata de atualizar scripts. Os scripts auto-hospedados não recebem atualizações automáticas para mudanças na 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 o script manualmente.

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

Fazer 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 para analisar a experiência e o comportamento do usuário. Ele disponibiliza as versões da página para diferentes amostras do tráfego do seu site e determina, com base em análises, 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. O JavaScript é frequentemente 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 até 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 servidor.

Carregamento lento de recursos de terceiros

Recursos de terceiros incorporados, como anúncios e vídeos, podem ser os principais responsáveis pela Velocidade de página lenta quando são mal construídos. 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. Você também pode carregar conteúdo de terceiros de forma lenta depois que o conteúdo da página principal for carregado, mas antes que um usuário interaja com a página.

Você pode carregar de forma lenta os recursos que o usuário não verá imediatamente quando a página for carregada.

Tenha cuidado ao carregar recursos de forma lenta, porque isso geralmente envolve código JavaScript que pode ser afetado por conexões de rede instáveis.

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

O DoubleClick tem orientações sobre como fazer 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 redimensionamento e usam APIs DOM, como getBoundingClientRect(), para calcular onde os elementos estão em relação à janela de visualização.

IntersectionObserver é uma API de navegador que permite aos proprietários de páginas detectar 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 o 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, existem estratégias disponíveis para inicializar a análise de forma lenta, mantendo os dados de carregamento de página iniciais.

A postagem do blog de Phil Walton A configuração do Google Analytics que uso em todos os sites que crio 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 maneira inconsistente, e as falhas dele são difíceis de depurar.

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

Uso das

flags do Chrome DevTools document.write().

Se você receber esse erro, verifique se o site usa document.write() procurando cabeçalhos HTTP enviados ao navegador. O Lighthouse também pode destacar scripts de terceiros que ainda usam document.write().

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

Use os Tag Managers 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 redes sociais, em um site. Essas tags adicionam solicitações de rede, dependências de JavaScript e outros recursos à sua página que podem afetar o desempenho dela. Minimizar esse impacto para os usuários fica mais difícil à medida que mais tags são adicionadas.

Para manter o carregamento de página rápido, recomendamos usar um Tag Manager, como o Google Tag Manager (GTM). O GTM permite implantar tags de forma assíncrona para que elas não bloqueiem o carregamento umas das outras, reduz o número de chamadas de rede que um navegador precisa fazer para executar tags e coleta dados de tags na interface da camada de dados.

Riscos de usar gerenciadores de tags

Embora os gerenciadores de tags sejam projetados para simplificar o carregamento de páginas, o uso descuidado pode deixá-lo mais lento das seguintes maneiras:

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

Evite scripts que poluam o escopo global

Os scripts de terceiros podem se comportar de várias maneiras que quebram sua página inesperadamente:

• Os scripts que carregam dependências de JavaScript podem poluir o escopo global com códigos que interagem mal com o seu.
• 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 sua 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 o autoteste, 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 na performance e na segurança do seu site:

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

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

• Política de Segurança de Conteúdo (CSP): use cabeçalhos HTTP na resposta do servidor para definir comportamentos de script confiáveis para seu site e detectar e mitigar os efeitos de alguns ataques, como scripting em vários sites (XSS).

Veja um exemplo de como usar a diretiva script-src da CSP para especificar as origens de 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>

Leitura adicional

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

• Desempenho e resiliência: teste de estresse de terceiros
• Adicionar interatividade com JavaScript
• Possíveis perigos com scripts de terceiros
• Como os scripts de terceiros podem ser cidadãos de alto desempenho na Web
• Why Fast Matters - CSS Wizardry (em inglês)
• O Paradoxo da Cadeia de Suprimentos do JavaScript: SRI, CSP e Confiança em Bibliotecas de Terceiros
• O CSS de terceiros não é seguro

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