
Audit des Google core web vitals
Durée: 44m42s
Date de sortie: 02/06/2021
En juin 2021, Google introduit de nouveaux indicateurs de performance pour les sites web. Ils annoncent qu'ils sont désormais pris en compte dans les critères pour le classement dans le résultat de recherches. On constate une panique générale des propriétaires de site web alors que Google avait prévenu depuis un moment que la vitesse de chargement serait de plus en plus prise en compte. Retrouvez toutes les notes et les liens de l'épisode sur cette page : https://double-slash.dev/podcasts/core-web-vitals/
Bonjour et bienvenue dans ce nouvel épisode de Double Slash, l'épisode numéro 24. Alors
aujourd'hui on va parler de performance, de web performance avec les Audit Core Web
Vitals, c'est un nom un peu complexe mais c'est Patrick qui va nous en parler plus. Salut Patrick !
Salut Alex, comment ça va ? Ecoute, nickel, ce sujet que moi je maîtrise pas du tout,
du coup tu vas nous expliquer un peu tout ce que c'est parce que en fait tu as eu la chance de
bosser sur une grosse audite d'un site internet du coup tu as dû jouer avec une méthodologie
et d'aller chercher et d'optimiser, de faire un audit de vraiment la performance du site.
Ouais, en fait c'est assez récent. Alors qu'est ce que c'est les Core Web Vitals ? En fait c'est
des indicateurs de performance pour les sites web qui sont lancés par Google,
simplement comme d'habitude et en fait je m'étais pas trop intéressé à ça et je me suis rendu compte
que la petite à petite les clients qui commencent à paniquer en fait en se disant mais ouais mais
parce que c'est censé arriver en juin, enfin c'était arrivé en mai, là j'entends juin maintenant
et c'est des indicateurs qui seront pris en compte au niveau du référencement du SEO etc.
Donc les gens commencent à paniquer un petit peu et voilà. Et du coup ça te fait grosse panique ou pas ?
J'ai l'impression que ça panique pas mal un peu comme le RGPD il y a deux ans.
Vite il faut qu'on se mette à conformité et tout ça. J'ai l'impression que par contre ça
n'aura pas une énorme impact de ce que j'ai entendu, ça ne va pas impacter énormément les résultats.
En gros il y a certaines personnes qui pensent qu'ils vont passer de la première page à la
cinquième page. En gros apparemment ce serait plutôt au moment d'avoir deux résultats équivalents
Google favoriserait le plus rapide, enfin celui qui a le meilleur score mais en gros ça c'est ça.
Après c'est toujours opaque. Est-ce que c'est Google ?
Après est-ce que c'est pas une approche plutôt bonus ? C'est à dire tu as un bonus si tu es rapide
mais par contre tu n'as pas de malus quoi. C'est exactement ça tu l'as bien résumé.
En gros c'est ça c'est un bonus si tu as un bon score mais en gros il n'y a pas de malus.
Mais c'est quand même mieux d'avoir un site qui est performant quand même.
On avait déjà des indicateurs tout ça des systèmes de test, le Google speed test etc qui nous
indiquaient déjà si on avait un bon score etc, le lighthouse. Mais là en fait la
nouveauté avec ces indicateurs c'est qu'ils sont plutôt orientés sur le ressenti en fait.
C'est là de chargement en fait. C'est pas vraiment sur du pur statistique.
Mais en fait je vais vous expliquer. Je vous ai dit rien.
Ok cool. Et ben feu du coup comment on peut regarder tout ça en fait ?
Moi je veux regarder ma performance. Comment je fais ? Qu'est ce que je fais ?
Déjà tu as des outils qu'on utilise au quotidien. Le devtools tout ça,
lighthouse qui nous donne pas mal d'indicateurs. Mais il y a maintenant donc il y a trois indicateurs
qui rentrent dans ces core web vitals. Le premier c'est le largest contentful pent
lcp pour les intimes. Ensuite il y a le first input delay donc fide et le cumulatif
layout shift, cls. Donc c'est trois indicateurs. Donc quand tu vas faire un test sur le pas
speed inside de google ils sont marqués avec un petit drapeau là pour dire cela ils sont pris
en compte dans le core web vitals. T'en as d'autres mais cela sont vraiment marqués comme quoi
c'est pris en compte pour voilà pour que les gens prennent l'habitude en fait de regarder
ces indicateurs. Et tu as un score et en gros tu as trois petits, tu as trois couleurs,
tu as rouge, orange et vert et forcément quand c'est rouge c'est très mauvais.
Est-ce que c'est les mêmes infos qu'on retrouve sur lighthouse ou des choses comme ça ou pas du tout ?
Oui sur lighthouse tu as l'onglet performance le premier je crois ou oui tu retrouves la même
chose. Tu as retrouvé exactement la même chose. C'est pour ça que tu as le lighthouse, il est
arrivé après le page speed inside donc ça reprenait en partie le page speed inside.
Mais oui tu les as sur lighthouse donc tu peux tester aussi directement ton navigateur quand tu fais
des développements. Après il est un petit peu différent quand tu fais le test sur le site
page speed inside. T'as aussi le core web vitals, il y a une page dédiée aussi maintenant sur le site.
Je sais plus que celle site google dev.dev. Après c'est différent parce que
quand tu le fais dans ton navigateur devtools, souvent tu as une bonne connexion,
tu as un bon ordinateur etc qui fonctionne donc ça peut fosser en fait tes résultats.
Parce que pourquoi ? Parce que tout simplement toi par exemple en tant que développeur tu as
un bon code. En tant que dev tu as une bonne machine puisque tu travailles dessus de la journée,
tu as un processeur qui est puissant etc tu as une bonne connexion souvent la fibre si on est bien
doté et ça peut fosser puisque ton devtools il va exécuter dans le navigateur
et donc ça peut fosser complètement résultats alors que le quand tu vas dans la page
de google il va le faire à distance et il va utiliser des machines tout ça etc et ça peut tu
peux avoir des gros écarts de résultats en fait entre la page google de page speed inside et ton
navigateur dans le devtools. Donc il faut vraiment faire attention à ça c'est bien d'utiliser le
devtools pour le développement etc d'avoir des indicateurs mais attention il faut toujours aller
tester quand même sur des outils de test séparés pour que ça prenne pas en compte tout ce que
voilà tu en as dit la fibre etc parce qu'en réalité le test il est réalisé sur du mobile
et comme on le sait les mobiles ils ont des processeurs même si aujourd'hui les mobiles haut de gamme
sont très puissants on a souvent des processeurs qui sont un peu plus lent et c'est à ce niveau-là
en fait que ça va ça va pénaliser en fait le site. Et donc non mais je comprends parfaitement
est-ce que tu peux détailler en fait les trois indicateurs de manière un peu plus
précise pour justement aller chercher de l'optimisation et en fait comment tu fais pour atteindre
ce niveau de granularité en fait parce que ok on a nos indicateurs ils sont mauvais
comment je fais déjà un comment je fais pour bien les auditer les séparer et avoir
ce que tu peux nous donner en fait des clés de lecture pour interpréter ces chiffres-là.
Ouais tout à fait bah je vais en va détailler les trois indicateurs puis je vais expliquer en
gros comment ça fonctionne comment sur quoi ils agit. Donc on va commencer par le plus simple
c'est le cumulative layout shift donc le CLS donc lui en fait il va mesurer la stabilité de la page
en gros on a tous eu l'expérience et surtout sur les sites de presse tu as le site qui charge
et quelques secondes après tu as une publicité qui s'affiche
au dessus et qui va te décaler tout le site. Voilà tu vois donc les inéments bougent.
Toi tu étais là tu allais cliquer sur le lien de l'article et d'un coup il descend l'article donc
tu cliques sur la pub on pourrait dire que c'est fait exprès mais malin et ça en fait c'est
voilà c'est ça le cumulative layout shift c'est ça que ça enfin c'est ce que ça mesure donc la
stabilité des éléments au chargement de la page donc il faut que les éléments bougent le moins
possible quand ta page se charge donc ça donc le plus connu c'est les publicités etc ça peut
être aussi les bannières qui voilà qui s'affichent pour afficher un message des choses comme ça et
il y a aussi donc ça c'est facilement il y a aussi il y a aussi les images par exemple les images
maintenant tu sais avec le responsive on met plus de taille dans la plupart du temps dans les balises
et on fait weed 100% et auto tu vois par exemple et en gros tu vas avoir un truc qui en fait l'image
va charger et elle va s'afficher et elle va prendre la place qu'elle a besoin et ça va te décaler
le reste en fait tu vois t'as souvent cet effet là en fait ok donc ça aussi c'est très mauvais
puisque ça décale le bloc de texte etc ça va te décaler le footer ça va te décaler tout
tout ce qui est en dessous en fait donc ça c'est ce qu'on aurait pas intérêt au niveau des images
par exemple à déclarer de manière volontaire les images selon le mobile et comme ça en fait on
aurait ça le layout il bougerait pas quoi bah c'est ça en fait c'est là dessus qu'il faut
travailler en fait donc que ça soit des images que ça soit de la publicité etc en fait la clé
pour ce technicateur c'est de en gros réserver la place qui est nécessaire pour ces éléments si
tu sais que tu vas afficher une bannière de pub de 200 pixels de haut tu lui réserve la place de 200
pixels et tu l'affiches après et ce qui est du coup ça va pas décaler le contenu pour les images
c'est pareil tu sais que ton image est fait tel taille tu vas essayer de réserver la place
pour que l'image s'affiche et décale pas le texte donc ça c'est un élément qui est plutôt
simple à corriger je pense c'est le plus simple et ensuite donc pour y a un quand on est en tant
que développeur dans le depth tools donc la plupart du temps pour trouver les indicateurs des
corps web vitals on va aller dans la longue les performances donc là je parle de chrome
toujours donc sur chrome on a longue les performances dans le depth tools on va lancer
un comment dire un script il va enregistrer en fait il va charger le site et il va enregistrer
tout ce qui se passe pendant qu'il charge le site et si on coche corps web vitals en fait il va
afficher des petits indicateurs pour voilà c'est différent de et fidé le cls ou ça et il va te dire
quel bloc bouge en fait et tu vas pouvoir trouver en fait exactement le bloc qui bouge
au moment du chargement donc ça on peut facilement corriger cet indicateur
ah ouais donc en fait on a il nous assiste vraiment en mode tel bloc donc à nous après de le corriger
faut-il encore faire l'effort de d'ouvrir son depth tools d'actionner performance
et de venir monitorer le cls quoi bah ouais après oui après ça c'est plutôt réserveur
développeur mais c'est enfin si tu as un mauvais score en toute façon tu n'as pas le choix il faudra
passer par là ok ensuite et oui vas-y vas-y vas-y après ce nouveau ce nouveau score qu'on va avoir
le ce mauvais score bon le coup là je prends un tout petit peu plus de recul et on va replonger dans
les dans les indicateurs toi est-ce que tu penses qu'il vaut mieux faire ton site et tu viens optimiser
apostrari ou en fait t'obterais plutôt pour une approche dès le départ non c'est c'est enfin c'est
comme le si o comme l'accessibilité de c'est dès le début en fait dès le début tu dois réfléchir
à qu'est ce que je vais utiliser comme package si tu fais une web app tu vas réfléchir attend
les packages qu'ils utilisent quel poids ils font comment je les charge est ce que je peux les
les différer etc c'est vraiment dès le début parce qu'en fait bah justement là là j'ai fait
j'ai fait une audite comme tu disais au début d'un site qui est déjà ben fini avancé enfin voilà
et aujourd'hui c'est difficile de donc il a c'est une web app et donc il a des packages npm qui sont
inclus dans le bundle final et aujourd'hui c'est difficile de va de changer de package parce que
c'est tout intégré dans le col c'est tout mélangé et tu peux plus voilà changer complètement de
package parce qu'il est trop lourd donc non c'est vraiment dès le début il faut vraiment le prendre
compte dès le début ça c'est c'est une évidence mais c'est pour tout en toute façon pour le si o pour
donc en fait on pourrait dire qu'il faudrait qu'on mette ça dans notre workflow de dev
prendre systématiquement ces performances là les intégrer en fait dans notre quotidien de
développeur pour que le résultat final soit aussi performant que esthétique fonctionnel et tout ça
ouais tout à fait accessible et bien référencé si haut donc en fait c'est un truc en plus à faire
quoi un truc en plus ouais c'est clair ok ensuite le deuxième indicateur bah justement parce que
comme on en parlait là c'est le first input délai donc en fait cet indicateur il y calculent
en fait le moment où ta page est utilisable et ça c'est vraiment valable pour les web app
clairement puisque le principal responsable de cette augmentation de délai en fait c'est le JavaScript
donc en gros comment il y calcul en fait pour lui c'est le moment où tu vas pouvoir
entendre que utilisateur cliquer sur parce qu'en fait des fois tu peux avoir des tu vas avoir ta page
qui va charger t'as un bouton qui s'affiche mais si tu cliques dessus il se passe rien en fait pourquoi
parce que sur une web app tu peux par exemple tu prends un gatsby ou un x ou n'importe quoi
tu vas avoir le html qui va être rendu du serveur et ensuite l'application va être réhydratée
et tous les événements vont être insérés dans les dans les boutons etc et sauf que ça ça
prend un certain temps et donc tu peux avoir un bouton qui est sur l'écran mais tu vas cliquer
mais il va rien se passer parce que l'événement est pas encore actif tu vois et ça c'est ce qui
calcule en fait le premier voilà à quel moment la page est utilisable et cliquable
et donc comme je dis c'est toujours le fichier js enfin tout ce qui est JavaScript qui est très long
en fait qui va ralentir ce first input délai parce que alors pour les normalement vous êtes censé le
savoir la plupart des gens sont censés savoir en tant que développeur donc le JavaScript qu'est-ce
que tu as déjà chargé tous les éléments enfin il va charger le html il va charger
tout ce qui est css javascript etc et quand il va charger déjà vascic par exemple il faut qui
déjà il faut qu'il le charge donc si le fichier est lourd bah ça prend du temps et ensuite il faut
qu'il le passe donc il va lire tout ce fichier et après il va aller agir sur le dom s'il y a besoin
si tu as des choses si tu as des jquery qui va modifier le dom etc il va il va le faire et à
une fois que ce sera fini tout ça il va dire ok la page elle est c'est bon elle est chargée
donc logiquement plutôt fichier js est gros et ben plus ça prend du temps en fait simplement et
plus d'opération en fait avec le dom ça prend du temps c'est logique sauf que ça ne marche pas
toujours comme ça et on se retrouve parfois avec des fichiers js extrêmement lourd alors la plupart
du temps on va encore faire des amis sur des sites wordpress qui utilisent des builders qui la
plupart du temps ont des gros fichiers js qui sont chargés sur les sites les gros fichiers css pourquoi
parce que ben ils ont des multiples options voilà pour que les gens puissent faire des blocs de rouge
ou blocs bleus enfin des trucs comme ça et donc on se trimballe des fichiers js extrêmement lourd
et ça c'est vraiment pénalisé et du coup mais ça on ne peut pas le on ne peut pas optimiser ça
avec le code splitting quoi est ce que ça c'est et c'est ça serait une meilleure pratique une bonne
pratique pour justement améliorer ce ce first input delay justement de pour éviter que quand j'arrive
sur la page de login je me charge toute l'application globale quoi si si si je split en fait mon gs en
différentes pages et c'est le gs le bundle gs est réhydraté au fur et à mesure de ma navigation
de page ce qui fait que quand j'arrive sur mon dashboard je prends que le gs du dashboard quand j'arrive
sur la page contact je prends que le gs du du page de la page contact ça c'est plutôt bien pour avoir
un meilleur first input delay non ouais ouais ouais c'est ce qui se passe déjà en fait c'est ce qui
se passe c'est exactement ce qu'il faut faire et c'est ce qui se passe sur les sur les outils qu'on
utilise gatsby nugs tout next ils vont chunker le javascript mais en fait le javascript est
chunker comment il fait pour chunker sur une application comme ça il bas c'est par rapport
aux routes donc ta page login il va prendre que le code qui correspond au login par exemple pour
afficher le gain etc etc donc c'est au niveau du bundle en fait au moment de mon build de mon bundle
où là il faut que ce soit chunker quoi déjà il le fait automatiquement quand tu prends des
frameworks pour faire des web app mais là ça marche très très bien déjà seulement si tu
utilises une librairie pour gérer le css par exemple ou des boutons enfin material UI par
exemple pour pour le palacité elle est utilisée au global dans l'application donc elle fait pas
partie des pages elle fait partie de elle fait partie du bundle global en fait de l'app donc tu
vas te la traînballer dès le début tu vas te la traînballer sur toutes les pages même si
elle utilisait que sur une page parce qu'en fait si tu prends react au matériel UI tu vas avoir un
provider qui va injecter la librairie dans l'application et tu vas l'avoir dans le bundle
principal tu ne l'auras pas dans les pages séparés et ça ça peut vraiment impacter énormément
le performance et du coup sur ces librairies sur ces librairies sur roda j'ai du mal à apparaître
sur ces librairies là est ce qu'on pourrait pas en fait faire ce que beaucoup de librairies font
maintenant du tri shaking où justement on va on va traînballer que ce qu'on utilise est ce que
ça ne serait pas une bonne pratique pour prendre matériel UI ils ont déjà des conseils pour
intégrer correctement la librairie comme un peu l'audage tu sais l'audage quand tu veux quand tu
veux utiliser juste un élément tu ne vas pas faire un un un un un un un un un un un un un
tu vas faire le slash avec le nombre de la propriété sur matériel UI c'est exactement la même
chose tu vas faire un slash bouton bouton ou autre comme ça pour utiliser que le bouton n'est pas tout
sauf que matériel UI il a pour utiliser le bouton tu as une librairie core etc qui va devoir
utiliser et c'est ça qui est lourd en fait c'est cette partie là qui est lourde mais ça on ne peut
pas le se séparer on ne peut pas l'améliorer donc attention en fait si j'ai envie d'y
pour faire juste trois boutons et un tableau ou juste je sais pas quoi dire enfin tu sais une
f a q avec des boules il y a des éléments franchement qui sont tellement simples à faire à la
mano que d'aller une librairie de aussi lourde pour ça c'est quand même vraiment dommage
mais bon chacun fait ses propres choix ok et du coup pour optimiser son son first input d'yla donc
bah code splitting triché king d'accord et qu'est ce qu'on peut faire encore pour améliorer
et ben éviter de te ramballer du js qui sert à rien donc là je parle en dehors des web apps
bah tout ce qui est ou presque tout ça éviter de se balader du code si on peut séparer les
codes et les utiliser uniquement sur les pages où c'est nécessaire enfin c'est ça en fait utiliser
le code js uniquement où c'est nécessaire et le css par et tout ce qui est défaut à sink tout ça
si c'est pas nécessaire c'est ça serait aussi des bonnes pratiques ou pas ouais c'est tellement
des bonnes ça c'était totalement des bonnes pratiques ça fait partie et bah alors on va
passer au dernier au dernier dernier indicateur c'est le largest content full paint le lcp
donc c'est un des plus important c'est le plus important et alors celui là comment il marche
après tout est lié on va voir que tout est lié mais celui là il concit en fait il prend
l'élément le plus gros dans le dans le vieux port donc quand le vieux port en gros c'est ce que tu
vois à l'écran après tu as la je sais pas comment ça s'appelle la ligne la ligne en ligne de flottaison
voilà là en tout ce qu'il y a en dessous de la ligne de flottaison donc ça rentre pas dans le vieux
port il va sélectionner en fait l'élément le plus gros dans cette partie là et il va calculer le temps
qui met pour s'afficher donc c'est assez subtil alors dans la plupart du temps c'est les images
tu sais la grosse mode en ce moment sur les la plupart des sites c'est de mettre des soit
des sliders soit des héros des trucs comme ça des images donc la plupart du temps c'est une image
90% des sites c'est les images qui s'affichent en premier donc pour déjà là on peut trouver j'ai
découvert ça ce week-end on peut trouver quel quel est l'élément en fait qui s'affiche donc qui
est pris en compte pour le lcp tu vas dans le déceau de tout le sparaille tu fais la performance
là tu as la timeline qui s'affiche et dans le dans la timeline tu as le bloc lcp et tu vas et quand
tu mets ta souris dessus en fait il va t'afficher le dément qui est pris en compte pour lcp donc après
ça peut changer comme comme principal quoi voilà pour lui c'est lui qui l'a c'est cet élément là
qui l'a mesuré combien de temps il met pour s'afficher donc ça peut changer en fonction des pages
si tu as une tiens héros ou un slider sur un carousel pardon sur la home page après ça peut changer
sur un site une page donc ça peut être soit des images soit des vidéos soit du texte en gros c'est
l'élément le plus gros et en fait bah pour que cet élément là s'affiche il se passe tout ce qui
doit se passer habituellement pour charger la page donc tout ce qui est ce qu'on a dit avant tout ce
qui est javascript cs et c charger les polices etc donc tout ça ça peut ralentir en fait l'affichage
de cet élément surtout si c'est une image puisque les images sont pas prioritaires et ça
fiche généralement à la fin de tout le reste donc il ya différents il ya différentes choses à
faire en fait c'est là c'est pour ça que j'ai fait une checklist la première chose c'est d'optimiser
le serveur donc si on dit netlify tout ça généralement il n'y a pas trop problème c'est déjà fait
mais si on utilise du wordpress ou des choses comme ça ou des sites plus classiques bah ça va dire
déjà optimiser le code optimiser la base de données pour que les requêtes soient plus rapides
mettre un système de cache pour qu'il évite de faire des requêtes et à la base de données et
qui renvoie directement du cache si si ça ne change pas en fait comme wp requêtes par exemple sur
wordpress donc là tu peux déjà améliorer ta réponse du serveur parce que si déjà t'arrives
ton serveur il met longtemps à répondre tu te fais déjà défoncer rien qu'avec ça déjà donc
la première des choses c'est déjà optimiser le serveur yes ok après il ya ce qu'on a déjà
dit avant donc c'est tout ce qui est fichier js fichier css donc réduire le poids au maximum
enlever tout ce qui n'est pas utilisé pour le css si tu utilises tywin d'bats tu fais du purge css
donc tu vas te dégager après je crois que tu peux l'utiliser aussi avec autre chose non tu
peux tu peux installer purge css ouais tu peux utiliser bien sûr ouais tu peux utiliser purge
css avec la même option tu n'utilises pas voilà ouais ouais avec grosse précaution parce que ça peut
péter le site donc enfin ça m'a déjà arrivé l'avantage de tywin c'est que lui bah les classes
sont connues donc il les trouve et il sait exactement après des fois tu as des subtilités si tu as du
ça sous des choses comme ça il ya des classes qui ne peuvent pas trouver le purge donc bon bref c'est
le css faut prendre vraiment avec précaution mais dans tous les cas il ya une technique aussi que
tu connais c'est le critical css donc séparé en fait le css qui va s'afficher en premier les
éléments qui s'affichent en premier par exemple le héros le aider etc tu vas les mettre dans un
critical css qui sera dans les dans l'idéal inclus dans la page html et donc ces éléments là seront
affichés hyper rapidement et tout le reste en dessous de la ligne de flotaison tu le mets dans un
fichier qui sera différé là déjà tu tu gagnes pas mal en perte ok donc à l'intérieur à l'intérieur
de la page en fait tu vas différer en fait tu vas tu vas défaire ton css aussi ouais ouais ouais en
fait c'est pour voilà alors le il faut savoir que le gs tu peux mettre à 5 ou défaire le css tu
peux pas le faire de natif natif le css ne tu peux pas le rendre un 5 gros nous ou le déférer
donc il faut utiliser une technique gs pour le faire tu vas créer des balises c'est un code tout
simple tu crée une balise link et que tu ajoutes dans le tag aide au chargement et puis après il va
charger les css plus tard ça c'est une technique voilà javascript classique mais le css par défaut
n'est pas on peut pas le différer et en plus il est bloquant donc attention à ça ok cool ça
donc il faut aller chercher sur du css critical c'est ça ouais css critical que qui est fait par
gatsby par exemple le fait par défaut il va inclure le css dans le dans le code nox tu sais
si il le fait chez plus il le fait il me semble qu'il le fait j'ai pas l'info je ne sais pas du
tout mais il faudra aller chercher ouais mais ouais je crois qu'il le fait mais voilà c'est
juste inclure le css dans le code html du coup ça évite une requête c'est plus rapide c'est
plus chargé plus rapidement par contre voilà c'est ça c'est séparé vraiment entre ce qui
affichait et ce qui n'est pas après ça demande du boulot alors attention le critical css ça
demande beaucoup de boulot mais si c'est pris dès le début normalement ça marche bien c'est dans
le flow ouais c'est dans le flow donc ça tout ça donc tous les css js ensuite les polices alors
la grosse mode depuis quelques années c'est de mettre plusieurs polices de caractère etc
machin attention puisque la police de caractère c'est ça ça pèse un certain poids et tu sais
on a le le foot et le foite comment s'appelle c'est le le le le le foot par exemple c'est le
c'est le moment où tu as ton texte il s'affiche en blanc et après il charge le police il va afficher
le texte tu n'as jamais ça oui tu vois ce que c'est il ya deux il ya deux phénomènes il ya deux étapes
en fait ouais il ya deux étapes et donc ça il faut essayer de le limiter au maximum puisque du coup
c'est le texte affiches pas déjà c'est désagréable quand tu visites un site que le texte s'affiche
pas et ça affiche après donc il ya une technique c'est d'utiliser fonds display swap donc ça
quand tu inclus des polices tu mets du swap donc ce qui fait qu'est tu mets un fallback et si par
exemple tu utilises comment s'appelle robotot imaginant tu me fais utiliser pour robotot tu ne
vas pas faire un fonds familie robotot tu vas mettre un fonds familie robotot virgule le vética
etc donc le fallback ça sera ça sera tout ce qui est derrière en fait les polices par défaut du
système tu vois et ce qui se passe en fait c'est que fonds display swap il va par défaut afficher
en fait ça dépend les navigateurs mais dans tous les cas il va afficher le texte donc par exemple
avec élética et une fois que robotot sera chargé il va remplacer la police tu vois donc t'auras
quand même ton texte qui sera affiché et voilà je vois bien donc il ya ces techniques là après ça
c'est aussi un truc désagréable après il me semble que dans sur quand on vient charger des fonds
cdn enfin depuis un cdn de google fontes par exemple je crois qu'il met le swap obligatoire
enfin pas obligatoire mais il met par défaut et donc mais c'est avec cette petite propriété en
plus dans l'url qu'on va pouvoir justement récupérer et optimiser un petit peu quoi ouais et
du coup tu vois quand tu mets swap et fallback t'as plus la police qui s'affiche en blanc
enfin t'as pas un blanc et après la police par contre un truc qui est super désagréable c'est de voir
ta police en élética et après elle change en robotot donc tu vois un changement de police ça
c'est super désagréable ça pour le pour le combattre en fait il faut mettre une sorte de il
faut mettre une balise preload en fait tu mets une preload avec la police dans le aide du coup
il va dès qu'il rentre dans la page il va charger la police et dès qu'il va rencontrer le truc il
va l'afficher enfin en fait tu réduis le temps de chargement en fait donc ça c'est pour les
polices et évidemment éviter d'utiliser cinq polices par site ou tu vois parce que c'est du bon sens
quoi ouais bah c'est du bon sens pas pour tout le monde donc ok voilà ça c'est pour les polices
et après les images évidemment la technique que tout le monde connaît c'est le c'est le système
de loading tu sais comment s'appelle déjà mais il n'y a pas du les îlots de maintenant
qu'est ça ouais tu mets l'autre dans la balise et tu mets tu mets loading égal les y c'est l'attribut
chercher les les y en fait j'ai oublié ok donc t'as le loading parce que si tu mets rien en fait il
va charger bah il va se démerder en fait quand il a eu le temps de charger l'image il va l'afficher
mais il va quand même l'afficher si elle est pas à l'écran si elle est tout en bas de ta page si tu
mets pas un loading les y il va l'afficher en fait il va la charger il va l'afficher si tu mets
un loading les y il va l'afficher uniquement quand elle sera visible à l'écran quand tu vas
scroller que tu vas arriver en bas de ta page il va la charger donc ça c'est super important parce
que ça veut dire si tu arrives sur une page où il y a plein d'images t'as pas forcément besoin de
les charger toutes au chargement tu tu vas les charger au fur et à mesure donc le loading égal les
y c'est hyper important ça réduit vraiment le le poids le poids de chargement quoi en fait de la page
le total et il y a aussi nous alors que tu viens réhydraté ouais la page au fur et à mesure
quoi voilà c'est ça en fait c'est en plus si tu en plus c'est tellement logique parce que ça
n'a rien d'utiliser fin de charger des images qui seront même peut-être même pas vues parce que
ça se trouve tu vas pas scroller jusqu'en bas tu vas cliquer sur un article par exemple et du
coup tu auras chargé une image qui est ce que tu verras jamais en fait c'est donc c'est un peu
c'est un peu con quoi il y a aussi un loading ailleurs en si qui en paramètres qui existent ça c'est
pour le rendre en priorité en fait cette image donc ça c'est j'ai testé ça peut être utile pour le
justement l'image qui est en premier en héros là que tu as en premier j'ai testé le loading ailleurs
pour voir si parce que du coup ça l'a un peu en priorité et ça j'ai l'impression que ça a fait
gagner un petit peu de temps sur le chargement pour justement pour ce premier élément qui est
qui est qui est testé le lcp ensuite en fait là sur les images c'est tellement logique donc on
a le loading on a le réduire le poids des images en gros cas classique j'ai des images sur mon site
qui font 900 de large mais la personne qui a géré le contenu a mis une bonne bonne image en 3
mille pixels de large avec 4 gigas de poids ben en gros tu défonces tout quoi donc là il te tuer la page
en gros c'est ouais réduire le poids des images par un script automatique tout ça au niveau du
déploiement mettre la bonne taille d'image donc ça sert à rien de si ta page si ton image tu sais
qu'elle va s'afficher à 900 ça sert à rien de mettre des images en 1800 de large est ce que
utiliser des des sourcettes c'est bien selon le viewport c'est là ça c'est une très très bonne
pratique mais ça rejoint ce que je te dis c'est faut limiter en fait le nombre de tailles les src
et src 7 là les sourcettes et si tu t'arrêtes si ta si ton image fait 900 de large au plus bah tu
t'arrêtes à 900 tu ne vas pas charger des 1800 tout ça ça rien d'aller d'extrapoler sur des
retina tout ça machin enfin bref donc limiter vraiment le format des images réduire le poids des
images ça c'est vraiment du bon sens en fait mais qui est tellement et passé et passé par des services
type clodinarié imagini qui vont en fait te te calculer automatiquement le ton le rendu de ton
image avec l'optimisation du format aussi parce qu'on n'a pas parlé de format encore mais c'est
réduire à la volée en fait les images et justement ça ça évite ce problème de personnes
qui charge des images de 3000 pixels parce que automatiquement en front ça va te la recr
resaiser et en plus clodinarié tout ça normalement il t'envoie si il calc il vérifie si le navigateur
est compatible et si c'est compatible il t'envoie une wap p par défaut donc il y a tous ces systèmes
là c'est l'idéal clairement c'est un peu un truc de feignon quoi mais c'est top quoi ouais mais
c'est tellement plus simple c'est clair on est d'accord c'est clair et et dernière chose bah c'est
les scripts tiers alors ouais je sais le fameux chatbot le fameux je sais le service marketing
il y a besoin de tout ça mais à un moment faut faut limiter quoi parce que parce que ça plombe
en fait le chargement de la page en fait c'est la plupart du tout à la plupart du temps un site
qui est long à charger ça vient des images qui sont pas optimisés et des scripts tiers qui sont
trop nombreux la plupart du temps une fois que t'as tout optimisé je me rappelle d'une discussion où le
mec il se casse les dents pour aller chercher des millis gondes sur la page et il fait il fait son taf il
passe beaucoup beaucoup de temps et à la fin le market dit bon en fait on va mettre un système de
chat en place et lui demande de charger un script tout et là il dit non mais les gars on a
passé des mois optimisé tout et là vous nous plombez quoi et ça ça est super triste mais ouais
je comprends après il y a aussi une réalité business quoi peut-être qu'il faut il faut vraiment
mettre ce script là un script tiers de de chat de de je sais pas quoi après c'est tout tout
tout vient avec un un poids quoi enfin un poids et avec des choix aussi quoi ok est-ce qu'on pète un
peu la perte mais on rajoute cette fonctionnalité là après ce qu'il n'y a pas possibilité de faire
des sortes de differ ou des choses comme ça ou en fait on vient structurer et hiérarchiser qu'est
ce qu'on affiche et en clair on lui dit bah le mon script de de chat tu le mets en dernier quand
tout est fini quoi est-ce qu'on peut faire ça ouais de toute façon il te la plupart des des services
sérieux te donne des conseils pour intégrer et oui la plupart du temps tu les insers en a5
enfin tout ce qui est voilà les balises google analytique google tags tout ça toutes ces choses
là c'est il s'est inséré en a5 mais dans tous les cas c'est pris en compte au niveau du chargement
global en fait la page même si c'est même si c'est en attente enfin c'est chargé en dernier ça
rend quand même en compte dans le chargement global de la page donc ok donc ouais alors c'est très
drôle parce que je sais pas si t'as déjà vu mais quand tu fais un test google page insight la plupart
du temps au niveau il va te dire oui il y a des fichiers statiques qui sont le cache n'est pas
assez long ou n'est pas optimisé et quand tu regardes c'est assez drôle parce que c'est souvent
google analytique en fait donc donc google dit lui même que ces fichiers sont pas assez fin bref
c'est des donc faut en gros les services tiers c'est très bien évidemment c'est nécessaire
parce que bah il y a le site souvent il y a du business derrière donc il faut il faut voilà il
faut convertir il faut mesurer il faut etc faut juste rester faut se donner des limites en fait pas
utiliser 18 et même service enfin ou 18 enfin faut faire des choix et surtout ouais première des choses
c'est de optimiser le site au maximum et après si tu rajoutes un google analytique oui ça va te
faire baisser le score mais ça va pas non plus te mettre dans le rouge par contre si déjà tu es
dans le rouge au niveau de ton site et qu'après tu mets encore des services tiers là tu es là
tu es vraiment enfin quand tu vois des sites qui arrivent en performance mobile tu as des résultats
à 30 sur 100 enfin c'est dramatique c'est à dire le site est extrêmement long en fait ça c'est
du classique hein tu tu prends n'importe quel site wordpress tu vas sur google tu t'as pas tu fais
une recherche tu prends un site wordpress la plupart du temps avec un boulder etc tu vas te retrouver
avec du 25 ou du 30 en résultats sur sur 100 sur le page spill inside donc
enfin voilà quoi après il y a moyen même si tu te dis ces techno là il y a moyen d'optimiser
quand même ou c'est c'est quand même compliqué clairement et je parle de wordpress parce que
c'est le plus bas c'est le domaine de marché tu peux avoir des sites wordpress avec de très
très bons scores vraiment mais enfin tu peux avoir des sites wordpress avec du 80 90 des résultats
sans problème si tu respectes toutes les bonnes pratiques si tu développes ton thème si tu
utilises un système de cache comme vp roquette si tu voilà tout ces jeux d'ailleurs vp roquette
tiens pour le je vais pas leur faire de la pub mais la prochaine version là qui sortait qui
vont sortir qui est en cours de déploiement il y a un système de purge qui est mis en place
automatiquement donc voilà on voit que alors vp roquette c'est français et il travaille beaucoup
sur l'optimisation des performances tout ça et d'inclure un système de purge automatique c'est
vraiment fin je trouve ça vraiment excellent donc ouais avec un wordpress tu peux avoir et à
contrario alors c'est on va casser un petit peu une légende urbaine parce qu'on voit souvent des
gens sur twitter et compagnie qui affiche ouais j'ai fait un gatsby j'ai 100 sur 100
machin et tout ça clairement enfin je sais pas si tu me tu t'es d'accord avec moi mais c'est pas parce
que tu dis du statique j'en vois beaucoup voilà c'est pas parce que tu utilises du statique de la
jam stack que ton site sera performant et ça c'est totalement faux en fait en fait tu ton site il
est rapide que si tu le rend rapide en fait peu importe la techno tu peux très bien avoir avec un site
statique tu peux très bien avoir des mauvais résultats en fait si tu viens si tu insères les
choses n'importe comment si tu utilises plein de police voilà donc c'est juste respecter les
bonnes pratiques et peu importe la techno les fondamentaux quoi tout simplement toujours
encore les fondamentaux quoi non parce que en fait ouais juste petit coup de gueule ça on fait
jamais de coup de gueule on va faire une rubrique coup de gueule je pense c'est casse le podcast
petit coup de gueule c'est qu'en ce moment à gatsby un peu la côte la côte et souvent ils sont
couplé avec des wordpress en back end et en gros ce qui se passe c'est que les gars à wordpress c'est
pas rapide alors je fais un gatsby en en front et puis là mon site il va il va défoncer en fait
non en fait non c'est faux déjà d'un wordpress peut être aussi rapide qu'un gasby et puis c'est pas
parce que tu mets un gasby en front que ton site va être rapide en fait si tu fais les mêmes conneries
qu'avec le wordpress enfin avec le thème dans la tonside sera aussi là en fait donc ouais faut un peu
casser cette l'air dans la hype aussi patrick on est dans la la et c'est bien ça ouais ouais
mais faut vraiment faut arrêter de croire que c'est automatique c'est juste ça beaucoup là juste
bah pour rappeler les outils en fait on va quand même rappeler les petits outils il y en a plein
des systèmes de test en fait pour les sites mais elle est plus commun en fait c'est déjà cette
devtools que vous avez dans un navigateur chrome firefox ou edge n'importe light house donc il est
aussi dans les devtools que vous pouvez aussi avoir en ligne via la page je sais même plus laquelle
je crois que c'est devtools non c'est pas devtools et web dev le truc ouais ouais c'est ça web dev et
aussi le cor web vital se teste aussi mais c'est pourquoi qu'ils sont en train de mixer les deux
et je crois qu'il y a aussi une cli sur sur la lighthouse comme ça tu es depuis ton terminal tu
peux aussi ouais ils ont fait une librairie ouais qui permet de calculer le page spin inside le plus
vieux là qui est toujours efficace après il y a plein d'autres sites qui permettent de mesurer les
vitesses des sites mais qui sont souvent basés sur light house gematrix tout ça et puis il y a aussi
pas oublier c'est que netlify ou versel t'as des plugins ou des versels si tu peux avoir directement
quand tu publie tu fais un déploiement il va te faire les tests en fait lighthouse tout ça au
fermure des déploiements ce qui fait que ce qu'il faut savoir c'est que l'optimisation des performances
ça se fait ça se fait vraiment petit bout par petit bout en fait tu vas essayer d'optimiser
tel truc tel truc machin et tu vas tester etc voir si ça marche et ces systèmes de déploiement avec
le système la lighthouse en fait c'est vachement pratique parce que à chaque déploiement tu auras
ton résultat et tu vas voir s'il y a un impact ou quoi en fait donc ça c'est c'est en fait de
manière incrémentale tu vas voir si tu dégrade ou si tu optimises ta perte au fur et à mesure de
tes déploiements ouais exactement ouais donc ça c'est super pratique pour justement optimiser
ses petits trucs mal donc ça c'est pas mal voilà je crois que on a fait un peu près le tour donc
ouais je rappelle juste donc c'est trois trois indicateurs largeus content full paint c'est le
first input délai et le cumulative layout shift c'est ces trois indicateurs qui seront pris en
compte donc normalement mes joints on sait pas exactement ce que google c'est un peu comme
il veut et après il y a plein plein de vidéos il y a plein d'articles le site web dev là que tu dis
il est vraiment bien fait ils expliquent tout correctement il y a des vidéos tout donc faut pas
hésiter à tout regarder puis c'est hyper intéressant top un grand merci patrick je crois
qu'on a fait un épisode assez technique c'est que là tu as bien creusé le sujet et tout donc
c'est c'est super intéressant merci à vous si vous êtes encore à la fin de cet épisode là pensez
à nous mettre un petit pouce un petit commentaire parler du podcast à vos collègues ça fait
toujours plaisir ouais et un grand merci à tous et on vous dit à bientôt ciao ciao
pas trouvé double slash sur le plateforme de podcast préféré et sur le site internet
podcast 3w pour un plage tiré podcast sur le site de la première épisode des références
évoquées durant les missions
Episode suivant:
Les infos glanées
DoubleSlashPodcast
Double Slash, un podcast sur le développement web. Retrouvez-nous régulièrement pour parler de sujets variés tels que la JAMStack, l’accessibilité, l’écoconception, React.js, Vue.js, Next.js, Nuxt.js, le CSS et des retours d’expériences sur des implémentations.
Tags
Card title
[{'term': 'Technology', 'label': None, 'scheme': None}, {'term': 'Technology', 'label': None, 'scheme': 'http://www.itunes.com/'}]
Go somewhere
Un site statique de 11000 pages