Como Melhorar o Desempenho do meu Site?
E o desempenho do site depende de que?
O desempenho de um site é o tempo que a infraestrutura leva para carregar seu site. Este tempo depende do provedor, link de internet, scripts e browser que estão no front-end.
São duas as partes principais da infraestrutura neste processo.
O front-end é o conjunto de recursos que auxiliam as páginas a serem renderizadas por um navegador . Isso inclui coisas como:
- HTML
- CSS
- Javascript
- Mídia (imagens, vídeo etc.)
Estes são os componentes que seu navegador usa para construir e renderizar uma página.
Existem vários sites que analisam se seu site está seguindo as práticas recomendadas pelo Google ou outras ferramentas de busca.
Uma boa pontuação nos analisadores significa que sua página está otimizada para o navegador renderizar o mais rápido possível.
Back-end: infraestrutura de servidores
Normalmente, as páginas lentas aumentam a velocidade de carregamento do site mesmo havendo adiamento do JavaScript, compressão ou otimização de imagens . No entanto, sua página otimizada ainda precisa ser criada e veiculada e, se demorar muito tempo, isto vai tornar o site inteiro muito lento.
O processo de construção do site depende de sua infraestrutura – o back-end do seu site: servidores, hospedagem, banco de dados, código, rede (links).
Iniciativas que vão melhorar seu desempenho
O PageSpeed e o YSlow indicam se o seu front-end (o que o navegador vê) segue ou não as práticas recomendadas para obter a velocidade ideal. Não diz nada sobre seu desempenho de back-end, o que é muito difícil de avaliar em um nível padronizado. As otimizações de back-end podem variar de otimização de código a atualizações de servidor / hospedagem e são muito mais envolvidas, pois exigem entendimento técnico da configuração do servidor ou criação de perfil de código para entender os gargalos de seus problemas de desempenho.
Como resultado, é difícil determinar os motivos de um back-end não otimizado. Os sites são construídos com plataformas diferentes (WordPress, Magento, CMS personalizado etc.) e servidos por diferentes níveis de configurações de hospedagem (compartilhada, VPS, dedicada, nuvem, AWS, etc.). Não há uma lista de práticas recomendadas para o desempenho de back-end devido a essa grande variação na arquitetura do site, e os sites podem tecnicamente fazer várias coisas para entregar o código final do front-end ao navegador.
Análise para dispositivos móveis
O padrão de renderização no Google é de um segundo.
Após subtrair a latência da rede (transporte), restam 700 milésimos de segundo. 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 ajudarão a atingir o tempo desejado:
- 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 é mantido no mínimo. Em condições ideais, dentro de 200 milésimos de segundo.
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), acrescentando centenas de milésimos de segundo de latência em redes 4G. Por essa razão, recomendamos aos webmasters que minimizem o número de redirecionamentos ou os eliminem por completo.
3. O número de viagens de ida e volta para a primeira renderização precisa 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 de 10 pacotes (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 três ou quatro 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 exiba 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 da primeira renderização da página.
Como resultado, o JavaScript e o CSS necessários para processar a região acima da dobra devem estar in-line. Já o JavaScript ou o CSS necessários para acrescentar outras funcionalidades à página devem ser carregados após a exibição do conteúdo ATF.
5. Reserve tempo para a renderização 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 segundo. Recomendamos que sejam reservados 200 milésimos de segundo para a sobrecarga do navegador.
6. Otimize a execução do JavaScript e o tempo de renderização
A execução de scripts complicados e códigos ineficazes pode levar dezenas e centenas de milésimos de segundo. Use ferramentas do desenvolvedor integradas no navegador para traçar o perfil e otimizar seu código.
Conclusão
Caracterísitcas como execução de javascripts e carregamento de imagens são fundamentais para o controle de desempenho de seu site.
Em 2011 foram realizados testes que demonstraram que em dispositivos móveis modernos, cada kilobyte adicional de JavaScript adiciona cerca de 1ms de tempo de análise ao tempo total de carregamento da página. Portanto, 100kB de JavaScript incluído no carregamento da página inicial adicionariam 100ms de tempo de carregamento para seus usuários. Como o JavaScript deve ser analisado em todas as visitas a uma página, esse tempo adicional de carregamento fará parte de cada carregamento da página, seja carregado na rede, via cache do navegador.
Deixe uma resposta