Feedback do desenvolvedor necessário: API Frame Timing

Nos últimos anos, os navegadores fizeram grandes avanços em termos de desempenho de renderização, especialmente em dispositivos móveis. Se antes você não tinha esperança de atingir uma taxa de frames suave para algo remotamente complexo, hoje isso é possível, desde que você tome cuidado.

No entanto, para a maioria de nós, há uma desconexão entre o que podemos testar de forma razoável nos nossos dispositivos e o que os usuários vivenciam. Se a experiência não for suave e com 60 fps, ela será prejudicada, e o usuário vai procurar outro lugar, e nós vamos sofrer. Por isso, o W3C está discutindo uma nova API que pode ajudar a entender o que os usuários veem: a API Frame Timing.

Jake Archibald e eu gravamos recentemente um vídeo de visão geral da API. Se você prefere assistir a ler, confira:

Usos da API Frame Timing

É possível fazer muitas coisas com a API Frame Timing e, principalmente, medir o que é importante para você e seu projeto. Mesmo assim, confira algumas ideias:

  • Rastreamento de QPS das animações JavaScript e CSS.
  • Acompanhar a fluidez da rolagem da página (ou talvez a lista de rolagem infinita que você tem).
  • Reduzir automaticamente os efeitos de destaque com base na carga atual do dispositivo.
  • Testes de regressão em métricas de desempenho de execução.

O pitch rápido

Confira como a API atualmente aparece na especificação: com ela, você pode extrair dados sobre o tempo da linha de execução do renderizador, em que o JavaScript, os estilos e o layout são executados. Você pode ter ouvido que a linha de execução do renderizador é chamada de linha de execução principal. É a mesma coisa, mas com outro nome.

var rendererEvents = window.performance.getEntriesByType("renderer");

Cada um dos registros de linha de execução do renderizador que você recebe tem esta aparência:

    {
      sourceFrameNumber: 120,
      startTime: 1342.549374253
      cpuTime: 6.454313323
    }

Cada registro é essencialmente um objeto que contém um número de frame exclusivo, um carimbo de data/hora de alta resolução para quando o frame foi iniciado e outro para quanto tempo de CPU ele usou. Com uma matriz dessas, você pode analisar cada um dos valores de startTime e descobrir se a linha de execução principal está a 60 fps. Ou seja, "o startTime de cada frame aumenta em pedaços de aproximadamente 16 ms?"

Além disso, você também recebe o cpuTime, para saber se está dentro do limite de 16 ms ou se está no limite. Se o cpuTime estiver próximo do limite de 16 ms, não haverá muito espaço para coisas como a coleta de lixo. Com o uso da CPU alto, o consumo de bateria também será maior.

Além da linha de execução do renderizador, você também pode extrair dados sobre o tempo da linha de execução do compositor, em que a pintura e a composição acontecem:

var compositeThreadEvents = window.performance.getEntriesByType("composite");

Cada um deles também retorna com um número de frame de origem, que pode ser usado para vincular os eventos da linha de execução principal:

{
    sourceFrameNumber: 120,
    startTime: 1352.343235321
}

Devido à forma como a composição geralmente funciona nos navegadores, pode haver vários desses registros por registro de linha de execução do renderizador. Use sourceFrameNumber para vincular esses registros. Há também uma discussão sobre se deve haver tempo de CPU nesses registros. Se você tiver certeza, fale sobre os problemas do GitHub.

Mais informações

Essa API ainda não está sendo enviada, mas esperamos que isso aconteça em breve. Enquanto isso, confira algumas coisas que você pode ler e fazer: