Aujourd'hui, j'ai parcouru brièvement les « Sites Web hautes performances ». La version chinoise de ce livre est « Guide pour la construction de sites Web hautes performances ».
Ce livre contient également un chapitre avancé « Des sites Web encore plus rapides » qui explore en profondeur les problèmes individuels, et la traduction chinoise est « Guide avancé pour créer des sites Web hautes performances ».
L'auteur l'a présenté dans le lien Douban ci-dessus, je ne le copierai donc pas ici.
Ce livre donne 14 principes pour améliorer les performances d'un site Web, chaque principe est un chapitre indépendant avec des exemples. La plupart de ces principes sont très pratiques et adaptés aux architectes de site et aux ingénieurs front-end. Cela revêt une plus grande importance pour les ingénieurs front-end.
Cette fois, j'ai regardé la version originale. Je manque d'expérience pratique en développement web et je le lis à la hâte, il peut donc y avoir des omissions et des expressions inappropriées. J'espère que les internautes se sentiront libres de me corriger.
Principe 1 Réduire le nombre de requêtes HTTP
Il faut du temps pour construire une demande et attendre une réponse, donc moins il y a de demandes, mieux c'est. L'idée générale de la réduction des requêtes est de fusionner les ressources et de réduire le nombre de fichiers nécessaires à l'affichage d'une page.
1. Carte d'images
En définissant l'attribut usemap de la balise <img> et en utilisant la balise <map>, vous pouvez diviser une image en plusieurs zones et pointer vers différents liens. Par rapport à l’utilisation de plusieurs images pour créer des liens séparément, le nombre de requêtes est réduit.
2. CSS SPRite (intégration de texture CSS/assemblage de texture/positionnement de texture)
Cela se fait en définissant le style de position d'arrière-plan de l'élément. Généralement utilisé pour les icônes d’interface. Les plus typiques peuvent se référer aux petits boutons au-dessus de l'éditeur TinyMCE. Plusieurs petites images sont essentiellement découpées à partir d'une grande image unifiée avec différents décalages. De cette manière, de nombreux boutons de l'interface de chargement ne doivent en fait être demandés qu'une seule fois (en demandant la grande image une seule fois), réduisant ainsi le nombre de requêtes HTTP.
3. Image en ligne
Ne spécifiez pas l'URL du fichier image externe dans le src de <img>, mais mettez directement les informations sur l'image. Par exemple, src="data:image/gif;base64,R0lGODlhDAAMAL..." est utile dans certains cas particuliers (par exemple, une petite image n'est utilisée que sur la page en cours).
Principe 2 : Utiliser le CDN multiligne
Fournissez à votre site un accès à plusieurs lignes (telles que les télécommunications nationales, China Unicom, China Mobile) et à plusieurs emplacements géographiques (nord, sud, ouest) afin que tous les utilisateurs puissent y accéder rapidement.
Principe 3 : utiliser le cache HTTP
Ajoutez des informations d'en-tête Expires plus longues aux ressources qui ne sont pas mises à jour fréquemment (telles que les images statiques). Une fois ces ressources mises en cache, elles ne seront plus transmises avant longtemps.
Principe 4 : Utiliser la compression Gzip
Utilisez Gzip pour compresser les messages HTTP afin de réduire la taille et le temps de transmission.
Principe 5 : Placer les feuilles de style en début de page
Chargez d'abord la feuille de style afin que le rendu de la page puisse démarrer plus tôt, donnant ainsi aux utilisateurs le sentiment que la page se charge plus rapidement.
Principe 6 : Placer les scripts en fin de page
La raison est la même que 5. L'affichage de la page est traité en premier, le rendu de la page est terminé plus tôt et la logique du script est exécutée plus tard, ce qui donne à l'utilisateur le sentiment que la page se charge plus rapidement.
Principe 7 Évitez d'utiliser des expressions CSS
Une logique de script JavaScript trop complexe, des opérations de recherche et de sélection DOM réduiront l'efficacité du traitement des pages.
Principe 8 Utiliser Javascript et CSS comme ressources externes
Cela semble contraire à l'idée de fusion du principe 1, mais ce n'est pas le cas : étant donné que chaque page introduit une ressource JavaScript publique (telle que jQuery ou une bibliothèque JavaScript telle qu'ExtJS), à en juger par les performances d'une seule page, en ligne (c'est-à-dire l'intégration de JavaScript dans HTML) les pages se chargeront plus rapidement (en raison de leur nombre inférieur de requêtes HTTP) que les pages sortantes (introduites à l'aide de balises <script>). Mais si de nombreuses pages introduisent cette ressource JavaScript publique, alors le schéma en ligne provoquera des transmissions répétées (car cette ressource est intégrée dans chaque page, cette partie de la ressource doit être transmise à chaque fois qu'une page est ouverte, provoquant ainsi un gaspillage de transmission réseau). ressources). Ce problème peut être résolu en rendant cette ressource indépendante et en la référençant en externe.
Puisque JavaScript et CSS sont relativement stables, nous pouvons définir des dates d'expiration plus longues pour leurs ressources correspondantes (voir principe 3).
Principe 9 Réduire les recherches DNS
Le conseil de l'auteur est le suivant :
1. Utilisez Keep-Alive pour rester connecté
Si la connexion est déconnectée, une recherche DNS devra être effectuée la prochaine fois que la connexion sera établie. Même si le mappage nom de domaine-IP correspondant a été mis en cache, la recherche prendra un certain temps.
2. Réduisez les noms de domaine
Chaque fois que vous demandez un nouveau nom de domaine, vous devez rechercher un nom de domaine différent via DNS et le cache DNS ne peut pas fonctionner. Par conséquent, vous devez faire de votre mieux pour organiser le site sous un nom de domaine unifié et éviter d’utiliser trop de noms de sous-domaines.
Principe 10 Réduisez votre JavaScript
Utilisez l’outil de compression JS pour compresser votre JavaScript, c’est très efficace. Il suffit de regarder les deux distributions différentes de jQuery pour voir la différence :
http://code.jquery.com/jquery-1.6.2.js version de lecture du code jQuery, 230 Ko
http://code.jquery.com/jquery-1.6.2.min.js version compressée du code jQuery (pour le déploiement réel), 89,4 Ko
Principe 11 Essayez d'éviter les redirections
Une redirection signifie qu'une série supplémentaire de requêtes HTTP est ajoutée avant que vous n'accédiez réellement à la page que vous souhaitez voir (le client lance une requête HTTP → le serveur HTTP renvoie une réponse de redirection → le client lance une demande pour une nouvelle URL → le HTTP le serveur renvoie du contenu, les parties soulignées sont des requêtes supplémentaires), cela prend donc plus de temps (ce qui donne également aux gens le sentiment d'une réponse plus lente). N’utilisez donc pas de redirections sauf si nécessaire. Plusieurs situations « nécessaires » :
1. Évitez les URL invalides
Après la migration de l'ancien site, afin d'éviter que l'ancienne URL ne devienne invalide, les demandes concernant l'ancienne URL sont généralement redirigées vers l'adresse correspondante du nouveau système.
2. Embellissement des URL
Convertissez entre les URL lisibles et les URL de ressources réelles. Par exemple, pour la barre d'outils Google, les utilisateurs se souviennent de http://toolbar.google.com, qui est une adresse sémantique pour les humains, mais il est difficile de se souvenir de http://www .google. .com/tools/Firefox/toolbar/FT3/intl/en/index.html est la véritable adresse de la ressource. Il faut donc conserver les premiers et rediriger les demandes des premiers vers les seconds.
Principe 12 Supprimer les scripts en double
N'incluez pas le même script à plusieurs reprises sur une page. Par exemple, les scripts B et C dépendent tous deux de A, il peut donc y avoir des références répétées à A dans les pages utilisant B et C. La solution consiste à vérifier manuellement les dépendances pour les sites simples et à éliminer les introductions répétées ; pour les sites complexes, vous devez créer votre propre mécanisme de gestion des dépendances/contrôle de version.
Principe 13 Manipulez les ETags avec précaution
ETag est une autre méthode de cache HTTP en plus de Last-Modified. Identifiez si la ressource a été modifiée par hachage. Mais il y a quelques problèmes avec ETag, tels que :
1. Incohérence : différents serveurs Web (Apache, IIS, etc.) définissent différents formats ETag
2. Le calcul de ETag est instable (en raison de la prise en compte de trop de facteurs), tels que :
1) Les mêmes ressources ont des ETags différents calculés sur différents serveurs, et les applications Web à grande échelle sont généralement servies par plusieurs serveurs. Cela fait que les ressources mises en cache du client sur le serveur A sont toujours valides, mais la prochaine fois qu'il demande B, car. l'ETag est différent, il est considéré comme invalide, entraînant une transmission répétée de la même ressource.
2) La ressource reste inchangée, mais l'ETag change en raison de modifications de certains autres facteurs, tels que les modifications du fichier de configuration. La conséquence directe est qu'après la mise à jour du système, des pannes de cache client se produisent à grande échelle, entraînant une forte augmentation du volume de transmission et une diminution des performances du site.
La suggestion de l'auteur est la suivante : soit améliorez la méthode de calcul ETag existante en fonction des caractéristiques de votre application, soit n'utilisez tout simplement pas ETag et utilisez le Last-Modified le plus simple.
Principe 14 : exploiter le cache HTTP avec Ajax
Ajax est une requête asynchrone. Les requêtes asynchrones ne bloqueront pas vos opérations en cours et lorsque la requête est terminée, vous pouvez voir les résultats immédiatement. Mais asynchrone ne signifie pas qu’il peut être réalisé instantanément, ni qu’il peut être toléré et prendre un temps infini. Par conséquent, les performances des requêtes Ajax doivent également être prises en compte. Il existe de nombreuses requêtes Ajax qui accèdent à des ressources relativement stables, alors n'oubliez pas de faire bon usage du mécanisme de cache HTTP pour les requêtes Ajax. Pour plus de détails, voir les principes 3 et 13.
Auteur : Yang Mengdong
Source de l'article : blog de Yang Mengdong Veuillez indiquer le lien source lors de la réimpression.