Résumé : Que ce soit au travail ou lors d'un entretien, l'optimisation des performances du front-end Web est très importante. Alors, de quels aspects avons-nous besoin pour commencer par l'optimisation ? Vous pouvez suivre les 34 Catch-Rules de Yahoo pour l'optimisation front-end, mais maintenant c'est 35, on peut donc dire qu'il s'agit du Catch-35 de Yahoo pour l'optimisation front-end. Il a été classé, ce qui est une bonne chose. De cette façon, nous avons une direction plus claire pour l'optimisation.
partie contenu 1. Minimisez le nombre de requêtes HTTP80 % du temps de réponse de l'utilisateur final est consacré au front-end, et la majeure partie de ce temps est consacrée au téléchargement des différents composants de la page : images, feuilles de style, scripts, Flash, etc. Réduire le nombre de composants réduira inévitablement le nombre de requêtes HTTP soumises par la page. C’est la clé pour rendre votre page plus rapide.
Une façon de réduire le nombre de composants de page consiste à simplifier la conception de la page. Mais existe-t-il un moyen de créer des pages complexes tout en accélérant les temps de réponse ? Eh bien, il existe effectivement un moyen d’avoir le gâteau et de le manger aussi.
La fusion de fichiers réduit le nombre de requêtes en regroupant tous les scripts dans un seul fichier. Bien entendu, vous pouvez également fusionner tous les CSS. La fusion de fichiers peut être une tâche fastidieuse si les scripts et les styles de chaque page sont différents, mais le faire dans le cadre du processus de publication du site peut en effet améliorer les temps de réponse. Les sprites CSS sont le moyen privilégié pour réduire le nombre de demandes d'images. Intégrez toutes les images d'arrière-plan dans une seule image, puis utilisez les propriétés CSS background-image et background-position pour positionner la partie à afficher. Le mappage d'images peut combiner plusieurs images en une seule image, la taille totale est la même, mais réduit le nombre de requêtes et accélère le chargement des pages. Le mappage d'image n'est utile que si l'image est continue sur la page, comme une barre de navigation. Le processus de définition des coordonnées d'une carte-image est ennuyeux et sujet aux erreurs, et l'utilisation de cartes-images pour la navigation n'est pas facile, cette méthode n'est donc pas recommandée. Les images en ligne (codées en Base64) utilisent le modèle data: URL pour intégrer des images dans la page. Cela augmentera la taille du fichier HTML. Mettre les images en ligne dans une feuille de style (en cache) est une bonne idée et évite d'alourdir la page. Cependant, les navigateurs grand public actuels ne prennent pas bien en charge les images en ligne.Réduire le nombre de requêtes HTTP pour une page est un point de départ. Il s'agit d'un principe directeur important pour améliorer la vitesse de la première visite du site.
2. Réduisez les recherches DNSLe système de noms de domaine établit un mappage entre les noms d'hôte et les adresses IP, un peu comme le mappage entre les noms et les numéros dans un annuaire téléphonique. Lorsque vous entrez www.yahoo.com dans le navigateur, celui-ci contactera le résolveur DNS pour renvoyer l'adresse IP du serveur. Le DNS a un coût, il faut 20 à 120 millisecondes pour rechercher l'adresse IP d'un nom d'hôte donné. Le navigateur ne peut rien télécharger à partir du nom d'hôte tant que la recherche DNS n'est pas terminée.
Les recherches DNS sont mises en cache plus efficacement, sur un serveur de mise en cache spécial par le FAI (fournisseur d'accès Internet) ou le réseau local de l'utilisateur, mais peuvent également être mises en cache sur l'ordinateur de l'utilisateur individuel. Les informations DNS sont stockées dans le cache DNS du système d'exploitation (le service client DNS sous Microsoft Windows). La plupart des navigateurs disposent de leur propre cache, indépendant du système d'exploitation. Tant que le navigateur conserve cet enregistrement dans son cache, il n’interrogera pas le système d’exploitation pour le DNS.
IE met en cache les recherches DNS pendant 30 minutes par défaut, comme indiqué dans le paramètre de registre DnsCacheTimeout. Firefox met en cache pendant 1 minute, qui peut être définie à l'aide de l'élément de configuration network.dnsCacheExpiration. (Fasterfox a modifié le temps de cache à 1 heure. PS Fasterfox est un plug-in d'accélération pour FF)
Si le cache DNS du client est vide (y compris le navigateur et le système d'exploitation), le nombre de recherches DNS est égal au nombre de noms d'hôte différents sur la page, y compris les URL de page, les images, les fichiers de script, les feuilles de style, les objets Flash et autres composants Nom d'hôte, la réduction des différents noms d'hôte peut réduire les recherches DNS.
La réduction du nombre de noms d'hôtes différents réduit également le nombre de composants qu'une page peut télécharger en parallèle. Éviter les recherches DNS réduit le temps de réponse, tandis que la réduction du nombre de téléchargements parallèles augmente le temps de réponse. Ma règle est de répartir les composants sur 2 à 4 noms d'hôte, ce qui est un compromis entre la réduction des recherches DNS et l'autorisation de téléchargements simultanés élevés.
3. Évitez les redirectionsLes redirections utilisent les codes d'état 301 et 302. Voici un en-tête HTTP avec un code d'état 301 :
HTTP/1.1 301 Déplacé de façon permanenteEmplacement : http://example.com/newuriContent-Type : text/html
Le navigateur accédera automatiquement à l'URL spécifiée dans le champ Emplacement. Toutes les informations nécessaires à la redirection se trouvent dans l'en-tête HTTP et le corps de la réponse est généralement vide. En fait, des en-têtes HTTP supplémentaires tels que Expires et Cache-Control représentent également des redirections. Il existe d'autres moyens de rediriger : actualisez les balises méta et JavaScript, mais si vous devez effectuer une redirection, il est préférable d'utiliser le code d'état HTTP standard 3xx, principalement pour que le bouton de retour puisse fonctionner correctement.
Gardez à l'esprit que les redirections peuvent ralentir l'expérience utilisateur. L'insertion d'une redirection entre l'utilisateur et le document HTML retardera tout sur la page et les composants ne commenceront pas à se télécharger tant que le document HTML ne sera pas servi sur la page. navigateur.
Il existe une redirection courante qui gaspille énormément de ressources, et les développeurs Web n'en sont généralement pas conscients, c'est-à-dire lorsqu'il manque une barre oblique à la fin de l'URL. Par exemple, accéder à http://astrology.yahoo.com/astrology renverra une réponse 301 qui redirigera vers http://astrology.yahoo.com/astrology/ (notez la barre oblique finale). Dans Apache, vous pouvez utiliser les instructions Alias, mod_rewrite ou DirectorySlash pour annuler les redirections inutiles.
L'utilisation la plus courante de la redirection est de connecter l'ancien site au nouveau site. Elle peut également connecter différentes parties d'un même site et effectuer certains traitements en fonction des différentes situations de l'utilisateur (type de navigateur, type de compte utilisateur, etc.). . La connexion de deux sites Web à l’aide de redirections est la plus simple et ne nécessite qu’une petite quantité de code supplémentaire. Bien que l’utilisation de redirections à ces moments-là réduise la complexité du développement pour les développeurs, elle réduit l’expérience utilisateur. Une alternative consiste à utiliser Alias et mod_rewrite, à condition que les deux chemins de code se trouvent sur le même serveur. Si la redirection est utilisée car le nom de domaine change, vous pouvez créer un CNAME (créer un enregistrement DNS pointant vers un autre nom de domaine comme alias) combiné avec la directive Alias ou mod_rewrite.
4. Rendre Ajax pouvant être mis en cacheL'un des avantages d'Ajax est qu'il peut fournir un retour immédiat à l'utilisateur, car il peut demander des informations de manière asynchrone au serveur principal. Cependant, avec Ajax, rien ne garantit que les utilisateurs ne s'ennuieront pas en attendant le retour des réponses JavaScript et XML asynchrones. Dans de nombreuses applications, la capacité de l'utilisateur à attendre dépend de la manière dont Ajax est utilisé. Par exemple, dans un client de messagerie Web, les utilisateurs resteront concentrés sur les résultats renvoyés par les requêtes Ajax afin de trouver les messages électroniques correspondant à leurs critères de recherche. Il est important de se rappeler qu’asynchrone ne signifie pas instantané.
Pour améliorer les performances, l'optimisation de ces réponses Ajax est cruciale. Le moyen le plus important d'améliorer les performances d'Ajax est de rendre la réponse pouvant être mise en cache, comme indiqué dans Ajout d'en-têtes HTTP Expires ou Cache-Control. Les règles supplémentaires suivantes s'appliquent à Ajax :
Examinons un exemple de client de messagerie Web 2.0 utilisant Ajax pour télécharger le carnet d'adresses de l'utilisateur pour la fonctionnalité de saisie semi-automatique. Si l'utilisateur n'a pas modifié son carnet d'adresses depuis la dernière utilisation et que la réponse Ajax peut être mise en cache et possède un en-tête HTTP Expires ou Cache-Control qui n'a pas expiré, alors le carnet d'adresses précédent peut être lu à partir du cache. Le navigateur doit être informé s'il doit continuer à utiliser la réponse du carnet d'adresses précédemment mise en cache ou en demander une nouvelle. Ceci peut être réalisé en ajoutant un horodatage à l'URL Ajax du carnet d'adresses indiquant l'heure de la dernière modification du carnet d'adresses de l'utilisateur, par exemple &t=1190241612. Si le carnet d'adresses n'a pas été modifié depuis le dernier téléchargement et que l'horodatage reste inchangé, le carnet d'adresses sera lu directement depuis le cache du navigateur, évitant ainsi un aller-retour HTTP supplémentaire. Si l'utilisateur a modifié le carnet d'adresses, l'horodatage garantit également que la nouvelle URL ne correspondra pas à la réponse mise en cache et le navigateur demandera la nouvelle entrée du carnet d'adresses.
Même si les réponses Ajax sont créées dynamiquement et ne peuvent être disponibles que pour un seul utilisateur, elles peuvent être mises en cache, ce qui rendra votre application Web 2.0 plus rapide.
5. Chargement paresseux des composantsExaminez la page de plus près et demandez-vous : qu'est-ce qui est nécessaire pour afficher la page en premier lieu ? Le reste peut attendre.
JavaScript est un choix idéal pour séparer avant et après l'événement onload. Par exemple, si vous disposez de code JavaScript et de bibliothèques prenant en charge le glisser-déposer et les animations, ceux-ci peuvent attendre car l'élément glisser-déposer se produit après le rendu initial de la page. Les autres sections qui peuvent être chargées paresseusement incluent le contenu masqué (contenu qui apparaît après une interaction) et les images réduites.
Les outils peuvent vous aider à réduire votre charge de travail : YUI Image Loader peut charger paresseusement des images réduites, et l'utilitaire YUI Get est un moyen simple d'introduire du JS et du CSS. La page d'accueil de Yahoo! est un exemple. Vous pouvez ouvrir le panneau réseau de Firebug et y regarder de plus près.
Il est préférable d'aligner les objectifs de performances sur d'autres bonnes pratiques de développement Web, telles que l'amélioration progressive. Si le client prend en charge JavaScript, l'expérience utilisateur peut être améliorée, mais vous devez vous assurer que la page fonctionne correctement lorsque JavaScript n'est pas pris en charge. Ainsi, une fois que vous êtes sûr que votre page fonctionne correctement, vous pouvez l'améliorer avec des scripts à chargement paresseux pour prendre en charge certains effets sophistiqués tels que le glisser-déposer et les animations.
6. Précharger les composants
Le préchargement peut sembler être l’opposé du chargement paresseux, mais il a en réalité des objectifs différents. En préchargeant les composants, vous pouvez utiliser pleinement le temps d'inactivité du navigateur pour demander des composants (images, styles et scripts) qui seront utilisés à l'avenir. Lorsque l'utilisateur accède à la page suivante, la plupart des composants sont déjà dans le cache, la page se chargera donc plus rapidement du point de vue de l'utilisateur.
Dans les applications réelles, il existe les types de préchargement suivants :
Une page complexe signifie plus d'octets à télécharger et l'accès au DOM avec JavaScript sera plus lent. Par exemple, lorsque vous souhaitez ajouter un gestionnaire d'événements, il existe une différence entre parcourir 500 éléments DOM sur la page et 5 000 éléments DOM.
Un grand nombre d'éléments DOM est le signe qu'il y a des balises non pertinentes sur la page qui doivent être nettoyées. Utilisez-vous des tableaux imbriqués pour la mise en page ? Ou avez-vous ajouté un tas de <div> juste pour résoudre le problème de mise en page ? Peut-être qu'un meilleur balisage sémantique devrait être utilisé.
Les utilitaires CSS YUI sont très utiles pour la mise en page : grids.css est destiné à la mise en page globale, et fonts.css et reset.css peuvent être utilisés pour supprimer le formatage par défaut du navigateur. C'est une bonne occasion de commencer à nettoyer et à réfléchir à votre balisage, par exemple en n'utilisant <div> que lorsque cela a un sens sémantiquement, et non parce qu'il génère une nouvelle ligne.
Le nombre d'éléments du DOM est facile à tester, il suffit de taper dans la console Firebug :
document.getElementsByTagName('*').lengthAlors, combien d’éléments DOM sont de trop ? Vous pouvez faire référence à d'autres pages similaires bien marquées. Par exemple, la page d'accueil de Yahoo! est une page assez chargée, mais comporte moins de 700 éléments (balises HTML).
8. Séparation inter-domaines des composantsLa séparation des composants peut maximiser les téléchargements parallèles, mais assurez-vous de n'utiliser que 2 à 4 domaines maximum, car il existe une pénalité de recherche DNS. Par exemple, vous pouvez déployer du contenu HTML et dynamique sur www.example.org et séparer les composants statiques en static1.example.org et static2.example.org.
9. Utilisez le moins possible les iframesVous pouvez utiliser iframe pour insérer un document HTML dans un document parent. Il est important de comprendre le fonctionnement d'iframe et de l'utiliser efficacement.
Avantages de <iframe> :
Inconvénients de <iframe> :
Les requêtes HTTP coûtent cher. Il n'est pas nécessaire d'utiliser une requête HTTP pour obtenir une réponse inutile (comme 404 Not Found). Cela ne fera que ralentir l'expérience utilisateur sans aucun avantage.
Certains sites utilisent l'utile 404 - Voulez-vous dire xxx ? , Ceci est bénéfique pour l'expérience utilisateur, mais cela gaspille également les ressources du serveur (telles que les bases de données, etc.). Le pire est que le JavaScript externe auquel vous créez un lien contient une erreur et le résultat est un 404. Premièrement, ce téléchargement bloquera les téléchargements parallèles. Deuxièmement, le navigateur tentera d'analyser le corps de la réponse 404 car il s'agit de code JavaScript et devra découvrir quelles parties de celui-ci sont disponibles.
partie CSS 11. Évitez d'utiliser des expressions CSSUtiliser des expressions CSS pour définir dynamiquement les propriétés CSS est un moyen puissant et dangereux. Pris en charge depuis IE5, mais obsolète depuis IE8. Par exemple, vous pouvez utiliser une expression CSS pour définir la couleur d'arrière-plan pour qu'elle alterne par heure :
background-color: expression( (new Date()).getHours()%2 ? #B8D4FF : #F08A00 );12. Sélectionnez <link> pour supprimer @import
Une bonne pratique a été évoquée plus haut : afin d’obtenir un rendu progressif, le CSS doit être placé en haut.
L'utilisation de @import dans IE a le même effet que l'utilisation de <link> en bas, il est donc préférable de ne pas l'utiliser.
13. Évitez d'utiliser des filtresLe filtre AlphaImageLoader propriétaire d'IE peut être utilisé pour résoudre le problème des images PNG translucides dans les versions antérieures à IE7. Pendant le processus de chargement de l'image, ce filtre bloquera le rendu, gèlera le navigateur, augmentera la consommation de mémoire et sera appliqué à chaque élément, pas à chaque image, il y aura donc beaucoup de problèmes.
Le meilleur moyen est simplement de ne pas utiliser AlphaImageLoader et de rétrograder gracieusement vers l'utilisation d'images PNG8 qui sont bien prises en charge dans IE. Si vous devez utiliser AlphaImageLoader, vous devez utiliser le trait de soulignement hack:_filter pour éviter d'affecter les utilisateurs d'IE7 et versions ultérieures.
14. Mettez la feuille de style en hautLors de l'étude des performances chez Yahoo!, nous avons découvert que le fait de placer des feuilles de style dans la section HEAD du document donnait l'impression que la page se chargeait plus rapidement. En effet, placer la feuille de style dans l’en-tête permet à la page de s’afficher progressivement.
Les ingénieurs front-end soucieux des performances souhaitent que la page s'affiche de manière incrémentielle. En d'autres termes, nous souhaitons que le navigateur affiche le contenu existant le plus rapidement possible, ce qui est particulièrement important lorsqu'il y a beaucoup de contenu sur la page ou lorsque la connexion Internet de l'utilisateur est très lente. L'importance de montrer des commentaires aux utilisateurs (tels que des indicateurs de progrès) a été largement étudiée et documentée. Dans notre cas, la page HTML est l'indicateur de progression ! Lorsque le navigateur charge progressivement l'en-tête de la page, la barre de navigation, le logo supérieur, etc., ceux-ci sont utilisés comme commentaires par les utilisateurs qui attendent le chargement de la page, ce qui peut améliorer l'expérience utilisateur globale.
partie js 15. Supprimez les scripts en doubleLes pages contenant des fichiers de script en double peuvent avoir un impact sur les performances plus important que vous ne le pensez. Lors d'un examen des 10 principaux sites Web aux États-Unis, seuls deux sites contenaient des scripts en double. Deux raisons principales augmentent les risques d'apparition de scripts en double sur une seule page : la taille de l'équipe et le nombre de scripts. Dans ce cas, les scripts en double créent des requêtes HTTP inutiles, exécutent du code JavaScript inutile et ont un impact sur les performances des pages.
IE génère des requêtes HTTP inutiles, mais pas Firefox. Dans IE, si un script externe non mis en cache est introduit deux fois par la page, il générera deux requêtes HTTP lors du chargement de la page. Même si le script peut être mis en cache, il générera des requêtes HTTP supplémentaires lorsque l'utilisateur rechargera la page.
En plus de générer des requêtes HTTP dénuées de sens, évaluer le script plusieurs fois fait perdre du temps. Car peu importe si le script peut être mis en cache ou non, le code JavaScript redondant sera exécuté dans Firefox et IE.
Une façon d'éviter d'importer accidentellement deux fois le même script consiste à implémenter un module de gestion de script dans le système de modèles. Une manière typique d'introduire des scripts consiste à utiliser des balises SCRIPT dans les pages HTML :
<script type=text/javascript src=menu_1.0.17.js></script>16. Réduire l'accès au DOM
L'accès aux éléments DOM avec JavaScript est très lent, donc afin de rendre la page plus réactive, vous devez :
Parfois, on a l'impression que la page n'est pas assez réactive car trop de gestionnaires d'événements fréquemment exécutés ont été ajoutés aux différents éléments de l'arborescence DOM. C'est pourquoi la délégation d'événements est recommandée. S'il y a 10 boutons dans un div, vous ne devez ajouter qu'un seul gestionnaire d'événements au conteneur div au lieu d'un pour chaque bouton. Les événements peuvent bouillonner, vous pouvez donc capturer l'événement et savoir quel bouton est la source de l'événement.
18. Mettez le script en basLe script bloquera les téléchargements parallèles. La documentation officielle HTTP/1.1 recommande que le navigateur ne télécharge pas plus de deux composants en parallèle par nom d'hôte. Si l'image provient de plusieurs noms d'hôte, le nombre de téléchargements parallèles peut dépasser deux. Si le script est en cours de téléchargement, le navigateur ne lancera aucune autre tâche de téléchargement, même sous un nom d'hôte différent.
Parfois, il n'est pas facile de déplacer le script vers le bas. Par exemple, si le script est inséré dans le contenu de la page à l'aide de document.write, il n'y a aucun moyen de le déplacer plus bas. Il peut également y avoir des problèmes de portée qui, dans la plupart des cas, peuvent être résolus.
Une suggestion courante consiste à utiliser des scripts différés. Les scripts avec l'attribut DEFER signifient qu'ils ne peuvent pas contenir document.write et invitent le navigateur à leur indiquer qu'ils peuvent continuer le rendu. Malheureusement, Firefox ne prend pas en charge l'attribut DEFER. Dans IE, le script peut être différé, mais pas comme prévu. Si le script peut être différé, nous pouvons le déplacer vers le bas de la page et la page se chargera plus rapidement.
javascript, css 19. Gardez JavaScript et CSS à l'extérieurDe nombreux principes de performances concernent la manière de gérer les composants externes. Cependant, avant que ces problèmes ne surviennent, vous devez vous poser une question plus fondamentale : JavaScript et CSS doivent-ils être placés dans des fichiers externes ou écrits directement sur la page ?
En fait, l'utilisation de fichiers externes peut rendre la page plus rapide car les fichiers JavaScript et CSS seront mis en cache dans le navigateur. Le JavaScript et le CSS en ligne dans un document HTML sont retéléchargés à chaque fois que le document HTML est demandé. Cela réduit le nombre de requêtes HTTP requises mais augmente la taille du document HTML. D'un autre côté, si le JavaScript et le CSS se trouvent dans des fichiers externes et ont été mis en cache par le navigateur, nous avons réussi à réduire la taille du document HTML sans augmenter le nombre de requêtes HTTP.
20. Réduire JavaScript et CSSLa compression supprime spécifiquement les caractères inutiles du code pour réduire la taille et ainsi améliorer la vitesse de chargement. La minimisation du code signifie supprimer tous les commentaires et les espaces inutiles (espaces, nouvelles lignes et tabulations). Faire cela en JavaScript peut améliorer la réactivité car le fichier à télécharger est plus petit. Les deux outils de compression de code JavaScript les plus couramment utilisés sont JSMin et YUI Compressor, qui peut également compresser le CSS.
L'obfuscation est une mesure facultative d'optimisation du code source qui est plus complexe que la compression, de sorte que le processus d'obscurcissement est également plus susceptible de produire des bogues. Dans une enquête menée auprès des dix principaux sites Web aux États-Unis, la compression peut réduire la taille de 21 % et l'obscurcissement peut réduire la taille de 25 %. Bien que l’obscurcissement fournisse un degré de réduction plus élevé, il est plus risqué que la compression.
En plus de compresser des scripts et des styles externes, les blocs <script> et <style> en ligne peuvent également être compressés. Même avec le module gzip activé, la compression préalable peut réduire la taille de 5 % ou plus. JavaScript et CSS sont de plus en plus utilisés, la compression du code aura donc un bon effet.
image 21. Optimiser les imagesEssayez de convertir le format GIF au format PNG et voyez si cela économise de l'espace. Exécutez pngcrush (ou un autre outil d'optimisation PNG) sur toutes les images PNG
22. Optimiser les sprites CSSN'utilisez pas d'images plus grandes que ce dont vous avez besoin simplement parce que vous pouvez définir la largeur et la hauteur en HTML. si nécessaire
<img width=100 height=100 src=mycat.jpg Hôte : us.yimg.com If-Modified-Depuis : mar. 12 décembre 2006 03:03:59 GMT If-None-Match : 10c24bc-4ab-457e1c1f HTTP/ 1.1 304 Non modifié32. Utilisez la requête GET pour Ajax
L'équipe Yahoo! Mailbox a découvert que lors de l'utilisation de XMLHttpRequest, la requête POST du navigateur est implémentée via un processus en deux étapes : d'abord l'envoi de l'en-tête HTTP, puis l'envoi des données. Il est donc préférable d'utiliser une requête GET, qui doit uniquement envoyer un message TCP (sauf s'il y a trop de cookies). La longueur maximale de l'URL d'IE est de 2 Ko, donc si les données à envoyer dépassent 2 Ko, GET ne peut pas être utilisé.
Un effet secondaire intéressant des requêtes POST est qu’aucune donnée n’est réellement envoyée, comme c’est le cas des requêtes GET. Comme décrit dans la documentation HTTP, les requêtes GET sont utilisées pour récupérer des informations. Sa sémantique consiste donc simplement à utiliser des requêtes GET pour demander des données, et non à envoyer des données qui doivent être stockées au serveur.
33. Effacez le tampon le plus tôt possibleLorsqu'un utilisateur demande une page, le serveur met environ 200 à 500 millisecondes pour assembler la page HTML, période pendant laquelle le navigateur reste inactif et attend l'arrivée des données. Il existe une fonction flush() en PHP, qui vous permet d'envoyer une partie de la réponse HTML préparée au navigateur, afin que le navigateur puisse commencer à récupérer les composants tout en préparant la partie restante en arrière-plan. L'avantage se reflète principalement. en arrière-plan très chargé ou en front-end très léger Sur la page (PS En d'autres termes, l'avantage se reflète mieux lorsque le temps de réponse est principalement en arrière-plan).
L'endroit idéal pour vider le tampon est après le HEAD, car la partie HEAD du HTML est généralement plus facile à générer et permet l'introduction de tous les fichiers CSS et JavaScript, permettant au navigateur de commencer à récupérer les composants en parallèle pendant que l'arrière-plan est encore en cours de traitement. .
Par exemple:
... <!-- css, js --> </head> <?php flush( ?> <body> ... <!-- content -->34. Utilisez un CDN (Content Delivery Network)
La distance physique de l'utilisateur avec le serveur a également un impact sur le temps de réponse. Le déploiement de contenu sur plusieurs serveurs géographiquement dispersés permet aux utilisateurs de charger les pages plus rapidement. Mais comment faire ?
La première étape pour obtenir un contenu distribué géographiquement est la suivante : n'essayez pas de reconcevoir votre application Web pour l'adapter à une structure distribuée. Selon l'application, la modification de la structure peut impliquer des tâches ardues telles que la synchronisation de l'état de la session et la réplication des transactions de base de données sur les serveurs (les traductions peuvent ne pas être exactes). Les propositions visant à réduire la distance entre les utilisateurs et le contenu peuvent être retardées ou tout simplement impossibles à adopter en raison de cette difficulté.
N'oubliez pas que 80 à 90 % du temps de réponse d'un utilisateur final est consacré au téléchargement des composants d'une page : images, styles, scripts, Flash, etc. C'est une règle d'or de performance. Il est préférable de disperser d'abord le contenu statique plutôt que de repenser la structure de l'application depuis le début. Cela réduit non seulement considérablement le temps de réponse, mais facilite également la démonstration de la contribution du CDN.
Un réseau de diffusion de contenu (CDN) est un groupe de serveurs Web dispersés dans différents emplacements géographiques pour fournir du contenu aux utilisateurs plus efficacement. Généralement, le serveur choisi pour diffuser le contenu est basé sur une mesure de la distance du réseau. Par exemple : choisissez le serveur avec le plus petit nombre de sauts ou le temps de réponse le plus rapide.
35. Ajouter un en-tête HTTP Expires ou Cache-ControlCette règle comporte deux aspects :
La conception Web s'enrichit, ce qui signifie qu'il y a plus de scripts, d'images et de Flash sur la page. Les nouveaux visiteurs du site devront peut-être encore soumettre quelques requêtes HTTP, mais en utilisant une date d'expiration, le composant peut être mis en cache, ce qui évite les requêtes HTTP inutiles lors des sessions de navigation ultérieures. Les en-têtes HTTP d'expiration sont généralement utilisés sur les images, mais ils doivent être utilisés sur tous les composants, y compris les scripts, les styles et les composants Flash.
Les navigateurs (et les proxys) utilisent la mise en cache pour réduire le nombre et la taille des requêtes HTTP afin que les pages se chargent plus rapidement. Le serveur Web utilise l'en-tête de réponse HTTP Expiration pour indiquer au client la durée pendant laquelle chaque composant de la page doit être mis en cache. L'utilisation d'une heure située dans un avenir lointain comme date d'expiration indique au navigateur que cette réponse ne changera pas avant le 15 avril 2010.
Expire : jeu. 15 avril 2010 20:00:00 GMT
Si vous utilisez le serveur Apache, utilisez la directive ExpiresDefault pour définir la date d'expiration par rapport à la date actuelle. L'exemple suivant définit une période de validité de 10 ans à compter de la date de la demande :
ExpireAccès par défaut plus 10 ans
Ce qui précède représente l’intégralité du contenu de cet article. J’espère qu’il sera utile à l’étude de chacun. J’espère également que tout le monde soutiendra le réseau VeVb Wulin.