Netflix publicou um excelente artigo, Making Netflix.com Faster, sobre a sua mudança para o Node.js. O artigo menciona como eles usam performance.timing.domInteractive para medir as melhorias:

A fim de testar e entender o impacto das escolhas, nós monitoramos uma métrica que chamamos de tempo para interação (time to interactive – tti).

Quantidade de tempo gasto entre a primeira interação do usuário com a plataforma, a partir do momento em que a UI já está disponível para utilização, independentemente da view. Note que isso não requer que a UI tenha carregado completamente, mas é o primeiro ponto no qual o cliente pode interagir com a UI usando um dispositivo de entrada.

Para aplicações em execução dentro de um navegador web, esse dado é facilmente recuperável da API Navigation Timing (quando suportada).

Eu mantenho meu olho aberto para as empresas de tecnologia bem-sucedidas que usam algo diferente de window.onload para medir o desempenho. Nós todos sabemos que window.onload já não é uma boa maneira de medir a velocidade do website a partir da perspectiva do usuário. Além de ser uma métrica muito melhor, domInteractive também sofre por não ser um bom proxy para a experiência do usuário em algumas (muito comuns) situações.

O foco do redesign da Netflix é fazer com que o conteúdo interativo chegue ao usuário o mais rápido possível. Essa é definitivamente a meta certa. O problema é que domInteractive não reflete necessariamente quando isso acontece. As discrepâncias são devido a scripts, folhas de estilo e fontes que bloqueiam a renderização. Os scripts podem tornar as medições domInteractive muito grandes enquanto o conteúdo já está visível muito mais cedo. Folhas de estilo e fontes personalizadas fazem as medições domInteractive muito rápidas, sugerindo que o conteúdo está interativo mais cedo do que o real.

Para demonstrar isso, eu criei três páginas de teste. Cada página tem alguns mockups de “conteúdo interativo” – links para clicar e um formulário para enviar. O objetivo dessas páginas de teste é determinar quando esse conteúdo crítico se torna interativo e comparar isso com tempo do domInteractive.

Scripts: Ao carregando domInteractive JS – página de teste muito conservadora, vemos que o conteúdo crítico é visível quase imediatamente. Abaixo desse conteúdo está um script que leva 8 segundos para carregar. O tempo do domInteractive é de mais de 8 segundos, mesmo que o conteúdo crítico já estivesse interativo em cerca de meio segundo. Se você tiver o bloqueio de scripts na página que ocorrem abaixo do conteúdo crítico, domInteractive produz medições que são muito conservadoras – elas são maiores do que quando o conteúdo já está realmente interativo (resultados WebPageTest para Chrome, Firefox, IE e Safari).

Folhas de estilo: Por outro lado, carregando o domInteractive CSS – página de teste demasiada otimista, o conteúdo crítico não é visível por mais de 8 segundos. Isso porque esse conteúdo é bloqueado de renderizar até que a folha de estilo termine de ser carregada, o que leva 8 segundos. No entanto, o tempo do domInteractive é de cerca de meio segundo. Se você usar folhas de estilo, domInteractive pode produzir medições que são extremamente otimistas – elas são menores do que quando o conteúdo está realmente interativo (resultados WebPageTest para Chrome, Firefox, IE e Safari).

Fontes: Os resultados para o domInteractive Font – demasiado otimista têm um tempo domInteractive de cerca de meio segundo em todos os navegadores, mas o momento em que o conteúdo crítico é visível varia. No Safari, o conteúdo crítico não é visível por mais de 8 segundos enquanto aguarda o arquivo de fonte ser carregado. No Chrome e no Firefox, o conteúdo crítico é bloqueado por 3 segundos no momento em que ele é processado com uma fonte padrão. Isso porque Chrome e Firefox usam um tempo de 3 segundos quando estão esperando por fontes; se a fonte não carregar dentro de três segundos, então uma fonte padrão é usada. IE11 exibe o conteúdo crítico imediatamente, usando uma fonte padrão. No Chrome, Firefox e IE11, o conteúdo é re-processado quando o arquivo de fonte termina de ser carregado, depois de mais de 8 segundos. Se você usar fontes personalizadas para qualquer de seu conteúdo crítico, domInteractive pode produzir medições que são demasiada otimistas no Chrome, Firefox e Safari – elas são menores do que quando o conteúdo está realmente interativo (a menos que você carregue suas fontes de forma assíncrona como o Typekit faz; resultados WebPageTest para Chrome, Firefox, IE e Safari).

Uma solução é evitar estas situações: sempre carregar scripts, folhas de estilo e fontes de forma assíncrona. Apesar de isso ser ótimo, não é sempre possível (eu estou olhando para você, snippets de terceiros!) e é difícil garantir que tudo é assíncrono quando há alterações no código.

A melhor solução é a utilização de métricas personalizadas. As páginas web de hoje são complexas e únicas, os dias de uma métrica padrão, built-in, que se aplica a todos os sites, não existem mais. O tempo de navegação nos dá métricas que são melhores do que window.onload, mas as equipes que estão focadas no desempenho precisam dar o próximo passo e implementar métricas personalizadas para medir com precisão o que seus usuários estão experimentando.

NOTA: Eu espero que ninguém, especialmente o pessoal da Netflix, ache que este artigo é uma crítica de seu trabalho. Muito pelo contrário, o artigo deles me deu a ideia de fazer essa investigação. Netflix é uma grande empresa de tecnologia, especialmente quando se trata de desempenho e compartilhamento com a comunidade de tecnologia. Também é provável que eles não sofram com essas fontes personalizadas e problemas de bloqueio de script e, assim, domInteractive está produzindo tempos de interação precisos para o website deles.

***

Steve Souders faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://www.stevesouders.com/blog/2015/08/07/dominteractive-is-it-really/