Dicas de otimização de aplicativos da web

Autor: Fenng | Você pode reimprimir. Ao reimprimir, certifique-se de indicar a fonte original e as informações do autor do artigo e a declaração de direitos autorais na forma de um hiperlink: http://www.dbanotes.net/web/flickr_web_tech. .html
Cal Henderson é um dos desenvolvedores do famoso site Flickr. Em um artigo chamado Serving JavaScript Fast, ele apresentou técnicas para otimizar aplicativos de sites do Flickr. Senti que me beneficiei muito ao lê-lo. “Mastigar o pão dos outros”, resume o conteúdo principal do artigo.

O Flickr é um site representativo da Web 2.0. Além da otimização de conteúdo comum aos sites em geral, os problemas de rede enfrentados também devem lidar com flexibilidade com a complexidade de implantação e distribuição causada por mudanças frequentes em JavaScript e CSS.

A primeira questão enfrentada ao definir a estratégia de tamanho de arquivo é: colocar todo o JavaScript e CSS em um arquivo ou dividi-lo em vários arquivos. Do ponto de vista da redução das solicitações de rede, o primeiro é melhor e o segundo é pior. No entanto, de uma perspectiva paralela, tanto o IE quanto o Firefox podem solicitar apenas dois recursos de um domínio ao mesmo tempo por padrão. Isso trará uma experiência ruim para os usuários em muitos casos - todos os arquivos devem ser baixados. usa um compromisso - dividir JavaScript e CSS em vários subarquivos, mantendo o número de arquivos o menor possível. Isso traz complexidade no desenvolvimento, mas os benefícios de desempenho são enormes.

Problema de otimização de compactação Não há dúvida de que compactar o conteúdo do site é um método de otimização da Web relativamente comum. Porém, nem sempre é possível obter o efeito desejado. A razão é que o módulo mod-gzip não apenas consome recursos da CPU do lado do servidor, mas também consome recursos da CPU do lado do cliente. Além disso, os arquivos temporários criados após o mod_gzip compactar os arquivos são colocados no disco, o que também causará sérios problemas. para disco IO Flickr O módulo mod_deflate suportado pelo Httpd 2.x e posterior é usado. As operações de compactação são todas executadas na memória. mod_deflate não está disponível no Httpd 1.x, mas você pode melhorar indiretamente o desempenho criando um disco RAM.

Claro, mod_gzip não é inútil. Ainda é benéfico para arquivos pré-compactados. Além disso, ao usar a compactação, você também deve prestar atenção à estratégia. Não há necessidade de compactar arquivos de imagem (há muitas imagens no Flickr).

Flickr

compacta apenas JavaScript e CSS. As versões mais recentes do mod_gzip podem lidar automaticamente com arquivos pré-compactados configurando a opção mod_gzip_update_static.

compactação Um meio principal é a compactação de conteúdo. Para JavaScript, você pode fazer isso reduzindo comentários, mesclando espaços, usando sintaxe compacta e outros truques (todos os scripts do Google são muito difíceis de ler e muito compactos, com ideias semelhantes, claro, depois). processar desta forma o JavaScript pode ter muitos parênteses que são difíceis de analisar. O Flickr usa o Dojo Compressor para construir uma árvore de análise. O Dojo Compressor tem sobrecarga muito baixa e é transparente para os usuários finais. O método de processamento JavaScript foi introduzido e o processamento CSS é relativamente simples. Por meio da substituição simples de expressões regulares (como a substituição de vários espaços por um caractere de espaço), você pode se levantar. taxa de compressão de 50%.

Otimização do cache Os desenvolvedores do Flickr fizeram uso total dos mecanismos Etag e Last-Modified definidos pela especificação HTTP 1.1 para melhorar a eficiência do cache. É importante notar que Cal introduziu um truque e-Tag sob condições de balanceamento de carga. você pode configurar o Apache para obter o E-Tag por meio do tempo de ajuste do arquivo e do tamanho do arquivo. Por padrão, o Apache obtém o e-Tag por meio do nó do arquivo. Claro, isso não é perfeito, porque afetará o if-modified-since.

Uso flexível de mod_rewrite Diz-se que o aplicativo do site Flickr é construído diariamente (Daily Build). Isto seria impensável sem um mecanismo flexível. Além disso, em sites como o Flickr, sincronizar modificações de conteúdo é uma dor de cabeça. Sua arma é o uso flexível do mod_rewrite. Ao configurar regras de reescrita de URL, é fácil mudar para diferentes ambientes. Parece muito simples, mas quão fácil é fazer isso sem certas habilidades em tecnologia web?!

Através da aplicação desses métodos principais, vimos um Flickr onírico e de alto desempenho?

A propósito: como o Flickr não possui um servidor na China, a velocidade de acesso para usuários do continente não pode ser mencionada :(

--Fim.

Este artigo [Dicas de otimização de aplicativos da Web para desenvolvedores do Flickr] vem de dbanotes.net