Análise para dispositivos móveis no PageSpeed Insights

O PageSpeed Insights analisa páginas para avaliar se elas seguem nossas recomendações de fazer uma página ser processada em menos de um segundo em uma rede móvel. Pesquisas mostraram que qualquer atraso maior que um segundo fará o usuário interromper seu fluxo de pensamento, gerando uma experiência ruim. Nossa meta é manter o usuário envolvido com a página e oferecer a experiência ideal, independentemente do dispositivo ou do tipo de rede.

Não é fácil atingir a meta de um segundo. Pelo menos, não é preciso que a página inteira seja processada dentro desse intervalo. Em vez disso, precisamos exibir e processar o conteúdo acima da dobra (ATF, na sigla em inglês) em menos de um segundo, permitindo que o usuário comece a interagir com a página o quanto antes. Depois, enquanto o usuário interpreta a primeira página de conteúdo, o restante da página pode ser exibido progressivamente em segundo plano.

Adaptação a redes móveis de alta latência

Cumprir o critério ATF de um segundo em dispositivos móveis apresenta desafios únicos que não estão presentes em outras redes. Os usuários podem estar acessando seu site por meio de diferentes redes 2G, 3G e 4G. As latências de rede são significantemente mais altas do que as de uma conexão com fio e consomem uma porção importante do orçamento de 1.000 ms para processar o conteúdo ATF.

  • tempo de viagem de ida e volta de 200-300 ms para redes 3G
  • tempo de viagem de ida e volta de 50-100 ms para redes 4G

O 4G é o tipo de rede dominante no mundo. Espera-se que a maioria dos usuários acesse sua página em uma rede 4G. Por isso, presumimos que cada solicitação de rede levará, em média, 100 milésimos de segundo.

Sabendo disso, vamos analisar o processo. Se observarmos uma sequência típica de comunicação entre um navegador e um servidor, 300 ms do tempo já terão sido utilizados pela sobrecarga da rede: uma busca DNS para resolver o nome do host (por exemplo, google.com.br) para um endereço IP, uma viagem de ida e volta da rede para gerar um handshake do TCP e uma conexão TLS opcional. Isso nos deixa com 700 ms.

Como proporcionar a experiência de renderização em menos de um segundo

Após subtrair a latência da rede, restam 700 milésimos de segundo, e ainda há muito trabalho a fazer. O servidor precisa renderizar a resposta; o código do aplicativo do cliente tem que ser executado; e o navegador precisa criar o layout e renderizar o conteúdo. Temos alguns critérios que devem ajudar a atingir o tempo desejado:

(1) O servidor precisa renderizar a resposta (< 200 ms).
O tempo de resposta do servidor é o tempo que o servidor leva para retornar o HTML inicial, calculando o tempo de transporte da rede. Como temos pouco tempo, ele deve ser mantido no mínimo (em condições ideais, dentro de 200 milésimos de segundo e, preferencialmente, ainda menos que isso).
(2) O número de redirecionamentos deve ser minimizado.
Redirecionamentos HTTP adicionais podem acrescentar uma ou duas viagens de ida e volta (duas caso outra busca DNS seja necessária), incorrendo em centenas de milésimos de segundo de latência adicional em redes 4G. Por essa razão, recomendamos aos webmasters que minimizem o número de redirecionamentos ou os eliminem por completo. Isso é especialmente importante para o documento HTML (evite redirecionamentos "m ponto" quando possível).
(3) O número de viagens de ida e volta para a primeira renderização deve ser minimizado.

Devido à forma como o TCP estima a capacidade de uma conexão (por exemplo, Início lento do TCP), uma nova conexão TCP não poderá usar imediatamente toda a largura de banda disponível entre o cliente e o servidor. Por isso, o servidor pode enviar até 10 pacotes TCP em uma nova conexão (cerca de 14 KB) na primeira viagem de ida e volta. Depois disso, ele precisa esperar que o cliente reconheça esses dados antes de aumentar a janela de congestionamento e exibir mais dados.

Além disso, é importante observar que o limite do pacote 10 (IW10) é uma atualização recente ao padrão TCP. Verifique se seu servidor está atualizado com a versão mais recente para aproveitar essa mudança. Caso contrário, o limite provavelmente será de 3 ou 4 pacotes.

Por causa desse comportamento do TCP, é importante otimizar seu conteúdo a fim de minimizar o número de viagens de ida e volta exigidas para exibir os dados necessários e fazer a renderização inicial da página. O ideal é que o conteúdo ATF tenha menos de 98 KB. Isso permite que o navegador preencha a página com apenas três viagens de ida e volta, deixando tempo suficiente para a latência da resposta do servidor e para a renderização do cliente.

(4) Evite bloqueios externos de JavaScript e CSS no conteúdo acima da dobra.

Antes de renderizar as páginas para o usuário, o navegador precisa analisá-las. Se forem encontrados scripts externos de bloqueio ou não assíncronos durante a análise, será preciso interrompê-la e fazer o download do recurso. Sempre que isso acontece, uma viagem de ida e volta é adicionada na rede, o que atrasa o tempo do primeiro processamento da página.

Como resultado, o JavaScript e o CSS necessários para processar a região acima da dobra devem estar in-line, e o JavaScript ou o CSS necessários para acrescentar funcionalidades adicionais à página devem ser carregados após o conteúdo ATF ser exibido.

(5) Reserve tempo para o processamento e a criação do layout do navegador (200 ms)
O processo de análise de HTML, CSS, e de execução do JavaScript usa tempo e recursos do cliente. Dependendo da velocidade do dispositivo móvel e da complexidade da página, esse processo pode levar centenas de milésimos de segundos. Recomendamos que sejam reservados 200 milésimos de segundos para a sobrecarga do navegador.
(6) Otimize a execução do JavaScript e o tempo de processamento
Scripts complicados e códigos ineficazes podem levar dezenas e centenas de milésimos de segundos para serem executados. Use ferramentas do desenvolvedor integradas no navegador para traçar o perfil e otimizar seu código. Para uma ótima introdução, confira nosso curso interativo para Ferramentas de desenvolvedor do Google Chrome.

Perguntas frequentes

Estou usando uma biblioteca JavaScript como a jQuery. Alguma recomendação?
Muitas bibliotecas JavaScript, como a JQuery, são usadas ​​para aprimorar a página e adicionar novas formas de interatividade, animações e outros efeitos. No entanto, muitos desses comportamentos podem ser adicionados com segurança depois que o conteúdo ATF é processado. Teste movendo a execução e o carregamento desse JavaScript para após o carregamento da página.
Estou usando uma estrutura de JavaScript para desenvolver a página. Alguma recomendação?
Se o conteúdo da página for criado pelo JavaScript do cliente, tente fazer a inserção in-line dos módulos de JavaScript relevantes para evitar idas e voltas adicionais da rede. Da mesma forma, ao aproveitar a renderização do servidor, você melhora significativamente o carregamento da primeira página: processe os modelos de JS no servidor, insira os resultados in-line no HTML e, em seguida, use os modelos do cliente quando o aplicativo for carregado.
Como identificar CSS essencial na minha página?
Nas Ferramentas para Desenvolvedores do Google Chrome, abra o painel de Auditorias e execute um relatório de Desempenho de página da Web. No relatório gerado, procure a opção "Remover regras CSS não utilizadas". Também é possível usar qualquer outra ferramenta ou outro script de terceiros para identificar quais seletores CSS são aplicados em cada página.
Essas práticas recomendadas podem ser automatizadas?
Certamente. Há muitos produtos comerciais e de otimização de desempenho da Web (WPO) de código aberto que podem ajudar você a satisfazer alguns ou todos os critérios acima. Para soluções de código aberto, dê uma olhada nas Ferramentas de otimização PageSpeed.
Como ajusto meu servidor para satisfazer a esses critérios?
Em primeiro lugar, verifique se o servidor está executando uma versão atualizada do sistema operacional. Para aproveitar o aumento do tamanho (IW10) da janela de congestionamento de TCP inicial, você precisará do Linux kernel 2.6.39+. Para informações sobre outros sistemas operacionais, consulte a documentação.
Para otimizar o tempo de resposta do servidor, instrumente seu código ou use uma solução de monitoramento de aplicativo para identificar o gargalo, por exemplo, tempo de execução de scripts, chamadas de banco de dados, solicitações de RPC, renderização etc. O objetivo é processar a resposta HTML em até 200 milissegundos.
E a Política de Segurança de Conteúdo?
Se você estiver usando a Política de Segurança de Conteúdo (CSP, na sigla em inglês), talvez seja necessário atualizar sua política padrão.
Primeiro, os atributos CSS in-line em elementos HTML (por exemplo, &lt p style=...&gt) devem ser evitados sempre que possível, já que muitas vezes eles levam à duplicação de código desnecessária e são bloqueados por padrão com a CSP (desativado por meio de "in-line não seguro" no "estilo src"). Se a CSP estiver ativada, ela bloqueará todas as tags de script in-line por padrão. Se você tiver JavaScript in-line, será necessário atualizar a política de CSP para usar hashes ou nonces de script ou utilizar "in-lines não seguros" para permitir que todos os scripts in-line sejam executados. Se você tiver estilos de in-line, será necessário atualizar a política de CSP para usar hashes ou nonces de estilo ou "in-lines não seguros" a fim de permitir que todos os blocos de estilo de in-line sejam processados.

Mais alguma pergunta? Mande suas perguntas e comentários para nosso grupo de discussão em pagespeed-insights-discuss.