diff options
Diffstat (limited to 'files/fr/web/performance/how_browsers_work/index.html')
-rw-r--r-- | files/fr/web/performance/how_browsers_work/index.html | 24 |
1 files changed, 12 insertions, 12 deletions
diff --git a/files/fr/web/performance/how_browsers_work/index.html b/files/fr/web/performance/how_browsers_work/index.html index 19a313e3aa..516c2d42fb 100644 --- a/files/fr/web/performance/how_browsers_work/index.html +++ b/files/fr/web/performance/how_browsers_work/index.html @@ -10,7 +10,7 @@ translation_of: Web/Performance/How_browsers_work --- <p>Les utilisateurs veulent des expériences Web avec un contenu rapide à charger et une interaction fluide. Par conséquent, un développeur doit s'efforcer d'atteindre ces deux objectifs.</p> -<p><span class="seoSummary">Pour comprendre comment améliorer les performances et les performances perçues, il est utile de comprendre le fonctionnement du navigateur.</span></p> +<p>Pour comprendre comment améliorer les performances et les performances perçues, il est utile de comprendre le fonctionnement du navigateur.</p> <h2 id="Vue_générale">Vue générale</h2> @@ -40,7 +40,7 @@ translation_of: Web/Performance/How_browsers_work <p>Si vos fichier de police, images, scripts, publicites/annonces et métriques ont tous un nom d'hôte différent, une recherche DNS devra être effectuée pour chacun d'eux.</p> -<p><img alt="Mobile requests go first to the cell tower, then to a central phone company computer before being sent to the internet" src="https://mdn.mozillademos.org/files/16743/latency.jpg" style="height: 281px; width: 792px;"></p> +<p><img src="latency.jpg"></p> <p>Cela peut être problématique pour les performances, en particulier sur les réseaux mobiles. Lorsqu'un utilisateur est sur un réseau mobile, chaque recherche DNS doit aller du téléphone à la tour cellulaire pour atteindre un serveur DNS faisant autorité. La distance entre un téléphone, une tour de téléphonie cellulaire et le serveur de noms peut ajouter une latence significative.</p> @@ -54,7 +54,7 @@ translation_of: Web/Performance/How_browsers_work <p>Pour les connexions sécurisées établies via HTTPS, une autre "liaison" est requise. Cette négociation, ou plutôt la négociation {{glossary('TLS')}}, détermine quel chiffrement sera utilisé pour chiffrer la communication, vérifie le serveur et établit qu'une connexion sécurisée est en place avant de commencer le transfert effectif des données. Cela nécessite encore trois allers-retours vers le serveur avant que la demande de contenu ne soit réellement envoyée.</p> -<p><img alt="The DNS lookup, the TCP handshake, and 5 steps of the TLS handshake including clienthello, serverhello and certificate, clientkey and finished for both server and client." src="https://mdn.mozillademos.org/files/16746/ssl.jpg" style="height: 412px; width: 729px;"></p> +<p><img src="ssl.jpg"></p> <p>Bien que sécuriser la connexion ajoute du temps au chargement de la page, une connexion sécurisée vaut la dépense en latence, car les données transmises entre le navigateur et le serveur Web ne peuvent pas être déchiffrées par un tiers.</p> @@ -92,7 +92,7 @@ translation_of: Web/Performance/How_browsers_work <p>Avec un {{glossary('TCP slow start')}}, après la réception du paquet initial, le serveur double la taille du paquet suivant, pour atteindre environ 28 Kb. La taille des paquets suivants augmente jusqu'à atteindre un seuil prédéterminé ou jusqu'à ce qu'un encombrement se produise.</p> -<p><img alt="TCP slow start" src="https://mdn.mozillademos.org/files/16754/congestioncontrol.jpg" style="height: 412px; width: 729px;"></p> +<p><img src="congestioncontrol.jpg"></p> <p>Si vous avez déjà entendu parler de la règle de 14 Kb pour le chargement de page initial, c'est le démarrage lent de TCP qui explique pourquoi la réponse initiale est de 14 Ko et pourquoi l'optimisation des performances Web appelle à l'optimisation de la focalisation avec cette réponse initiale à l'esprit. Le démarrage lent TCP augmente progressivement les vitesses de transmission en fonction des capacités du réseau afin d'éviter les encombrements.</p> @@ -110,15 +110,15 @@ translation_of: Web/Performance/How_browsers_work <h3 id="Building_the_DOM_tree">Building the DOM tree</h3> -<p>Nous décrivons cinq étapes dans le chemin de rendu critique, ou "<a href="/en-US/docs/Web/Performance/Critical_rendering_path">critical rendering path</a>".</p> +<p>Nous décrivons cinq étapes dans le chemin de rendu critique, ou "<a href="/fr/docs/Web/Performance/Critical_rendering_path">critical rendering path</a>".</p> -<p>La première étape consiste à traiter le balisage HTML et à créer l'arborescence DOM. L'analyse HTML implique la création de jetons, <a href="/en-US/docs/Web/API/DOMTokenList">tokenization,</a> et la construction du DOM tree. Les jetons HTML incluent les balises de début et de fin, ainsi que les noms et les valeurs des attributs. Si le document est bien formé, son analyse est simple et rapide. L'analyseur analyse les entrées sous forme de jetons dans le document, créant ainsi le document tree.</p> +<p>La première étape consiste à traiter le balisage HTML et à créer l'arborescence DOM. L'analyse HTML implique la création de jetons, <a href="/fr/docs/Web/API/DOMTokenList">tokenization,</a> et la construction du DOM tree. Les jetons HTML incluent les balises de début et de fin, ainsi que les noms et les valeurs des attributs. Si le document est bien formé, son analyse est simple et rapide. L'analyseur analyse les entrées sous forme de jetons dans le document, créant ainsi le document tree.</p> <p>Le DOM tree décrit le contenu du document. L'élément <code><a href="/fr/docs/Web/HTML/Element/html"><html></a></code> est la première balise et le premier nœud racine de du document tree. L'arbre reflète les relations et les hiérarchies entre différentes balises. Les balises imbriquées dans d'autres balises sont des nœuds enfants. Plus le nombre de nœuds DOM est élevé, le plus de temps ca prends pour construire le DOM tree.</p> -<p><img alt="The DOM tree for our sample code, showing all the nodes, including text nodes." src="https://mdn.mozillademos.org/files/16759/DOM.gif" style="height: 689px; width: 754px;"></p> +<p><img src="dom.gif"></p> -<p>Lorsque l'analyseur trouve des ressources non bloquantes, telles qu'une image, le navigateur demande ces ressources et poursuit l'analyse. L'analyse peut continuer lorsqu'un fichier CSS est rencontré, mais les balises <code><script></code>, en particulier celles sans attribut <code><a href="/en-US/docs/Web/JavaScript/Reference/Statements/async_function">async</a></code> ou <code>defer</code>, bloquent le rendu et mettent en pause l'analyse du code HTML. Bien que le scanner de précharge du navigateur accélère ce processus, le nombre excessif de scripts peut toujours constituer un goulot d'étranglement important.</p> +<p>Lorsque l'analyseur trouve des ressources non bloquantes, telles qu'une image, le navigateur demande ces ressources et poursuit l'analyse. L'analyse peut continuer lorsqu'un fichier CSS est rencontré, mais les balises <code><script></code>, en particulier celles sans attribut <code><a href="/fr/docs/Web/JavaScript/Reference/Statements/async_function">async</a></code> ou <code>defer</code>, bloquent le rendu et mettent en pause l'analyse du code HTML. Bien que le scanner de précharge du navigateur accélère ce processus, le nombre excessif de scripts peut toujours constituer un goulot d'étranglement important.</p> <h3 id="Preload_scanner">Preload scanner</h3> @@ -178,17 +178,17 @@ translation_of: Web/Performance/How_browsers_work <p>Sur la page Web, presque tout est une boîte. Différents périphériques et différentes préférences de bureau signifient un nombre illimité de tailles de fenêtres d'affichage différentes. Au cours de cette phase, prenant en compte la taille de la fenêtre d'affichage, le navigateur détermine les dimensions de toutes les différentes boîtes à l'écran. En prenant la taille de la fenêtre comme base, la présentation commence généralement par le corps, elle présente les dimensions de tous les descendants du corps, ainsi que les propriétés du modèle de boîte de chaque élément, offrant ainsi un espace réservé aux éléments remplacés dont il ne connaît pas les dimensions: comme notre image.</p> -<p>La première fois que la taille et la position des nœuds sont déterminées est appelée "mise en page", ou <em lang="en">layout</em>. Les recalculs ultérieurs de la taille et des emplacements des noeuds sont appelés redistributions, ou <em lang="en">reflows</em>. Dans notre exemple, supposons que la mise en page initiale se produise avant que l'image ne soit renvoyée. Comme nous n’avons pas déclaré la taille de notre image, il y aura un reflow une fois que la taille de l’image est connue.</p> +<p>La première fois que la taille et la position des nœuds sont déterminées est appelée "mise en page", ou <i lang="en">layout</i>. Les recalculs ultérieurs de la taille et des emplacements des noeuds sont appelés redistributions, ou <i lang="en">reflows</i>. Dans notre exemple, supposons que la mise en page initiale se produise avant que l'image ne soit renvoyée. Comme nous n’avons pas déclaré la taille de notre image, il y aura un reflow une fois que la taille de l’image est connue.</p> <h3 id="Peindre">Peindre</h3> -<p>La dernière étape du chemin de rendu critique consiste à peindre les nœuds individuels à l'écran, la première occurrence étant appelée la première peinture significative, ou <em lang="en">first meaningful paint</em>.</p> +<p>La dernière étape du chemin de rendu critique consiste à peindre les nœuds individuels à l'écran, la première occurrence étant appelée la première peinture significative, ou <i lang="en">first meaningful paint</i>.</p> <p>Lors de la phase de peinture ou de rastérisation, le navigateur convertit chaque case calculée lors de la phase de mise en page en pixels réels à l'écran. La peinture implique de dessiner chaque partie visuelle d'un élément sur l'écran, y compris le texte, les couleurs, les bordures, les ombres et les éléments remplacés, comme les boutons et les images. Le navigateur doit faire cela très rapidement.</p> <p>Pour assurer un défilement et une animation fluides, tout ce qui occupe le fil principal, y compris le calcul des styles, ainsi que le redistribution et la peinture, doit nécessiter moins de 16,67ms de navigateur.</p> -<p>À 2048 X 1536, l’iPad a plus de 3 145 000 pixels à peindre à l’écran. C'est beaucoup de pixels qui doivent être peints très rapidement. Afin de pouvoir repeindre même plus rapidement que la peinture initiale, le dessin à l'écran est généralement divisé en plusieurs couches, ou <em lang="en">layers</em>. Si cela se produit, la composition est nécessaire.</p> +<p>À 2048 X 1536, l’iPad a plus de 3 145 000 pixels à peindre à l’écran. C'est beaucoup de pixels qui doivent être peints très rapidement. Afin de pouvoir repeindre même plus rapidement que la peinture initiale, le dessin à l'écran est généralement divisé en plusieurs couches, ou <i lang="en">layers</i>. Si cela se produit, la composition est nécessaire.</p> <p>La peinture peut diviser les éléments de l’arborescence en couches. La promotion du contenu en couches sur le GPU (au lieu du thread principal sur le CPU) améliore la performances de la peinture originale et chaque la performances de repeinte supplémentaire.</p> @@ -210,7 +210,7 @@ translation_of: Web/Performance/How_browsers_work <p>Dans notre exemple, l'image a peut-être été chargée rapidement, mais le fichier <code>unautrescript.js</code> faisait 2 MB et la connexion réseau de notre utilisateur était lente. Dans ce cas, l'utilisateur verrait la page très rapidement, mais ne pourrait pas faire défiler sans jank jusqu'à ce que le script soit téléchargé, analysé et exécuté. Ce n'est pas une bonne expérience utilisateur. Évitez d’occuper le fil principal, comme illustré dans cet exemple <a href="https://webpagetest.org">WebPageTest</a>:</p> -<p><img alt="The main thread is occupied by the downloading, parsing and execution of a javascript file - over a fast connection" src="https://mdn.mozillademos.org/files/16760/visa_network.png" style="height: 699px; width: 1200px;"></p> +<p><img src="visa_network.png"></p> <p>Dans cet exemple, le processus de chargement du contenu du DOM a duré plus de 1,5 seconde et le thread principal a été entièrement occupé pendant tout ce temps, ne répondant pas pour cliquer sur des événements ou sur des taps à l'écran.</p> |