Hoje naveguei brevemente em "Sites de alto desempenho". A versão chinesa deste livro é "Guia para construção de sites de alto desempenho".
Este livro também possui um capítulo avançado "Sites ainda mais rápidos", que explora profundamente questões individuais, e a tradução chinesa é "Guia avançado para construir sites de alto desempenho".
O autor o introduziu no link Douban acima, então não vou copiá-lo aqui.
Este livro fornece 14 princípios para melhorar o desempenho do site, cada princípio é um capítulo independente com exemplos. A maioria desses princípios é muito prática e adequada para arquitetos de sites e engenheiros front-end. É de maior importância para engenheiros front-end.
Dessa vez assisti a versão original. Não tenho experiência prática em desenvolvimento web e li com pressa, por isso pode haver omissões e expressões inadequadas. Espero que os internautas se sintam à vontade para me corrigir.
Princípio 1 Reduza o número de solicitações HTTP
Leva tempo para construir uma solicitação e aguardar uma resposta, portanto, quanto menos solicitações, melhor. A ideia geral de redução de solicitações é mesclar recursos e reduzir o número de arquivos necessários para exibir uma página.
1. Mapa de imagem
Ao definir o atributo usemap da tag <img> e usar a tag <map>, você pode dividir uma imagem em várias áreas e apontar para links diferentes. Comparado ao uso de múltiplas imagens para construir links separadamente, o número de solicitações é reduzido.
2. CSS SPRite (integração de textura CSS/costura de textura/posicionamento de textura)
Isso é feito definindo o estilo da posição de fundo do elemento. Geralmente usado para ícones de interface. Os típicos podem referir-se aos pequenos botões acima do editor TinyMCE. Várias imagens pequenas são essencialmente cortadas de uma imagem grande unificada com diferentes deslocamentos. Dessa forma, muitos botões na interface de carregamento só precisam ser solicitados uma vez (solicitando a imagem grande uma vez), reduzindo assim o número de solicitações HTTP.
3. Imagem embutida
Não especifique a URL do arquivo de imagem externo no src de <img>, mas coloque diretamente as informações da imagem. Por exemplo, src="data:image/gif;base64,R0lGODlhDAAMAL..." é útil em alguns casos especiais (por exemplo, uma imagem pequena é usada apenas na página atual).
Princípio 2: Utilize CDN multilinha
Forneça ao seu site acesso a múltiplas linhas (como telecomunicações domésticas, China Unicom, China Mobile) e múltiplas localizações geográficas (norte, sul, oeste) para que todos os usuários possam acessá-lo rapidamente.
Princípio 3: Use cache HTTP
Adicione informações de cabeçalho Expires mais longas a recursos que não são atualizados com frequência (como imagens estáticas). Depois que esses recursos forem armazenados em cache, eles não serão transmitidos novamente por um longo período no futuro.
Princípio 4: Use compactação Gzip
Use Gzip para compactar mensagens HTTP para reduzir o tamanho e o tempo de transmissão.
Princípio 5: Coloque folhas de estilo na frente da página
Carregue a folha de estilo primeiro para que a renderização da página possa começar mais cedo, dando aos usuários a sensação de que a página carrega mais rápido.
Princípio 6: Coloque scripts no final da página
O motivo é o mesmo que 5. A exibição da página é processada primeiro, a renderização da página é concluída mais cedo e a lógica do script é executada mais tarde, o que dá ao usuário a sensação de que a página carrega mais rápido.
Princípio 7 Evite usar expressões CSS
Lógica de script JavaScript excessivamente complexa, pesquisa DOM e operações de seleção reduzirão a eficiência do processamento de páginas.
Princípio 8 Use Javascript e CSS como recursos externos
Isto parece ser contrário à ideia de fusão do princípio 1, mas não é: considerando que cada página introduz um recurso JavaScript público (como jQuery ou uma biblioteca JavaScript como ExtJS), a julgar pelo desempenho de uma página sozinha, inline (ou seja, incorporando JavaScript em HTML) as páginas carregarão mais rápido (devido ao menor número de solicitações HTTP) do que as páginas de saída (introduzidas usando tags <script>). Mas se muitas páginas introduzirem este recurso JavaScript público, então o esquema inline causará transmissão repetida (porque este recurso está incorporado em cada página, esta parte do recurso deve ser transmitida sempre que uma página for aberta, causando assim um desperdício de transmissão de rede recursos). Este problema pode ser resolvido tornando este recurso independente e referenciando-o externamente.
Como JavaScript e CSS são relativamente estáveis, podemos definir datas de expiração mais longas para os recursos correspondentes (consulte o Princípio 3).
Princípio 9: Reduzir pesquisas de DNS
O conselho do autor é:
1. Use Keep-Alive para ficar conectado
Se a conexão for desconectada, uma pesquisa de DNS deverá ser realizada na próxima vez que a conexão for estabelecida. Mesmo que o mapeamento de nome de domínio-IP correspondente tenha sido armazenado em cache, a pesquisa levará algum tempo.
2. Reduza nomes de domínio
Cada vez que você solicita um novo nome de domínio, você precisa procurar um nome de domínio diferente por meio do DNS, e o cache DNS não funciona. Portanto, você deve tentar o seu melhor para organizar o site sob um nome de domínio unificado e evitar usar muitos nomes de subdomínios.
Princípio 10 Minimize seu JavaScript
Use a ferramenta de compactação JS para compactar seu JavaScript, é muito eficaz. Basta olhar para as duas distribuições diferentes do jQuery para ver a diferença:
http://code.jquery.com/jquery-1.6.2.js lendo o código jQuery da versão, 230 KB
http://code.jquery.com/jquery-1.6.2.min.js versão compactada do código jQuery (para implantação real), 89,4 KB
Princípio 11 Tente evitar redirecionamentos
Um redirecionamento significa que uma rodada adicional de solicitações HTTP é adicionada antes de você realmente acessar a página que deseja ver (o cliente inicia uma solicitação HTTP → o servidor HTTP retorna uma resposta de redirecionamento → o cliente inicia uma solicitação para um novo URL → o HTTP servidor retorna conteúdo, as partes sublinhadas são solicitações adicionais), por isso consome mais tempo (o que também dá às pessoas a sensação de resposta mais lenta). Portanto, não use redirecionamentos, a menos que seja necessário. Várias situações "necessárias":
1. Evite URLs inválidos
Após a migração do site antigo, para evitar que o URL antigo se torne inválido, as solicitações do URL antigo geralmente são redirecionadas para o endereço correspondente do novo sistema.
2. Embelezamento de URL
Converta entre URLs legíveis e URLs de recursos reais. Por exemplo, para a Barra de Ferramentas Google, os usuários se lembram de http://toolbar.google.com, que é um endereço semântico para humanos, mas é difícil lembrar de http://www .google. .com/tools/Firefox/toolbar/FT3/intl/en/index.html é o endereço real do recurso. É, portanto, necessário manter os primeiros e redirecionar os pedidos dos primeiros para os segundos.
Princípio 12 Remover scripts duplicados
Não inclua o mesmo script repetidamente em uma página. Por exemplo, os scripts B e C dependem de A, portanto pode haver referências repetidas a A em páginas que usam B e C. A solução é verificar manualmente as dependências de sites simples e eliminar introduções repetidas para sites complexos; você precisa construir seu próprio mecanismo de gerenciamento de dependências/controle de versão.
Princípio 13: Manuseie ETags com cuidado
ETag é outro método de cache HTTP além da última modificação. Identifique se o recurso foi modificado por meio de hash. Mas existem alguns problemas com a ETag, como:
1. Inconsistência: Diferentes servidores web (Apache, IIS, etc.) definem diferentes formatos de ETag
2. O cálculo da ETag é instável (devido à consideração de muitos fatores), tais como:
1) Os mesmos recursos têm ETags diferentes calculadas em servidores diferentes, e aplicativos da Web em grande escala geralmente são atendidos por mais de um servidor. Isso faz com que os recursos armazenados em cache do cliente no servidor A ainda sejam válidos, mas na próxima vez que ele solicitar B. a ETag for diferente, ela será considerada inválida, resultando na transmissão repetida do mesmo recurso.
2) O recurso permanece inalterado, mas a ETag muda devido a alterações em alguns outros fatores, como alterações no arquivo de configuração. A consequência direta é que após a atualização do sistema, ocorrem falhas em grande escala no cache do cliente, resultando em um grande aumento no volume de transmissão e na diminuição do desempenho do site.
A sugestão do autor é: ou melhore o método de cálculo da ETag existente de acordo com as características da sua aplicação, ou simplesmente não utilize a ETag e utilize o Last-Modified mais simples.
Princípio 14: Aproveite o cache HTTP com Ajax
Ajax é uma solicitação assíncrona. As solicitações assíncronas não bloquearão suas operações atuais e, quando a solicitação for concluída, você poderá ver os resultados imediatamente. Mas assíncrono não significa que possa ser concluído instantaneamente, nem que possa ser tolerado e levar um tempo infinito para ser concluído. Portanto, o desempenho das solicitações Ajax também precisa de atenção. Existem muitas solicitações Ajax que acessam recursos relativamente estáveis, portanto, não se esqueça de fazer bom uso do mecanismo HTTP Cache para solicitações Ajax. Para obter detalhes, consulte os Princípios 3 e 13.
Autor: Yang Mengdong
Fonte do artigo: blog de Yang Mengdong. Por favor, indique o link da fonte ao reimprimir.