 Bonjour à tous, très heureux d'être présent aujourd'hui pour parler de web performance avec vous et merci à l'organisation pour faire l'opportunité d'être présent aujourd'hui pour cette conférence. Je suis Erwin Moyet, je suis le créateur de l'agence web performance qui est une petite structure qui est spécialisée dans la web performance. On ne fait que ça de l'audit, de l'optimisation, de l'accompagnement. On est trois. Avant de faire ça, j'ai été expère en web-père Freelance pendant plusieurs années et encore avant ça, j'ai un passé de développeur front-end. J'ai fait notamment beaucoup de WordPress, du thème, du plugin, etc. Je continue à contribuer régulièrement à de la traduction d'extension pour WordPress. Et je suis également titulaire d'une certification hop-quest en maîtrise de la qualité en projet web. Si vous voulez me contacter par la suite, je suis disponible sur les réseaux sociaux Twitter LinkedIn. Vous pouvez également visiter mon site, ainsi que le site de l'agence web performance sur lequel vous trouverez de nombreuses informations à propos de ce qu'on propose et également à propos de la web-père faussance large puisqu'on publie régulièrement des billets. On va commencer pour parler de la web-père faite de WordPress par un petit retour sur l'histoire de WordPress et sur les étapes importantes d'un point de vue web-père. Donc en gros, entre 2007 et 2013, il y a eu quelques mises à jour de WordPress avec une approche principalement back-end, amélioration des tendres réponses, etc. avec un travail côté requête. C'est à partir de 2013, et de l'introduction des sites responsifs et de la logique mobile first, qu'on a commencé à voir les premières briques de poser pour une logique d'amélioration de la performance, etc. Et globalement, le sujet a véritablement été pris en main à partir du lancement de Gutenberg, donc en gros 2019 à partir de ces années-là, où on a remis en question finalement la logique de la façon dont on conçoit le front. Il y a eu un impact bien sûr en termes de fer sur le back-end aussi avec davantage de JavaScript, etc. Mais globalement, Gutenberg a été un marqué un tournant pour l'amélioration, enfin dans une logique de web-père dans WordPress. Et dernière étape très importante, en 2021, la création de la performance team, où pour la première fois, côté WordPress, on s'est dit, finalement c'est un sujet qui doit être traité de façon transversale avec une équipe dédiée. Et donc là, il y a de nouveaux outils qui sont en cours de tests, en cours de mise en place, et donc il faut s'attendre à avoir au WordPress encore évolué de façon très importante sur le sujet dans les prochaines années. Ce qu'on voit également, c'est qu'il y a une partie, il y a une petite icône Core Web Vitals, qui n'est pas liée directement à la timeline, c'est un événement, c'est un facteur environnemental qui fait que finalement, le sujet a été porté aussi dans WordPress, mais comme dans l'ensemble de l'écosystème du web et de la création de sites. Puisque Google, à partir de ce moment-là, a dit, la performance est importante, non seulement d'un point de vue UX, mais également pour votre SEO. D'abord sur mobile, ensuite sur desktop, et donc le sujet a été pris en main, forcément, par l'ensemble des acteurs dans le web, dont les éditeurs de sites sous WordPress et les créateurs de plugins, de thèmes, etc. On va parler donc, j'ai parlé des Core Web Vitals, c'est donc des métriques de calcul de la performance qui sont hyper importants. On les considère aujourd'hui comme faisant référence dans le domaine. En gros, on considère que les trois métriques qui sont affichés au centre-là sont représentatives de l'expérience en termes de performance sur une page. C'est pour ça qu'on va en parler, je ne suis pas là pour présenter ça de façon poussée. L'idée, c'est simplement que vous compreniez ce que sous-entendre chacune de ces trois métriques, puisqu'on va les utiliser par la suite pour dire dans quel domaine il va y avoir des gains. Donc le LCP, globalement, c'est une représentation de la vitesse d'affichage du site. On dit combien de temps met l'élément principal visible dans ma page pour s'afficher. Donc c'est une bonne représentation, une bonne idée de la vitesse de chargement globale d'une page. Ensuite, on a le FID, qui lui est basé sur les JavaScripts exécutés sur le site, où la question c'est de se dire est-ce que mon site est suffisamment réactif, est-ce qu'il est utilisable de façon fluide et qu'il n'y a pas de saccade, etc., quand j'essaye d'interagir avec, du fait des JavaScripts qui sont chargés dans mes pages. Et c'est une problématique très courante. Et enfin, la troisième métrique, qui est complémentaire, qui mesure quelque chose de complètement différent, elle mesure les décalages visuels. Finalement, est-ce que ma page est stable visuellement quand elle se charge et quand j'interagis avec, ou est-ce que quand je scroll, finalement, j'ai des éléments qui vont bouger, qui vont décaler les autres, etc., et qui vont faire que d'un point de vue expérience utilisateur, je vais vivre quelque chose de désagréable. Et enfin, il y a une autre métrique qui est importante qu'on va utiliser également. C'est le TTFB qui métrique beaucoup plus ancienne, les temps de réponse serveurs en gros. Est-ce que mon serveur me permet de faire tourner mon site correctement et de commencer à ficher mes pages suffisamment rapidement ? Donc ça, c'est une métrique historique qui est aussi très, très importante puisque mécaniquement, elle impacte le LCP et toutes les métriques liées à la vitesse de chargement. S'il démet, s'il débute du chargement et long, forcément, toutes les métriques liées à la vitesse de chargement vont être impactées. Alors pourquoi l'approche performance est-elle importante ? On parle de WebPerf, je vois que ça intéresse beaucoup de monde. On sait que la WebPerf, c'est un impact à différents niveaux. On parle beaucoup d'expérience utilisateur. On parle également de SEO. Donc c'est les deux sujets principaux. Quand on parle de WebPerf, la plupart des gens savent qu'il y a ça derrière. Ce dont on parle moins, c'est l'aspect efficience résilience. On va créer des sites qui sont faits pour durer davantage. On parle aussi très peu de l'aspect environnemental où, en gros, on va créer des sites plus légers en améliorant leur performance, le but c'est de retirer tout ce qui n'est pas utilisé. Et finalement, derrière chacun de ces volets, il y a d'autres thématiques qui apparaissent derrière l'expérience utilisateur. On peut parler de performance marketing, avec des hausses de conversion, des baisses d'étau de rebond. On peut aller jusqu'à parler des augmentations de chiffres d'affaires, etc. Donc il y a un impact business direct. Côté SEO, on va avoir une hausse de visibilité, une amélioration du crawl, de l'indexabilité qui va conduire à une hausse de fréquentation. Côté efficience résilience, on va parler d'évolutivité en posant des bases solides, en se tournant vers des outils minimalistes. On va être capable d'avoir un site beaucoup plus évolutif. On va diminuer la tête technique, en se tournant vers des outils qui sont vraiment adaptés spécifiquement à ce qu'on veut faire. Et tout ça, ça va permettre d'améliorer la durée de vie du site sur le long terme. Et enfin, côté environnement, on peut parler de décarbonation où on va nettoyer le site, retirer tout ce qui n'est pas nécessaire avec un impact... Nous, on aime bien lancer des websites carbone sur les sites qu'on optimise en parallèle des page feed insight pour calculer les métriques et on voit qu'une optimisation de la performance a un impact majeur sur les émissions de gaz à effet de serre d'une page. Et on peut parler également des co-conceptions puisqu'on est dans cette logique de se tourner vers des outils minimalistes qui ne font que ce qu'on veut faire et d'exclure tout ce qui n'est pas nécessaire. Alors, beaucoup de monde se pose la question. On a entendu beaucoup de développeurs dire, oui, mais WordPress, c'est pas performant. OK. On a ici une courbe qui présente les sites... C'est un échantillon du Chrome User Experience Report, des données d'utilisateurs réels. On voit le révolution dans le temps et ça représente les pourcentages de sites qui ont de bons Core Web Vitals. WordPress, c'est la courbe en bleu. Ce qu'on voit, c'est qu'il est plutôt un bar. En gros, on a un peu moins de 30% des sites WordPress qui ont de bons Core Web Vitals. Et on voit qu'au-dessus, on a du Drupal, du EpiFi, du Wix, du Joomla, du PrestaShop et que globalement, sur ce panel qui est extrêmement large, qui est quand même plutôt représentatif d'une expérience globale pour l'ensemble des utilisateurs de la planète, on peut dire, WordPress n'est plutôt pas performant. Alors après, il faut faire attention à ce qu'on voit là et aux conclusions qu'on peut en tirer. Ce que ça veut dire, c'est que les sites WordPress ne sont pas performants, mais ça veut pas dire que c'est parce que WordPress n'est pas performant. Ça veut simplement dire que les utilisateurs de WordPress n'ont pas forcément mis en place ce qu'il faut et que donc ils n'ont pas forcément de sensibilité à ces problématiques-là. Ça veut pas dire que les outils n'existent pas, ça veut pas dire que WordPress ne veut pas être performant. Et pour illustrer ça, on a un second extrait ici d'un export que j'ai fait de cette même base, mais en se basant sur les 100 000 sites les plus populaires. Donc là, on était sur 100 millions de sites à la base, là, on est sur 100 000. Et là, c'est des sites avec beaucoup plus de moyens, des gros sites. Et ce qu'on voit, c'est qu'ici WordPress est beaucoup mieux. Maintenant, on arrive à 30, 35 % de sites WordPress qui ont de bons corévitals. Donc on est au-dessus, et on est aussi au-dessus des Joomla, des PrestaShop, etc., des autres CMS. Donc ce que ça ment, c'est que globalement, sur des sites qui ont les moyens, qui ont une démarche, qui ont une volonté de présenter un site performant à leurs clients, à leurs visiteurs, on peut tout à fait le faire. Il suffit simplement d'initier la démarche. Et donc maintenant, on va voir ensemble, tous les choix, tout ce qu'il faut mettre en place pour avoir un site WordPress performant. On va commencer par un volet qui ne concerne pas spécifiquement WordPress, c'est le seul. Après, on va parler beaucoup plus spécifiquement de WordPress, mais l'hébergement, qui a un impact majeur sur la performance des sites puisque WordPress est systématiquement hébergé sur des serveurs qui fonctionnent avec PHP, etc. On a besoin d'un serveur. Dans les indispensables, dans les choix qu'il faut faire, on va veiller à choisir un serveur qui a des ressources, processeurs et mémoires vives qui correspondent à ce qu'on veut faire. Donc bien dimensionner par rapport au projet. Si on a un gros projet d'un site, on se dit ben moi je vise les 10 000, 20 000 utilisateurs jour sur mon site, on va pas aller sur un mutualisé GOVH premier prix. idem côté SLA, si on veut avoir un taux de disponibilité suffisamment élevé, pour ne pas être pénalisé côté crawl, pour que nos utilisateurs aient une bonne expérience tout le temps, on va pas aller sur un serveur premier prix. On va se dire ben je vais prendre un VPS, je vais prendre éventuellement un dédié, etc. Donc c'est important de choisir quelque chose de bien dimensionné par rapport au projet et aux ambitions. Et ensuite on va pas sur un volet d'avantage paramétrage où on va faire en sorte d'activer la compression Brotli plutôt que jazip. En gros quand vos contenus sont servis depuis un serveur, ils sont pas envoyés tel quel, ils sont compressés. Ça fait très longtemps qu'on utilise jazip, mais il y a l'algorithme de compression Brotli qui est beaucoup plus performant. On parle sur les ressources qui sont téléchargées. Ce qui fait que ça va être téléchargé plus vite et que donc les pages vont se charger plus vite. Donc ça la plupart des hébergers proposent du Brotli. En option. Ensuite on va veiller à activer HTTP2 voire HTTP3 s'il est disponible. Depuis très longtemps on servait les sites en HTTP1. HTTP2 offre de nombreuses optimisations côté performance en permettant d'envoyer des entêtes de façon plus performante en permettant la parallelisation du téléchargement des ressources. Donc au lieu d'avoir les fameuses waterfall avec les ressources d'ad, façon escalier, on va avoir des waterfall avec davantage de sojans parallèles ce qui fait qu'on va accélérer le téléchargement des ressources. On va ensuite veiller à activer TLS 1.2 voire 1.3. IDEM ici, TLS c'est ce qui est utilisé pour sécuriser pour les connexions HTTPS. On va avec chaque nouvelle version de TLS il y a des améliorations sur la performance qui permettent d'accélérer les connexions SSL sur les pages en HTTPS qui sont une majorité de pages aujourd'hui et en gros il y a des gains super intéressants c'est sur le TTFP et sur le temps de réponse serveur la fameuse métrique dont je parlais tout à l'heure et enfin on va veiller à activer une version récente de PHP, idéalement la version actuelle c'est la 7.4 aujourd'hui bientôt la 8.0 globalement chaque nouvelle version de PHP permet des gains de performance généralement de quelques % on parle de 1, 2, 3 % c'est souvent pas grand chose, en revanche quelques fois il y a des gains beaucoup plus important et là je pense notamment à la 8.1 j'ai regardé un petit peu ce que ça allait pouvoir donner on parle de 47 % de gains sur les temps de réponse de WordPress pour la 8.1 à venir donc il n'est pas encore une version la version recommandée mais qui fonctionne déjà et donc globalement voilà c'est important il faut pas rester sur d'anciennes versions de PHP ça a un impact sur la performance et sur la performance dans l'administration et des pages qui ne sont pas mises en cache tout ce qui est dynamique dès qu'on fait des des cons exécutes des scripts de PHP avec des requêtes SQL on a ces problématiques là et c'est super intéressant d'améliorer la version de PHP et ensuite on peut aller encore plus loin si on a vraiment une démarche performance poussée on peut choisir de se tourner vers des serveurs web engines ou life speed plutôt qu'à pâche qui est le serveur classique qu'on trouve sur la plupart des hébergements on peut également choisir de mettre en place un cache-objet via Redis, il y a une extension pour WordPress si c'est mis en place côté serveur ça peut ça permet des gains vraiment hyper important puisqu'au lieu de faire des requêtes en base de données on va effectuer des requêtes dans la mémoire vive et donc on va stocker les options, type transciente, les options et même éventuellement des tables de poste dans la mémoire vive, avec des latences très très faibles et enfin on peut se tourner vers un CDN qui permet de répondre à beaucoup de problématiques évoquées plus haut et notamment de combler les lacunes d'un hébergement qui serait de type mutualisé pas très performant etc un CDN peut permettre d'activer Brotli, HTTP2 et TLS 1.3 en même temps je pense à Cloudflare par exemple mais il y a d'autres outils mais globalement c'est une bonne solution d'avoir un hébergement performant on va passer au volet suivant on va parler maintenant des thèmes, des plugins des patchbuilders etc et globalement il y a une démarche par rapport à tout ça c'est qu'il faut il est hyper important de ne pas multiplier j'en ai parlé dès le début, je parle de minimalisme etc le but c'est de se tourner vers un minimum d'outils, vers les outils qui font exactement ce qu'on veut et de ne pas en rajouter régulièrement et c'est une démarche qui est compliquée, c'est ce que j'explique ici parce qu'on a beaucoup beaucoup de clients qui viennent vers nous avec des sites peu performants et on se rend compte que finalement très souvent ils ont installé des extensions parce que finalement c'est la première extension qu'ils ont trouvé, ça faisait à peu près le job donc ils ont dit ok, ça répond on met besoin j'y vais et donc globalement c'est très très rare qu'on ait l'occasion l'opportunité de tester de comparer différentes solutions et je pense notamment, là je mets un petit warning on trouve en ligne quand on recherche une extension un comparatif, voilà je veux un plugin d'annuaire pour gérer un annuaire on trouve des comparatifs qui vont dire voilà les différents plugins, très très souvent c'est des choses qui n'ont aucune valeur ajoutée parce que c'est simplement des listes avec des liens d'affiliation et en fait l'idéal c'est de se faire l'idée soi-même, de tester ce qui prend du temps, ce qui est coûteux mais derrière l'impact est majeur ensuite c'est ce que je mets là, très souvent quand on n'a pas un profil de développeur on a un besoin spécifique, on va les regarder tiens, quel est le plugin qui va répondre à mon besoin en tout temps, les besoins vont s'accumuler le site va évoluer, on va se retrouver comme ça avec 20, 30, 40, 50 extensions dans notre WordPress ce qui aura un impact majeur côté perf et enfin, le côté aussi changement d'intervenant dans la vie d'un site, il est courant qu'on change d'agence, de salarié etc et globalement, ça crée une forme de dette technique puisque chacun va arriver avec ses affinités, oui moi je travaille avec ça, moi je fais du élémentor, moi je fais ça et globalement on va venir faire évoluer le site avec des nouveaux composants pour augmenter le nombre d'extensions donc globalement, l'idée c'est de, idéalement si on peut arriver à ça, c'est top entre 15 et 20 extensions dans un WordPress c'est une fourchette qui permet pour la plupart des projets d'avoir quelque chose qui correspond à ce qu'on est censé faire et qui n'aura pas d'impact majeur en termes de perf, on voit des sites avec 60, 70 extensions activées c'est vraiment énorme alors dans le choix du thème on va parler des pièges à éviter puisque je pensais que aborder le sujet de cette façon-là globalement, ce qu'on fait souvent et qu'il ne faut surtout pas faire, jamais, c'est choisir un thème pour son look en gros, on est là en train de regarder sur cette boutique de thème celui-là, il correspond bien à ce que je veux faire j'aime bien le style etc je vais le prendre, c'est une grave erreur on ne doit pas choisir un thème pour son look je vais expliquer après comment on doit choisir un thème ensuite, l'autre erreur qu'on a tendance à faire c'est choisir un thème pour ses fonctionnalités on a envie de faire quelque chose de très spécifique par exemple, moi je vais lancer un annuaire avec des listes d'hôtels dans un wordpress parce que je maîtrise bien wordpress je ne vais surtout pas aller choisir un thème annuaire parce qu'en gros je resterai bloqué avec mon thème annuaire, il sera un thème annuaire et le jour où je vais le faire évoluer, ce sera compliqué et enfin, l'autre erreur classique c'est de se tourner vers des thèmes usinagaz je les appelle comme ça, avec des centaines de toggle qui permettent de tout faire et qui finalement seront extrêmement lourds en front qui charge beaucoup de JavaScript de CSS etc donc ça c'est à éviter aussi du Havada, du n-fold etc sur theme forest c'est une démarche que je ne conseille absolument pas c'est très très compliqué à optimiser et donc la démarche performance c'est quoi ? et bien finalement c'est de se tourner vers un thème généraliste, donc qui permet qui est pas orienté vers un métier spécifique mais qui est évolutif à la fois d'un point de vue visuel on va pouvoir venir, on va parler de Gutenberg un petit peu mais on va pouvoir venir le faire évoluer assez facilement et on va pouvoir aussi le customiser avec des mécanismes de crochet c'est ce dont je parle ici l'idée c'est qu'on peut venir greffer ce qu'on veut, là où on veut on dit bah moi sur mes pages de blog je veux tel élément à tel endroit je veux pouvoir mettre mon formulaire ici et globalement ces thèmes-là permettent de faire ça donc c'est très très pratique en termes de fonctionnement on peut rajouter derrière des custom post tags des custom fields et custom taxonomie et venir se greffer là où on veut dans ces différents typologies de pages et finalement créer l'architecture de notre site comme ça qui correspond vraiment à nos besoins avec ces mécanismes de crochet on ne se rend pas prisonnier d'un système qui nous est imposé ensuite je recommande aussi fortement de se concentrer sur le répertoire officiel de WordPress et de choisir des thèmes populaires la popularité c'est quelque chose d'important parce que c'est l'assurance derrière qu'il y aura du support, des mises à jour, une documentation une communauté donc en gros on peut facilement quand on a un problème débugué on peut trouver des solutions, des portions de code etc et ça c'est hyper important pour la durée de vie comme pour la performance et enfin, la bonne logique c'est de pour tous les besoins spécifiques de se tourner vers les extensions en gros une problématique spécifique doit être adressée via une extension et pas via un thème c'est pas la solution on parle des extensions maintenant donc sur le vol des extensions pareil, il y a des pièges à éviter le principal piège commun c'est on installe plein d'extensions on en parlait tout à l'heure, 40, 50 et on regarde pas ce qui se passe en front on a des besoins, on multiplie et derrière certaines de ces extensions vont venir charger du CSS, du JavaScript, dans mes pages et ça va commencer à faire gonfler le poids des pages alors que la plupart du temps je n'aurai pas besoin de ces CSS et de ces JavaScript sur l'ensemble de mes pages là je mets l'exemple de contact Form7 qui est un plugin de contact très très utilisé, très populaire on a e-charge ce script là par exemple, 10Kg de CSS et de JavaScript sur chacune des pages du site alors que bien souvent, il n'est utilisé, le shortcode est utilisé, appelé depuis 1 page la page de contact et éventuellement quelques autres mais sur un site qui a 10 000 pages de rajouter 10Kg de ressources qui sont absolument inutiles sur l'ensemble des pages du site et ensuite l'autrologique c'est ce que j'ai expliqué tout à l'heure installer une extension pour le moindre besoin c'est absolument pas ce qu'il faut faire alors encore une fois, quand on n'est pas développeur ce n'est pas évident mais il y a très souvent des problématiques qui peuvent être adressées avec un petit bout de code voilà, ou l'avantage de votre poids c'est qu'il y a une grosse communauté on trouve beaucoup de documentation en ligne et donc la plupart du temps, si on est un minimum à l'aise on trouve le fonction.php de notre thème enfant une petite portion de code qui va permettre d'adresser une problématique ce qui nous évitera d'avoir à installer un plugin supplémentaire et donc la démarche performante là c'est la même que pour les thèmes se tourner vers des extensions populaires pour les mêmes raisons, le support, la documentation etc éviter les extensions exactement comme pour les thèmes usinagas qui font tout si on a une problématique, on va choisir l'extension qui répond le plus spécifiquement possible à notre problématique c'est bien de se dire, ah oui, si j'ai d'autres besoins je pourrais faire ça éventuellement plus tard c'est pas une bonne logique il faut aussi bler vraiment des extensions les plus légères possibles et qui ont le moins d'impact possible en front ensuite, une recommandation qui est là, je vous invite à tout suivre parce que celle-là, je pense que 95% des gens ne la font pas, c'est de lire la documentation quand on installe une extension il faut aller regarder ce qu'elle fait mais de façon, voilà, lire la doc c'est dire, ah tiens oui je l'ai prise parce qu'elle fait ça, elle fait aussi ça et ce qu'on va faire derrière après avoir lu c'est qu'on va paramétrer donc on va aller regarder les différents paramètres ce qui va permettre éventuellement de désactiver ce dont on n'a pas besoin très très souvent, il y a des extensions qui font un petit peu voilà, deux trois petites choses différentes si on a besoin que d'une fonctionnalité eh ben on va désactiver tout ce qui n'est pas nécessaire avec un impact là aussi intéressant sur la performance et enfin activer les mises à jour automatiques ou à défaut en tout cas, avoir une routine l'idée c'est de mettre à jour régulièrement ces extensions parce que, dans les extensions, il y a des améliorations de la performance régulièrement c'est une problématique qui fait partie de ce qu'on trouve dans les changelog régulièrement, voilà, on fixe des bugs etc et ça peut être des bugs à la fois côté code PHP, donc côté backend avec un impact sur les temps de génération des pages et ça peut être également des problématiques qui vont avoir un impact côté front via le JavaScript etc donc c'est important de mettre à jour ces extensions on passe à la partie constructeur de page où en gros, là, il y a d'autres d'autres pièges très très classiques qu'on croise régulièrement le plus dangereux et le plus grave de mon point de vue, c'est d'adopter un constructeur de page pour son site parce que c'est celui qui est fourni avec le thème qu'on a acheté donc ça pour moi c'est une grave erreur on doit systématiquement choisir un page builder qui est quand même l'outil qu'on va utiliser tous les jours pour créer nos contenus, ça doit être un choix ça doit être une démarche qu'on a fait en se disant voilà aujourd'hui à quoi ressemble le PSA il y a les mentors, il y a Divi, il y a Visual Composer etc moi j'ai vu que ça correspond bien à ce que je veux faire en termes de démarche etc donc c'est vers ça que je veux aller et si le thème qu'on propose est fourni avec tel page builder je ne prendrai pas ce thème parce que ce n'est pas ce que je veux faire donc ça a tendance quand je parlais d'aide technique tout à l'heure ça typiquement des clients qui se retrouvent avec un Visual Composer alors qu'ils n'aiment pas l'outil etc et qu'ils disent oui mais j'en peux plus mais j'ai 800 pages qui sont faites dessous donc je n'ai pas de choix c'est une vraie problématique c'est vraiment l'idéal ensuite, autre problématique il y a des plugins de constructeurs de pages pour les page builder je pense notamment à Elementor qui a un bel écosystème c'est catastrophique niveau perf et si on peut éviter d'installer des extensions pour les page builder ça aura un intérêt majeur dans la mesure où Elementor a fait de gros progrès par exemple sur la web perf en cindant notamment ces CSS et JavaScript mais ce n'est pas encore le cas de toutes ces extensions mais globalement si vous activez les mécanismes d'optimisation d'Elementor et que vous mettez une extension pour Elementor il profitera pas de ces mécanismes et en gros il charge aura des dizaines et des dizaines de kiloctés de CSS, de JavaScript y compris s'ils ne sont pas utilisés et enfin la troisième problématique qui elle aussi est très grave et qui rejoint un petit peu ce que je disais au début c'est de rédiger ces articles de blog avec un constructeur de pages on ne doit jamais rédiger ces articles de blog avec un constructeur de pages parce qu'on crée là aussi un passif, une dette technique ce n'est pas dit que le jour où on fait évoluer l'entreprise ou on a d'autres projets etc on veut y rester avec et globalement ça veut dire que le jour où on veut changer on se dit bah oui je vais aller vers Gutenberg maintenant parce que maintenant ça fonctionne mieux qu'avant je trouve que c'est le moment d'y aller et bah oui mais je devrais me réécrire mes 800 articles me les transférer sous Gutenberg parce qu'ils étaient dans un autre page builder donc ça c'est très problématique WordPress a tout ce qu'il faut que soit les leaders classiques ou Gutenberg pour faire de la rédaction de contenu on gère la mise en page éventuellement via les mentors mais il y a des templates et pas dans la page en elle-même et donc la démarche performance j'ai deux propositions la première que moi je préfère adopter Gutenberg qui est mature aujourd'hui je le dis officiellement on peut utiliser Gutenberg pour faire des choses même très très poussées en termes de mise en page si on a des besoins spécifiques on peut rajouter du généré de blogs que j'aime beaucoup, du spectra, du ultimate blogs etc donc tous ces outils là qui permettent d'aller encore plus loin avec l'éditeur Gutenberg mais en faisant ça on créera beaucoup moins de tête technique et beaucoup moins de passif que ce qu'on peut faire en se tournant vers des page builder comme ceux dont on a parlé plus tôt et comme d'ailleurs d'ailleurs d'IVI ou élémentaires qui est le second volet ça peut aussi être une solution mais encore une fois c'est ce que je disais tout à l'heure il faut que ce soit un choix, ça peut se justifier de dire moi je veux d'IVI avec le thème d'IVI ou je veux élémentaires avec élémentaires parce que je sais ce que je fais et que c'est un choix et que l'outil correspond bien en termes de possibilités à ce que je veux mettre en place qui fait suite à un questionnement on va passer maintenant au volet où en gros on va se demander ce qu'il est possible de mettre en place imaginons que vous venez de créer un site ou vous récupérez un site qui n'est pas forcément performant qu'est-ce qui doit être mis en place et donc cette démarche là elle est valable à la fois dans une optique d'optimisation initiale quand on vient de créer son site comme dans une optique d'optimisation à posteriori ça peut être fait à n'importe quel moment puisque là on va parler des optimisations qu'on peut mettre en place via des extensions spécialisées et donc là systématiquement vous aurez en bas une liste des extensions qui sont concernées là je vois par exemple on est sur la partie cache donc je liste quelques plugins qui permettent d'adresser la problématique du cache ah ouais d'accord ils sont coupés bon ils sont là c'est ça je les dirai à votre comme ça mais l'idée là c'est vraiment de ne pas se focaliser sur l'outil, sur l'extension elle-même et vraiment sur la démarche en gros la première optimisation qu'on met en place systématiquement un système de cache j'ai entendu qu'il y en a qui en parlaient tout à l'heure c'est connu si on veut améliorer la performance on met en place le cache pourquoi on met en place du cache l'objectif c'est de ne plus générer systématiquement à chaque affichage de la page les pages via PHP qui est un langage dynamique en gros quand on exécute une page en PHP on fait des requêtes SQL dans les bases de données et c'est coûteux ça consomme des ressources processeurs quand on met les pages en cache elle est servie dans sa version statique à l'ensemble des utilisateurs donc ça permet de réduire très fortement la consommation de ressources du serveur en gros on soulage le CPU donc le processeur et ça permet quoi donc ça permet d'accélérer non seulement pour les visiteurs qui vont avoir des pages mis en cache donc ils seront très rapides à charger mais ça permettra aussi de soulager l'administration qui reste en dynamique quand on est connecté on a des pages qui sont exécutées en PHP avec un petit peu plus de requêtes qu'en front et en gros comme le serveur respira un petit peu mieux qu'il aura moins de requêtes à la seconde on aura des pages plus performantes y compris pour en mode connecté et donc là la métrique que ça impacte c'est le TTFP, le tendre réponse serveur en gros c'est ce que j'ai expliqué les pages sont déjà générées, elles sont c'est des fichiers sur le FTP, sur le serveur et en gros via un mécanisme de via le fichier HD access la page statique au lieu de la générer dynamiquement à la volée et donc les extensions W3 total cache WEP super cache et WEP requêtes qui permettent tous les 3 d'adresser de gérer les problématiques de cache ensuite ce qu'on fait qui est un gros boulot c'est de supprimer les ressources non utilisées en gros WordPress intègre tous les mécanismes de déregistreurs de script ou de CSS en gros on va dire je désenregistre telle ressource parce que j'en ai pas besoin c'est ce qu'on fait typiquement je parlais de contacts form 7 tout à l'heure en gros c'est fichier CSS et 10Khz de CSS et de JavaScript qui sont chargés sur l'ensemble des pages de mon site moi je vais aller les désenregistrer dire je n'en veux pas je n'en veux que sur cette page là et donc on va comme ça alléger à la fois le CSS et de JavaScript je parle ici dans ce volet là aussi des web fontes qui a un vrai vrai problème en termes de web perf beaucoup de thèmes, beaucoup de patchbuilder beaucoup d'extensions tendant à charger des icons fontes du fonteau somme des fonte custom e-commune qui vont faire qu'on va se retrouver il y a d'ailleurs il y a élémenteur à son propre e-icons il y a WordPress à son propre système etc en gros on se retrouve très souvent avec des sites qui ont 3, 4 icons fontes donc là il y a aussi une question de je ne souhaite en utiliser qu'une seule j'ai suffisamment très certainement des icônes redondantes dans ces différentes libraries et donc il faut faire un choix et il faut là moi je fais très très souvent des déregistreurs sur du fonteau somme par exemple c'est classique qu'on ait un thème qui va utiliser 3 icônes une pour le menu une pour un bouton et finalement il nous charge un fonteau somme complet avec 100 en plus de 100 kilos octets de fonte en waf en waf2 etc et du css pour 2 boutons donc ça on y va aussi et enfin je parle de la suppression des ressources chargées en doublons on a aussi très très souvent 2 jQuery ou des fichiers css appelés en double notamment quand on a des thèmes enfants si on n'a pas bien vérifié les thèmes parents appelaient déjà le css du thème enfant etc donc là faut toujours aller vérifier dans les devtools donc on fait inspecter on regarde dans les outils du navigateur ce qui se passe dans la partie réseau pour les différents types de ressources le css le javascript, les webfront on regarde toujours ce qui se passe pour les extensions qu'on a utilisées ce qu'elle charge en fonte et comment ça se passe quel est l'impact sur la performance et je parle aussi de gtm très très souvent on a beaucoup beaucoup de clients qui ont décide sur lesquels ils charge 2 3 4 on a vu 5 google tag manager qui inscrit extrêmement coûteux et générateur de blocking time ok donc ça génère je parle de ça impacte le blocking time ça impacte globalement le blocking time et aussi le lcp la vitesse de chargement des pages en elle-même puisque le css quand on le charge de façon classique il est bloquant pour la page et en gros plus on réduit le poids du css plus on va permettre d'accélérer le début d'affichage de la page, le rendu etc et donc le fcp, le lcp le speed index, toutes ces métriques qui sont liés directement à la vitesse d'affichage ensuite on va passer les javascript je vais accélérer un peu sur le rythme on va passer les javascript en diffère et ou en report d'exécution donc là je pense à des outils là-bas il y a marqué WProquet qui fait ça très bien mais il y a aussi perfmator ce qu'il fait auto-optimize l'idée ici c'est que ce qu'on veut absolument c'est que notre page soit visible pour les utilisateurs donc ce qu'on va faire pour ça, on va privilégier le rendu de la page, le rendu c'est ce que fait le navigateur quand il prend votre code HTML votre code css qui les combine et qui dit voilà à quoi doit ressembler ma page et ça c'est coûteux en termes de ressources processeurs ça veut dire que c'est des mécanismes qui consomment des ressources processeurs et en gros nous on veut que ça se passe de la façon la plus rapide possible et donc pour faire ça on va dire je ne veux qu'aucun javascript vienne interrompre cette phase de rendu et donc je les passe en diffère en gros ils sont en asynchronous complets et je les exécute une fois seulement que le rendu de la page a été fait et donc ça c'est hyper important en gros aujourd'hui on ne doit plus avoir de script en async on doit avoir des scripts qui sont en diffère systématiquement et ensuite les scripts qui ne sont pas propres aussi donc je parlais de Google Tag Manager mais globalement tous les scripts qui ne sont pas directement liés à l'utilisation du site en lui même pour les menus etc on va les passer en report d'exécution ça veut dire que là non seulement on va pas les charger au départ mais en plus on va attendre que l'utilisateur commence à interagir avec la page qui bouche son curseur, qui scroll, qui clique etc pour les télécharger et pourquoi on fait ça ? parce que ça permet de réduire le blocking time au chargeur au rendu initial de la page en gros au lieu d'avoir une grosse fenêtre pendant laquelle on va exécuter tous nos fichiers javascript on va créer deux fenêtres d'exécution une première pour les scripts qui sont directement nécessaires au fonctionnement de la page je veux que mon menu puisse s'ouvrir, que mon slider s'affiche etc et on aura une seconde fenêtre d'exécution pour les scripts tiers ce qui fait qu'on va soulager le processeur dans le blocking time en gros en termes d'expérience, l'utilisateur c'est hyper intéressant et c'est pris en compte dans les Core & Bytole donc Google, dans la search console fait remonter les problématiques de ce type là ensuite on va combiner et minifier les fichiers CSS c'est hyper important pourquoi ? pour deux raisons on minifie parce que dans les fichiers CSS il y a souvent des choses qui traînent qui sont à la base faites pour les développeurs je parle des commentaires, je parle des source maps etc donc des données qui pour un utilisateur du site n'ont aucun intérêt et on va également les combiner alors c'est une recommandation sur laquelle il y a eu pas mal de choses qui ont été dites dernièrement on considère qu'avec HTTP2 qui permet la parallelisation dont je parlais tout à l'heure on n'a plus besoin aujourd'hui de combiner des JavaScripts ou des CSS je dis que c'est faux et pourquoi c'est faux ? parce que en combinant des fichiers CSS on va tirer davantage profit des algorithmes de compression jésif et broccoli on va utiliser des fichiers CSS d'un kilo octet que vous les combinez une fois jésipé ils ne feront pas dix kilo octets ils feront que 8,5 ou neuf kilo octets parce que les algorithmes de compression jésip et broccoli sont basés sur les récurrences de texte et que donc potentiellement plus vous mettez de contenu dans vos fichiers plus il y a de chance qu'il y ait des répétitions et que donc ça profite de la compression et donc là encore une fois si on réduit le poids de nos ressources CSS qu'on les combine et qu'elles sont plus légères, plus rapides à télécharger on va améliorer le FCP, le LCP, le speed index donc une nouvelle fois toutes les métriques liées au temps d'affichage de la page ensuite on va les îloder les images et les iframes et les iframes, pardon donc le les îloding des images c'est hyper important pourquoi ? pareil ça c'est une bonne pratique qui est connue l'idée c'est de ne charger que ce qui est nécessaire au rendu initial de la page en gros on veut que le visiteur il voit ce qui est dans le viewport on n'a pas besoin qu'il voit que les images en pied de page soient chargées ça permet de libérer de la bande passante pour les ressources qui sont elles nécessaires à l'affichage de la page ce qu'on veut nous on est dans un monde informatique fini ou en gros on a une certaine quantité de bande passante qui est disponible qui est variable pour chaque utilisateur mais clairement tout le monde, personne n'a une bande passante illimitée et l'idée c'est qu'on veut utiliser cette bande passante au mieux pour faire en sorte que ce qui est visible par l'utilisateur soit visible le plus tôt possible et l'autre comment ? l'autre sujet qu'on peut traiter également en les îlodant les iframes et je pense notamment à tout ce qui est en bête YouTube, Facebook etc c'est qu'on va réduire le blocking time puisque quand on télécharge quand on insère une iframe YouTube par exemple dans une page elle va télécharger et exécuter énormément de je mets la 2,5 MHz de JavaScript mais 2,5 MHz de JavaScript qui vont être exécutés et qui sont fortement générateurs de blocking time donc en mettant en place le lesiloding d'une iframe on va supprimer cette exécution de JavaScript au chargement initial et ils ne seront exécutés que plus tard quand la personne scrollera vers le bas et qui se filent à la fois sur les images comme sur les iframes on va passer les Google fontes sans local la l'idée c'est que quand on télécharge une Google fontes il y a des connexions réseaux on parle de connexions de négociations SSL, de résolution DNS de connexions initiales etc c'est des étapes réseaux qui sont coûteuses qui génèrent des latences etc donc l'idée c'est de les repasser sur notre site ce qui fait qu'on pourra profiter de la parallelisation je parle un nouveau de HTTP2 sans la tense et ça va permettre également de mettre en place d'autres optimisations notamment le préload on ne peut pas faire de préload vers une Google fontes dont l'URL de la police change selon le navigateur etc on va également pouvoir mettre en place des fonds de fallback ce qui n'est pas possible de faire quand on utilise Google fontes et enfin dernier point on va pouvoir s'affranchir de l'écosystème de Google moi personnellement je trouve ça important de pouvoir avoir un site aujourd'hui sur lequel on n'a pas de Google tag manager l'écosystème de Google et donc ça un impact majeur sur le lcp et résolution de problématique aussi liée au cumulative layout shift donc ce dont je parle au début les décalages d'interface on peut avoir des décalages d'interface liés au chargement des polices où en gros mes textes sont affichés dans un premier temps avec la police de repli de fallback et une fois que ma police est téléchargée elle vient prendre la place et elle peut occuper un espace différent ce qui fait que ça va générer des décalages à l'écran et donc là en mettant en place ces optimisations on réduit, on supprime quasiment ces problématiques de CLS liées au fond on va également précharger les ressources les plus importantes notamment les web fontes qui sont très souvent appelées via une feuille de style externe elles sont appelées trop tard donc là l'idée c'est de les précharger pour que dire au navigateur on va avoir besoin de ces ressources là et comme ça dès que le navigateur voit que dans la page il y a des zones de texte qui utilisent cette web fontes elles vont être, elles seront disponibles sans avoir besoin d'être téléchargées et ce qu'on peut faire également dans le préchargement des ressources c'est précharger l'image de l'LCP sur certaines pages l'LCP n'est pas systématiquement une image mais c'est souvent le cas quand on a une image mise en avant par exemple dans WordPress très très souvent ça va être cette image qui va être le lcp et donc on peut mettre en place un préchargement de cette ressource là et donc là avec un impact majeur également sur le lcp oui alors il y a encore pas mal de choses optimiser le poids des images je vais passer rapidement parce que je pense qu'il me reste 2 minutes on réduit le poids des images, en gros on choisit des formats adaptés jpeg pour les photos, png ou svg pour les logos on upload des images aux dimensions cohérentes si on a l'image qui est affichée en 500 pixels on n'en met pas une de 3000 pixels et on exporte les outils on exporte les images dans un format optimisé le plus léger possible on utilise éventuellement des outils pour réduire leur poids avant même la mise en ligne y compris si on a un imageify ou un plugin d'optimisation déjà sur son site c'est une bonne démarche et servir les images en web page et classique côté page feed insight on sert les images en webp avec un warning ici on ne les sert en webp que si elles sont plus légères que les images en jpeg il faut savoir que webp est un format moderne avec une meilleure compression donc on a des images plus légères mais que quelques fois les outils nous génèrent des images webp qui sont plus lourdes que les images d'origine et dans ce cas là c'est absolument pas intéressant de proposer une version alternative plus lourde d'autant plus qu'elle mettra plus de temps le webp est un format qui est plus coûteux en termes de ressources processeurs à être décodés donc ce serait doublement contre productif de faire ça et donc là je mets il doit y avoir des utilisateurs d'imageify imageify est le seul plugin qui permet aujourd'hui d'adresser cette problématique là en disant je ne génère les webp que s'ils sont plus léger que les images d'origine et donc ça c'est vraiment la bonne logique il faut faire attention générer 100% de webp pour faire du webp ça n'a aucun intérêt et donc là il y a un super intéressant sur le lcp je passe à la dernière slide oui donc globalement ce qu'il faut retenir de tout ça c'est qu'il y a un gros besoin de sensibilisation globalement toutes les personnes là aujourd'hui vous êtes très certainement dans des entreprises, dans des agences etc il est important de parler de ces sujets là autour de vous de pas simplement garder ça pour vous de mettre en place des procès des routines c'est ça qui vous permettra de vous améliorer sur le sujet pareil quand on met en place des optimisations ou quand on crée un site performant quand on pense avoir fait quelque chose d'intéressant il est important de mettre en place du monitoring derrière ça veut dire de surveiller soit via un outil soit via une routine mais globalement on laisse pas notre site vivre comme ça sans se poser de questions sur sa performance la search console peut être un très bon outil pour surveiller ça et enfin pour aller encore plus loin ce qui peut se faire ce qui se fait dans certaines entreprises c'est la création d'une équipe transverse en disant je vais prendre quelqu'un du marketing d'Eve, quelqu'un du côté Afra-Raiso et ensemble tous les mois on fera une réunion d'une heure pour dire quels sont les probléatiques de perf etc pour faire en sorte de créer une émulation et une dynamique autour de la performance un sujet très vaste très bien abordé je suppose qu'il y a des questions il n'y a pas de question pour R1 ? si j'aimerais savoir ce que vous pensez de qui installe le serveur alors ce que je pense de qui installe un très bon hébergeur globalement en termes d'hébergement si il n'y a pas de problématique vraiment qu'on ne constate pas de ralentissement etc et qui fournit la possibilité d'activer ce que je disais le minimum c'est pouvoir activer Brotli, HTTP2 TLS 1.3 globalement si il fournit cette base-là et qu'il n'y a pas de ralentissement que l'administration est navigable et qu'il n'y a pas de problématique quand on met de nombreuses pages en cache etc j'ai pas de contre-indication par rapport à des hébergeurs en particulier merci, est-ce qu'il y a d'autres questions ? n'hésitez pas ah, une question en fond j'ai une question en propos des ressources du serveur comment on peut bien dimensionner son serveur en fonction de son trafic pour la performance ok, donc on est sur des questions back-end à nouveau comment bien dimensionner son serveur ? eh ben déjà c'est ce que j'ai expliqué tout à l'heure la question à la base c'est quand on lance un site c'est d'essayer d'anticiper la présentation enfin le volume de visiteurs qu'on va avoir et globalement on se rend compte que ça va pas si ça rame ça veut dire qu'on aura mal anticipé après ce qui peut être fait pour adresser ces problématiques là c'est d'aller vers des solutions en VPS type VPS qui permettent d'augmenter la quantité de cœur-processeurs la mémoire-ville etc. donc on a le côté évolutif qui peut être super intéressant si on n'est pas certain de faire les bons choix au départ mais globalement oui, ça dépend vraiment ça dépend de la taille du projet ça dépend de ce qu'on va mettre en termes de volumes de plugins etc. ça dépend du système de cache qu'on va mettre en place derrière ça dépend du volume de la base de données ça dépend de nombreux facteurs donc c'est compliqué de dire il n'y a pas de règles qui permet facilement d'estimer le bon dimensionnement d'un émergement par rapport à un site WordPress merci pour la présentation j'avais une autre question concernant je voulais savoir s'il y avait des optimisations aussi à envisager au niveau des Ajax et du système d'Ajax proposé par WordPress comment est-ce qu'il est améliorable en fait alors oui il est améliorable après tout dépend dans quel cadre on l'utilise globalement ça crée quand on fonctionne avec de l'Ajax ça crée des latences liées au connexion réseau forcément après tout dépend de l'outil qui est derrière finalement si c'est de l'Ajax pour envoyer un formulaire c'est pas gênant quand on clique sur un bouton envoyé d'avoir une latence de 200 300ms pour envoyer un formulaire et avoir la confirmation après si on commence à mettre de l'Ajax sur un sous-menu par exemple qu'on voudrait charger dynamiquement ça peut être beaucoup plus gênant et finalement les latences font que ça va être problématique d'un point de vue expérience utilisateur voilà mais globalement pour 90% des besoins l'API reste de WordPress permet de faire de fonctionner très très bien avec du JS pour adresser des problématiques classiques après il peut y avoir des besoins vraiment plus spécifiques qui vont nécessiter de développer soi-même une couche de requête etc avec des WP query encore une fois ça dépend oui merci moi j'ai une question sur le webp parce que donc tu le recommandais comme beaucoup de gros acteurs du web d'ailleurs mais moi quand j'avais été voir sur Can I use il me semblait que c'était pas si largement supporté enfin si tous les navigateurs modernes oui mais même si on revenait sur des versions de macOS qui n'étaient pas sillées que ça il me semblait que c'était pas supporté et tout donc ma question c'est on n'y go ou... Alors webp le support c'est très très nettement amélioré depuis deux ans globalement on est à un niveau de support on doit être autour de 90% je pense sous les navigateurs actuels après on n'utilise pour l'instant pas webp seul webp doit être utilisé avec une solution de fallback vers du jpeg soit via un source set soit via une balise picture soit via htaccess etc la logique est même plutôt l'inverse aujourd'hui on parlait d'images failles etc ces plugins là finalement affichent les images le fonctionnement que moi j'utilise j'affiche les images en jpeg ou en png et via htaccess je viens vérifier donc c'est le fonctionnement standard je viens vérifier si mon image en webp c'est sur le serveur et je serre cette image en webp au navigateur qui la supporte mais dans le code source de la page finalement on a des images en jpeg ou en png avec des formats standards et ça permet d'assurer un fonctionnement idéal sous tous les navigateurs de façon complètement transparente et sans le moindre besoin de code côté template etc Super merci Erwan pour tes réponses merci à tous pour votre attention on applaudit encore une fois Erwan