Desempenho de renderização

Os usuários percebem quando sites e apps não funcionam bem. Por isso, otimizar o desempenho de renderização é fundamental.

Os usuários da Web de hoje esperam que as páginas que visitam sejam interativas e suaves, e é aí que você precisa concentrar cada vez mais seu tempo e esforço. As páginas não devem apenas carregar rapidamente, mas também responder rapidamente à entrada do usuário durante todo o ciclo de vida. Na verdade, esse aspecto da experiência do usuário é exatamente o que a métrica Interaction to Next Paint (INP) mede. Um bom INP significa que uma página foi consistente e confiável em relação às necessidades do usuário.

Embora um componente importante do que faz uma página parecer rápida envolva a quantidade de JavaScript que você executa em resposta às interações do usuário, o que os usuários esperam são mudanças visuais na interface. As mudanças visuais em uma interface do usuário são o resultado de vários tipos de trabalho, geralmente chamados coletivamente de renderização, e esse trabalho precisa acontecer o mais rápido possível para que a experiência do usuário seja rápida e confiável.

Para criar páginas que respondam rapidamente às interações do usuário, você precisa entender como o HTML, o JavaScript e o CSS são processados pelo navegador e garantir que o código que você escreve, assim como qualquer outro código de terceiros que você inclua, seja executado da maneira mais eficiente possível.

Observação sobre as taxas de atualização do dispositivo

Atualmente, a maioria dos dispositivos atualiza as telas 60 vezes por segundo. Cada atualização produz a saída visual que você vê e é conhecida como frame. No vídeo a seguir, o conceito de frames é demonstrado:

Embora a tela de um dispositivo sempre seja atualizada em uma taxa consistente, os aplicativos executados em um dispositivo nem sempre conseguem produzir frames suficientes para corresponder a essa taxa de atualização. Por exemplo, se houver uma animação ou transição em execução, o navegador precisará corresponder à taxa de atualização do dispositivo para produzir um frame para cada vez que a tela for atualizada.

Como uma tela típica é atualizada 60 vezes por segundo, uma conta rápida revela que o navegador tem 16,66 milissegundos para produzir cada frame. Na realidade, porém, o navegador tem a própria sobrecarga para cada frame, então todo o seu trabalho precisa ser concluído em 10 milissegundos. Quando você não atende a esse orçamento, o frame rate cai e o conteúdo da página treme na tela. Esse fenômeno é chamado de instabilidade.

No entanto, as metas mudam de acordo com o tipo de trabalho que você está tentando fazer. Atender ao limite de 10 milissegundos é crucial para animações, em que os objetos na tela são interpolados em uma série de frames entre dois pontos. Quando se trata de mudanças discretas na interface do usuário, ou seja, passar de um estado para outro sem nenhum movimento entre eles, é recomendável que você faça essas mudanças em um período que pareça instantâneo para o usuário. Nesses casos, 100 milissegundos é um valor frequentemente citado, mas o limite "bom" da métrica INP é de 200 milissegundos ou menos para acomodar uma variedade maior de dispositivos com recursos variados.

Sejam quais forem suas metas, seja produzir os muitos frames que as animações exigem para evitar instabilidade ou apenas produzir uma mudança visual discreta na interface do usuário o mais rápido possível, entender como o pipeline de pixels do navegador funciona é essencial para seu trabalho.

O pipeline de pixels

Há cinco áreas principais que você precisa conhecer e considerar no seu trabalho como desenvolvedor web. Essas cinco áreas são aquelas sobre as quais você tem mais controle, e cada uma representa um ponto-chave no pipeline de pixels para tela:

• JavaScript: o JavaScript normalmente é usado para lidar com o trabalho que vai resultar em mudanças visuais na interface do usuário. Por exemplo, pode ser a função animate do jQuery, a classificação de um conjunto de dados ou a adição de elementos DOM à página. No entanto, o JavaScript não é estritamente necessário para acionar mudanças visuais: as animações CSS, as transições CSS e a API Web Animations são capazes de animar o conteúdo da página.
• Cálculos de estilo: é o processo de descobrir quais regras de CSS se aplicam a quais elementos HTML com base em seletores correspondentes. Por exemplo, .headline é um seletor de CSS que se aplica a qualquer elemento HTML com um valor de atributo class que contém uma classe de headline. Depois que as regras são conhecidas, elas são aplicadas, e os estilos finais de cada elemento são calculados.
• Layout: depois que o navegador sabe quais regras se aplicam a um elemento, ele pode começar a calcular a geometria da página, como o espaço que os elementos ocupam e onde eles aparecem na tela. O modelo de layout da Web significa que um elemento pode afetar outros. Por exemplo, a largura do elemento <body> normalmente afeta as dimensões dos elementos filhos em toda a árvore, então o processo pode ser bastante complexo para o navegador.
• Pintura: é o processo de preenchimento de pixels. Envolve desenhar texto, cores, imagens, bordas, sombras e, essencialmente, todos os aspectos visuais dos elementos depois que o layout deles na página é calculado. O desenho geralmente é feito em várias superfícies, geralmente chamadas de camadas.
• Composição: como as partes da página podem ter sido desenhadas em várias camadas, elas precisam ser aplicadas à tela na ordem correta para que a página seja renderizada conforme o esperado. Isso é especialmente importante para elementos que se sobrepõem, já que um erro pode fazer com que um elemento apareça sobre o outro incorretamente.

Cada uma dessas partes do pipeline de pixels representa uma oportunidade de introduzir instabilidade nas animações ou atrasar a pintura de frames, mesmo para mudanças visuais discretas na interface do usuário. Portanto, é importante entender exatamente quais partes do pipeline o código aciona e investigar se é possível limitar as mudanças apenas às partes do pipeline de pixels necessárias para renderizá-las.

Talvez você já tenha ouvido o termo "rasterizar" usado em conjunto com "pintar". Isso ocorre porque a pintura é, na verdade, duas tarefas:

1. Criar uma lista de chamadas de desenho.
2. Preenchendo os pixels.

O último é chamado de "rasterização". Portanto, sempre que você encontrar registros de pintura no DevTools, pense neles como incluindo a rasterização. Em algumas arquiteturas, a criação da lista de chamadas de desenho e a rasterização são feitas em linhas de execução diferentes, mas isso não está sob seu controle como desenvolvedor.

Nem sempre você vai tocar em todas as partes do pipeline em cada frame. Na verdade, há três maneiras de o pipeline normalmente ser executado para um determinado frame quando você faz uma mudança visual, seja com JavaScript, CSS ou a API Web Animations.

1. JS / CSS > Estilo > Layout > Pintura > Composição

Se você mudar uma propriedade de "layout", como uma que altera a geometria de um elemento, como largura, altura ou posição (como as propriedades CSS left ou top), o navegador precisará verificar todos os outros elementos e "reorganizar" a página. Todas as áreas afetadas precisarão ser repintadas, e os elementos pintados finais precisarão ser compostos novamente.

2. JS / CSS > Estilo > Pintura > Composição

Se você mudou uma propriedade "somente pintura" de um elemento no CSS, por exemplo, propriedades como background-image, color ou box-shadow, a etapa de layout não é necessária para confirmar uma atualização visual na página. Ao omitir a etapa de layout, quando possível, você evita um trabalho de layout potencialmente caro que, de outra forma, poderia ter contribuído para uma latência significativa na produção do próximo frame.

3. JS / CSS > Estilo > Composição

Se você mudar uma propriedade que não exige layout nem pintura, o navegador pode pular direto para a etapa de composição. Esse é o caminho mais barato e desejável pelo pipeline de pixels para pontos de alta pressão no ciclo de vida de uma página, como animações ou rolagem. Curiosidade: o Chromium otimiza a rolagem da página para que ela ocorra apenas na linha de execução do compositor, quando possível. Isso significa que, mesmo que uma página não esteja respondendo, você ainda pode rolar a página e ver partes dela que foram desenhadas anteriormente na tela.

A performance na Web é a arte de evitar trabalho, aumentando ao máximo a eficiência de qualquer trabalho necessário. Em muitos casos, trata-se de trabalhar com o navegador, não contra ele. Vale lembrar que o trabalho mostrado anteriormente no pipeline difere em termos de custo computacional. Algumas tarefas são inerentemente mais caras do que outras.

Vamos analisar as diferentes partes do pipeline. Vamos analisar os problemas comuns e como diagnosticá-los e corrigi-los.

Otimizações de renderização do navegador

O desempenho é importante para os usuários. Para criar boas experiências do usuário, os desenvolvedores web precisam criar sites que reajam rapidamente às interações do usuário e sejam renderizados sem problemas. O especialista em desempenho Paul Lewis está aqui para ajudar você a destruir o jank e criar apps da Web que mantêm o desempenho de 60 quadros por segundo. Você vai sair deste curso com as ferramentas necessárias para criar perfis de apps e identificar as causas de um desempenho de renderização abaixo do ideal. Você também vai conhecer o pipeline de renderização do navegador e descobrir padrões que facilitam a criação de sites rápidos que os usuários vão adorar usar.

Este é um curso sem custo financeiro oferecido pelo Udacity, e você pode fazê-lo a qualquer momento.