Le développement de WordPress 6.2 a introduit des améliorations dans le fonctionnement de l’équipe de développement principale, ce qui a permis de mettre l’accent sur les performances à chaque étape du développement. Ces nouveaux processus détectent les problèmes au moment de l’introduction des modifications, les empêchant d’intégrer la version finale.
Les deux améliorations responsables de ce changement sont :
- Un nouveau rôle de leader de la performance pour coordonner les équipes
- Analyse comparative automatisée
Ces deux améliorations ont permis à l’équipe WordPress d’intégrer les performances dans le développement de chaque partie de WordPress, en l’ajoutant essentiellement à son ADN de développement.
Le résultats parlent d’eux-mêmes :
6.2 est la première version majeure qui améliore les performances côté serveur à tous les niveaux :
- +25 % pour les thèmes de bloc dans toutes les métriques (médiane, min, max, 75e centile).
- +10% d’amélioration pour les thèmes classiques (75e centile).
Ces résultats sont plus remarquables par rapport aux versions précédentes de la version principale.
Les versions 6.1, 6.0, 5.8 et 5.9 de WordPress ont toutes pris du retard avec des mesures de performances négatives.
Leçons apprises de WordPress 6.1
La version précédente de WordPress, la version 6.1, était marquée par une baisse globale des performances, ce que WordPress appelle des régressions de performances.
Une régression des performances se produit lorsqu’une amélioration entraîne une diminution des performances.
Ce qu’ils ont découvert, c’est que même s’ils ont corrigé la principale cause de régression des performances et introduit de multiples améliorations des performances, les performances globales du site étaient toujours ralenties par des changements qui dégradaient les performances.
WordPress a expliqué la leçon qu’ils ont tirée de la version 6.1 :
“Malgré d’autres améliorations de performances dans ces versions, les régressions ont effectivement fini par annuler les améliorations.”
… Plus il y a de régressions, moins les autres améliorations de performances ont un impact global.
Responsable des performances de développement WordPress
Le processus de développement de WordPress 6.2 a été achevé avec la coordination d’un nouveau rôle de responsable des performances.
Le responsable de la performance n’est pas à l’origine des changements et des améliorations. C’était le travail de l’équipe de développement.
Le lead Performance s’est simplement coordonné entre les équipes.
Chacune des équipes est responsable des gains de performance sur ses projets.
Le responsable de la performance a expliqué comment cela fonctionnait :
« Cela m’a permis de collaborer étroitement et de soutenir les autres contributeurs et de coordonner avec eux nos approches de mesure de la performance.
… les gains de performance dans cette version sont le résultat de l’excellent travail de plusieurs contributeurs sur l’identification des faiblesses de performance.
L’introduction du rôle de responsable de la performance… a simplement apporté une meilleure représentation de la performance aux côtés des autres membres de l’équipe de publication.
Analyse comparative automatisée de WordPress
WordPress a noté que les régressions de performances sont passées inaperçues car tous les changements ne pouvaient pas être vérifiés manuellement pour l’impact sur la version globale.
Pour remédier à l’inconvénient de ne pas pouvoir tester manuellement chaque modification apportée au cœur, WordPress a introduit une analyse comparative automatisée des performances pour toutes les modifications.
L’analyse comparative automatisée des performances mesure l’impact de chaque modification afin de détecter les goulots d’étranglement cachés avant qu’ils ne se retrouvent dans les versions finales.
WordPress décrit ce changement de flux de travail :
“Plusieurs contributeurs ont collaboré à l’introduction d’un flux de travail CI de mesure des performances automatisé dans le cœur de WordPress…
Avec ce flux de travail CI, les mesures de performances de base de WordPress sont désormais enregistrées pour chaque commit et sont disponibles dans ce tableau de bord.
Cela nous permet de repérer facilement une régression potentielle là où auparavant elle serait passée inaperçue.
La mise à jour WordPress 6.1 a introduit des régressions de performances dans Gutenberg, des problèmes qui auraient été détectés à l’avance avec des tests automatisés.
Des tests de performances automatisés sont effectués à chaque core commit dans GitHub pour mesurer les performances de WordPress sur les thèmes classiques et en blocs.
Les tests collectent également des mesures de synchronisation du serveur à l’aide de la dernière version de PHP.
Plus d’informations sur la surveillance automatisée des performances ici : Surveillance automatisée des performances dans le noyau WordPress.
Les contributeurs WordPress ont travaillé ensemble
Les contributeurs de WordPress ont travaillé pour identifier les domaines nécessitant des améliorations avec un accent renouvelé sur les performances.
Le profilage des performances côté serveur du cœur de WordPress a été réalisé avec les outils open source Xdebug, XHProf et Blackfire (SaaS).
L’analyse comparative du cœur de WordPress était moins simple car les groupes de développement utilisaient des outils différents.
La standardisation des outils utilisés pour les mesures de performance est en cours afin que toutes les équipes mesurent la même chose avec le même ensemble d’outils.
Fait : WordPress 6.2 fonctionne mieux
Le résultat de l’analyse comparative automatisée des performances et de la coordination des performances entre les équipes de développement est une amélioration substantielle des mesures de performance.
WordPress partagé :
“Sur la base des tests de laboratoire, WordPress 6.2 se charge globalement de 14 à 18 % plus rapidement pour les thèmes de blocs et de 2 à 5 % plus rapidement pour les thèmes classiques (mesuré via Largest Contentful Paint / LCP).
En particulier, les performances côté serveur (mesurées via Time to First Byte / TTFB) connaissent une augmentation majeure de 17 à 23 % pour les thèmes de blocs et de 3 à 5 % pour les thèmes classiques, ce qui contribue directement au temps de chargement global.
Les tests de performance ne se produisent pas seulement au stade de la validation principale, mais l’analyse comparative a lieu pour l’ensemble des versions candidates de WordPress.
WordPress décrit ce processus :
«À ce stade en particulier, il est conseillé d’utiliser la version ZIP de production du noyau WordPress (par exemple, une version bêta ou RC particulière) au lieu de mesurer dans l’environnement de développement du noyau WordPress.
La commande « benchmark-web-vitals » mentionnée dans la section précédente est parfaite pour ce cas d’utilisation, car elle fournit des mesures de performances de haut niveau qui capturent les performances côté serveur et côté client.
Les données résultantes peuvent ensuite être comparées aux mêmes métriques de la version stable précédente, par exemple, pour avoir une idée de la façon dont les performances du noyau WordPress ont changé (espérons-le améliorées !) dans la nouvelle version.
WordPress a tourné un coin sur la performance
WordPress a travaillé dur ces dernières années pour intégrer des améliorations de performances dans le workflow de développement.
Au début, l’équipe de performance apportait des améliorations telles que la réduction du code JavaScript redondant ou inutile qui était chargé pour chaque page et l’ajout d’éléments tels que le chargement paresseux d’images.
Mais maintenant, l’équipe de performance intègre l’analyse comparative des performances directement dans la phase de développement de chaque composant amélioré au niveau de la validation GitHub et utilise l’analyse comparative des performances automatisée pour mettre à l’échelle les améliorations.
Essentiellement, WordPress a réussi à ajouter des performances dans l’ADN de son processus de développement.
C’est l’un des changements les plus importants pour la façon dont WordPress est développé et un signe que WordPress est sur la voie de rattraper les autres systèmes de gestion de contenu.
Enfin, WordPress est peut-être de retour dans le jeu des performances.
Lisez l’annonce complète de WordPress, qui contient des détails sur leur progression et des liens vers les outils utilisés pour comparer les performances.
Les avantages de hiérarchiser et de mesurer les performances dans WordPress 6.2
Image sélectionnée par Shutterstock/Asier Romero
to www.searchenginejournal.com
Abonnez-vous à notre page Facebook: https://www.facebook.com/mycamer.net
Pour recevoir l’actualité sur vos téléphones à partir de l’application Telegram cliquez ici: https://t.me/+KMdLTc0qS6ZkMGI0
Nous ecrire par Whatsapp : Whatsapp +44 7476844931
Jeu de briques
Snake
Pacman
Bubble