Rendu du navigateur : du texte aux images

📖 10min read

L’écran dessiné n’est pas magique

Lorsque j’ai commencé le développement front-end (Vue.js), je considérais le navigateur comme un simple « cadre pour afficher le code ». Il était naturel que si vous utilisiez

, un carré apparaisse, et si vous utilisiez color: red, il deviendrait rouge.

Cependant, mes pensées ont changé à mesure que j’expérimentais le bégaiement de l’animation ou les secousses de l’écran lors du défilement (jank). « Pourquoi le même code s’exécute-t-il correctement dans Chrome mais plante-t-il dans Internet Explorer (IE) ? » « Pourquoi mon processeur monte-t-il en flèche lorsque je change un peu le style avec JavaScript ? »

Il s’avère que le navigateur n’est pas seulement un cadre photo. Le navigateur était un énorme « Peintre » et « Architecte » qui interprétait le texte (HTML/CSS) que nous envoyions, calculait mathématiquement chaque pixel et l’imprimait.

La dernière fois, nous avons transmis des données en toute sécurité sur des routes difficiles. Cette fois, ouvrons la boîte de données (paquet) qui est arrivée et découvrons comment le navigateur dessine une image appelée écran. Il s’agit de la dernière histoire de la série Re : Booting CS Basics.

Le navigateur est un chantier de construction où le code est lu, construit et peint.

La cargaison est arrivée, l’assemblage commence

Dans notre vision du monde du « centre logistique numérique », le produit (fichier HTML) est désormais arrivé chez le client (navigateur). Cependant, ce qui est arrivé n’était pas un produit fini, mais un « manuel de montage ». L’équipe de travail appelée moteur de navigateur (moteur de rendu) lit ce manuel et commence immédiatement l’assemblage. Ce processus est appelé pipeline de rendu.

Étape 1 : analyse du plan (analyse et arborescence DOM)

Lit le texte HTML qui arrive en premier et crée un « squelette ».

Étape 2 : Design d’intérieur (arborescence CSSOM)

Ensuite, lisez le fichier CSS et créez des « règles de style ».

Étape 3 : Créer un bon de travail (Render Tree)

Maintenant, nous combinons le squelette (DOM) et la conception (CSSOM). Le point important ici est que seules les « éléments qui apparaîtront réellement à l’écran » sont sélectionnées.

L’arbre de rendu est une liste finale de « ceux qui peuvent être dessinés pour de vrai ».

[Vérification du code] Redistribution et repeinture

C’est maintenant l’étape vraiment importante. La clé de l’optimisation des performances réside ici. Une fois l’arbre de rendu créé, le navigateur effectue deux tâches lourdes.

Tentons la différence de coût avec le code.

const box = document.getElementById('box');

// Case 1: Code qui declenche le layout (Reflow) (couteux !)
// Si la taille ou la position change, les elements voisins doivent tous etre recalcules.
box.style.width = '200px'; 
box.style.height = '200px';
box.style.margin = '20px';

// Case 2: Code qui declenche seulement le paint (Repaint) (relativement bon marche)
// Position inchangee, seule la couleur change. Pas de calcul, juste un repaint.
box.style.backgroundColor = 'blue';
box.style.color = 'white';
box.style.visibility = 'hidden';

Analyse :

En pratique, la plupart des cas d’« animation saccadée » se produisent parce que les propriétés de mise en page telles que width, left et top sont touchées en temps réel. Dans ce cas, une technique est nécessaire pour ignorer le calcul de mise en page en utilisant des propriétés telles que transform.

Conseil pratique : N’intimidez pas votre navigateur

Je ne le savais pas quand j’étais à l’université, alors j’ai manipulé le DOM au hasard avec JavaScript. En parcourant l’instruction for, j’ai modifié la taille et le style de chaque élément. Du point de vue du navigateur, c’est comme être torturé en détruisant et en reconstruisant un bâtiment des dizaines de fois par seconde.

Conseils pour garantir les performances :

Changer l’emplacement (Reflow) est une opération beaucoup plus coûteuse que changer la couleur (Repaint).

Série finale 1 : Mon CS redémarré

Avec cet article, la [Re: Booting] CS Basics Series a pris fin.

Nous avons fait un long voyage ensemble.

Au début, c’était juste des connaissances que j’avais mémorisées pour trouver un emploi. Cependant, après avoir rencontré des erreurs dans la pratique et après avoir regardé à nouveau, CS (ingénierie informatique) n’était pas une lettre morte, mais une terre solide qui soutenait mon code.

Les travaux de fondation sont maintenant terminés. Il est temps de construire votre propre château sur des bases solides. Dans la prochaine série [Monolith Builder], j’aborderai la création d’applications Web à l’aide de Spring Boot et Vue.js, que j’ai expérimenté en pratique. Veuillez attendre avec impatience le processus de transformation de la « théorie » en « pratique ».

Laisser un commentaire