Otimizar tarefas longas

Você recebeu a instrução "não bloquear a linha de execução principal" e "dividir as tarefas longas", mas o que isso significa?

Jeremy Wagner

Brendan Kenny

Publicado em 30 de setembro de 2022 e atualizado pela última vez em 19 de dezembro de 2024

O conselho comum para manter os apps JavaScript rápidos tende a se resumir a este:

• "Não bloquear a linha de execução principal".
• "Divida as tarefas longas."

Esse é um ótimo conselho, mas qual é o trabalho envolvido? Enviar menos JavaScript é bom, mas isso equivale automaticamente a interfaces de usuário mais responsivas? Talvez, mas talvez não.

Para entender como otimizar tarefas em JavaScript, primeiro você precisa saber o que são tarefas e como o navegador as processa.

O que é uma tarefa?

Uma tarefa é qualquer trabalho discreto que o navegador realiza. Esse trabalho inclui renderização, análise de HTML e CSS, execução de JavaScript e outros tipos de trabalho que você talvez não tenha controle direto. De tudo isso, o JavaScript que você escreve é talvez a maior fonte de tarefas.

A task started by a click event handler in, shown in Chrome DevTools' performance profiler.

As tarefas associadas ao JavaScript afetam a performance de algumas maneiras:

• Quando um navegador faz o download de um arquivo JavaScript durante a inicialização, ele enfileira tarefas para analisar e compilar esse JavaScript para que ele possa ser executado mais tarde.
• Em outros momentos durante a vida da página, as tarefas são enfileiradas quando o JavaScript funciona, como responder a interações por gerenciadores de eventos, animações geradas por JavaScript e atividades em segundo plano, como a coleta de dados de análise.

Todas essas coisas, com exceção de workers da Web e APIs semelhantes, acontecem na linha de execução principal.

O que é a linha de execução principal?

A linha de execução principal é onde a maioria das tarefas é executada no navegador e onde quase todo JavaScript escrito é executado.

A linha de execução principal só pode processar uma tarefa por vez. Qualquer tarefa que leve mais de 50 milissegundos é uma tarefa longa. Para tarefas que excedem 50 milissegundos, o tempo total da tarefa menos 50 milissegundos é conhecido como período de bloqueio da tarefa.

O navegador bloqueia as interações enquanto uma tarefa de qualquer tamanho está em execução, mas isso não é perceptível para o usuário, desde que as tarefas não sejam executadas por muito tempo. No entanto, quando um usuário tenta interagir com uma página com muitas tarefas longas, a interface do usuário não responde e pode até mesmo ficar corrompida se a linha de execução principal for bloqueada por muito tempo.

Uma tarefa demorada, conforme mostrado no perfilador de desempenho do Chrome. As tarefas longas são indicadas por um triângulo vermelho no canto da tarefa, com a parte de bloqueio preenchida com um padrão de listras vermelhas diagonais.

Para evitar que a linha de execução principal seja bloqueada por muito tempo, divida uma tarefa longa em várias menores.

A visualização de uma única tarefa longa em comparação com a mesma tarefa dividida em cinco tarefas mais curtas.

Isso é importante porque, quando as tarefas são divididas, o navegador pode responder a trabalhos de maior prioridade muito mais rápido, incluindo interações do usuário. Depois, as tarefas restantes são concluídas, garantindo que o trabalho que você inicialmente colocou na fila seja concluído.

Uma visualização do que acontece com as interações quando as tarefas são muito longas e o navegador não consegue responder às interações com rapidez suficiente, em comparação com quando as tarefas mais longas são divididas em tarefas menores.

Na parte de cima da figura anterior, um manipulador de eventos enfileirado por uma interação do usuário teve que esperar uma única tarefa longa antes de começar. Isso atrasa a interação. Nesse cenário, o usuário pode ter notado um atraso. Na parte de baixo, o manipulador de eventos pode começar a ser executado mais cedo, e a interação pode ter sido instantânea.

Agora que você sabe por que é importante dividir as tarefas, aprenda a fazer isso em JavaScript.

Estratégias de gerenciamento de tarefas

Um conselho comum na arquitetura de software é dividir o trabalho em funções menores:

function saveSettings () {
  validateForm();
  showSpinner();
  saveToDatabase();
  updateUI();
  sendAnalytics();
}

Neste exemplo, há uma função chamada saveSettings() que chama cinco funções para validar um formulário, mostrar um ícone de carregamento, enviar dados para o back-end do aplicativo, atualizar a interface do usuário e enviar análises.

Conceitualmente, o saveSettings() tem uma boa arquitetura. Se você precisar depurar uma dessas funções, navegue pela árvore do projeto para descobrir o que cada uma faz. Essa divisão facilita a navegação e a manutenção dos projetos.

Um possível problema aqui é que o JavaScript não executa cada uma dessas funções como tarefas separadas, porque elas são executadas na função saveSettings(). Isso significa que todas as cinco funções serão executadas como uma tarefa.

Uma única função saveSettings() que chama cinco funções. O trabalho é executado como parte de uma tarefa monolítica longa, bloqueando qualquer resposta visual até que as cinco funções sejam concluídas.

Na melhor das hipóteses, até mesmo uma única função pode contribuir com 50 milissegundos ou mais para a duração total da tarefa. Na pior das hipóteses, mais dessas tarefas podem ser executadas por muito mais tempo, especialmente em dispositivos com recursos limitados.

Nesse caso, o saveSettings() é acionado por um clique do usuário. Como o navegador não pode mostrar uma resposta até que a função inteira seja executada, o resultado dessa tarefa demorada é uma interface lenta e sem resposta, e será medido como uma Interaction to Next Paint (INP) ruim.

Importante:o JavaScript funciona dessa maneira porque usa o modelo de execução até a conclusão da execução de tarefas. Isso significa que cada tarefa será executada até ser concluída, independentemente de quanto tempo ela possa bloquear a linha de execução principal.

Adiar manualmente a execução do código

Para garantir que tarefas importantes do usuário e respostas da interface aconteçam antes de tarefas de menor prioridade, você pode ceder à linha de execução principal interrompendo brevemente seu trabalho para dar ao navegador oportunidades de executar tarefas mais importantes.

Um método que os desenvolvedores usam para dividir tarefas em tarefas menores envolve setTimeout(). Com essa técnica, você transmite a função para setTimeout(). Isso adia a execução do callback para uma tarefa separada, mesmo que você especifique um tempo limite de 0.

function saveSettings () {
  // Do critical work that is user-visible:
  validateForm();
  showSpinner();
  updateUI();

  // Defer work that isn't user-visible to a separate task:
  setTimeout(() => {
    saveToDatabase();
    sendAnalytics();
  }, 0);
}

Isso é conhecido como rendimento e funciona melhor para uma série de funções que precisam ser executadas sequencialmente.

Ponto-chave:ao ceder à linha de execução principal, você dá a ela a oportunidade de processar tarefas mais importantes do que as que estavam inicialmente na fila. O ideal é ceder à linha de execução principal sempre que você tiver um trabalho voltado ao usuário, como atualizar a interface do usuário, que será executado mais cedo do que se você não ceder.

No entanto, seu código nem sempre é organizado dessa forma. Por exemplo, você pode ter uma grande quantidade de dados que precisam ser processados em um loop, e essa tarefa pode levar muito tempo se houver muitas iterações.

function processData () {
  for (const item of largeDataArray) {
    // Process the individual item here.
  }
}

O uso de setTimeout() aqui é problemático devido à ergonomia do desenvolvedor. Depois de cinco rodadas de setTimeout()s aninhadas, o navegador vai começar a impor um atraso mínimo de 5 milissegundos para cada setTimeout() adicional.

O setTimeout também tem outra desvantagem em relação ao rendimento: quando você o usa para adiar a execução de código em uma tarefa subsequente, essa tarefa é adicionada ao final da fila.setTimeout Se houver outras tarefas em espera, elas serão executadas antes do código adiado.

Uma API dedicada: scheduler.yield()

Browser Support

• 129
• 129
• x
• x

Source

scheduler.yield() é uma API projetada especificamente para ceder à linha de execução principal no navegador.

Não é uma sintaxe no nível do idioma nem um construtor especial. scheduler.yield() é apenas uma função que retorna um Promise que será resolvido em uma tarefa futura. Qualquer código encadeado para ser executado depois que Promise for resolvido (em uma cadeia .then() explícita ou depois de await em uma função assíncrona) será executado nessa tarefa futura.

Na prática: insira um await scheduler.yield() e a função vai pausar a execução nesse ponto e ceder à linha de execução principal. A execução do restante da função, chamada de continuação da função, será programada para ser executada em uma nova tarefa de loop de eventos. Quando essa tarefa for iniciada, a promessa esperada será resolvida, e a função vai continuar a ser executada de onde parou.

async function saveSettings () {
  // Do critical work that is user-visible:
  validateForm();
  showSpinner();
  updateUI();

  // Yield to the main thread:
  await scheduler.yield()

  // Work that isn't user-visible, continued in a separate task:
  saveToDatabase();
  sendAnalytics();
}

Agora, a execução da função saveSettings() é dividida em duas tarefas. Como resultado, o layout e a pintura podem ser executados entre as tarefas, oferecendo ao usuário uma resposta visual mais rápida, medida pela interação do ponteiro agora muito mais curta.

Importante:não é necessário gerar após cada chamada de função. Por exemplo, se você executar duas funções que resultam em atualizações críticas na interface do usuário, provavelmente não vai querer gerar entre elas. Se possível, deixe que o trabalho seja executado primeiro. Em seguida, considere gerar entre funções que fazem trabalhos menos críticos ou em segundo plano que o usuário não percebe.

No entanto, o verdadeiro benefício de scheduler.yield() em relação a outras abordagens de rendimento é que a continuidade delas é priorizada, o que significa que, se você ceder no meio de uma tarefa, a continuação da tarefa atual será executada antes de qualquer outra tarefa semelhante ser iniciada.

Isso evita que o código de outras origens de tarefas interrompa a ordem de execução do código, como tarefas de scripts de terceiros.

Quando você usa scheduler.yield(), a continuação retoma de onde parou antes de passar para outras tarefas.

Suporte a vários navegadores

scheduler.yield() ainda não é compatível com todos os navegadores, então é necessário usar uma alternativa.

Uma solução é colocar o scheduler-polyfill no build. Em seguida, o scheduler.yield() pode ser usado diretamente. O polyfill vai lidar com a queda para outras funções de programação de tarefas para que ele funcione de maneira semelhante em todos os navegadores.

Como alternativa, uma versão menos sofisticada pode ser escrita em algumas linhas, usando apenas setTimeout envolvido em uma promessa como substituto, se scheduler.yield() não estiver disponível.

function yieldToMain () {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }

  // Fall back to yielding with setTimeout.
  return new Promise(resolve => {
    setTimeout(resolve, 0);
  });
}

Atenção:verifique se o scheduler global e tem um método yield.

Embora os navegadores sem suporte a scheduler.yield() não recebam a continuação priorizada, eles ainda vão ceder para que o navegador continue responsivo.

Por fim, pode haver casos em que o código não pode ceder à linha de execução principal se a continuação dela não for priorizada (por exemplo, uma página conhecida por estar ocupada em que a cessão de recursos corre o risco de não concluir o trabalho por algum tempo). Nesse caso, o scheduler.yield() pode ser tratado como um tipo de melhoria progressiva: renderizar nos navegadores em que o scheduler.yield() está disponível, caso contrário, continuar.

Isso pode ser feito detectando o recurso e voltando a esperar por uma única microtarefa em uma linha útil:

// Yield to the main thread if scheduler.yield() is available.
await globalThis.scheduler?.yield?.();

Dividir o trabalho de longa duração com scheduler.yield()

O benefício de usar qualquer um desses métodos de uso de scheduler.yield() é que você pode await em qualquer função async.

Por exemplo, se você tiver uma matriz de jobs para executar que geralmente resultam em uma tarefa longa, insira rendimentos para dividir a tarefa.

async function runJobs(jobQueue) {
  for (const job of jobQueue) {
    // Run the job:
    job();

    // Yield to the main thread:
    await yieldToMain();
  }
}

Importante:scheduler.yield() só programa uma tarefa. É a await que pausa a execução para aguardar o início da nova tarefa. Não se esqueça do await e tenha cuidado com métodos iterativos, como Array.prototype.forEach, que não esperam a resolução de cada callback antes de passar para a próxima iteração.

A continuação de runJobs() será priorizada, mas ainda permitirá que trabalhos de maior prioridade, como responder visualmente à entrada do usuário, sejam executados sem precisar esperar que a lista potencialmente longa de trabalhos seja concluída.

No entanto, esse não é um uso eficiente de rendimento. O scheduler.yield() é rápido e eficiente, mas tem algumas desvantagens. Se alguns dos jobs em jobQueue forem muito curtos, o overhead poderá aumentar rapidamente, resultando em mais tempo gasto em rendimento e retomada do que na execução do trabalho real.

Uma abordagem é agrupar os jobs, só produzindo entre eles se tiver decorrido tempo suficiente desde o último. Um prazo comum é de 50 milissegundos para evitar que as tarefas se tornem longas, mas ele pode ser ajustado como uma compensação entre a capacidade de resposta e o tempo para concluir a fila de jobs.

async function runJobs(jobQueue, deadline=50) {
  let lastYield = performance.now();

  for (const job of jobQueue) {
    // Run the job:
    job();

    // If it's been longer than the deadline, yield to the main thread:
    if (performance.now() - lastYield > deadline) {
      await yieldToMain();
      lastYield = performance.now();
    }
  }
}

O resultado é que os jobs são divididos para nunca levar muito tempo para serem executados, mas o executor só cede à linha de execução principal a cada 50 milissegundos.

Jobs agrupados em várias tarefas.

Não use isInputPending()

Browser Support

• 87
• 87
• x
• x

Source

A API isInputPending() oferece uma maneira de verificar se um usuário tentou interagir com uma página e só retorna se uma entrada estiver pendente.

Isso permite que o JavaScript continue se nenhuma entrada estiver pendente, em vez de renderizar e terminar na parte de trás da fila de tarefas. Isso pode resultar em melhorias impressionantes no desempenho, conforme detalhado na Intent to Ship, para sites que, de outra forma, não retornariam à linha de execução principal.

No entanto, desde o lançamento dessa API, nosso entendimento sobre o rendimento aumentou, principalmente com a introdução do INP. Não recomendamos mais o uso dessa API. Em vez disso, recomendamos gerar independentemente de a entrada estar pendente ou não por vários motivos:

• isInputPending() pode retornar false incorretamente, mesmo que um usuário tenha interagido em algumas circunstâncias.
• A entrada não é o único caso em que as tarefas precisam ser geradas. Animações e outras atualizações regulares da interface do usuário podem ser igualmente importantes para oferecer uma página da Web responsiva.
• Desde então, APIs de rendimento mais abrangentes foram introduzidas para resolver problemas de rendimento, como scheduler.postTask() e scheduler.yield().

Conclusão

Gerenciar tarefas é um desafio, mas isso garante que sua página responda mais rapidamente às interações do usuário. Não há um único conselho para gerenciar e priorizar tarefas, mas sim várias técnicas diferentes. Para reiterar, estas são as principais coisas que você deve considerar ao gerenciar tarefas:

• Transmita para a linha de execução principal tarefas críticas para o usuário.
• Use scheduler.yield() (com um substituto para vários navegadores) para renderizar ergonomicamente e receber continuações priorizadas
• Por fim, faça o mínimo de trabalho possível nas suas funções.

Para saber mais sobre scheduler.yield(), a scheduler.postTask() relativa à programação de tarefas explícitas e a priorização de tarefas, consulte os documentos da API Priorized Task Scheduling.

Com uma ou mais dessas ferramentas, você pode estruturar o trabalho no seu aplicativo para que ele priorize as necessidades do usuário, garantindo que o trabalho menos crítico ainda seja feito. Isso vai criar uma experiência do usuário melhor, mais responsiva e agradável de usar.

Agradecemos especialmente a Philip Walton pela avaliação técnica deste guia.

Imagem em miniatura extraída do Unsplash, cortesia de Amirali Mirhashemian.