Bienvenue sur Double Slash, le podcast dédié aux outils et aux techniques pour le développement
web.
Bonjour à tous, bienvenue sur ce nouvel épisode de Double Slash, épisode spécial web performance.
Donc comme d'habitude, nous sommes avec Alex.
Salut Alex.
Salut Patrick, salut tout le monde.
Et donc pour cet épisode, nous avons un invité, R1.
Bonjour R1.
Bonjour.
Voilà, donc on t'a invité parce que tu es un spécialiste au niveau de la web performance.
Moi je t'avais découvert en fait sur le World Camp à Lyon où tu as fait une présentation,
j'avais trouvé ça sympa.
Je me suis dit bah ce gars il sait quand même de quoi il parle.
Donc je me suis dit bah pour le podcast ça va être intéressant.
Et donc voilà, merci d'être venu pour parler de web performance et bah on va te laisser
te présenter en fait, nous expliquer un peu ce que tu fais dans la vie, ton background,
ton activité.
Ok, ok, ok, c'est un plaisir déjà d'être reçu ici.
C'est toujours sympa de parler des sujets qu'on aime.
Et donc moi je suis R1 voyé, je suis expert web perf au sein de l'agence web performance
que j'ai créé il y a un an et demi maintenant.
On est trois dans la société donc on est deux experts web perf et une personne qui est
chargée de gérer les planning etc.
Et avant ça, j'étais expert web perf en freelance pendant quelques années.
Et encore avant ça, j'ai fait du développement web, pas mal de WordPress mais sur des projets
très variés et encore avant ça en fait depuis, j'ai toujours bossé à mon compte, j'ai
toujours été freelance depuis que j'ai commencé à travailler après mes études.
Et en gros j'ai été éditeur de site pendant une quinzaine d'années dans différentes
thématiques, sites d'actualité, sites plus orientés bon plan et commerce etc.
Et finalement j'ai toujours eu dans ce que je faisais cette approche orientée vers la
performance avec beaucoup de questionnements techniques sur les choix des différents
outils de la stack, des serveurs etc.
Enfin vraiment toujours une approche pointue pour essayer de faire au plus performant
et au mieux pour mes utilisateurs.
Et voilà et donc je suis monté en compétence au fil des années jusqu'à finalement en
faire mon job à temps plein puisque à la base c'est vraiment une passion, la passion
pour faire les choses bien en adoptant les bons outils etc.
Donc voilà pour mon histoire.
Excellent, excellent.
Alors je te cache pas qu'en préparant l'épisode on a plein de questions, on a envie de…
Parce qu'en fait c'est un sujet qui est assez large en fait.
Parce que la web performance, ok la perte c'est important, je pense qu'aujourd'hui
on va, et à un moment donné on va aussi parler de Google ou avec ses règles qui évoluent
et la partie mobile qui est venue aussi bouger tout ça.
Est-ce que toi tu vois déjà en fait des grosses tendances sur en fait est-ce qu'on
doit faire de la perte et à quel moment on fait de la perte, est-ce qu'on le fait tout
de suite au départ, à la fin ? Parce que moi quand j'entends ton discours tu me
dis ok tu fais de la perte mais au final est-ce que c'est pas le sujet un peu de chacun
ou c'est à posteriori après qu'on fait de la perte, on fait ça au départ sur l'architecture,
comment on fait quoi ?
Alors idéalement c'est vrai que nous on intervient beaucoup finalement auprès de clients qui ont
des problématiques de performance ou en tout cas qui ont la volonté à un moment précis d'améliorer
la performance de leur site. C'est pas la bonne façon de faire en fait nous on intervient parfois
en mode pompier en fait quand c'est catastrophique, on intervient parce que la direction a décidé
que c'était le sujet important ou comme tu le disais parce que Google a mis à jour ces guidelines
et que maintenant on dit que la perte c'est hyper important etc. Pour moi c'est pas,
enfin la bonne approche en fait c'est que dans les différents corps de métier en fait la performance
soit un sujet compris je dirais pas forcément maîtrisé mais au moins compris et malheureusement
c'est pas forcément le cas, il y a des métiers d'intégrateur, des métiers de développeur,
des métiers d'administrateur système, il y a tout un tas de métiers finalement qui ont un impact
direct dont les choix techniques ont des impacts directs sur la performance et pourtant 10 ans
plus tard on fait les mêmes constats que c'est pas forcément les bons outils qui ont été choisis
et donc oui en fait il faudrait que tout le monde se forme et on apprenne un peu plus sur la
performance et finalement c'est ça qui ferait qu'on n'aurait pas besoin de revenir questionner des
stacks complètes en fait ou devenir passer des heures et des heures à faire des audits et des
implementations à faire des corrections etc pour arriver à quelque chose de même pas forcément
performant mais souvent potable en fait il y a les limites des outils on arrive souvent on peut
parler des frameworks js etc les choix techniques de base en fait font qu'on va avoir des limites et
à moins de faire une refonte complète finalement on sera bridé on sera limité par certains choix
mais est ce que c'est important au final est ce que vraiment c'est important la perte
est ce que c'est important alors j'ai envie de dire oui c'est important c'est important pour les
fin pour les utilisateurs avant tout en fait c'est une question serait qu'on parle de web
performance qui est un sujet technique en fait qui touche à des bah notamment au langage du web html
javascript css php enfin voilà tous les langages qui sont utilisés pour créer les sites mais l'impact
finalement là où c'est important c'est qu'on est plus du tout dans des considérations techniques
mais dans des conditions du x et que au final ce qu'on cherche à améliorer c'est l'expérience
de nos utilisateurs quand on a un site qui se charge rapidement pour parler du de ce qui est le
plus facilement mesurable et de ce qu'on a toujours mesuré quand on parlait de web performance
pendant longtemps on parlait de temps de chargement c'est agréable pour un utilisateur d'avoir un
site qui charge rapidement et pouvoir interagir avec dans la seconde ou dans les deux secondes qui
suivent son pic sur le lien et c'est ce qu'on cherche à atteindre dans l'idéal il y a eu beaucoup
beaucoup après ce fin on peut parler des études de cas des chiffres qui ont été remontés etc mais
on sait que l'étend de chargement notamment ont un impact sur les taux de conversion sur les sur
sur des métriques purement business purement marketing purement business etc donc il y a un
intérêt pour les éditeurs de site et quelle que soit l'activité qu'on soit dans du e-commerce
qu'on soit dans du sur un site d'édition etc quand on garde nos utilisateurs quand on leur propose
une bonne expérience et qu'on arrive à les garder captifs ben finalement ils vont plus cliquer
sur les pubs ils vont plus s'inscrire des newsletters ils vont passer plus de temps sur le site et ça
donne de la valeur au site dans tous les cas et est ce que ça sur sur du e-commerce et
excuse moi patrick et sur des sites de e-commerce est ce que t'arrives en fait à voir en fait un
espèce de pro rata c'est à dire ok tant de millisecondes gagnés c'est du chiffre de
business en plus est ce qu'on peut avoir en fait des outils métriques aussi poussés en disant ok
on a on a on a mesuré que en gagnant des millisecondes on génère plus de chiffres d'affaires est ce
qu'on peut pousser en fait à atteindre des une sorte de de de KPI en fait des unités de métriques
pour mesurer de ça et le rendre tangible pour que ça soit aussi intelligible pour la partie
business quoi et non pas tech ouais c'est une question importante et pendant longtemps c'était un
petit peu on se reposait beaucoup c'est pour ça quand j'ai parlé j'ai dit il y a des chiffres
qui existent il ya des études de cas en fait on a tendance à se reposer sur des ondis en fait oui
amazon a dit que s'ils améliorer de cent mille secondes ils ont monté leur chiffre de 3% etc
ça c'est ce qu'on a fait pendant longtemps et c'est vrai que c'est une on se base sur des données
d'autres personnes et finalement c'est dur de réimpacter ça sur un business existant avec des
chiffres qui fin voilà avec un fonctionnement qui n'est pas forcément le même etc on a maintenant
la possibilité heureusement grâce au corv by tolls et à différents outils qui ont été développés
d'avoir accès à des données terrain du real user monitoring du rum pour finalement réintégrer
les données de performance donc les métriques notamment les corv by tolls dans des outils
type google analytics etc ou dans des dashboard de spécifique via du data studio etc et on peut
mettre en parallèle maintenant les données des utilisateurs terrain donc les données réelles
avec des taux de conversion avec des paniers moyens avec des taux de rebonds etc et il ya des outils
plus en plus puissants qui permettent de faire ça je pense notamment à des gros outils qui sont
utilisés par beaucoup nous on a beaucoup de gros clients e-commerce qui font plusieurs millions de
ca par mois etc qui utilisent des outils comme content square mais il ya des outils aussi libres
qui permettent de venir via la pays javascript web by tolls de venir réintégrer ça dans
différents dashboard et là on est capable de dire bah finalement on voit que nos utilisateurs qui
ont la meilleure performance commande x pour cent plus ou moins parce qu'après justement il ya des
les chiffres sont dans la web performance les données terrain sont extrêmement complexes à analyser
et il ya très souvent des contre des contre vérité en fait dans ce qu'on va analyser en étudiant
ça et il ya un cas notamment qui est assez assez connu c'est que finalement on va se rendre
compte que nos utilisateurs qui ont la meilleure performance sont ceux qui commandent le moins par
exemple et pourquoi parce que c'est mon ex collègue Boris Shapira qui expliquait ça parce qu'en
fait nos utilisateurs qui ont la meilleure performance c'est des utilisateurs qui reviennent
sur le site donc ils sont déjà venus une première fois qui ont des ressources en cache et pour qui
donc la page va s'afficher plus rapidement et ces utilisateurs là ça va être par exemple un
utilisateur qui va venir regarder si le statut de sa commande a bougé sur son site e-commerce est
ce que tiens ben gère sur mail votre commande a été préparé etc il retourne la page elle est très
rapide à charger parce qu'il ya peu de ressources dedans il est pas sur des pages de listing produits
avec des photos etc il a déjà des ressources en cache et donc il va avoir un super lcp etc on va
dire chouette lui c'est rapide mais il va pas convertir il va pas passer de commande alors
voilà alors qu'on a l'effet inverse l'exemple inverse où on a des utilisateurs extrêmement
motivés qu'il va l'acheter un produit il va sur le site il sait qu'il veut l'acheter que le site
mette deux secondes ou dix secondes à charger si il sait qu'il veut l'acheter il est impliqué dans le
processus d'achat et il va aller jusqu'au bout quelque soit la performance il y a beaucoup de biais
il faut faire extrêmement attention au bout de la compterre des données des données terrain voilà sur
les métriques de performance ok et après je vous la rajoutez au-delà de lui x la conversion
etc il y a aussi quelque chose qui est souvent ignoré au niveau de la vitesse des sites aussi
c'est que les sites qui sont rapides sont mieux croelés par google en fait il y a plus de pages
qui sont croelés ça c'est important aussi ouais complètement bah ça c'est beaucoup plus simple
j'ai envie dire c'est l'une des premières enfin d'un point de vue si on parle souvent
des impacts de l'optimisation fin d'un site performance sur le si ça c'est le premier
impact et l'impact mécaniquement le plus simple puisque oui tendres réponses donc ttfb en baisse
égal à amélioration du fin diminution des temps de crawl par google et donc augmentation du crawl
sur le site avec bah deux effets positifs le premier c'est que google va pouvoir croeler plus de pages
donc il va pouvoir aller plus profond etc dans l'arbre essence et donc on optimise le crawl
budget et le deuxième effet qui peut être intéressant c'est qu'il va aussi repasser plus
régulièrement sur certaines pages sur les pages les plus importantes et que donc on aura des pages
plus fraîches dans l'index de google donc c'est un double intérêt voilà et là l'impact il est
vraiment ce que je disait c'est mécanique on voit les impacts dans les dans la search console
dans laquelle on a accès aux data sur le crawl de google on voit que globalement quand les temps
de réponse diminue google va aller croller plus de pages on a les deux courbes qui s'inversent
est ce que est ce que tu penses que le niveau global en fait en termes de technique je parle
en termes de performance et bas chez les développeurs en règle générale et enfin j'ai deux questions
en une est-ce que les corps web vitals que google a poussé un peu squel coca-tier en fait et a
forcé tout le monde à se mettre un petit peu à la performance ouais alors le niveau de c'est une
grande question et j'ai envie de dire malheureusement on se rend compte qu'il y a encore beaucoup beaucoup
de on va dire beaucoup de pratiques qui sont inscrites chez les développeurs et qui sont pas
remises en question en fait on ils ont leur leur propre méthode au etc leur propre façon de bosser
leurs habitudes finalement et il y en a beaucoup qui ne questionne pas ce qu'ils font en fait qui vont
à bâtiens on utilise des icônes font depuis dix ans j'utilise des icônes font on utilise tel
ou tel techno bah voilà oui je veux faire deux manipulations de manipulation de d'hommes etc
je vais mettre un jicori parce que les outils existent et que j'ai des librairies pour ça etc et
en fait on a tendance à continuer à faire ce qu'on a fait sauf que le web et les outils disponibles
ont évolué que les bonnes pratiques ont évolué aussi et que maintenant on a tu parles des corps et
battle sont à des moyens de mesurer aussi l'impact de ces de ces fonctionnement là sur la performance
et qu'on se rend compte qu'en fait il y a beaucoup de choses qu'on faisait qui sont plus du tout
pertinentes là je peux parler aussi de htp2 qui a modifié complètement par rapport à htp1.1 la
façon dont les ressources se chargent et donc la façon dont on doit procéder pour les appels
de feuilles de style de fichiers enfin voilà de javascript etc donc j'ai envie de dire quoi
qu'il en soit il y a toujours un manque de maturité de beaucoup de développeurs sur ces sujets là
parce que ils développent des sites et que la performance c'est un sujet secondaire ça rejoint
un petit peu la question que tu posais tout à l'heure à quel moment on doit se préoccuper
finalement de la web performance et finalement la réponse c'est le plus tôt et le mieux même
heureusement c'est des sujets qui sont encore absent dans beaucoup de cahiers des charges etc et
où les gens se disent ben c'est un petit peu comme l'accessibilité ils se disent après coup
oh bah tiens mince on il faut se serait bien qu'on ait un site accessible mais c'est trop tard et
donc on va les mettre un petit outil javascript qui non seulement est pas optimal dans le fonctionnement
parce qu'il n'est pas intégré au site et qui en plus un impact sur la performance etc donc
voilà c'est des sujets sur lesquels voilà toutes les équipes auraient un grand intérêt à se sensibiliser
et après oui bah vas-y vas-y continue pour le genre et j'allais dire sur la deuxième question
sur les coréas vitals oui c'est grâce à google et grâce au coréas vitals que la web performance
est devenu un sujet important pour beaucoup de monde après l'encore malheureusement c'est un sujet
qui est important qui est devenu important grâce à google pour les si o clairement qui est devenu
important aussi pour certains certains certaines directions marketing etc parce que c'est des choses
qui vont regarder dans la search console après pour les développeurs malheureusement ils sont loin
de ils sont loin de ça en fait c'est pas des on a très très rarement des développeurs qui viennent
nous dire qui regardent dans la dans la search console etc en fait on a vraiment différents
profils d'équipe qui vont aller consulter ça et qui vont qui vont finalement se rendre compte
que c'est important et c'est pas des profils de type développeur même si eux derrière on va leur
dire finalement bah regarde ce serait intéressant d'optimiser les coréas vitals parce que google
dit que dans les faits c'est pas eux qui vont prendre le sujet en main dès le départ c'est pas eux
qui sont initiateurs finalement des de cette démarche là d'améliorer la performance ok donc c'est
souvent des équipes marketing tout ça qui viennent vous consulter pour améliorer la performance
c'est pas forcément des développeurs tout ça quoi ouais c'est ça ouais finalement c'est ceux qui
sont en relation c'est les utilisateurs de la search console à qui google fait peur c'est eux
qui reçoivent les alertes attention dégradation etc alerte le lcp c'est dégradé etc donc c'est
ceux qui regardent les signaux web essentiels et le volet page expérience qui vont qui vont
aller discuter avec les autres équipes en disant il y a quelque chose qui va pas sur notre site
ok et toi tu donc du coup tu préconises des choses est est ce que c'est bien reçu par les
développeurs derrière ce que c'est super bien reçu par les développeurs en fait on a deux de façon
d'intervenir auprès des entreprises avec l'agence web performance soit on fait des audits donc on
analyse de fond on analyse vraiment l'intégralité du site avec des checklist qu'on a sur des
énormément de points il ya énormément de points de contrôle et on rédige un livrable qu'on
présente aux équipes et donc là ils sont toujours super intéressés ça a été très très rare qu'on
ait des développeurs qui le prennent mal on a souvent au début un petit peu d'appréhension
un petit peu de des gens un petit peu en retrait un petit peu en recul en se disant qu'est-ce qu'ils
vont nous dire c'est pas cool ils sont là pour pour remettre en question ce qu'on a fait pour pour
critiquer etc mais finalement on se rend compte que très rapidement au bout de quelques minutes
quand ils voient qu'on maîtrise le sujet et que finalement on n'est pas là pour critiquer mais on
est plus là pour apporter des recommandations sur les la bonne façon de faire ils accueillent ça
à bras ouverts et en fait on a des discussions très intéressantes avec vraiment de l'échange oui
mais nous on fait comme ci etc et en fait derrière on voit que à la fin il nous remercie en fait
ils nous disent merci franchement j'ai appris énormément de trucs c'est quasi systématique même
avec des développeurs frontaines de seniors etc en fin de présentation d'un livrable ils nous disent
c'est génial j'ai appris tellement de trucs ça va changer ma façon de faire sur ce projet là mais
aussi sur d'autres parce que ben telle telle fonctionnalité telle api je connaissais même pas je
savais pas qu'on pouvait faire ça comme ça etc donc super intéressant et de la même façon
quand on a optimisé en fait on a aussi un livrable sauf qu'au lieu de dire bah il faut faire comme
ça on dit on a fait ça sur voilà on est intervenu sur votre on a modifié tel comportement là aussi
nous disons bah enfin voilà top on va regarder ce que vous avez fait on va regarder soit sur le
geek lab les comités etc soit aller regarder dans les fichiers ce qui a été modifié parce que
encore une fois quand on voit l'impact puisqu'on présente aussi nous dans les compte rendus on
explique ce qu'on a fait et on montre l'impact notamment sur les core et vitals entre le avant
et le après donc les gens nous disent bah oui finalement on a multiplié enfin notre lcp était
divisé par 3 on a plus de cls on a on a du blocking time qui a été divisé par 2 etc comment vous
avez fait quoi en sachant que le site est identique finalement nous quand on intervient on ne modifie
pas visuellement dit ni fonctionnellement les sites donc on a les mêmes ressources on a le même
fonctionnement mais on a juste repriorisé on a juste modifié on a optimisé etc et donc il y
en a beaucoup qui ne soupçonne pas finalement que en ayant un site visuellement identique et
fonctionnellement identique on peut avoir une telle différence de performance en même temps ça
forme c'est le bon côté de la chose aussi c'est que ça forme aussi les équipes quand ils doivent
modifier les choses et du coup ça leur apprend à la web performance finalement ouais complètement
ah oui ils montent en compétences on a des clients qu'on a accompagné et on les voit évoluer on les
accompagne sur un audit deux audits et on voit qu'après sur d'autres choses ils nous demandent
bah est ce que vous pouvez venir juste venir contrôler finalement parce qu'ils ont intégré
toutes les bonnes pratiques est ce que vous pouvez venir regarder juste prendre une heure pour
regarder si tel site qu'on vient de développer ils répondent enfin ils les performent pas et
globalement il y a des équipes qui sont capables de prendre sa main et d'intégrer les bonnes
pratiques dans leurs dans leurs outils de développement etc vrai donc ça c'est cool c'est
nous c'est ce qu'on veut c'est quand c'est comme ça c'est génial quand on voit un client qui
est autonomes sur le sujet on a gagné quoi et on va dire le gros point noir on va dire
l'erreur la plus courante que tu trouves et est ce qu'il est ce qu'il y a toujours des mêmes
patterns qui sont que tu vois partout et on va dire la grosse erreur que tu verras tu vois tout le
temps c'est quoi des grosses erreurs il y en a beaucoup malheureusement il y a beaucoup de choses
qui reviennent régulièrement je peux parler fin des des icônes fonds par exemple j'en parlais
de tout à l'heure des des polices d'icônes mais en gros quand on a un deux trois fontosomes chargés
sur le site plus plus de trois autres icônes fonds en fait on a des des sujets comme ça qui
sont très largement sous-estimés en termes d'impact sur la performance je parle des icônes fonds
par exemple les icônes fonds pourquoi c'est important parce qu'elles sont téléchargées par le
navigateur en priorité extrêmement élevée en fait parce que c'est des ressources qui sont des
fonds par défaut et que donc le navigateur estime que pour afficher la page il a besoin d'avoir les
polices d'écriture et donc elles sont téléchargées avec la priorité de la plus élevée ou une priorité
haute et en fait elles entrent en concurrence avec d'autres ressources de la page d'autres ressources
critiques notamment des images dans le viewport des feuilles de style etc et donc elles retardent
d'autant potentiellement le lcp et en fait quand les icônes fonds sont en plus beaucoup plus lourdes
souvent que les polices d'écriture textuelle et donc on va se retrouver comme ça à pénaliser
le lcp à impacter la performance avec des centaines de kilo octets d'icônes fonds alors que finalement
dans chaque icône fonds on se rend compte qu'ils utilisent deux trois icônes mais ça c'est des
choses courantes que nous on a l'habitude d'optimiser par exemple et donc et pour optimiser ça tu fais
quoi tu fais du chargement svg à la volée on fait alors ça dépend des clients soit on va
préconiser soit ils ont déjà par exemple une icône fonte custom type un icône ou une etc
donc nous on va leur on va aller réintégrer les icônes effectivement en partant de svg dans
leur icône fonte custom pour éviter de faire appel à une librairie complète une fontosome j'en
parlais c'est celui qu'on croise le plus souvent mais c'est dans chacun des fichiers il y a trois
fichiers fontosome solide brand c'est régulard dans chacun il y a entre 700 et 800 glyphes entre 700
et 800 icônes voilà donc il y en a qui charge de ça là on était sur un site hier encore d'un client
un chevron le chevron du menu chevron vers le bas donc un glyph et il chargeait derrière un
fontain fichier fontosome de 77 kilo octet 77 kilo octet de waf 2 plus le fichier css avec les les
750 classes pour chacune des icônes l'impact est majeur après j'ai envie de dire le par rapport
à la question de base j'aurais envie de repartir sur le le fondamental quand tu dis est-ce qu'un
sujet qui revient souvent c'est peut-être la sous-estimation du côté du côté serveur avec un
impact sur le ttfb ou en gros le temps de réponse serveur le ttfb c'est une métrique qui par
définition est incontournable tant qu'on n'a pas passé tant qu'on n'a pas eu une réponse de la page on
ne peut pas passer à la suite et donc elle impacte directement d'autres métriques comme le fcp le
first content full paint et le lcp le largest content full paint et en gros finalement si on a un
ttfb à une seconde 5 on sait que notre fcp sera au moins une seconde 5 et idem pour le lcp donc en
fait on a des compétitions voilà exactement et en gros on a des clients bah qui vont un peu
sous-estimer la capacité serveur nécessaire etc et ça c'est des choses qu'on signale aussi
régulièrement on a croisé des clients e-commerce qui sont sur du mutualisé ovh ou des choses comme
ça en gros dans les premières recours nous on optimise mais on leur dit bah c'est pas possible
déjà en termes de temps de réponse serveur et même en termes de techno disponible il n'y a pas de
il n'y a pas de redis il n'y a pas de fin voilà il y a beaucoup d'outils qui ne sont pas disponibles sur
des hébergements comme ça donc la recommandation tout de suite va c'est de passer sur de redimensioner
correctement l'hébergement en passant sur quelque chose de plus performant un bon petit mutualisé à
10 balles par mois c'est ça marche nickel après il y a des après c'est pas forcément une question
de coup parce que on a beaucoup de clients aussi quand on dirige il y a un hébergeur aux deux switch
qui permet d'héberger du worldpress à des coûts vraiment abordables et à la mer s'ils font des
trucs extrêmement performants donc il n'y a pas forcément besoin de payer cher il faut juste éviter
éviter les nobles et non parce que on est sur le verge on a des fin nous on a des serveurs
voilà non non mais un vps enfin à partir du moment où on sait ce qu'on met dessus on met un
place que derrière avec tout ce qu'il faut il n'y a pas de raison que ce soit pas performant
au verge ils ont les infrastructures réseaux et les serveurs qui vont bien c'est juste que
voilà c'est plus le côté mutualisé voilà mutualisé comme tu dis à 10 euros par mois ça
passe pas on peut traduire ttfb time to first bite ouais tu peux expliquer un peu ce que c'est pour
oui en gros quand on quand on visite un site quand on ouvre une page le navigateur va aller
demander au serveur au serveur de mada fiché le fin de servir quelque chose finalement de lui de
lui renvoyer quelque chose la page et en gros le ttfb le time to first bite c'est le délai entre
la demande du navigateur et le moment où le serveur renvoie la première réponse du serveur en
sachant que le time to first bite il y a l'étape de connexion pour que le serveur puisse renvoyer
quelque chose il faut que le navigateur soit connecté au serveur et donc il y a trois étapes
incompressibles elle aussi la la résolution dns où en gros on va aller finalement transformer l'url
en adresse ip pour savoir sur quel serveur on doit aller taper ensuite la connexion initiale donc la
connexion tcp et ensuite la la négociation ssl pour avoir le site en https où on va avoir les
échanges notamment sur les certificats et c'est les ces trois étapes en fait qui sont systématiquement
nécessaires avant de pouvoir afficher quoi que ce soit et globalement basse et ce ttfb est
important parce qu'il est il impacte la page en elle même quand on appelle une page on a besoin
de cette page pour savoir derrière quelles autres ressources on va devoir appeler c'est la fameuse
vue en cascade en fait je sais pas si ça para peut-être à certains mais quand on affiche les
le chargement des ressources on a ce qu'on appelle la waterfall où en gros on voit le
chargement des ressources et le time to first bite c'est sur la première ligne finalement pour notre
page en elle même combien de temps elle met pour s'afficher mais on a ce délai aussi de
connexion sur d'autres ressources et c'est pour ça aussi qu'on évite d'héberger des scripts sur
d'autres domaines parce qu'on a systématiquement besoin de s'y connecter et qu'on a des latences
de entre 500 millisecondes et une seconde systématiquement quand on appelle une ressource sur un
autre serveur ok et je reviens vas-y vas-y vas-y vas-y vas-y je rebondis j'ai je rebondis juste ce
que tu viens de dire tu dis quand on se connecte sur les ressources sur d'autres serveurs est ce
que tu préconises du cdn ou plutôt d'avoir les ressources sur son propre serveur son propre
domaine pour éviter justement des connexions annexes oui alors un cdn ça peut être bien ça peut
être une réponse à des certaines problématiques notamment de géolocalisation quand on a des
utilisateurs un peu partout dans le monde c'est un gros gros fin ça un impact majeur sur les temps
après oui du cdn ça peut être pertinent si il est configuré sur l'intégralité du domaine en
fait on a beaucoup d'outils de cdn sur des sur des images on a aussi beaucoup on croiserait
régulièrement dans les optimes qu'on fait du cdnjs.clotlark.com du cdn.bootstrap etc du tout
les les js hébergés sur des sur des cdn je peux parler aussi des google fontes qui sont hébergés
sur des cdn tout ça c'est à partir du moment c'est ce que je disais à partir du moment on a des
ressources qui sont hébergées sur un domaine tiers il va y avoir une latence supplémentaire liée à
cette connexion et c'est une latence qui est jamais qui est jamais invisible en fait on a toujours un
impact et c'est d'autant plus important si ça concerne des ressources bloquantes type des scripts
appelés en sans async ou diffère ou des feuilles de style en gros on va retarder le le fcp et le lcp
au minimum des délais de connexion et du temps de téléchargement de ce genre de cela par contre
en gros sur ces cdn là excuse moi patrick est ce que sur ces cdn t'as le droit de mettre quand
même des images parce que les images sont peut-être moins bloquantes et parce qu'en fait il y a
plein de services pour optimiser tes images où tu vas transformer tes images à la volée par
contre c'est leur service à eux donc en fait là c'est totalement détaché et c'est tiers donc
c'est vraiment un autre service par contre les images c'est moins important qu'un script ça dépend
alors tu peux le faire sur les images si ce ne sont pas des images visibles dans le viewport au
chargement initial de la page en gros ce qu'il faudrait pas c'est que ton image de lcp par exemple
si ton lcp si ton large esconte infle paint ton élément visible dans le viewport le plus gros
élément visible dans le viewport au chargement initial de la page si c'est une image il faut
que cette image soit hébergée sur le même domaine que ton que ton site en fait si elle est hébergée
ailleurs tu vas retarder ton lcp d'autant donc tu peux avoir ces outils là et d'ailleurs il recommande
eux la mise en place de d'image optimisé etc sur tout sur tout ce qui se passe under the fold
en fait dans la partie inférieure de la page et par contre sur ton image principale c'est pas souhaitable
très clairement ok voilà donc et globalement le site le site performant le site performant
optimal n'a aucune ressource sur un domaine tiers idéalement on devrait avoir toutes les ressources
les css les javascript les web fontes les images etc hébergé sur le domaine principal d'où l'intérêt
éventuellement d'avoir un cdn sur l'intégralité du domaine puisque là quand c'est comme ça c'est
idéal on espère même domaine il n'y a pas de il n'y a pas besoin de faire de de connexion à d'autres
d'autres domaines et on peut même éventuellement aller plus loin en mettant en place des proxies
sur certains scripts etc notamment les scripts de de tracking c'est des choses que nous on fait ça
voilà plutôt que d'avoir un google tag manager qui va aller taper sur un sur un domaine tiers on
peut aller mettre notre outil d'analytics directement avec un proxy etc pour qu'il soit chargé sur le
domaine principal et ça c'est optimal donc en gros si tu as que des clients tu es en france et que
client en france ça sert à rien d'avoir un cdn vaut mieux tout avoir sur son propre serveur
ou un proxy du type cloud flare qui va faire le middleware entre les deux mais alors après ça
dépend de ça dépend du ça dépend de la façon dont c'est fait non non idéalement idéalement
en fait tu as ton serveur en france tu as tes utilisateurs en france tu n'as pas besoin de cdn
si ton site a été bien conçu j'en regarde malheureusement il y a beaucoup de ce qu'on disait
beaucoup de sites qui sont développés sans considération de performance etc et c'est pour ça
qu'on a des outils de type ça des cdn performance j'ai envie de dire qui proposent à ces sites
là finalement de faire des optimisations à la volée et donc on a des clients finalement qui vont
venir mettre ce gros pensement sur leur site parce que derrière le site en lui-même n'est pas
performant et donc on va utiliser un cdn qui va venir refaire de la combinaison de la minification
de la repriorisation de script de la mise en diffère du report d'exécution javascript
du passage en local des fonte tout ce que finalement on est censé faire
quand on a quand on est une approche orientée performance à l'origine en fait ces cdn là
permettent de le faire donc là ça peut être une solution à des problématiques de performance
après après c'est pas une approche que nous on a tendance à pousser parce que toutes ces choses
là peuvent enfin pourraient être faites directement au niveau du site en lui-même et c'est un petit
dommage finalement de se reposer sur un outil tiers avec un abonnement etc finalement on devient
dépendant d'un outil pour corriger des problématiques qui pourraient être corriger à la source si les
développeurs avaient eu les fins avait eu le cahier des charges qui expliquaient qu'il fallait faire
de telle ou telle façon quoi ouais c'est un peu comme les outils d'accessibilité c'est pareil
finalement on vient mettre des dépensements derrière parce qu'on n'a pas géré à l'origine
c'est vrai qu'il y a tous les outils toutes les apis c'est ce qu'on disait quand on explique
aux équipes de dev ce qu'il est possible de faire voilà c'est juste que ces outils là ces apis
toutes ces choses qui sont disponibles nativement à la plupart du temps dans les navigateurs ne sont
pas suffisamment connues des développeurs bien t'as parlé de script au tiers gros sujet
donc c'est un gros sujet parce que souvent on se casse la tête alors quand tu fais tes
développeurs et tu connais en petit connais un peu performance tu te casses la tête pour que
ce soit performant pour que ton score il soit au top au corps va être valide tout ce que tu veux
et puis là derrière l'équipe marketing arrive et de mettre 18 scripts de le google aïti qui le
facebook pixel machin et alors là le score il descend complètement c'est j'imagine que c'est un
sujet récurrent chez toi oui oui bah ça fait partie des points on va dire compliqué à gérer avec
beaucoup de clients et là tu parles des scripts tiers mais on a aussi très souvent le cas de
figure où ne serait-ce que le tag manager en lui même donc des notamment le google manager on
en a on a on a déjà croisé 8 sur un site client voilà si si parce qu'en fait il y a
différents intervenants et chacun doit pouvoir venir charger on a voilà on a 8 google tag manager
et derrière 4 ou 5 on a un google analytics parce qu'il faut que les différentes équipes et accès
à leur analytics et derrière certains va avoir du hotjar on va avoir différents outils et
figure et targeting etc mais finalement ne serait-ce que le tag manager en lui même c'est déjà pas
il n'y a déjà pas de gestion cohérente et globale voilà donc nous on pousse les clients quand
c'est comme ça à mettre en place une forme de gouvernance autour de ce sujet là déjà on leur
explique voilà si vous pouviez recentrer tout ça autour d'un tag manager éventuellement de mais
voilà 8 c'est trop on en a beaucoup je dis 8 c'est le cas extrême mais on en a très souvent
3 4 5 voilà c'est courant ce qu'on fait nous bah par rapport à ça déjà on vient modifier
le tag en lui même puisque google tag manager fourni un code à synchrone un code à synchrone
qui vient injecter le tag dynamiquement en java script dans la page ça c'est pas du tout un
comporsement souhaité d'autant plus qu'ils expliquent de le mettre en en tête que c'est hyper
important donc nous on rebelle ça en footer et on modifie le script pour le mettre en dur avec
une balise au script et en diffère et avec un petit fait je priori t low pour le déprioriser
finalement donc en gros ce qu'on fait en faisant ça c'est que on dit explicitement en alligator de
n'exécuter ces scripts là qu'une fois que le rendu de la page a été fait ce qui est déjà une
première bonne étape pour commencer à réduire un petit peu l'impact sur le tta sur le tbt le
blocking time et sur le time to interactive puisque les scripts appelés en async en fait comme le
tag fourni par google vont venir ils sont à synchrone en téléchargement mais par contre ils
sont synchrone en exécution ça veut dire qu'ils se téléchargent en arrière-plan mais que quand
le navigateur a téléchargé la ressource il va l'exécuter dans la foulée et potentiellement il
va l'exécuter en venant interrompre le rendu de la page et donc c'est extrêmement pénalisant puisque
d'un point de vue navigateur les deux les deux opérations les plus coûteuses et les plus
consommatrices de ressources cpu c'est l'exécution des javascript et le rendu de la page et donc
si on vient si on vient voir des phases de rendu qui s'enchaînent de phases de des phases d'exécution
javascript et qu'on reprend sur du rendu etc on est sûr de venir saturer les ressources cpu disponibles
et devenir avoir des longues tasks et donc du tout et donc augmenter le total blocking time et donc
impacter le time to interactive avec derrière aussi un impact potentiellement sur d'autres métriques
d'interactivité comme l'eNP l'interaction to next paint qui va bientôt faire son entrée dans
les corvoid vitals mais voilà donc ça c'est la première étape c'est ça déjà de s'assurer
qu'on n'interrompe pas le rendu de la page mais tu vois google ils sont pas un petit peu
schizophrène sur les bords parce que d'un côté marveille te sortent les corvoid vitals il faut
décider de performance et de l'autre côté il te sorte un google ton pack manager qui donne le
pouvoir à n'importe qui de mettre n'importe quel script sur un site et patrick et patrick c'est pas
les mêmes équipes c'est pas les mêmes équipes et en fait effectivement si tu regardes ça d'un
œil google voilà tu vas dire mais c'est n'importe quoi parce qu'ils te sortent aussi google fontes
d'ailleurs c'est marrant comme ils ont changé dans les rapports tu lances un page feed insight
ou un light house au début ils te faisaient des récords attention les polices doivent être
maintenant ils ignorent totalement truc il ya des google fontes c'est pas un problème de
performance alors que nous on le voit tu passes des polices en local tu remplaces des google fontes
par des polices hébergés localement tu vas avoir un impact un impact significatif sur la performance
de tes pages donc il y a ça il ya le google tag manager il y a aussi les cdn qui permettent d'héberger
certains scripts etc enfin il ya beaucoup de beaucoup de pratique finalement côté google enfin on
peut parler des pubs aussi les tags publicitaire google qui génère du cls aujourd'hui il n'y a
aucune dans la façon dont c'est fait ils proposent notamment ils actifent par défaut pour les
les éditeurs de site qui mettent des google ads en automatique leur fameux gestion automatique
etc ils viennent insérer dans les pages des publicités aux endroits pertinents mais en poussant
les contenus en fait s'ils estiment qu'entre le sur ton contenu entre le deuxième et le troisième
paragraphe c'est l'endroit pour mettre une pub il va venir injecter la pub en javascript
dynamiquement pousser l'intégralité de la page vers le bas donc un gros layout shift derrière ça
génère du cls voilà côté google ads ils sont contents ils ont une pub bien placée côté côté
lighthouse au page pide insight on te dit ça va pas voilà donc c'est des outils que qu'on fin
qu'il ne faut pas utiliser tel quel finalement en tout cas faut avoir une une démarche derrière
complémentaire pour venir finalement pallier les les les les les manques tous tout le tout la partie
de code que google ne fournit pas etc donc on va faire on va faire par exemple sur les pubs de la
réservation d'espace via css pour éviter de venir pousser les contenus enfin voilà il y a beaucoup de
beaucoup de techniques finalement qui permettent de limiter l'impact de des différents outils google
qui impacte la performance mais est ce que on pourrait juste commencer par ok arrêter de faire du
copier coller tel quel de tous ces services là et en fait d'essayer de repenser un peu ok qu'est
ce que va faire ce service je pense à segment ou des choses comme ça qui
ou on peut en fait extraire vraiment le la compréhension ok ce service va qu'est ce qui va
faire et à quel moment je dois l'insérer dans mon script pour justement enfin dans mon site
pour éviter justement que ça vienne pénaliser sur sur sur sur la perte donc est ce qu'on pourrait
déjà commencer par éviter de faire du copier coller vite fait bien fait pour optimiser quoi
pour y de comprendre ce que fait le service oui bah c'est certain que si chacun en fait ce qu'il
faut garder en tête c'est vrai qu'il y en a beaucoup qui n'ont pas ses considérations là mais quand
on quand on gère un site chaque modification qu'on fait finalement chaque chaque ajout chaque
chaque ressource qu'on vient rajouter à un impact sur la performance et en fait si on se pose pas
systématiquement la question quel impact ça va avoir on peut rapidement arriver à ce qu'on
disait tout à l'heure à avoir plusieurs google tag manager etc en fait on devrait systématiquement
questionner en fait et c'est là la base en fait nous ce qu'on fait quand on arrive on fait un
audit etc on a d'un client on va tout questionner donc c'est sûr que ça ça ça fait un peu peur
mais ça pourrait très bien être fait au fur et à mesure et l'intérêt serait énorme en fait de
finalement nous y a des clients qu'on a accompagné comme ça je pense un très très gros compte sur
lequel on a intervenu dans un premier temps bah comme ça en mode audit en questionant tout ce
qui avait été fait mais par contre ils ont réussi à intégrer dans leur roadmap et dans les mises
en prod etc cette démarche où on finalement on se pose tiens bah on va faire on va modifier le menu
mobile on va mettre tel icon etc et derrière ils ont réussi à mettre en place cette démarche
de systématiquement questionner et si ils étaient restés dans ce qu'ils aient avant mais ils auraient
dit ok on va aller utiliser rajouter une icône fonte etc on va faire telle ou telle chose on va
venir appeler le logo et puis finalement avec le avec ce qu'ils ont appris avec le révolution côté
sensibilité sur la performance ils vont dire bah non là en fait on pourrait faire comme ça on a
tel choix tel choix tel choix et bah finalement on va mettre du svg en inline etc on va faire ça de
telle façon mais en fait ça c'est des choses qui sont pas naturelles et en fait on a très très
souvent on le voit sur les clients qu'on accompagne sur des mises en prod en fait c'est on y va comme ça
il faut faire ça ok c'est comme ça en fait on se pose pas de questions et c'est ça qui fait qu'on
c'est ça qui fait qui fait qui cause une grosse partie du problème finalement et on parlait de
scriptière on a suivi un petit peu l'évolution des workers et je sais pas si tu connais Party Town
qui vient en fait créer un worker dans ton navigateur donc une sorte de multistread en fait on
vient séparer et on vient différer les choses qui n'ont pas d'importance est-ce que toi c'est
des choses que tu as déjà utilisé tu as des recos là dessus ou qu'est ce t'en penses ?
Alors c'est un outil qui est extraordinaire sur le papier puisqu'il permet de sortir du
main thread en fait c'est vrai que tout à l'heure je parlais des choses coûteuses en termes de
ressources cpu je parlais du rendu des pages et de l'exécution des javascript en fait ce que
j'ai pas expliqué c'est que dans le navigateur malheureusement quand on consulte un site on a
accès à une à un certain volume de ressources processeur et on a un seul fil d'exécution finalement
tout tout ce qui s'exécute dans le navigateur pour un site s'exécute avec les mêmes ressources
cpu et c'est pour ça qu'on a toutes ces problématiques de blocking time etc parce qu'on est
limité en termes de ressources et donc ce que tu ce que t'expliques l'outil partitone permet
finalement de venir sortir l'exécution des javascript de cette fenêtre là pour l'exécuter
ailleurs et en fait ça permet de récupérer énormément de ressources cpu potentiellement et
donc de réduire le blocking time d'améliorer les temps de rendu etc donc super intéressant après
c'est un outil qui est encore en beta et qui est assez complexe en termes de mise en de mise en
prod de déploiement il est pas compatible avec tous les outils en fait l'idée c'est que on va
sortir des on va sortir notamment des outils d'analytiques etc mais ces outils là n'ont pas été
pensés pour fonctionner de cette façon là en fait le worker il est un petit peu isolé de son côté
c'est là où les problématiques sont compliquées c'est que les api disponibles dans le worker ne sont
pas forcément différente d'une église à l'émeu en tout cas les api les api accessible via javascript
nativement ne sont pas toutes disponibles dans le worker donc en fait il y a des il y a certains
outils qui font en sorte de se mettre en conformité finalement de s'adapter à cette nouvelle façon
de faire mais c'est pas le cas des principaux malheureusement et quand on met des google tag
manager des choses comme ça dans party town ça fonctionne pas ça fonctionne pas de façon
optimale on loupe des données etc et donc nous on l'a recommandé à certains clients qui avaient
des grosses problématiques de blocking time et on s'est rendu compte qu'en fait les scripts qui
étaient les plus générateurs de blocking time notamment les outils du xanalytics type hotjar
etc ou les outils d'abé testing type type abé testi type caméléoun etc n'était pas compatible
non plus donc en fait ça peut permettre de répondre à une partie des problématiques avec un
coût de développement quand même important avec une une montée en compétences indispensable chez les
équipes de développement parce qu'il faut se familiariser avec tout ça qui est nouveau
voilà qui est nouveau et en gros les scripts les plus problématiques ne sont pas ceux qui pourraient
potentiellement bénéficier de ces comportements là en tout cas pour l'instant donc nous on
surveille ce qui se passe côté party town et éventuellement côté du côté d'autres acteurs
qui vont travailler sur ces sur ces outils là mais c'est en tout cas ce serait une solution optimale
le jour où on est capable de faire ça d'exécuter des javascript les javascript
tiers classiques avec d'autres ressources au cpu disponible par ailleurs ce sera ce sera
optimal quoi mais on en a un j'ai travaillé dessus je l'ai intégré et puis il y a aussi des problèmes
de corps en fait ça provoque pas mal de problèmes de corps et d'objet de passer par un proxy pour
éviter les problèmes de corps et tout ça donc c'est vrai que c'est pas simple à intégrer mais
ça que son papier sur le papier c'est magique ça peut marcher un jour
ouais on a et ok là en fait on a fait un gros bilan de de de de la web perte comment on peut la
la monitorer maintenant on va dire simple développeur comment on pourrait faire pour
se pencher dessus est ce que dans le le chrome développeur tools là ou dans n'importe quel
développeur tools on n'a pas déjà des choses intéressantes tout à l'heure tu parlais de
de chargement en cascade est ce qu'on n'a pas des outils pour visualiser justement ces temps
de chargement des outils en fait on va dire accessible à tout le monde pour commencer à
se pencher sur cette démarche de web performance et l'intégrer justement le plus tôt possible
dans la construction du site quoi si bien sûr non non on a les les devtools en fait les outils
pour les développeurs dans les navigateurs que ce soit dans chrome firefox etc on a accès à
énormément d'informations et je pense notamment à chrome que nous on utilise sur lequel on a des
outils en fait google a énormément travaillé cette je veux dire cette depuis un an un an et demi
sur les outils qui proposent il ya énormément d'outils disponibles en version labs en fait des
outils d'analyse de la performance de présentation du css d'affichage des pages dans lesquels on
peut afficher en temps réel les corps et vitals on peut afficher les re-paint les reflots tout ce
qui se passe au niveau des processus de rendu on peut aussi aller analyser finement ce qui se passe
côté javascript sur les interactions en termes de layout painting compositing enfin sur les
différentes étapes etc donc ça peut être très pointu après il ya des certains outils dans les
devtools je pense notamment à l'onglet réseau qui a un super point de départ dans lequel nous on
passe beaucoup de temps en fait moi j'adore c'est un outil incroyable en gros c'est aller analyser
les différentes ressources téléchargées par la page quelle est leur priorité quelle est leur
poids quelle est leur format quelle est la politique de cache etc on a accès à toutes les informations
sur ces ressources là et à partir de là on peut déjà finalement on peut déjà isoler une bonne
partie des problématiques on va dire un gros 80% des problèmes des problématiques de performance
tout simplement en jetant un œil dans cet onglet là dans l'onglet réseau on peut déjà
identifier des problématiques et on s'était amusé à faire ça d'ailleurs en fin d'année dernière
là on avait fait des petits avec la boîte on avait fait une journée de mini audits où en gros
on avait proposé à des clients de se connecter par des prospects etc de devenir passé une demi-heure
avec nous sur leur site en attaquant par les devtools c'est en fait on arrivait comme ça sur des sites
et bien tiens voilà mon site ok et en regardant on pouvait faire déjà énormément de recommandations
juste en se basant sur cet outil là voilà donc non ça c'est un très très bel outil j'ai parlé
des fonds par exemple on peut voir notamment tiens bah j'ai des cd cd vraiment des trucs très basiques
mais j'ai des fonds en ttf qui sont chargés sur ma sur ma page en sachant que le ttf c'est un format
ancien qui est lourd etc voilà bah il faudrait idéalement qu'elle soit en waf et en waf 2 donc ça
c'est vrai voilà on peut voir des choses comme ça on peut voir des problématiques de priorisation
si on va dans l'onglet javascript de la partie réseau si on voit qu'on a un google tag manager qui est
chargé en deuxième ou troisième position et qu'on a ensuite des javascripts du site propre site
sur le domaine principal qui sont chargés on va dire bah ce serait bien que les scripts propres
sites qui sont nécessaires au fonctionnement du site en lui même soient chargés avant les
scripts tiers par exemple là on va parler de repriorisation etc donc c'est une belle porte
d'entrée pour ces problématiques là il est sur les pages mais tu as dit qu'il y avait des personnes
qui charge des fonds en ttf non mais bien sûr non mais bien sûr en ttf on a des oui non
oui mais non parce que le graphiste en fait c'est le c'est le la fameuse le non questionnement le
graphiste a fourni les maquettes il a envoyé les polices etc et finalement il a envoyé les
polices en ttf qu'il avait c'est tel ou tel police et puis bah dedans non seulement aller en ttf mais
en plus il y a tous les subsets il y a du cirilis qui a dû il y a de l'arabe 700 carot de police
exactement on va déjà croiser des fichiers je crois qu'on a eu 350 kilos au ttf voilà donc tu
la passe finalement tu fais un petit nettoyage du sub setting tu la passes en wof 2 ton fichier
fait plus que 27 kiloctets au lieu de 350 donc c'est voilà mais on fait toujours tous les jours c'est
pour ça je dis c'est basique parce que c'est c'est tristement basique j'ai envie de dire c'est on
est en fait il manque les bases en fait c'est en train de dire qu'il y a pas mal de personnes qui
ont acquis manquent juste les bases en fait c'est ça en fait ouais enfin il manque une certaine
sensibilité une certaine ouais moi je vais moi j'ai envie de dire le questionnement le fait que
je suis en train de faire et est-ce que je le fais bien c'est juste ça finalement en sachant que c'est
des choses qui font tous les jours en plus un intégrateur web si il a mis ce fichier là en ttf de
350 kiloctets il l'a fait là mais il l'a certainement fait aussi sur d'autres projets etc et il
continue à le faire donc le tout c'est de se dire bah est-ce que finalement moi c'est ça qui m'a amené
là où j'en suis aujourd'hui finalement c'est dans mon passé des diteurs en fait je me questionnais
systématiquement et quand je voulais faire quelque chose j'allais lire j'allais enfin non seulement
il y avait une veille mais j'allais lire aussi finalement tous les articles techniques de spécialistes
etc pour me dire bah finalement quelle est la meilleure façon de faire ça en fait il y a toujours c'est
ça qui est intéressant aussi dans le web il y a toujours cinq six façons de faire il n'y a pas une
façon de faire et finalement la question c'est de se dire bah quelle est la bonne façon de faire celle
qui aura le minimum d'impact sur la performance et qui en même temps nécessite pas trop de voilà
qui est pas trop complexe non plus pour que ce soit enfin pour que ça puisse être intégré dans des
process etc voilà donc là il est clairement il n'y a pas de questionnement quand c'est comme ça
quoi et ok allez on va dire que grâce au podcast les personnes vont vont on va dire
s'éveiller un peu sur la web performance ok je vais aller inspecter un petit peu mon outil réseau
néanmoins c'est quand même un outil qui est un peu barbare quand tu sais pas du tout l'utiliser
quand tu t'as des novices est ce que tu pourrais nous donner peut-être des recommandations de
formation ou des personnes à suivre justement pour accompagner cette montée en compétences à
l'utilisation de tous ces outils et ce qu'il y a des formations qui existent qui sont spécialisées
dans la web performance qui nous apprennent justement à utiliser ces outils là pour venir
faire des audits et après des recommandations et après de la mise en place de solutions
vraiment pour optimiser quoi mais on va dire commencer par le début à l'utilisation de tous
ces outils de monitoring ouais alors il y a beaucoup de beaucoup de matière c'est ce que je disais
moi déjà il y a 15 ans quand je regardais j'allais déjà suivre des spécialistes du
domaine ils étaient moins nombreux clairement on est un peu plus à s'intéresser au sujet aujourd'hui
il y a beaucoup de matière beaucoup de matière vous pouvez notamment les regarder il y a eu un
événement il n'y a pas longtemps dans lequel il y a des spécialistes qui sont exprimés le wheel
of speed qui est le seul événement français voilà qui parle de web performance et en gros il
y a des spécialistes qui s'y sont exprimés etc des gens qui peuvent enfin qui peuvent être
intéressants à suivre et il y a notamment pas mal de ces spécialistes qui sont des personnes
qui travaillent chez google sur le développement de google chrome comme c'est les gens globalement
qui travaillent sur le sur le développement des decor et vitals des dev tools de light house etc
qui sont les plus les plus compétents j'ai envie de dire aujourd'hui ce qui veut pas dire qu'il
n'y en a pas dans d'autres dans d'autres entreprises mais en gros voilà je conseillerais que ça
c'est un bon point de départ d'aller éventuellement même regarder les conférences de elles sont
disponibles en replay depuis hier je crois donc c'est un bon point de vidéo voilà pour mettre un
pied là dedans et voir un petit peu ce qui se dit ce qui se fait qui sont les acteurs après nous on
publie pas mal aussi on publie régulièrement sur linkedin et sur twitter ce qu'on appelle des
bref de webpair avec voilà deux fois par semaine des tuyaux sur voilà la bonne façon de faire
justement qu'est ce qu'il faut quels sont les mauvaises pratiques à éviter et quelle est la
façon optimale de faire et ça plaît pas mal on a des articles sur le blog aussi et après je sais
qu'il ya quelques formations il ya très très peu de formation vraiment il ya brain cracking qui fait
ça une formation de 21h sur la webpair voilà après nous on fait aussi des formations pour les
des formations un petit peu plus courtes de quelques heures justement sur vraiment les fondamentaux
de la webpair pour les équipes de dev ce qui peut être intéressant aussi avec l'approche notamment
sur la compréhension nous on se foquait on se base vraiment sur la la compréhension de ce qui se
passe côté navigateur en fait comprendre toutes les étapes du rendu d'une page toutes les étapes
côté réseau etc en gros qu'est ce qui est en jeu quels sont les mécanismes en jeu quand on affiche
une page et par conséquence on comprend en fait c'est en venir à finalement l'intérêt de mettre en
place telle ou telle pratique et son impact sur le navigateur les fondamentaux quoi bien comprendre
les fondamentaux pour justement pouvoir analyser et comprendre tous les indicateurs les lcp les
first time beat et tout ça pour si on n'a pas compris le mécanisme de de chargement d'une page
on peut pas optimiser tout ça ok excellent ça on explique notamment en fait le point de départ
c'est vraiment en fait toutes les problématiques de performance qu'on a c'est lié au navigateur et
c'est lié au c'est lié à l'informatique finalement c'est le c'est l'outil qu'on utilise est ce qu'on
explique notamment c'est que ces problématiques de performance on les a pour deux raisons pour des
raisons de limites fin de raison finalement de les limites physiques liée à la connexion réseau
le débit et la latence et pour des problématiques aussi de ressources cpu disponibles parce qu'on
est sur tel ou tel appareil qu'il ya des ressources limitées et finalement si on était dans un monde
où on avait des ressources cpu illimité et des ressources réseau illimité on n'aurait aucun
problème de performance tout serait instantané etc voilà donc et c'est comprendre finalement comment
comment ça s'articule et comment ça vient impacter finalement la façon dont on doit concevoir des
sites web et est ce que tu tu interviens aussi dans des formations de reconversion développeur
enfin toutes ces nouvelles écoles qui se montent pour former les champs au développement tu fais des interventions
non on fait pas ça j'ai pas eu l'occasion de le faire non après c'est vrai que le
finalement ce qu'on fait beaucoup c'est vraiment ce que je disais dans les dans les compte rendus
où on va passer très souvent une heure et demi deux heures avec les devs et où on les sensibilise
bah sur le là où c'est intéressant c'est que c'est sur ce que eux ont fait sur ce que eux ont
déployé etc et qu'ils voient des choses donc concrètes et on a des développeurs comme ça ce
que je disais qui vraiment c'est une première étape en fait ça va finalement ils vont se dire
ah bah tiens ils ont le déclic en se disant bah oui je peux remettre aux questions il y a d'autres
façons de faire et on en a comme ça je disais qui a qui ont intégré ça dans leur process et
beaucoup finalement c'est un petit déclic et au fur et à mesure comme ça on a des équipes de
plus en plus impliquées dans la en tout cas de plus en plus qui questionne de plus en plus tout ce
qui font côté performance ok par contre c'est si par contre moi patrick moi je pense que moi je peux
répondre ce que je suis intervenu plusieurs fois dans ces formations là et je peux te dire que
c'est la performance c'est le dernier qui a des soucis alors tu pourrais dire tu pourrais dire c'est
bien c'est pas bien après il faut aussi se remettre dans le contexte de la formation c'est des
formations rapides donc ils vont souvent les personnes sont assez loin et alors je comprends
qu'il faut intégrer ce process de web performance l'intégrer le plus tôt possible dans la démarche
de développement néanmoins quand tu es en face quand tu es en face de toi des personnes qui sont
assez débutants nos vies totale ils sont pas dans ces considérations là eux déjà chargés à un
icône c'est déjà monstrueux c'est déjà cool ils ont chargé une icône dans la page donc c'est
déjà bien avant il savait même pas ce que c'était une requête donc tu le expliques que c'est
une requête et tout ça ok donc je pense que ça serait un petit peu prématuré de parler de
performance ou alors peut-être avorder à l'éveiller en disant ok aujourd'hui on fait ça par
contre c'est pas la bonne pratique parce que demain dans la vraie vie il faudra plutôt optimiser
aujourd'hui on fait mais c'est pour un gain de temps pour la facilité pour nous par contre demain
pour faire un vrai truc en prod il faudra changer mais peut-être plus éveillé par contre c'est
clair que c'est pas du tout au programme ça je te le dis mais c'est clair ils ont tellement de choses
à apprendre déjà que si on a encore des blocs mais ce qui serait intéressant c'est d'expliquer
sans parler même de web performance en fait sans vraiment sans aborder ce sujet là d'expliquer
comment fonctionne le navigateur c'est ce que je disais tout à l'heure en fait la performance
c'est juste la conséquence des limites du navigateur en fait voilà fait apprendre même en
une heure expliquer voilà comment ça marche voilà ce que fait le navigateur quand vous appelez une
page et voilà quels sont les mécanismes en jeu côté réseau côté côté processeur côté moteur
moteur d'exécution moteur de rendu et déjà quand on a compris ça on est capable derrière finalement
de c'est ça de venir question on va se poser les questions soi même finalement se dire à
bah attend bah oui mais je sais qu'il fait ça etc que ça rentre en concurrence avec telle
autre telle autre fonctionnement donc je vais peut-être éviter ça et ce serait une bonne première
voilà juste un petit petit approche et ça il ya beaucoup de développeurs qui ne savent pas en
fait ils utilisent des outils ils développent etc et je pense que le petit gap en fait il
peut il peut être là yes il ya alors vite fait mais il ya quelque chose qu'on n'a pas encore abordé
c'est les bases de données en fait est-ce que vous intervenez aussi au niveau des bases de données
pour la performance quand il manque des index etc ou l'utilisation de redis je sais que tu
préconises aussi redis pour le cache tout ça mais oui voilà oui en fait nous on est des experts
on est des experts frontaine d'avant tout donc on optimise enfin voilà on a parlé de beaucoup
de choses quand je parle du navigateur quand je dis que c'est essentiel c'est parce que c'est du
plus refronte après ça nous empêche pas quand on intervient de voir des problématiques côté
côté bac et c'est ce que je disais quand on a un client qui est hébergé qui a un e-commerce sur
voilà sur un mutualisé ovh clairement là on très rapidement on ne serait-ce qu'en faisant
l'audit on se rend compte qu'il ya des problèmes de dimensionnement évident que c'est lent etc donc
là on va déjà recommander de passer sur quelque chose de plus performant et après oui on a des
clients quand on va voir sur certaines problématiques sur certains gabarits de page etc par exemple que
sur les pages dans lesquels il ya des prix parce qu'ils sont appelés via une api etc tel micro
service par exemple un petit peu lent en termes de temps de réponse etc et donc ça impacte la
performance on va être amené à faire des recos et on a des clients qui nous donnent accès
à leurs outils à leurs outils bac type du neuralik etc sur lesquels on va pouvoir venir avoir des
informations complémentaires venir comprendre est ce qu'il ya des sloguerries est ce qu'il ya des
temps de réponse un petit peu élevée etc et ça peut nous arriver ou à faire des recos sur de la
mise en place d'index sur du nettoyage de base de données on a pas mal de clients sous wordpress
ça c'est des choses que nous on fait systématiquement d'aller en base de données faire du
nettoyage notamment dans des tables dans des tables critiques type la table des options en fait
on a des sites avec un historique important et l'un des gros inconvénients du wordpress c'est que
sur les sites anciens il va conserver des tables des champs d'options d'anciens plugins d'anciens
thèmes etc et ces champs sont chargés systématiquement avec avec chaque page c'est une requête qui
vient ciblir l'intégralité de ces éléments là et il n'y a aucun outil qui permet de nettoyer de
faire ce nettoyage là de façon automatique et donc nous ça c'est une voilà un truc qu'on fait on
va supprimer toutes les références toutes les les options des extensions et des thèmes qui ne sont
plus installés et là ça a un impact majeur sur les temps de réponse sur les temps de réponse
est ce que tu as vu aussi une tendance sur le serverless et on va dire sur maintenant le edge
c'est à dire de déporter en fait l'exécution de ce code non pas sur un un server centralisé mais
sur des des des workers sur des edges computing qu'on va faire au plus proche de l'utilisateur donc
ça veut dire aussi qu'il ya une contrainte géographique c'est à dire que vous êtes déjà
sur des gros sites qui sont répliqués un peu à l'international par contre est ce que c'est des
outils que vous allez recommander en clair est ce que ouais vous êtes aujourd'hui en fait est ce que
le marché est relativement mature pour cet outil là et la techno et deux les clients sont prêts à
entendre ok en fait il va falloir que je déporte mon code sur des serverless sur des edge function
ou des choses comme ça qui est comme ça je vais vraiment gagner en perf est ce que il ya en fait
le sujet c'est le le edge function quoi ouais alors on n'a pas encore eu l'occasion d'avoir de
clients sur des techno comme ça on a accompagné des clients sur du réact du angular js sur des
techniques de type framework avec derrière des architectures un peu complexes je parlais de micro
service etc ça on a fait par contre c'était déjà des clients très matures niveau niveau dev niveau
bac etc avec vraiment des des architectures bien conçus bien pensés et ces clients là ne sont pas
je sais pas quel serait le profil finalement des clients qui adopterait ces technologies là
aujourd'hui moi je vois que c'est déjà sur ce qu'on voit il ya déjà une certaine complexité
notamment sur les côtés équipes de dev parfois à maîtriser des technologies qui sont pas forcément
récentes enfin qui sont pas forcément les plus récentes en tout cas ça rejoint un petit peu
partitone finalement c'est des choses un petit peu sur le papier c'est top mais dans la pratique est ce
c'est production ready et ce que c'est le niveau de technicité qu'il ya derrière en fait et la
complexité qui font que pour l'utiliser en prod aujourd'hui sur un gros site avec des objectifs
derrière des objectifs concrets en termes de business etc c'est pas évident clairement ok et je
pense que ça fait encore un peu peur comme beaucoup je pense qu'il y en a qui attend enfin voilà il y
en a beaucoup qui attendent peut-être de voir ce que ça va donner comment ça va se développer
et que ce soit considéré vraiment comme mature et d'avoir éventuellement quelques gros use case
derrière pour être rassuré et est ce que par contre aujourd'hui partir sur une architecture
récente aujourd'hui je pars de scratch donc je construis mon archi met ça dans la balance en
tout cas le poser sur la table et dire est ce que c'est une archi qui peut être intéressante parce
que ça nous vient enfin ça vient supprimer ces problèmes de perf à de scale ok on n'aura pas
à gérer ça plus tard parce que l'archi est-elle que au final elle est future proof en fait on va dire
et scale ready pour utiliser plein de mots anglais mais est ce que c'est toi tu penses que c'est
intéressant de passer sur des techno pour sur ces techno là de edge et de serverless sur le prisme
ou la performance pure pour toi je suis pas convaincu on a vu ce que ça pouvait donner
ouais sur les gros frameworks dont je parlais un du réact etc on voit que ça en impact
enfin c'est des outils qui sont complexes et la complexité fait que bien souvent les développeurs vont
avoir d'autres enfin d'autres priorités finalement d'autres priorités de s'assurer que le taux de
en gros de après la performance malheureusement c'est des problématiques qui passent après je pense
que déjà quand une architecture comme ça qu'elle tient comme tu dis qu'elle est escalable que c'est
déjà quelque chose de beau après de là elle est monitorée la performance pour voir si c'est
enfin voilà si c'est stable dans le temps en termes de temps de réponse etc je suis pas sûr que
ce soit quelque chose qui soit qui soit réalisable facilement ok voilà sur ces problématiques là
par contre on a des clients qui passent en micro service avec du docker du kubernetes des choses
comme ça derrière et ça c'est plus l'approche aujourd'hui voilà avec avec du monitoring côté
bac voilà sur les sur les donc moi ça me semble déjà être une bonne fin une bonne première
approche qui est elle et enfin c'est aussi pas mal évolutif c'est voilà ça répond à une partie
des problématiques que t'évoquer pour adopter des technos là plus moderne quoi yes voilà
peut-être une dernière question alexe qu'est-ce qu'on pense après on finit là dessus je rebondis
parce que tu parles de réacte tout ça angulaire est-ce que tu penses que ces dernières années on
n'a pas un petit peu fait des sites avec les mauvaises technos on a peut-être un peu trop de javascript
tout ça la hype la h est-ce qu'on a pas un peu trop suivi la hype pour certains sites alors que
des sites plus simples étaient largement suffisants des technos classiques type php des choses comme
ça ou du ruby c'est certain on a sorti l'artillerie lourde clairement il ya beaucoup de sites qui sont
conçus autour de technos alors c'est beau en tant que développeur c'est enfin voilà il y a un côté
accomplissement on fait des trucs incroyables avec du javascript on génère enfin voilà on génère ça
voler on fait du spa on fait en termes de performance c'est malheureusement la plupart du temps
dont on est intervenu sur beaucoup de sites comme ça et la plupart des sites qu'on audite sur des
technos comme ça présente d'importants problématiques de performance et là où c'est là où c'est
triste j'ai envie de dire c'est que on a non seulement les problématiques frontaine qu'on connaît
habituellement du type on va retrouver des polices voilà on peut avoir des polices en ttf sur une sur
une et on en a vu et on en a vu des problématiques d'image des problématiques de très classique
vraiment pure front des problématiques de priorisation et qu'en plus on a des problématiques
complémentaires qui sont pas maîtrisées non plus notamment sur l'hydratation etc sur des sur
du du SSR sur où c'est pas fait comme il faut et où finalement on va avoir par exemple une page
avec du SSR et on va l'envoyer en front et il va y avoir une réhydration derrière en fait finalement
on va venir impacter en double le coup du javascript ou des choses comme ça parce que c'est pas
suffisamment maîtrisée donc en fait des sites comme ça il y en a qui sont bien faits clairement
mais on va dire que le niveau de complexité fait que on potentiellement on vient plus rajouter des
problématiques potentielles d'un point de vue performance bien sûr je parle que performance
on vient plus potentiellement rajouter des problématiques qu'en corriger ouais on rajoute de
complexité et on rajoute aussi un niveau de complexité sur le monitoring de la performance puisque
analyser la performance de ces sites là est beaucoup plus compliqué que sur des sites classiques
puisque sur un site comme ça le TTFB ne veut rien dire puisque de toute façon le site n'affiche
rien tant que les javascript ne sont pas téléchargés c'est beaucoup plus compliqué de calculer un
lcp etc on va naviguer d'une page à l'autre et finalement la page ne change pas on vient juste
recharger des parties donc on a beaucoup moins d'indicateurs mais c'est pas parce qu'on n'a pas
ces métriques là qui remontent côté core vitals que ça veut dire qu'elles sont bonnes donc il y a
toute cette problématique de finalement d'avoir et c'est pour ça notamment que google a fait
évoluer les core vitals encore une fois avec des indicateurs qui sont calculés tout au long
de la navigation des utilisateurs et plus seulement au chargement initial des pages je pense à l'indp
qui remplace une métrique qui à la base mesurer le temps de réactivité du javascript qu'il
mesurait mal et qu'il mesurait uniquement en chargement initial ou là on vient le mesurer
tout au long de la navigation y compris 30 secondes une minute après après le chargement et
qu'il calcule beaucoup mieux avec finalement le calcul complet combien de temps mais mon élément
à être modifié à l'écran une fois que j'ai cliqué sur tel élément d'interface voilà et donc ça
va bouger progressivement de plus en plus vers ça en fait l'idée c'est que on doit être capable
d'estimer la performance quel que soit la technologie utilisée y compris sur des aspects
ok voilà de façon après c'est un c'est un c'est une problématique les créateurs de framework
ont compris et font évoluer puisque là tous les frameworks évoluent next js 13 évolue sur
du serveur component next etc tout ça avec l'iron component enfin il y a beaucoup de choses qui
évoluent ils vont être beaucoup plus performants dans les prochaines heureusement on est on est loin
de ce que c'était au début et ça évolue très positivement les les framores plus performants
ouais la nouvelle mesure actu d'ici la c'est là il comment tu l'as bien interaction
to next paint et ça rentre en 2024 c'est ça je crois un mars 2024 ouais ouais ouais ben on
y a déjà accès c'est déjà en gros elle est déjà disponible dans les différents dans les
différents rapports terrains dans les données du premier user expérience report etc mais elle
n'est pas prise en compte dans l'algo de google voilà pour l'instant voilà pour l'instant donc elle le
sera en mars 2024 avec un délai de enfin encore une fois un délai de comme ils font souvent de
un an a priori pendant lequel elle sera prise en compte mais pas pas intégrer enfin voilà ils font
ça doucement pour pas pas bousculer tout le monde le score sera pondéré quoi ouais voilà mais en
tout cas c'est des métriques super intéressantes parce que c'est tellement plus pertinent que ce
qu'on avait jusqu'à présent le fin pour le javascript en gros nous on regardait plus du tout côté
core vitals on regardait le total blocking time qui est qui est beaucoup plus représentatif de la
réalité en termes d'exécution déjà la script voilà et donc là l'indp va avoir beaucoup de sens
et elle sera aussi beaucoup plus représentatif de la performance d'un site on verra beaucoup plus
de différence que ce qu'on voit aujourd'hui dans les données terrains sur les métriques qu'on a
ok top merci c'est c'est super intéressant après je pense que c'est un sujet qui est tellement vaste
et je pense que en une heure on peut pas tout parler de tout de évoquer le problème d'aborder des
des solutions c'est un peu un peu complexe après je pense si si on a un truc à garder c'est ouais
il faut s'éveiller sur les fondamentaux pour bien comprendre comment ça marche et d'aller explorer
la note site à travers le dev tools et on a déjà beaucoup beaucoup d'accès d'outils
et accès à ces outils qui nous permettent de monitorer et donc de mieux comprendre et donc
demain d'optimiser directement quoi exactement trop bien le maître maud c'est questionné
trop bien écoute à h1 un grand merci pour pour cet échange là c'est super intéressant donc
merci on mettra tous les liens de qu'on a pu qu'on a pu évoquer on mettra tous les liens dans
la description et et top pensez à mettre un petit pouce à discuter du podcast avec tout le monde
vous pouvez aussi nous soutenir directement sur le github de sur l'organisation github du podcast
parler du podcast à vos collègues à vos amis et un petit peu un petit pouce ça fait toujours
plaisir un grand merci à h1 un grand merci patrick à bientôt merci à très bientôt à bas
retrouver le slash sur la plateforme de podcasts préférés et sur le site internet du podcast
3w.slash-podcast.fr sur le site vous allez retrouver tous les liens d'épisode les références évoquées
durant l'émission