Addy Osmani

Atualmente, recursos de terceiros (como incorporações e scripts) são muito usados na Web. Eles fornecem soluções prontas para incorporar mídias sociais, vídeos, análises, chat ao vivo, publicidade, testes A/B, personalização e outros. As incorporações de terceiros são uma parte necessária dos sites modernos. Com elas, os proprietários podem se concentrar nas principais competências e, ao mesmo tempo, descarregar as funções padrão, mas essenciais, para provedores externos.

Quando uma página da Web trabalha em harmonia, tanto terceiros quanto terceiros podem proporcionar uma ótima experiência ao usuário. No entanto, isso exige um esforço significativo das equipes de engenharia e negócios e geralmente é negligenciado, resultando em páginas da Web com desempenho inferior e um impacto negativo nas métricas centradas no usuário, como as Core Web Vitals. Isso é prejudicial para ambas as partes e cria oportunidades perdidas para os negócios. Podemos fazer melhor aqui?

Temos uma visão futura da Web, em que scripts e recursos de terceiros fornecem o valor comercial pretendido com regressão mínima ao desempenho ou à experiência do usuário dos sites que os utilizam no navegador. Isso permite que os usuários tenham carregamentos de página mais rápidos.

No ano passado, consideramos, discutimos e testamos muitas possibilidades que poderiam proteger a experiência do usuário do impacto prejudicial de scripts de terceiros sem reduzir o valor comercial deles para os proprietários dos sites.

Nesta postagem, queremos compartilhar informações sobre alguns dos nossos experimentos. Esperamos que este seja o início de um processo que incentive a transparência e a visibilidade entre user agents, empresas e provedores terceirizados e prepare o caminho para uma Web mais rápida.

Uma análise mais detalhada sobre terceiros

Um terceiro é um recurso disponibilizado por um provedor externo ao site. Eles não estão diretamente sob o controle dos proprietários do site, mas estão presentes com sua aprovação. Os recursos de terceiros são:

• Hospedado em uma origem compartilhada e pública diferente da origem principal do site.
• Não criados nem influenciados por um proprietário de site.
• Amplamente usado por diversos sites.

De ajudar a gerar receita (com anúncios) até oferecer melhores oportunidades de marketing (incorporações de mídia social), terceiros atendem a uma ampla variedade de objetivos de negócios. As categorias comuns de terceiros incluem o seguinte:

Fonte: terceiros por categoria.

Esses scripts e bibliotecas de terceiros permitem que os desenvolvedores da Web aproveitem soluções testadas e aprovadas para implementar recursos padrão, em vez de reinventar a roda. Assim, terceiros reduzem o tempo de desenvolvimento e ajudam as empresas a lançar ou atualizar os produtos mais rapidamente. Não é de se admirar que mais de 94% de todos os sites em computadores e dispositivos móveis usem terceiros.

Como terceiros afetam a performance?

O ideal é que desenvolvedores de terceiros sejam especialistas no assunto para os recursos específicos que fornecem. Os terceiros mais populares passaram por várias iterações, e é possível esperar que seu código seja otimizado para suas próprias metas de negócios, que podem ou não incluir o desempenho das páginas que os utilizam. No entanto, mesmo os terceiros mais bem otimizados afetam o desempenho. Estes são os principais motivos desse impacto:

1. Custos de execução de script e tamanho: os terceiros geralmente buscam fornecer uma funcionalidade significativa "simplesmente" colocando um elemento <script> ou <iframe> na sua página. Esses elementos então extraem scripts e recursos de tamanho significativo e que levam mais tempo para serem baixados e executados. O excesso de JavaScript mantém a linha de execução principal ocupada por mais tempo, bloqueia a renderização e atrasa as interações do usuário. Alguns dos principais terceiros foram conhecidos por bloquear a linha de execução principal de 42 ms para 1,6 s em mais de 50% dos sites analisados. Uma linha de execução principal bloqueada resulta em um tempo total de bloqueio (TBT, na sigla em inglês) alto, que é uma das métricas que afeta a pontuação de desempenho do site. Além disso, ele também atrasa a resposta às interações do usuário e degrada a métrica Interaction to Next Paint (INP) usada para medir a capacidade de resposta dos sites. Portanto, os custos de execução de script têm um impacto significativo no desempenho.

2. Número: em média, os sites usam cerca de 21 terceiros diferentes na Web e em dispositivos móveis. Muitas vezes, as tags de terceiros são adicionadas por ferramentas de gerenciamento de tag que não são controladas diretamente pelas equipes técnicas/de desenvolvimento. As tags que não são necessárias podem ser adicionadas por outras equipes sem um processo de revisão e nunca são removidas. Eles podem afetar significativamente a experiência do usuário, o peso da página ou o uso da CPU. Estabelecer um processo de governança pode lidar com essas situações e permitir que os desenvolvedores auditem o impacto de cada provedor. Seria útil se os desenvolvedores tivessem dados prontos para todos os terceiros que fornecessem uma função específica com o impacto no desempenho, os benefícios e as compensações para comparação. Outro desafio que as equipes enfrentam é que, para muitos sites, as tags de terceiros só são executadas na produção, mas não nos ambientes de desenvolvimento, o que dificulta ainda mais o teste dos desenvolvedores.

3. Rede: como terceiros são hospedados em origens diferentes, os navegadores precisam fazer um número maior de conexões para fazer o download de conteúdo deles. As diferentes conexões não podem coordenar o download com base na prioridade, resultando em contenção de rede. Isso poderá atrasar ainda mais o carregamento da página se as otimizações adequadas não forem consideradas.

4. Sequenciamento: terceiros podem bloquear a linha de execução principal e lidar com a largura de banda por recursos mais importantes. Sendo assim, em alguns casos, são necessários recursos de terceiros para renderizar a página. A sequência ideal dos recursos próprios e de terceiros torna-se necessária quando os sites utilizam vários terceiros. Os desenvolvedores da Web precisam estar cientes das diferentes opções disponíveis para otimizar o sequenciamento.

Como consequência do que foi dito acima, terceiros podem afetar qualquer um ou todos os componentes das Core Web Vitals. A maioria dos terceiros afeta negativamente a Maior exibição de conteúdo (LCP) e a latência na primeira entrada (FID, na sigla em inglês). As incorporações do YouTube bloqueiam a conversa principal por 4,5 segundos para 10% dos sites em dispositivos móveis e pelo menos 1,6 segundo para 50% dos sites estudados. Imagine a frustração de um usuário ao encontrar uma página com 20 desses scripts em uma conexão lenta. A visualização a seguir do site thirdpartyweb.today mostra os terceiros com o maior impacto no desempenho no momento.

"Entre os principais 4 milhões de sites, cerca de 2.700 origens representam cerca de 57% de todo o tempo de execução do script. As 50 principais entidades já representam cerca de 47%." - Web de terceiros

Páginas que são renderizadas rapidamente e se tornam interativas em um período razoável são essenciais para uma boa experiência do usuário, conforme avaliada pelas Core Web Vitals. Uma boa UX geralmente significa um bom negócio para os sites, o que pode ser um bom negócio para terceiros. Trabalhar em conjunto para reduzir o impacto de terceiros pode ser vantajoso para todos na cadeia.

Sabemos que o Google usa vários scripts de terceiros usados com frequência, incluindo o Gerenciador de tags do Google, incorporações do YouTube e reCAPTCHA, para citar alguns. Sabemos que alguns dos nossos scripts podem ter um impacto menor no desempenho das Core Web Vitals e estamos comprometidos em explorar maneiras de melhorar esse impacto sempre que possível.

Como o Chrome pode ajudar?

A baixa qualidade dos recursos de terceiros em termos de desempenho costuma ser um desafio para os desenvolvedores, exigindo uma mudança gradual na dinâmica do ecossistema subjacente. O Chrome quer explorar esse espaço para alcançar os seguintes resultados:

1. Encontrar maneiras melhores de carregar recursos de terceiros na Web sem regredir a experiência do usuário ou os resultados de negócios.

   Sabemos que não podemos avançar nesse esforço se não colaborarmos com parceiros, empresas, terceiros e desenvolvedores. Queremos criar um campo aberto para discutir as possibilidades e trocar ideias por meio de explicações e especificações públicas. Os desenvolvedores terão tempo para enviar feedback e testar o impacto de muitas dessas propostas.

2. Os usuários de scripts de terceiros têm uma atribuição melhor dos custos em ferramentas e no campo, caminhos claros e pavimentados para o uso, além de incentivos melhores no tempo de criação para garantir a otimização por padrão.

   Queremos melhorar todas as camadas, como user agents, frameworks e scripts de terceiros, para reduzir o impacto no desempenho de terceiros. Também pretendemos fornecer insights suficientes para ajudar os proprietários de sites a adotar as práticas recomendadas em cada script incorporado, incluindo alternativas mais rápidas, quando aplicável.

Abordagem proposta

Propomos uma abordagem com três pilares para alcançar esses resultados...

1. **Dê aos desenvolvedores uma atribuição mais detalhada sobre o impacto por terceiros via RUM e nas ferramentas para desenvolvedores do Chrome.**

   O RUM se refere a dados de métricas de usuários reais (também conhecidos como dados de campo) disponíveis nas APIs de monitoramento de desempenho da Web. As ferramentas para desenvolvedores do Chrome incluem o Lighthouse, o Chrome DevTools e o Chrome User Experience Report. Propomos aprimorar as APIs e ferramentas disponíveis para que os desenvolvedores de sites entendam o impacto de cada terceiro usado em cada página. As ferramentas também ensinam as ações que podem ser tomadas para reduzir o impacto (por exemplo, adiamento ou uso de facades) e exploram outras possíveis soluções (outros terceiros ou "aprenda a fazer") com compensações. Para as APIs de monitoramento de desempenho da Web, estamos analisando formas de ampliar a cobertura de recursos de origem cruzada sem comprometer a privacidade e a segurança dos nossos usuários.

2. **Ofereça às empresas um caminho bem-iluminado para carregar recursos de terceiros com eficiência.**

   Gostaríamos de propor novos padrões que incentivem os navegadores a escolher, de maneira mais inteligente, como os recursos primários e de terceiros são carregados em nome de uma melhor experiência de carregamento para os usuários. Mais tarde, vamos destacar algumas dessas propostas, como incorporações com carregamento lento de terceiros por padrão ou a aplicação de uma priorização diferente para recursos de terceiros que talvez não sejam tão essenciais para o conteúdo inicial com que os usuários possam se interessar. Essas são apenas algumas das ideias que estamos avaliando. Seria ótimo colaborar com especialistas em desempenho na Web e com a comunidade em geral para melhorar esse trabalho.

   Da mesma forma, gostaríamos de abordar esses problemas nas estruturas JavaScript e nos sistemas de gerenciamento de conteúdo (CMS), quando mais apropriado. Projetos como o Aurora e a WordPress Performance Team (link em inglês) mostraram a importância dos padrões integrados que resolvem problemas de carregamento conhecidos. Padrões incorporados em frameworks e no CMS orientam as empresas por um caminho bem iluminado. Elas também podem ser úteis para o user agent (por exemplo, o Chrome) como dicas que permitem aplicar heurísticas para otimizar o carregamento de página e as Core Web Vitals. Essas dicas podem ajudar o user agent a decidir quando e como terceiros específicos devem ser carregados no ciclo de vida da página. Por exemplo, o componente de script Next.js tem um padrão integrado para carregar scripts de terceiros depois que a página se torna interativa.

3. **Ofereça incentivos a terceiros para reduzir o impacto no desempenho com esforços de mais transparência.**

   Atualmente, os desenvolvedores terceirizados não têm a visibilidade necessária para entender o impacto dos scripts em sites como um todo. Planejamos resolver esse problema e equipar esses fornecedores com ferramentas para analisar o impacto e compará-lo com outros produtos no mercado que oferecem o mesmo valor. Também queremos ajudá-los a usar os dados para diagnosticar o que causa o impacto e mitigá-lo no upstream. Para isso, teremos que recorrer a todos os terceiros, incluindo aqueles de autoria do Google.

Desafios

Um esforço dessa magnitude não se resume a desafios. Alguns dos principais desafios que precisamos considerar são.

• Terceiros são um problema transversal que envolve anúncios, análises, gerenciamento de tags, utilitários e muitos outros. Cada área requer a consideração de um conjunto exclusivo de requisitos e compensações. Exemplo:
  • A decisão de otimizar o carregamento de anúncios depende de um equilíbrio entre receita e experiência do usuário. Muito cedo, eles bloqueiam conteúdo valioso; tarde demais, o usuário sentiria falta de vê-los.
  • Os scripts do Google Analytics são adicionados ao peso da página, mas fornecem dados valiosos sobre as ações do usuário para a empresa.

Esperamos fazer parcerias com várias categorias de terceiros, compreender as nuances envolvidas, resolver concessões e desenvolver incentivos que funcionem para todos. Sabemos que precisamos trabalhar separadamente com as entidades em cada área para que nossa estratégia seja eficaz. Isso inclui nossos parceiros internos, como o Gerenciador de tags do Google, o Google Ads e o YouTube.

1. Queremos proporcionar uma atribuição mais detalhada para desenvolvedores de sites e desenvolvedores terceirizados. Isso requer um esforço consciente em que identificamos quais dados são mais relevantes para medir o impacto, os atribuímos com precisão e granularidade e fornecemos o caminho certo a seguir. Em última análise, o cálculo do desempenho de um determinado terceiro em relação à concorrência deve ser transparente para todos.

2. Propomos melhorar o Chrome para que ele possa aplicar otimizações que ajudem a encontrar o equilíbrio certo para priorizar o carregamento de recursos próprios e de terceiros. Uma mudança valiosa é disponibilizada como padrão em todos os navegadores, mas isso leva tempo. Por exemplo, o atributo loading para os elementos <img> e <iframe> está disponível no Chrome/Edge desde 2019, mas ficou disponível no Safari apenas em 2022. Até que um recurso seja padronizado, os usuários de recursos de terceiros precisarão garantir que eles também sejam otimizados para outros navegadores. Vamos ajudar destacando isso em nossas orientações, quando relevante.

3. Para colocar esse projeto em prática, precisaremos interagir com parceiros e desenvolvedores não apenas para nos ajudar a entender os requisitos específicos, mas também para testar soluções experimentais em grande escala, fornecer feedback, iterar e improvisar conforme necessário. As alterações terão que ser planejadas, permitindo um período razoável para teste e avaliação.

Propostas Inicial de Padrões

Realizamos alguns experimentos iniciais para desenvolver recursos que podem ser ativados para otimizar o processo de carregamento de terceiros. Estamos satisfeitos com os resultados observados e agora podemos discutir dois desses recursos.

LazyEmbeds

Anteriormente, o Chrome carregava lentamente os elementos <img> e <iframe> fora da tela para os usuários do Modo Lite. Esse recurso pode ser estendido a todos os usuários para adiar o carregamento de elementos <iframe> considerados como incorporações de terceiros até que o usuário role a tela para perto deles. Isso pode acelerar o carregamento de outras partes da página, melhorar as Core Web Vitals, reduzir o uso da memória e economizar dados.

Confira uma demonstração usando LazyEmbeds para carregar vídeos do YouTube de maneira lenta em uma página. Normalmente, uma única incorporação de vídeo do YouTube adiciona de 500 a 600 KB de JavaScript à página. Tentamos otimizar uma postagem de blog com 14 incorporações desse tipo de vídeo usando LazyEmbeds. Os resultados foram promissores em termos de tempo de carregamento de página e economia de dados.

Para saber mais sobre esse trabalho, consulte a explicação e a conversa sobre a intenção de experimento (em inglês) e a extensão do experimento do blink-dev.

Limitação de terceiros segmentada

Scripts de terceiros geralmente são adicionados por várias equipes sem processos de supervisão holísticos. A equipe de engenharia do The Telegraph disse que "todos querem usar a tag em uma página para gerar receita para a organização". Isso pode aumentar continuamente o fardo de gerenciar o impacto no desempenho.

A limitação direcionada de scripts de terceiros se propõe a limitar tipos muito específicos de terceiros para reduzir o impacto deles. Isso permite que os navegadores carreguem o conteúdo principal e terceiros essenciais antecipadamente, enquanto aqueles com segurança para carregamento posterior são limitados.

Aprimoramento de APIs RUM

Também estamos pensando em melhorar as APIs RUM para incluir informações relevantes na avaliação do desempenho de terceiros. As melhorias incluem o seguinte:

1. Relatórios de <iframe>: estamos trabalhando em soluções que podem usar a API Performance Timeline para gerar relatórios entre frames. Isso permitiria que os autores da página de nível superior inspecionem os dados de desempenho de um iframe de terceiros incorporado à página.

2. Atribuição de tarefas longas: a API Long Tasks no RUM ajuda os proprietários de sites a identificar tarefas longas que unem a linha de execução principal por muito tempo e atrasam as interações.

Mais atualizações

Ainda estamos testando muitas dessas ideias e esperamos publicar explicações do GitHub e rascunhos de especificação para mudanças conforme avançamos. Terceiros e proprietários de sites que quiserem colaborar conosco ou deixar feedback podem contribuir com as discussões. Terceiros também podem começar a se concentrar na otimização das Core Web Vitals e das métricas de INP para garantir que dados insuficientes das Core Web Vitals/INP não sejam atribuídos a eles. Por enquanto, aqueles que estão procurando atualizações podem consultar as postagens no grupo blink-dev.

Esperamos explorar ainda mais esse espaço problemático e interagir com a comunidade para aprendermos mais.

Agradecimentos especiais a Leena Sohoni-Kasture, Jeremy Wagner, Gilberto Cocchi, Kenji Baheux, Kouhei Ueno, Kentaro Hara, Alex N. José, Melissa Mitchell, Yoav Weiss, Shunya Shishido e Minoru Chikamune pelo feedback e contribuições.