Como a CMP da PubConsent reduziu o INP dos clientes em até 64% usando uma estratégia de rendimento que usa as APIs do Scheduler do navegador para corrigir problemas de capacidade de resposta identificados com o Chrome DevTools.
As plataformas de gestão de consentimento (CMPs) são ferramentas que ajudam os sites a obedecer aos regulamentos de privacidade obtendo o consentimento do usuário para o uso de cookies e tecnologias de rastreamento. Além de garantir a conformidade legal, as CMPs, como scripts de terceiros, também precisam garantir impactos mínimos no desempenho e na experiência do usuário.
PubConsent CMP é o produto mais recente da PubTech. Projetada com foco principal no desempenho, a CMP do PubConsent foi projetada para ser leve, garantir uma experiência do usuário otimizada e impacto mínimo no desempenho geral do site.
A introdução da métrica Interaction to Next Paint (INP) permitiu que a PubTech descobrisse problemas com a capacidade de resposta da CMP. Neste estudo de caso, a PubTech mostra como resolver os problemas com a capacidade de resposta na plataforma CMP do PubConsent e como melhorar o INP antes de se tornar uma das Core Web Vitals em março de 2024, demonstrando um compromisso sólido de oferecer o melhor desempenho possível em um produto de CMP.
Por que a PubTech se importa com o desempenho?
A CMP do PubConsent, assim como a maioria das CMPs, oferece a funcionalidade de gestão de consentimento implementada como um script de terceiros nas páginas do site. Reduzir o impacto na performance da nossa oferta de CMP, inclusive na capacidade de resposta, é crucial para garantir uma integração bem-sucedida da CMP.
Ao priorizar a performance e manter o script de CMP do Pub/Sub leve, os proprietários dos sites podem encontrar um equilíbrio delicado entre a incorporação de funcionalidades valiosas de gerenciamento de consentimento e, ao mesmo tempo, preservar a qualidade da experiência do usuário.
Considerando a importância da funcionalidade que uma CMP oferece e do impacto que ela pode ter no desempenho, a PubTech define as seguintes metas:
- Minimizar o impacto do produto de CMP do PubConsent no INP.
- Reduza tarefas longas atribuíveis ao produto da CMP.
- Reduza o Tempo total de bloqueio (TBT, na sigla em inglês), que pode ter um efeito negativo no INP de uma página.
Como o INP foi medido
A PubTech usou o Chrome DevTools para realizar uma análise inicial e diagnosticar manualmente interações lentas. Com esse fluxo de trabalho, a PubTech identificou problemas específicos que afetam a capacidade de resposta da página. Por exemplo, uma interação de clique no produto da CMP para aceitar todos os cookies e, em seguida, dispensar a caixa de diálogo de consentimento de cookies causou uma tarefa longa que atrasou a atualização da renderização da interface do usuário. Como é possível ver na imagem a seguir, a interface do usuário não foi atualizada para mostrar que a caixa de diálogo estava fechada até que a longa tarefa fosse concluída.
Assim como o botão para aceitar todos os cookies, o botão para rejeitar todos os cookies ou personalizar as preferências de cookies, todos seguem o mesmo fluxo de trabalho na arquitetura da CMP do PubConsent. Por isso, as melhorias detalhadas neste estudo de caso afetaram uma série de interações de usuários no produto da CMP.
Esse atraso fez com que a percepção visual do painel ficasse em um estado bloqueado durante a tarefa. Como isso bloqueou a atualização da renderização por um período perceptivelmente longo, o INP da página foi afetado negativamente.
Como a PubTech otimizou o INP para botões e links
Para melhorar o INP, diferentes estratégias de rendimento foram adotadas na CMP do PubConsent.
Executar tarefas de alta prioridade
O método yieldToMainUiBlocking mostrado no snippet de código a seguir foi projetado para otimizar tarefas JavaScript de alta prioridade, gerando scheduler.yield se disponível, mas voltando para postTask com prioridade user-blocking (alta) se postTask estiver disponível e finalmente retornando a nada.
setTimeout foi evitado aqui porque o método yieldToMainUiBlocking foi projetado para lidar com operações internas de configurações da CMP e trabalhos de alta prioridade que precisam manter essa prioridade durante o rendimento. Isso significa que apenas os navegadores que implementam essas APIs de agendamento (que atualmente estão disponíveis apenas em navegadores baseados no Chromium no momento em que este artigo foi escrito) se beneficiam das melhorias detalhadas neste estudo de caso. Mesmo assim, essa abordagem foi considerada um aprimoramento progressivo aceitável para essas tarefas de alta prioridade.
function yieldToMainUiBlocking () {
return new Promise((resolve) => {
if ('scheduler' in window) {
if ('yield' in window.scheduler) {
return window.scheduler.yield().then(() => resolve(true));
}
if ('postTask' in window.scheduler) {
return window.scheduler.postTask(() => resolve(true), { priority: 'user-blocking' });
}
}
resolve(false);
});
};
Rendimento em tarefas médias e em segundo plano
O método yieldToMainBackground mostrado no snippet de código abaixo é usado para dividir tarefas longas que têm prioridade user-visible (média) ou background. A lógica vai implementar scheduler.yield() se ele estiver disponível, mas ele difere usando postTask com prioridade média e, por fim, voltando para setTimeout em navegadores que não são do Chromium.
function yieldToMainBackground () {
return new Promise((resolve) => {
if ('scheduler' in window) {
if ('yield' in window.scheduler) {
return window.scheduler.yield().then(() => resolve(true));
}
if ('postTask' in window.scheduler) {
return window.scheduler.postTask(() => resolve(true), { priority: 'user-visible' });
}
}
setTimeout(() => { resolve(true) }, 0);
});
};
yieldToMainBackground permite que o navegador renderize a próxima exibição (fechando a interface da CMP) mais cedo.
Como a PubTech reduziu ainda mais o TBT com a otimização do layout de renderização
Após aplicar a estratégia de rendimento, notou-se que o INP melhorou de forma significativa para a CMP. Na verdade, depois de reduzir significativamente a duração de processamento do manipulador de eventos, foi descoberta uma oportunidade de fazer outras melhorias de renderização para a próxima exibição da ação Close UI. Originalmente, esta ação foi projetada para remover elementos do DOM. Isso apresentou desafios, especialmente em sites com um número substancial de nós DOM, resultando em um aumento inesperado no trabalho de renderização.
Para lidar com o aumento da quantidade de trabalho de renderização necessário para remover elementos do DOM, foi apresentada uma solução que a equipe chamou de "rerenderização lenta". Primeiro, essa abordagem aplica uma regra CSS display: none à caixa de diálogo de consentimento da CMP depois que o usuário dá o consentimento para ocultá-la. Em seguida, a remoção dos nós do DOM associados à caixa de diálogo da CMP é movida para um momento posterior quando o navegador fica inativo usando requestIdleCallback. Essa abordagem provou ser muito mais rápida do que remover os nós DOM no momento em que o usuário fechava a caixa de diálogo de consentimento.
Como a PubTech reduziu ainda mais o INP ao melhorar a biblioteca do TCF do IAB
Depois de resolver com sucesso a maioria dos problemas de capacidade de resposta da CMP, identificamos mais oportunidades de melhoria em uma das principais dependências: a biblioteca do Estrutura de Transparência e Consentimento (TCF) do IAB.
Os componentes dessa biblioteca mais caros em termos computacionais foram "strings de build" e "consentimento de envio". Esses componentes fazem parte da biblioteca do TCF do IAB. As seguintes otimizações desses componentes foram aplicadas em uma bifurcação separada especificamente para as necessidades da PubTech:
- Reutilizar resultados calculados para o processo de decodificação, que é executado para cada callback de terceiros que precise ler o consentimento do usuário.
- Evitar e reduzir loops desnecessários no processo de codificação das restrições do editor, que é executado quando o usuário dá o consentimento.
A primeira dessas otimizações reduziu o tempo gasto pela CMP em cada callback de terceiros conectado à biblioteca do TCF do IAB. A segunda otimização reduziu a duração do processamento do componente "strings de build". Essa otimização permitiu uma redução de até 60% dos loops executados sempre que um usuário devia o consentimento.
Resultados
Com as estratégias que geravam resultados e as novas otimizações de layout de renderização, o INP da CMP melhorou em até 65%. Como resultado, a capacidade de resposta da experiência do usuário da CMP da PubConsent quanto à CMP foi aprimorada e, para alguns anúncios, a visibilidade até 1,5% melhorou com a otimização de solicitações de anúncios.
Além dessas melhorias, na biblioteca do TCF do IAB, observou-se que a INP melhorou em até 77% em dispositivos móveis para os clientes afetados, como resultado da redução em até 85% das tarefas longas induzidas pelo TCF. Isso ajudou a reduzir significativamente a sobrecarga de cada callback de terceiros executado durante todo o ciclo de vida de uma página.
O número de origens que transmitem INP ao usar a CMP do PubConsent aumenta em mais de 400%, passando de 13% para 55% em dispositivos móveis. Para alguns clientes, o INP da página foi reduzido pela metade, de 470 milissegundos para 230 milissegundos, devido às otimizações do SDK PubTech feitas.
Conclusão
Os clientes da PubTech conseguiram reconhecer rapidamente os resultados positivos de performance de INP e métricas de negócios resultantes dos nossos esforços de otimização. Outras melhorias de desempenho para a CMP do PubConsent já estão sendo consideradas, aproveitando dados inestimáveis de monitoramento de usuários reais (RUM, na sigla em inglês) dos clientes. Esses dados rastreiam de perto as regressões e os avanços, impulsionando os esforços de melhoria contínua da PubTech.
Como uma empresa terceirizada, a PubTech também percebeu que tinha a oportunidade de melhorar o desempenho da Web em grande escala e oferecer melhor capacidade de resposta, além de evitar impactos negativos nos KPIs de negócios. Nunca é tarde para começar a implementar esses tipos de melhorias.
Agradecimentos especiais a Luca Coppola, CTO da PubTech para apoiar esse trabalho de inovação, e a Jeremy Wagner, Michal Mocny e Rick Viscomi do Google.