Scripts de terceiros em segundo-plano com PartyTown

Um grande problema quando estamos trabalhando com aplicações web é o impacto no desempenho que scripts de terceiros podem causar no nosso site. Quando o navegador executa scripts síncronos, ele por padrão o faz na thread principal, a mesma que fica responsável pela renderização do conteúdo da página. Compartilhar a thread responsável pela renderização da página com processos síncronos longos pode causar congelamentos e lentidões inesperadas no fluxo de renderização da nossa aplicação. Exemplo: Abra o console do navegador e digite while(true) Execute (Enter) e tente realizar alguma interação com a página. Toda a página e suas interações estarão congeladas porque a thread que processa os eventos da DOM está ocupada executando o seu loop. Delegando para web workers Esses congelamentos podem ser contornados se delegarmos a execução desses scripts para web workers, que serão executados em threads separadas, deixando a thread principal livre para processar eventos e renderizações. // workerService.js onmessage = ({ data }) => { const processedData = process(data); } // index.js const worker = new Worker('workerService.js'); No entanto, trabalhar com web workers pode ser trabalhoso na maior parte dos casos, principalmente pelo fato de workers não possuírem acesso à DOM. Para acessar a DOM e, por exemplo, processar um input do usuário, faríamos algo como: // index.js document.querySelector("#field").addEventListener("change", (e) => { const { value } = e.target; worker.postMessage(value); }); Mas fazer isso em scripts de terceiros passa a ser bem mais penoso, já que teríamos que identificar esses acessos à DOM no código terceiro e executá-los na thread principal, delegando para os workers somente o que ele tem a capacidade de processar. É nesse contexto que surge o PartyTown

Mar 8, 2025 - 20:04

Scripts de terceiros em segundo-plano com PartyTown

Um grande problema quando estamos trabalhando com aplicações web é o impacto no desempenho que scripts de terceiros podem causar no nosso site.

Quando o navegador executa scripts síncronos, ele por padrão o faz na thread principal, a mesma que fica responsável pela renderização do conteúdo da página.

Compartilhar a thread responsável pela renderização da página com processos síncronos longos pode causar congelamentos e lentidões inesperadas no fluxo de renderização da nossa aplicação.

Exemplo: Abra o console do navegador e digite

while(true)

Execute (Enter) e tente realizar alguma interação com a página. Toda a página e suas interações estarão congeladas porque a thread que processa os eventos da DOM está ocupada executando o seu loop.

Delegando para web workers

Esses congelamentos podem ser contornados se delegarmos a execução desses scripts para web workers, que serão executados em threads separadas, deixando a thread principal livre para processar eventos e renderizações.

// workerService.js
onmessage = ({ data }) => {
    const processedData = process(data);
}

// index.js
const worker = new Worker('workerService.js');

No entanto, trabalhar com web workers pode ser trabalhoso na maior parte dos casos, principalmente pelo fato de workers não possuírem acesso à DOM. Para acessar a DOM e, por exemplo, processar um input do usuário, faríamos algo como:

// index.js
document.querySelector("#field").addEventListener("change", (e) => {
    const { value } = e.target;
    worker.postMessage(value);
});

Mas fazer isso em scripts de terceiros passa a ser bem mais penoso, já que teríamos que identificar esses acessos à DOM no código terceiro e executá-los na thread principal, delegando para os workers somente o que ele tem a capacidade de processar.

É nesse contexto que surge o PartyTown