Os usuários percebem quando os 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 eles visitam sejam interativas e fluídas, e é nisso que você precisa concentrar 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 responsiva de forma consistente e confiável às necessidades do usuário.
Embora um componente importante do que torna uma página 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 do usuário. As mudanças visuais em uma interface do usuário são o resultado de vários tipos de trabalho, muitas vezes chamados coletivamente de renderização. 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 escrever páginas que respondam rapidamente às interações do usuário, é necessário entender como HTML, JavaScript e CSS são processados pelo navegador e garantir que o código escrito, assim como qualquer outro código de terceiros incluído, seja executado da maneira mais eficiente possível.
Observação sobre as taxas de atualização do dispositivo

Atualmente, a maioria dos dispositivos atualiza a tela 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 a uma taxa consistente, os aplicativos executados em um dispositivo nem sempre podem 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 precisa corresponder à taxa de atualização do dispositivo para produzir um frame a cada atualização da tela.
Considerando que uma tela típica é atualizada 60 vezes por segundo, algumas contas rápidas revelam que o navegador tem 16,66 milissegundos para produzir cada frame. Na realidade, no entanto, o navegador tem sua própria sobrecarga para cada frame. Portanto, todo seu trabalho precisa ser concluído em 10 milissegundos. Quando você não cumpre esse orçamento, a taxa de frames diminui e o conteúdo da página fica instável na tela. Esse fenômeno é chamado de instabilidade.
No entanto, seus objetivos mudam de acordo com o tipo de trabalho que você está tentando fazer. Atingir o 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, passando de um estado para outro sem nenhum movimento entre eles, é recomendado que você faça essas mudanças em um período que pareça instantâneo para o usuário. Em casos como esses, 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.
Seja qual for sua meta, seja produzir os muitos frames que as animações precisam para evitar o lag 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.
Pipeline do pixel
Há cinco áreas principais que você precisa conhecer e considerar no seu trabalho como desenvolvedor da 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 geralmente é usado para processar trabalhos que resultam
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. O JavaScript não é estritamente necessário para acionar mudanças visuais: animações CSS, transições CSS e a API Web Animations podem 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 nos seletores correspondentes. Por exemplo,
.headline
é um exemplo de seletor CSS que se aplica a qualquer elemento HTML com um valor de atributoclass
que contém uma classe deheadline
. Depois que as regras são conhecidas, elas são aplicadas e os estilos finais de cada elemento são calculados. - Layout:quando o navegador sabe quais regras se aplicam a um elemento, ele pode
começar a calcular a geometria da página, como a quantidade de 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 de cima para baixo, então o processo pode ser bastante complexo para o navegador. - Pintura:é o processo de preenchimento de pixels. Ele envolve a exibição de texto, cores, imagens, bordas, sombras e, basicamente, todos os aspectos visuais dos elementos depois que o layout deles na página foi calculado. O desenho geralmente é feito em várias superfícies, muitas vezes chamadas de camadas.
- Composto:como as partes da página foram potencialmente 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 resultar na exibição incorreta de um elemento sobre outro.
Cada uma dessas partes do pipeline de pixels representa uma oportunidade de introduzir jank em 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 são acionadas pelo código e investigar se é possível limitar as mudanças apenas às partes do pipeline de pixels que são necessárias para renderizá-las.
Você já deve ter ouvido o termo "rastrear" usado com "pintar". Isso acontece porque a pintura é, na verdade, duas tarefas:
- Criação de uma lista de chamadas de exibição.
- Preenchendo os pixels.
O segundo é chamado de "rastreamento". Portanto, sempre que você encontrar registros de pintura nas Ferramentas do desenvolvedor, pense que eles incluem rasterização. Em algumas arquiteturas, a criação da lista de chamadas de renderização 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 todos os frames. 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 muda a geometria
de um elemento, como largura, altura ou posição (como as propriedades CSS
left
ou top
), o navegador precisa verificar todos os outros elementos e "refluir" a
página. Todas as áreas afetadas precisarão ser pintadas novamente, e os elementos pintados
finais precisarão ser compostos novamente.
2. JS / CSS > Estilo > Pintura > Composição

Se você tiver alterado uma propriedade "somente pintura" para um elemento no CSS, por exemplo,
propriedades como background-image
, color
ou box-shadow
, a etapa de layout
não será necessária para confirmar uma atualização visual na página. Ao omitir a etapa de layout,
sempre que possível, você evita trabalhos de layout potencialmente caros que poderiam
ter causado latência significativa na produção do próximo frame.
3. JS / CSS > Estilo > Composto

Se você mudar uma propriedade que não exige nenhum layout ou pintura, o navegador poderá pular diretamente 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, sempre que possível. Isso significa que, mesmo que uma página não esteja respondendo, você ainda pode rolar a página e conferir partes dela que foram renderizadas anteriormente na tela.
A performance da Web é a arte de evitar trabalho, aumentando ao máximo a eficiência de qualquer trabalho necessário. Em muitos casos, é preciso trabalhar com o navegador, não contra ele. Vale lembrar que o trabalho mostrado anteriormente no pipeline é diferente em termos de custo computacional. Algumas tarefas são inerentemente mais caras do que outras.
Vamos conhecer 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, e para criar boas experiências, os desenvolvedores da Web precisam criar sites que reajam rapidamente às interações do usuário e renderizem sem problemas. O especialista em desempenho Paul Lewis está aqui para ajudar você a acabar com o lag e criar apps da Web que mantenham a performance de 60 frames por segundo. Ao final deste curso, você vai ter as ferramentas necessárias para criar perfis de apps e identificar as causas de performance de renderização subótima. 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 pela Udacity, e você pode participar a qualquer momento.