Addy Osmani

Os recursos de terceiros (como incorporações e scripts) são muito usados na Web atualmente. Eles oferecem soluções prontas para incorporação de mídias sociais, vídeos, análises, chat ao vivo, publicidade, testes A/B, personalização e muito mais. As incorporações de terceiros são uma parte necessária dos sites modernos que permitem que os proprietários se concentrem nas principais competências, enquanto transferem funções padrão, mas essenciais, para provedores externos.

Quando os dados próprios e de terceiros em uma página da Web funcionam em harmonia, é possível que ela ofereça uma ótima experiência do usuário. No entanto, isso exige um esforço significativo das equipes de engenharia e de negócios e muitas vezes é ignorado, resultando em páginas da Web com desempenho inferior e um impacto negativo nas métricas centradas no usuário, como as Principais métricas da Web. Isso é prejudicial para ambas as partes e cria oportunidades perdidas para as empresas. Podemos melhorar isso?

Temos uma visão futura da Web em que scripts e recursos de terceiros oferecem o valor comercial pretendido com a regressão mínima à performance ou à experiência do usuário dos sites que os usam no navegador. Isso permitiria que os usuários tivessem carregamentos de página mais rápidos.

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

Neste post, queremos compartilhar informações sobre alguns dos nossos experimentos. Esperamos que isso seja o início de um processo que incentive a transparência e a visibilidade entre agentes do usuário, empresas e provedores terceirizados, além de pavimentar o caminho para uma Web mais rápida.

Uma análise mais detalhada de terceiros

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

• Hospedado em uma origem pública e compartilhada diferente da origem do site principal.
• Não é criado ou influenciado por um proprietário do site.
• É amplamente usado por vários sites.

Além de ajudar a gerar receita (com anúncios) e oferecer melhores oportunidades de marketing (incorporações de mídias sociais), os terceiros atendem a uma grande variedade de objetivos de negócios. As categorias comuns de terceiros incluem:

Fonte: Terceiros por categoria.

Esses scripts e bibliotecas de terceiros permitem que os desenvolvedores da Web aproveitem soluções testadas e implementadas 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 com mais rapidez. Não é de se admirar que mais de 94% de todos os sites em computadores e dispositivos móveis usam terceiros.

Como as partes externas afetam a performance?

O ideal é que os desenvolvedores terceirizados sejam especialistas no assunto dos recursos específicos que oferecem. A maioria das ferramentas de terceiros mais conhecidas passou por várias iterações, e é possível que o código delas seja otimizado para as próprias metas de negócios, o que pode ou não incluir a performance das páginas que as usam. No entanto, sabemos que até mesmo os terceiros mais bem otimizados afetam a performance. Confira os principais motivos desse impacto:

1. Tamanho e custos de execução do script: terceiros geralmente têm como objetivo oferecer funcionalidades significativas "apenas" inserindo um elemento <script> ou <iframe> na sua página. Esses elementos extraem scripts e recursos de tamanho significativo e demoram mais para serem transferidos e executados. Muito 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 bloqueiam a linha de execução principal de 42 ms a 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 afetam a pontuação de desempenho do site. Além disso, ela 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 do script têm um impacto significativo na performance.

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

3. Rede: como os terceiros são hospedados em origens diferentes, os navegadores precisam fazer um número maior de conexões para fazer o download do conteúdo. As diferentes conexões não podem coordenar o download com base na prioridade, resultando em contenção de rede. Isso pode 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 competir pela largura de banda para recursos mais importantes. No entanto, em alguns casos, os recursos de terceiros são essenciais para renderizar a página. A sequência ideal dos recursos próprios e de terceiros se torna necessária quando os sites usam vários terceiros. Os desenvolvedores da Web precisam conhecer as diferentes opções disponíveis para otimizar a sequência.

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

"Em cerca de 4 milhões de sites, cerca de 2.700 origens representam cerca de 57% de todo o tempo de execução do script, com as 50 principais entidades já representando cerca de 47%". - third-party-web

As 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 medida pelas Core Web Vitals. Uma boa UX geralmente significa bons negócios para sites, o que pode significar bons negócios para terceiros. Trabalhar em conjunto para reduzir o impacto de terceiros pode ser uma vitória para todos na cadeia.

Sabemos que o Google vende vários scripts de terceiros usados com frequência, como o Gerenciador de tags do Google, as incorporações do YouTube e o ReCaptcha, para citar alguns. Sabemos que alguns dos nossos scripts podem ter um impacto menor na performance das Core Web Vitals. Estamos comprometidos em encontrar maneiras de melhorar esse impacto sempre que possível.

Como o Chrome pode ajudar?

Os recursos de terceiros que têm desempenho ruim geralmente são um desafio para os desenvolvedores, exigindo uma mudança gradual na dinâmica do ecossistema. O Chrome quer explorar esse espaço para alcançar os seguintes resultados:

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

   Sabemos que não vamos conseguir avançar muito 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. Permitir que os usuários de scripts de terceiros tenham uma melhor atribuição dos custos de ferramentas e de campo, caminhos claros e bem definidos para uso e incentivos melhores durante a criação para garantir que eles sejam otimizados por padrão.

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

Abordagem proposta

Propomos uma abordagem de três partes para alcançar esses resultados:

1. **Dê aos desenvolvedores uma atribuição mais profunda do impacto de cada terceiro pelo RUM e nas ferramentas para desenvolvedores do Chrome.**

   O RUM se refere aos 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. Nossa proposta é 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 vão educar os usuários sobre as ações que podem ser tomadas para reduzir o impacto (por exemplo, adiar ou usar fachadas) e explorar outras soluções potenciais (outras partes terceirizadas ou faça você mesmo) com compensações. Para as APIs de monitoramento de desempenho da Web, estamos buscando maneiras de expandir a cobertura de recursos entre origens sem comprometer a privacidade e a segurança dos nossos usuários.

2. **Dê à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 fazer trocas mais inteligentes entre a forma como os recursos próprios 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 o carregamento lento de incorporações de terceiros por padrão ou a priorização de recursos de terceiros que podem não ser tão importantes para o conteúdo inicial que os usuários mais gostam. Essas são apenas algumas das ideias que estamos avaliando nesse espaço e adoraríamos colaborar com especialistas em performance da Web e com a comunidade em geral para dar forma a esse trabalho.

   Também gostaríamos de resolver esses problemas em frameworks JavaScript e sistemas de gerenciamento de conteúdo (CMS) quando for mais apropriado. Projetos como o Aurora e a WordPress Performance Team nos ensinaram a importância de padrões integrados que resolvem problemas de carregamento conhecidos. Os padrões integrados a frameworks e CMSs orientam as empresas por um caminho bem iluminado. Elas também podem ser úteis para o agente do usuário (por exemplo, o Chrome) como dicas que permitem a aplicação de heurísticas para otimizar o carregamento da página e a CWV. Essas dicas podem ajudar o agente do usuário a decidir quando e como os 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. **Dê incentivos a terceiros para reduzir o impacto na performance com esforços de transparência melhores.**

   Atualmente, os desenvolvedores terceirizados não têm a visibilidade necessária para entender o impacto dos scripts nos sites em geral. Planejamos resolver esse problema e fornecer aos provedores ferramentas para analisar o impacto e comparar com outros produtos no mercado que oferecem o mesmo valor. Também queremos ajudar a empresa a usar os dados para diagnosticar a causa do impacto e mitigá-lo antes que ele aconteça. Para ter sucesso, precisamos chamar a atenção de todas as partes terceirizadas, incluindo as criadas pelo Google.

Desafios

Um esforço dessa magnitude não está livre de desafios. Alguns dos principais desafios que precisamos considerar são:

• As partes externas são um problema transversal que envolve anúncios, análises, gerenciamento de tags, utilitários e muito mais. Cada área exige 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 trade-off entre receita e experiência do usuário. Se for muito cedo, elas bloqueiam conteúdo valioso. Se for muito tarde, o usuário não vai mais vê-las.
  • Os scripts do Google Analytics aumentam o peso da página, mas fornecem dados valiosos sobre as ações dos usuários para a empresa.

Esperamos fazer parcerias com várias categorias de terceiros, entender as nuances envolvidas, resolver as compensações e desenvolver incentivos que funcionem para todos. Percebemos que precisamos trabalhar separadamente com 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 oferecer uma atribuição mais detalhada para desenvolvedores de sites e terceirizados. Isso exige um esforço consciente para identificar quais dados são mais relevantes para medir o impacto, atribuí-los com precisão e granularidade e fornecer o caminho certo. Por fim, o cálculo de como um determinado terceiro se sai em relação à concorrência precisa ser transparente para todos.

2. Propomos aprimorar 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 fica disponível como padrão em todos os navegadores, mas leva tempo. Por exemplo, o atributo loading para os elementos <img> e <iframe> está disponível no Chrome/Edge desde 2019, mas só foi disponibilizado no Safari em 2022. Até que um recurso seja padronizado, os usuários de recursos de terceiros vão precisar garantir que ele também seja otimizado para outros navegadores. Vamos destacar isso nas nossas orientações, quando for relevante.

3. Para executar este projeto, precisamos interagir com parceiros e desenvolvedores para entender requisitos específicos, testar soluções experimentais em grande escala, fornecer feedback, iterar e improvisar quando necessário. As mudanças precisam ser planejadas, permitindo um período razoável para testes e avaliação.

Propostas iniciais 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 podemos discutir dois desses recursos.

LazyEmbeds

Antes, o Chrome carregava de forma lenta 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> determinados como incorporações de terceiros até que o usuário role a tela até eles. Isso pode acelerar o carregamento de outras partes da página, melhorar as Core Web Vitals, reduzir o uso da memória e salvar dados.

Confira uma demonstração de como usar o LazyEmbeds para carregar vídeos do YouTube em uma página. Uma única incorporação de vídeo do YouTube geralmente adiciona 500 a 600 KB de JavaScript à página. Tentamos otimizar uma postagem de blog com 14 dessas in-line usando o LazyEmbeds. Os resultados foram promissores em relação ao tempo de carregamento da página e à economia de dados.

Para saber mais sobre esse trabalho, consulte nossa explicação e a discussão sobre a intenção de fazer experimentos e a extensão de experimentos do blink-dev.

Limitação direcionada de terceiros

Os scripts de terceiros geralmente são adicionados por várias equipes sem processos de supervisão holística. A equipe de engenharia do The Telegraph disse que "todo mundo quer "essa tag" em uma página que vai gerar receita para a organização". Isso pode aumentar continuamente a carga de gerenciamento do impacto na performance.

O estrangulamento de script de terceiros direcionado propõe limitar tipos muito específicos de terceiros para reduzir o impacto deles. Isso permitiria que os navegadores carregassem o conteúdo principal e os terceiros essenciais com antecedência, enquanto os que podem ser carregados mais tarde são limitados.

Como melhorar as APIs RUM

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

1. Relatórios <iframe>: estamos trabalhando em soluções que possam aproveitar a API Performance Timeline para relatórios entre frames. Isso permitiria que os autores da página de nível superior inspecionassem os dados de performance de um iframe de terceiros que está 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 ocupam a linha de execução principal por muito tempo e atrasam a interação.

Outras atualizações

Ainda estamos testando muitas dessas ideias e esperamos publicar explicações e rascunhos de especificações no GitHub para as mudanças. Terceiros e proprietários de sites que queiram fazer parceria conosco ou deixar feedback podem contribuir para as discussões. Terceiros também podem começar a se concentrar na otimização das métricas das Core Web Vitals e da INP para garantir que dados ruins das Core Web Vitals/INP não sejam atribuídos a eles. Por enquanto, quem procura atualizações pode consultar as postagens no grupo blink-dev.

Esperamos explorar esse espaço de problemas e interagir com a comunidade sobre nossas descobertas.

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