Otimização de desempenho de front-end - pré-carregamento de recursos
Quando se trata de otimização de desempenho de front-end, primeiro pensamos em mesclagem de arquivos, compactação, armazenamento em cache de arquivos e compactação gzip do lado do servidor. Isso torna o carregamento da página mais rápido e os usuários podem usar nosso aplicativo da web para atingir seus objetivos o mais rápido possível .
O pré-carregamento de recursos é outra técnica de otimização de desempenho, podemos usar essa técnica para informar ao navegador que determinados recursos podem ser usados no futuro.
Citando a explicação de Patrick Hamann:
O pré-carregamento é uma dica do navegador para os recursos que podem ser usados no futuro. Alguns recursos podem ser usados na página atual e alguns podem ser usados em algumas páginas no futuro. Como desenvolvedores, conhecemos nossos aplicativos melhor do que navegadores, portanto, podemos usar essa tecnologia para nossos recursos principais.
Essa prática já foi chamada de pré-busca, mas não é uma tecnologia única, ela pode ser subdividida em várias tecnologias diferentes: pré-busca DNS, sub-recurso e pré-busca padrão, pré-conexão, pré-renderização.
Pré-resolução de DNS A pré-busca de DNS
informa ao navegador que podemos obter recursos de um URL específico no futuro por meio da pré-resolução de DNS. Quando o navegador realmente usa um recurso no domínio, ele pode concluir a resolução de DNS o mais rápido possível. Por exemplo, se pudermos obter imagens ou recursos de áudio de example.com no futuro, podemos adicionar o seguinte conteúdo à tag na parte superior do documento:
Mencionado no artigo de Harry Roberts:
Uma linha simples de código pode dizer aos navegadores compatíveis para realizar a pré-resolução de DNS, o que significa que quando o navegador realmente solicita um recurso no domínio, a resolução de DNS já está completa.
Esta parece ser uma otimização de desempenho muito pequena e não parece tão importante, mas não é o caso - o Chrome sempre fez otimizações semelhantes. Quando você insere um pequeno segmento do URL na barra de endereço do navegador, o Chrome conclui automaticamente a pré-resolução de DNS (ou mesmo a pré-renderização da página), economizando tempo vital para cada solicitação.
Pré-conectar
Semelhante à pré-resolução de DNS, a pré-conexão não apenas completa a pré-resolução de DNS, mas também realiza handshake TCP e estabelece um protocolo de camada de transporte. Ele pode ser usado assim:
1 Há uma introdução mais detalhada no artigo de Ilya Grigorik:Os navegadores modernos tentam prever quais conexões o site precisará no futuro e, em seguida, pré-estabelecer conexões de soquete para eliminar pesquisas DNS caras, handshake TCP e sobrecarga de ida e volta de TLS. No entanto, o navegador não é inteligente o suficiente para prever com precisão todos os alvos de pré-link para cada site. Felizmente, no Firefox 39 e no Chrome 46, podemos usar a pré-conexão para informar ao navegador quais pré-conexões precisamos fazer.
Pré-busca
Se tivermos certeza de que um determinado recurso será usado no futuro, podemos pedir ao navegador para solicitar o recurso com antecedência e colocá-lo no cache do navegador. Por exemplo, uma imagem e um script ou qualquer recurso que possa ser armazenado em cache pelo navegador:
1 Diferente da pré-resolução de DNS, a solicitação real é pré-buscada e o recurso é baixado e armazenado no cache. Mas a pré-busca também depende de algumas condições. Algumas pré-buscas podem ser ignoradas pelo navegador, como buscar um arquivo de fonte enorme em uma rede muito lenta. Além disso, o Firefox só fará uma pré-busca de recursos quando o navegador estiver ocioso.Conforme mencionado na postagem de Bram Stein, esta é uma melhoria muito óbvia no desempenho de webfonts. Atualmente, os arquivos de fonte devem esperar até que o DOM e o CSS sejam construídos antes de começarem o download. O uso de pré-busca pode facilmente contornar esse gargalo.
Nota: É um pouco difícil testar a pré-busca de recursos, mas existem registros de pré-busca de recursos no painel de rede do Chrome e Firefox. Também é necessário lembrar que os recursos pré-buscados não são restritos pela política de mesma origem.
Subrecursos
Este é outro método de pré-busca. Os recursos pré-buscados especificados desta forma têm a prioridade mais alta e são executados antes de todos os itens de pré-busca:
1 De acordo com a documentação do Chrome:rel = prefetch fornece um método de pré-carregamento de recursos de baixa prioridade para páginas futuras e rel = subresource fornece um método de pré-carregamento de recursos de alta prioridade para a página atual.
Portanto, se o recurso for necessário para a página atual ou se o recurso precisar estar disponível o mais rápido possível, é melhor usar sub-recursos em vez de pré-busca.
Pré-render
Esta é uma arma nuclear, porque o pré-renderizador pode pré-carregar todos os recursos do documento:
1 Steve Souders escreveu em um de seus artigos:Isso é semelhante a abrir um link em uma página de guia oculta - todos os recursos serão baixados, estrutura DOM criada, layout de página concluído, estilo CSS aplicado, script JavaScript executado, etc. Quando o usuário realmente visita o link, a página oculta é alterada para visível, fazendo com que a página pareça ser carregada instantaneamente. A Pesquisa Google usa essa tecnologia em sua página de busca instantânea há muitos anos, e a Microsoft também anunciou que oferecerá suporte a esse recurso no IE11.
Deve-se notar que não abuse deste recurso.Você pode realizar a pré-renderização somente quando você sabe que o usuário irá clicar em um link, caso contrário o navegador irá baixar incondicionalmente todos os recursos necessários para a pré-renderização.
Mais discussões relacionadas:
Todas as tecnologias de pré-carregamento têm um risco potencial: a previsão de recursos está errada e o custo de pré-carregamento (preempção de recursos da CPU, consumo de bateria, desperdício de largura de banda etc.) é alto, portanto, devemos proceder com cautela. Embora seja difícil determinar quais recursos os usuários acessarão na próxima etapa, existem cenários de alta confiança:
Se o usuário concluir uma pesquisa com resultados óbvios, a página de resultados provavelmente será carregada.
Se o usuário entrar na página de destino, a página de destino bem-sucedida provavelmente será carregada.
Se o usuário ler um artigo de várias páginas ou visitas um conjunto de resultados paginados, a próxima página provavelmente será carregada.
Por fim, o uso da API de visibilidade da página pode impedir que a página seja executada antes de estar realmente visível.
Pré-carga
O pré-carregamento é uma nova especificação. Ao contrário da pré-busca (que pode ser ignorada), o navegador deve pré-carregar o recurso:
1 Embora a especificação não seja compatível com todos os navegadores, a ideia por trás dela ainda é muito interessante.Resumindo
Prever quais recursos o usuário acessará em seguida é difícil e requer muitos testes, mas a melhoria de desempenho que isso traz é óbvia. Se estivermos dispostos a experimentar essas técnicas de pré-busca, isso certamente irá melhorar significativamente a experiência do usuário.
-
Reduza a latência e as solicitações da rede.
Evite usar páginas de destino para redirecionamento.
O redirecionamento causará solicitações HTTP adicionais, atrasos na rede e tornará mais lento o processamento de páginas da web. O redirecionamento também pode causar pesquisas DNS adicionais, handshake TCP e negociação TLS.
Combine recursos e reduza as solicitações de rede
. A forma mais comum de combinar recursos é sprite.
Além disso, você também pode mesclar código CSS e JS. -
Controlando o número de downloads de recursos Ao
acessar uma página da web, os recursos solicitados devem ser úteis para evitar solicitações de recursos inúteis, como: -
jsArquivos extras ,cssarquivos -
Pedido de imagem extra
-
Solicitação de fonte extra
-
Otimização do volume de recursos Os recursos
usados no site são principalmente:
Recursos de texto, como js, css e html;
recursos de imagem, várias figuras
3.1 Otimização de recursos de texto
Em primeiro lugar, é claro, você deve escrever um código conciso e de alta qualidade.
Em segundo lugar, para arquivos js, arquivos html e arquivos css, é necessário minimizar os arquivos, remover espaços e quebras de linha entre os textos e substituir os nomes das variáveis.
Essas tarefas geralmente são realizadas quando o projeto de front-end é empacotado, como:
Arquivos HTML usam HTMLMinifier;
arquivos CSS são empacotados em Webpack, configure o carregador para minimizar;
arquivos JS usam plug-in UglifyJsPlugin; a
próxima etapa é usar GZIP para codificar e compactar os arquivos.
Os navegadores modernos podem aceitar arquivos no formato gzip, tudo o que precisamos fazer é configurar o servidor.
3.2 Otimização
de recursos de imagem Escolha o formato de imagem correto.
Embora seja freqüentemente dito que imagens png podem representar melhor as imagens fotográficas do que imagens jpge, para muitas imagens, as imagens no formato png são convertidas para o formato jpeg para a clareza da imagem. grande impacto, mas o volume pode ser bastante reduzido.
Remover metadados desnecessários
Algumas fotos tiradas conterão metadados, que são dados que descrevem os dados. Os metadados descrevem as informações do dispositivo, carimbo de data / hora, tamanho da imagem, etc. da foto tirada. Isso não é muito importante para algumas fotos de páginas da Web, portanto, podemos remover esses metadados.
Experimente este site VerExif.
Reduzindo o tamanho da imagem Em
alguns casos, mesmo se uma imagem grande for usada como plano de fundo da tag ou rótulo <img>, seu tamanho na página da web real também é muito pequeno. Neste caso, usar uma imagem grande é um desperdício de recursos. É possível redefinir o tamanho da imagem, como alterar uma imagem de 1200 x 600 pixels para 600 x 300 pixels.
Reduzir a qualidade da imagem
Em alguns casos, reduzir a qualidade da imagem não causa nenhuma diferença visual, mas pode reduzir muito o volume.
Existem diversos softwares que tratam da qualidade da imagem, como:
XNConvert
ImageOptim
Resizelt
mais referências aqui.
Compactação de imagem
Embora a compactação gzip não seja eficaz para imagens, ainda existem muitos softwares que podem compactar imagens sem afetar o tamanho e a qualidade visual da imagem, como este site.
Para obter mais sites, consulte [aqui] (
http: //enviragallery.com/9-be ....
- Usando o cache HTTP
Estritamente falando, isso também é considerado para reduzir o número de solicitações, mas a implementação é completamente diferente.
Usar o cache HTTP é definir uma estratégia de cache apropriada, que pode evitar que o navegador solicite recursos repetidamente do servidor.
O armazenamento em cache HTTP é principalmente sobre como definir as informações de cabeçalho de resposta correta no lado do servidor.
Existem dois tipos de cache: cache forte e cache de negociação.
4.1 Cache forte O cache
forte significa que o navegador usa diretamente os recursos locais sem fazer solicitações ao servidor. Existem dois cabeçalhos de resposta envolvidos: Expires e Cache-control.
Expires é o conteúdo do http 1.0, e seu conteúdo é um horário específico definido pelo servidor, como Expires: Wed, 21 Out 2015 07:28:00 GMT, não há necessidade de saber muito.
Cache-control é um novo cabeçalho adicionado por http 1.1 e seu valor é um ou uma combinação dos seguintes comandos:
no-cache: indica que o navegador pode armazenar em cache o conteúdo, mas você deve primeiro confirmar com o servidor. Se o recurso não mudou, você pode usar diretamente o cache do navegador. Mutuamente exclusivo com no-store;
no-store: indica que o conteúdo não pode ser armazenado em cache, incluindo navegadores e dispositivos intermediários, como servidores proxy etc., mutuamente exclusivo com no-cache;
público: indica que o cache pode existem em navegadores e dispositivos intermediários, e privado é mutuamente exclusivo;
privado: indica que o cache só pode existir no navegador do cliente;
idade máxima: o intervalo de tempo em segundos, indicando por quanto tempo o conteúdo em cache irá expirar. Após a data de expiração, o navegador deve baixar o recurso novamente.
Depois de definir o cache forte, o navegador usará o conteúdo em cache local ou verificará o navegador com base nas informações de cabeçalho retornadas para cada solicitação.
4.2 Cache de negociação
Quando o servidor não define um cache forte para recursos, o cache de negociação pode ser usado. Existem duas maneiras de habilitar o cache de negociação:
Last-Modified e If-Modified-Since;
Etag e If-None-Match;
Os nomes dos dois conjuntos de informações de cabeçalho são muito semânticos, o que reduz a dificuldade de compreensão.
4.2.1 O
servidor Last-Modified e If-Modified-Since define o cabeçalho de resposta Last-Modified para indicar a hora em que o recurso foi modificado pela última vez. Este valor é um ponto no tempo. Quando o navegador solicitar, ele trará um cabeçalho If-Modified-Since, cujo valor é o valor de Last-Modified. O servidor compara a hora da última modificação do recurso com a hora indicada por If-Modified-Since e retorna 304 se não foi alterado.
4.2.1 Etag e If-None-Match O
servidor configura o cabeçalho de resposta Etag para indicar a string de identificação única do recurso.Contanto que o recurso seja modificado, um Etag será gerado novamente. Quando o navegador solicitar, ele trará um cabeçalho If-None-Match, cujo valor é o valor de Etag. O servidor compara os valores atuais de Etag e If-None-Match do recurso e, se eles corresponderem, ele retorna 304.
Fonte do artigo: https://www.jianshu.com/p/4bb9eee3bd57