Récemment, j'ai étudié le livre "Guide to Construction of High Performance Sites Web". Cet article est une note d'étude. Je trierai ce que j'ai appris pour une visualisation facile plus tard.
Performance Golden Rule explique que seulement 10% à 20% du temps de réponse de l'utilisateur final est consacré à accepter des documents HTML demandés par l'utilisateur, tandis que les 80% restants à 90% du temps sont consacrés aux demandes HTTP pour tous les composants (images, scripts, temps de réaction final, etc.) référencé par le document HTML, et le temps de réponse final est passé sur les composants de page.
- Sounders STEVE
1 Fermer de fichiers (Réduisez le nombre de demandes HTTP)
Sprites CSS
Utilisez CSS Sprites pour fusionner les images utilisées sur le site Web en une seule image et utilisez une icône via la position, la largeur et la hauteur de l'arrière-plan pour contrôler la position de l'image d'arrière-plan. Cette méthode peut réduire plusieurs demandes d'image en une fois. Il existe de nombreux outils pour générer des sprites CSS. Il y a des plug-ins connexes en grognement et en gorgée, et CSSGaga est également bon.
Fusionner JS et CSS
Comme la carte Sprite, la fusion des fichiers CSS et JS est également un moyen important de réduire les demandes HTTP. Il n'y a pas de controverse sur la fusion des fichiers CSS actuellement, mais pour la prévalence actuelle de la modularité JS, la fusion de tous les fichiers JS dans un seul fichier semble être à l'envers. La bonne façon consiste à respecter le modèle de langue compilé, à maintenir la modularité de JS et à générer des fichiers cibles uniquement pour les fichiers JS utilisés dans la demande initiale pendant le processus de génération.
2 Utiliser du contenu pour publier le réseau (réduire le temps de demande HTTP)
Un autre facteur influençant le temps de demande HTTP est la distance que vous êtes du serveur Web de site Web. De toute évidence, plus la distance est longue, plus la demande prend la demande, ce qui peut s'améliorer considérablement par le CDN.
CDN est un serveur Web distribué dans plusieurs emplacements géographiques, utilisés pour publier du contenu aux utilisateurs plus efficacement. La fonction principale de CDN est de stocker des fichiers statiques pour les utilisateurs finaux et fournit également un téléchargement, des services de sécurité et d'autres fonctions.
3 Définissez le cache du navigateur (évitez les demandes HTTP en double)
Utilisation d'expiration / contrôle du cache
Les navigateurs peuvent éviter les demandes répétées à chaque fois en utilisant du cache. HTTP 1.0 et HTTP 1.1 ont différentes méthodes d'implémentation de cache, expirent (1.0) et contrôle du cache (1.1). Le serveur Web utilise Expire pour indiquer au client que toutes les copies en cache du fichier seront utilisées dans un délai spécifié et ne font plus à plusieurs reprises les demandes du serveur, par exemple:
Expire: Thu, 01 décembre 2016 16:00:00 GMT (format GMT)
Ce paramètre signifie qu'au 1er décembre 2016, la copie en cache est disponible sans faire d'autres demandes.
Expires a une limitation de la manière de passer les délais: il nécessite une synchronisation stricte entre le client et les horloges du serveur, tandis que le contrôle de cache introduit par HTTP 1.1 spécifie une date de cache en spécifiant un temps en secondes, donc cette limitation n'est pas présente, par exemple:
Cache-Control: Max-Age = 31536000
Ce paramètre signifie que le temps de cache est d'un an, et il est recommandé d'utiliser le contrôle du cache, mais lorsque HTTP 1.1 est pris en charge, une autre chose à noter: le contrôle du cache et l'expiration existent en même temps, le contrôle du cache a une priorité plus élevée.
Configurer ou supprimer Etag
L'utilisation d'expire / de contrôle du cache peut éviter la deuxième visite, utiliser le cache local pour éviter les demandes HTTP en double et améliorer la vitesse du site Web. Cependant, si l'utilisateur clique sur le navigateur actualiser ou expire, une demande de GET HTTP sera toujours émise au serveur. Si le fichier ne change pas pour le moment, le serveur ne renvoie pas le fichier entier mais renverra un code d'état 304 non modifié.
Il y a deux basiss pour le serveur pour déterminer si le fichier a changé: dernier modifié (dernière date de modification) et ETAG (Entity Tag);
ETAG (étiquettes d'entité) a été introduite dans HTTP 1.1 et a une priorité plus élevée lorsqu'elle existe en même temps que la dernière modification. Le serveur compare l'ETAG (if-none-match) envoyé par le client avec l'ETAG actuel, et renvoie 304 non modifié si il est vrai, sinon le fichier entier et 200 OK seront renvoyés.
Il y a un problème avec ETAG: lorsque le navigateur envoie une demande GET à un serveur, puis demande le composant d'un autre serveur, ETAG ne correspond pas. Bien sûr, si votre site Web est hébergé sur un seul serveur, et maintenant de nombreux sites Web utilisent plusieurs serveurs, l'existence d'ETAG réduit considérablement le taux de réussite de la validité de vérification.
La solution à ce problème consiste à configurer ETAG, à supprimer la valeur du serveur innove et à conserver uniquement l'horodatage de modification et la taille comme valeur ETAG, ou supprimer directement ETAG, et utiliser la dernière modification pour vérifier la validité du fichier.
4 composants de compression (réduire la taille de la demande HTTP)
En compressant les fichiers transmis par HTTP, en réduisant la taille des demandes HTTP et en améliorant la vitesse de demande, GZIP est actuellement la méthode de compression la plus couramment utilisée et la plus efficace.
Cependant, tous les fichiers de ressources ne doivent pas être compressés. Le coût de la compression comprend que le serveur doit dépenser les cycles CPU pour compresser, et le client doit également décompresser les fichiers compressés, qui doivent être pesés en combinaison avec son propre site Web. Maintenant, la plupart des sites Web compressent leurs documents HTML, et certains sites Web choisissent de compresser JS et CSS. Presque aucun site Web n'utilise la compression GZIP pour les images, les PDF et autres fichiers. La raison en est que ces fichiers ont été compressés, et l'utilisation de HTTP pour compresser des choses qui ont été surcompressées ne peuvent pas la rendre plus petite. En fait, l'ajout d'en-têtes, comprimer des dictionnaires et vérifier le corps de réponse le rend en fait plus grand et gaspille également le processeur.
Comment activer GZIP sur le site Web nécessite des réglages dans le serveur Web (IIS, Nginx, Apache, etc.).
5 fichiers CSS sont placés en premier
Mettre le fichier CSS dans le premier et le dernier n'affecte pas les demandes HTTP, donc elle est cohérente en termes de temps de demande. Cependant, du point de vue de l'expérience utilisateur, la mise en place du fichier CSS dans le premier vous donnera une meilleure expérience utilisateur.
La raison en est que le navigateur analyse le document HTML de haut en bas et place le fichier CSS à la tête. La page fera d'abord une demande au fichier CSS, puis chargera l'arborescence DOM et le rendra. La page sera progressivement présentée à l'utilisateur.
Au contraire, si le fichier CSS est placé à la fin, la page charge le DOM complet et demande le fichier CSS, puis rend l'ensemble de l'arborescence Dom et la présente à l'utilisateur. Du point de vue de l'utilisateur, avant que le fichier CSS ne soit demandé, la page entière est dans un état d'écran blanc. L'écran blanc est un comportement du navigateur. L'explication de David Hyatt est comme ça
Avant que l'arbre de style ne soit complètement chargé, le rendu de l'arbre Dom est un déchet, car il sera rendu à nouveau après le chargement de l'arborescence de style, et le problème FOUC (sans cliquetis de contenu) se produit.
Une autre chose à noter est d'utiliser le lien au lieu de @Import pour introduire des feuilles de style CSS. Même si le style introduit par @Import est écrit dans l'en-tête, il sera chargé à la fin du document.
Le fichier 6 js est placé à la fin
Les demandes HTTP sont parallèles et le nombre de téléchargements parallèles de différents navigateurs est différent (2, 4 ou 8). Les téléchargements parallèles améliorent la vitesse des demandes HTTP. Le fait de mettre le fichier JS en premier lieu bloquera non seulement le téléchargement du fichier suivant, mais bloquera également le rendu de la page.
Pourquoi cela se produit-il? Il y a deux raisons:
Document.Write peut exister dans le fichier JS pour modifier le contenu de la page, de sorte que la page ne sera pas rendue après l'exécution du script.
Différents fichiers JS peuvent avoir des dépendances quelle que soit la taille, ils doivent donc être exécutés dans l'ordre, ils sont donc interdits lors du chargement des scripts.
Par conséquent, la meilleure façon est de placer le fichier JS à la fin et d'attendre que tous les composants visuels de la page soient chargés avant de faire des demandes pour améliorer l'expérience utilisateur.
Ce qui précède sont quelques suggestions sur l'amélioration des performances du site Web par JavaScript que l'éditeur vous a présenté (1). J'espère que cela vous sera utile. Si vous voulez en savoir plus, veuillez faire attention à wulin.com. Dans le prochain article, l'éditeur vous présentera les suggestions d'amélioration de l'optimisation des performances du site Web de JavaScript (II)