Recentemente, tenho estudado o livro "Guia para a construção de sites de alto desempenho". Este artigo é uma nota de estudo. Vou resolver o que aprendi para facilitar a visualização mais tarde.
A regra de ouro de desempenho explica que apenas 10% a 20% do tempo de resposta do usuário final é gasto aceitando documentos HTML do usuário solicitado, enquanto os 80% a 90% do tempo são gastos em solicitações HTTP para todos os componentes (imagens, scripts, respostas de time, etc.), com o HTML, e o final do documento.
-Sonders-steve
1 Arquivo Merge (reduza o número de solicitações HTTP)
Sprites css
Use sprites CSS para mesclar as imagens usadas no site em uma imagem e use um ícone através da posição de fundo, largura e altura para controlar a posição da imagem em segundo plano. Este método pode reduzir várias solicitações de imagem para uma vez. Existem muitas ferramentas para gerar sprites CSS. Existem plug-ins relacionados no Grunt e Gulp, e o CSSGAGA também é bom.
Mesclar JS e CSS
Como o mapa Sprite, a fusão de arquivos CSS e JS também é uma maneira importante de reduzir as solicitações HTTP. Atualmente, não há controvérsia sobre a fusão dos arquivos CSS, mas para a prevalência atual de modularidade JS, mesclando todos os arquivos JS em um arquivo parece ser um atraso. A maneira correta é cumprir o padrão de linguagem compilada, manter a modularidade do JS e gerar arquivos de destino apenas para os arquivos JS usados na solicitação inicial durante o processo de geração.
2 Use o conteúdo para publicar a rede (reduza o tempo de solicitação HTTP)
Outro fator que influencia o tempo de solicitação HTTP é a distância que você é do servidor da web do site. Obviamente, quanto maior a distância, maior a solicitação, o que pode melhorar bastante através da CDN.
O CDN é um servidor da Web distribuído em vários locais geográficos, usado para publicar conteúdo nos usuários com mais eficiência. A principal função do CDN é armazenar arquivos estáticos para usuários finais e também fornece download, serviços de segurança e outras funções.
3 Defina o cache do navegador (evite solicitações http duplicadas)
Usando o Expire/Cache-Control
Os navegadores podem evitar solicitações repetidas sempre usando o cache. HTTP 1.0 e HTTP 1.1 têm diferentes métodos de implementação de cache, expira (1.0) e controle de cache (1.1). O servidor da web usa expira para dizer ao cliente que todas as cópias em cache do arquivo serão usadas dentro de um tempo especificado e não é mais repetidamente fazer solicitações ao servidor, por exemplo:
Expira: qui, 01 de dezembro de 2016 16:00:00 GMT (formato GMT)
Essa configuração significa que, em 1º de dezembro de 2016, a cópia em cache está disponível sem fazer mais solicitações.
O Expires tem uma limitação na maneira de passar os prazos: requer sincronização estrita entre os relógios do cliente e do servidor, enquanto o controle de cache introduzido pelo HTTP 1.1 especifica uma data de cache especificando um tempo em segundos, portanto essa limitação não está presente, por exemplo:
Controle de cache: máximo = 31536000
Essa configuração significa que o tempo de cache é de um ano e é recomendável usar o controle de cache, mas quando o HTTP 1.1 é suportado, outra coisa a ser observada: o controle de cache e o expiração existem ao mesmo tempo, o controle de cache tem maior prioridade.
Configurar ou remover ETAG
O uso do controle Expire/Cache pode evitar a segunda visita, usar o cache local para evitar solicitações HTTP duplicadas e melhorar a velocidade do site. No entanto, se o usuário clicar na atualização ou expirar do navegador, uma solicitação HTTP GET ainda será emitida para o servidor. Se o arquivo não alterar no momento, o servidor não retornará o arquivo inteiro, mas retornará um código de status 304 não modificado.
Existem dois basiss para o servidor determinar se o arquivo mudou: última modificação (data de modificação mais recente) e ETAG (tag de entidade);
O ETAG (tags de entidade) foi introduzido no HTTP 1.1 e tem uma prioridade mais alta quando existe ao mesmo tempo que o último modificado. O servidor compara o ETAG (se não-nada) enviado pelo cliente com o ETAG atual e retorna 304 não modificado se o mesmo for verdadeiro, caso contrário, o arquivo inteiro e 200 OK serão retornados.
Há um problema com o ETAG: quando o navegador envia uma solicitação GET para um servidor e solicita o componente de outro servidor, o ETAG não corresponde. Obviamente, se o seu site estiver hospedado em um servidor, e agora muitos sites usam vários servidores, a existência do ETAG reduz bastante a taxa de sucesso da validade da verificação.
A solução para esse problema é configurar o ETAG, remover o valor do servidor InnoDe e reter apenas o carimbo de data e o tamanho da modificação como o valor ETAG ou remova diretamente o ETAG e use o último modificado para verificar a validade do arquivo.
4 Componentes de compactação (reduza o tamanho da solicitação HTTP)
Ao comprimir arquivos transmitidos por HTTP, reduzindo o tamanho das solicitações HTTP e melhorando a velocidade da solicitação, o GZIP é o método de compressão mais comumente usado e mais eficaz no momento.
No entanto, nem todos os arquivos de recursos precisam ser compactados. O custo da compactação inclui que o servidor precisa gastar ciclos de CPU para comprimir, e o cliente também precisa descomprimir os arquivos compactados, que devem ser pesados em combinação com seu próprio site. Agora, a maioria dos sites comprime seus documentos HTML, e alguns sites optam por comprimir JS e CSS. Quase nenhum sites usa compactação GZIP para imagens, PDFs e outros arquivos. O motivo é que esses arquivos foram compactados e o uso de HTTP para comprimir coisas que foram supercompacidas não podem torná -lo menor. De fato, adicionar cabeçalhos, comprimir dicionários e verificar o corpo da resposta realmente o torna maior e também desperdiçando a CPU.
Como ativar o GZIP no site requer a configuração no servidor da Web (IIS, NGINX, Apache, etc.).
5 arquivos CSS são colocados primeiro
Colocar o arquivo CSS no primeiro e o último não afeta as solicitações HTTP, por isso é consistente em termos de tempo de solicitação. No entanto, da perspectiva da experiência do usuário, colocar o arquivo CSS no primeiro oferecerá uma melhor experiência do usuário.
O motivo é que o navegador analisa o documento HTML de cima para baixo e coloca o arquivo CSS na cabeça. A página primeiro fará uma solicitação ao arquivo CSS, depois carregará a árvore Dom e a renderá. A página será gradualmente apresentada ao usuário.
Pelo contrário, se o arquivo CSS for colocado no final, a página carregará o DOM completo e solicitar o arquivo CSS e, em seguida, renderiza toda a árvore Dom e a apresenta ao usuário. Do ponto de vista do usuário, antes que o arquivo CSS seja solicitado, a página inteira está em um estado de tela branca. A tela branca é um comportamento do navegador. A explicação de David Hyatt para isso é assim
Antes que a árvore de estilo esteja totalmente carregada, a renderização da árvore dom é um desperdício, porque será renderizada novamente após ocorre o problema da árvore do estilo e o problema do FOUC (sem filmes de conteúdo de estilo).
Outra coisa a observar é usar o link em vez de @import para introduzir folhas de estilo CSS. Mesmo que o estilo introduzido por @Import esteja escrito no cabeçalho, ele será carregado no final do documento.
6 o arquivo JS é colocado no final
As solicitações HTTP são paralelas e o número de downloads paralelos de diferentes navegadores é diferente (2, 4 ou 8). Downloads paralelos melhoram a velocidade das solicitações HTTP. Colocar o arquivo JS em primeiro lugar não apenas bloqueará o download do arquivo subsequente, mas também bloqueará a renderização da página.
Por que isso está acontecendo? Existem dois motivos:
Document.Write pode existir no arquivo JS para modificar o conteúdo da página, para que a página não seja renderizada após a execução do script.
Diferentes arquivos JS podem ter dependências, independentemente do tamanho, portanto, devem ser executados em ordem, para que sejam proibidos ao carregar scripts.
Portanto, a melhor maneira é colocar o arquivo JS no final e aguardar até que todos os componentes visuais da página sejam carregados antes de fazer solicitações para melhorar a experiência do usuário.
O exposto acima são algumas sugestões para melhorar o desempenho do site do JavaScript que o editor apresentou a você (1). Espero que seja útil para você. Se você quiser saber mais, preste atenção ao wulin.com. No próximo artigo, o editor apresentará a você as sugestões para melhorar a otimização do desempenho do site JavaScript (ii)