Auteur : Fenng | Vous pouvez réimprimer lors de la réimpression, assurez-vous d'indiquer la source originale et les informations sur l'auteur de l'article ainsi que la déclaration de droit d'auteur sous la forme d'un lien hypertexte : http://www.dbanotes.net/web/flickr_web_tech. .html
Cal Henderson est l'un des développeurs du célèbre site Flickr. Dans un article intitulé Serving JavaScript Fast, il a présenté des techniques d'optimisation des applications du site Flickr. J'ai senti que ma lecture en avait beaucoup profité. "Mâchez les petits pains des autres", résume le contenu principal de l'article.
Flickr est un site représentatif du Web 2.0. En plus de l'optimisation du contenu commune aux sites Web généraux, les problèmes de réseau rencontrés doivent également gérer avec flexibilité la complexité du déploiement et de la distribution causée par les changements fréquents de JavaScript et CSS.
La première question posée lors de la définition de la stratégie de taille de fichier est de savoir s'il faut mettre tous les JavaScript et CSS dans un seul fichier, ou les diviser en plusieurs fichiers. Du point de vue de la réduction des requêtes réseau, le premier est meilleur et le second est pire ? Cependant, d'un point de vue parallèle, IE et Firefox ne peuvent par défaut demander que deux ressources à un même domaine en même temps. Cela apportera une mauvaise expérience aux utilisateurs dans de nombreux cas - tous les fichiers doivent être téléchargés sur une page Flickr décente. utilise un compromis : diviser JavaScript et CSS en plusieurs sous-fichiers tout en gardant le nombre de fichiers aussi petit que possible. Cela entraîne une complexité dans le développement, mais les avantages en termes de performances sont énormes.
Problème d'optimisation de la compression Il ne fait aucun doute que la compression du contenu d'un site est une méthode d'optimisation Web relativement courante. Cependant, il n’est pas toujours possible d’obtenir l’effet souhaité. La raison en est que le module mod-gzip consomme non seulement des ressources CPU côté serveur, mais également des ressources CPU côté client. De plus, les fichiers temporaires créés après la compression par mod_gzip des fichiers sont placés sur le disque, ce qui entraînera également de graves problèmes. pour le disque IO Flickr Le module mod_deflate pris en charge par Httpd 2.x et versions ultérieures est utilisé. Les opérations de compression sont toutes effectuées en mémoire. mod_deflate n'est pas disponible dans Httpd 1.x, mais vous pouvez indirectement améliorer les performances en créant un disque RAM.
Bien entendu, mod_gzip n'est pas inutile. Il reste bénéfique pour les fichiers pré-compressés. De plus, lors de l'utilisation de la compression, il faut également faire attention à la stratégie. Il n'est pas nécessaire de compresser les fichiers image (il existe de nombreuses images sur Flickr, et). la compression ne peut pas apporter beaucoup d'avantages). Flickr compresse uniquement JavaScript et CSS. Les versions plus récentes de mod_gzip peuvent gérer automatiquement les fichiers précompressés en configurant l'option mod_gzip_update_static. Cal a également souligné que cette fonctionnalité entraînerait des problèmes sur certaines anciennes versions des navigateurs
. compression L'un des principaux moyens est la compression du contenu. Pour JavaScript, vous pouvez le faire en réduisant les commentaires, en fusionnant les espaces, en utilisant une syntaxe compacte et d'autres astuces (tous les scripts Google sont très difficiles à lire et très compacts, avec des idées similaires bien sûr). En traitant de cette manière, JavaScript peut comporter de nombreuses parenthèses difficiles à analyser. Flickr utilise Dojo Compressor pour créer une arborescence d'analyse. Dojo Compressor a une très faible surcharge et est transparent pour les utilisateurs finaux. La méthode de traitement JavaScript a été introduite et le traitement CSS est relativement simple grâce à un simple remplacement d'expression régulière (comme le remplacement de plusieurs espaces par un seul caractère d'espace). à 50% de taux de compression.
Optimisation de la mise en cache Les développeurs de Flickr ont pleinement utilisé les mécanismes Etag et Last-Modified définis par la spécification HTTP 1.1 pour améliorer l'efficacité de la mise en cache. Il convient de noter que Cal a introduit une astuce e-Tag dans des conditions d'équilibrage de charge. vous pouvez configurer Apache pour obtenir l'E-Tag via le temps d'ajustement du fichier et la taille du fichier. Par défaut, Apache obtient l'e-Tag via le nœud de fichier. Bien sûr, ce n’est pas parfait, car cela affectera la modification depuis.
Utilisation flexible de mod_rewrite On dit que l'application du site Flickr est construite quotidiennement (Daily Build). Cela serait impensable sans un mécanisme flexible. De plus, sur des sites comme Flickr, synchroniser les modifications de contenu est un casse-tête. Leur arme est l'utilisation flexible de mod_rewrite. En configurant des règles de réécriture d'URL, il est facile de basculer vers différents environnements. Cela semble très simple, mais est-il facile de le faire sans certaines compétences en technologie Web ?!
Grâce à l'application de ces méthodes principales, nous avons vu un Flickr onirique et performant.
BTW : étant donné que Flickr n'a pas de serveur en Chine, la vitesse d'accès pour les utilisateurs du continent ne peut pas être mentionnée :(
--Fin.
Cet article [Conseils d'optimisation des applications Web pour les développeurs Flickr] provient de dbanotes.net