WordPress Core Committer Adam Silverstein a publié un proposition d’ajout d’outils de performance automatisés qui offrirait une surveillance continue des problèmes de performances afin qu’ils puissent être résolus avant que des régressions majeures ne soient commises sur le noyau.
« Semblable à notre suite de tests unitaires, les tests de performances automatisés aideraient à protéger le noyau contre l’introduction de régressions de performances importantes en détectant les problèmes immédiatement et en suivant les performances au fil du temps », a déclaré Silverstein. « L’automatisation des tests signifie également une économie d’efforts des contributeurs en remplaçant un processus manuel chronophage. »
Alors que l’équipe Performance se concentre sur l’introduction de nouvelles fonctionnalités avec des gains mesurables, ainsi que sur les tests de nouvelles versions de WordPress avant leur expédition, ils ont découvert au hasard ce que Silverstein a décrit comme des « régressions de performances significatives ». Quelques exemples incluent une régression trouvée avant WP 6.1 dans le traitement theme.json et un autre publier avec des modifications pour le chargement du textdomain.
« Les tests automatisés détecteraient ce type de régression dès son introduction, ce qui le rendrait beaucoup plus facile à résoudre », a-t-il déclaré.
Silverstein a souligné le projet Gutenberg comme un bon exemple de suivi des performances, car chaque version publie des métriques sur les modifications du temps de chargement, du temps de saisie et du temps de sélection des blocs. L’équipe a également commencé à suivre le TTFB (temps jusqu’au premier octet) pour les thèmes classiques par rapport aux thèmes de bloc dans leur tableau de bord de santé du code, ce qui les aide à voir l’impact immédiat des derniers commits.
« Cela rend visible la régression des performances dans le rendu des thèmes de blocs par rapport aux thèmes classiques pour une simple page » bonjour le monde « », Emily Clarke, contributrice de l’équipe WordPress Performance. a dit lors de la dernière réunion de l’équipe. « En tant qu’équipe, nous aimerions nous assurer que nous priorisons correctement les tickets que nous avons pour 6.2 qui auraient un impact positif sur cette métrique, en particulier tout ce dont nous avons besoin pour atterrir avant le jalon bêta 1 la semaine prochaine. »
Quelques contributeurs ont déjà travaillé sur l’amélioration des temps de réponse du serveur pour les thèmes de blocs, avec des PR qui devraient débarquer en 6.2.
« Semblable à Gutenberg, le noyau de WordPress rassemblerait un ensemble de mesures de performances automatisées ainsi que les tests existants (par exemple, les tests unitaires, les normes de codage) que nous avons déjà pour chaque nouveau commit », a déclaré Silverstein. « Ces métriques peuvent être utilisées pour identifier le point exact où une régression des performances est introduite dans le cœur. À des jalons comme une version majeure, les métriques peuvent être comparées à la version précédente pour évaluer les progrès.
Silverstein propose que WordPress commence petit en exécutant simplement un ensemble de tests automatisés sur chaque commit de base pour des choses comme le temps de chargement et le temps de requête total pour les thèmes classiques et de bloc. À l’avenir, l’équipe pourrait capturer des métriques de synchronisation de serveur supplémentaires et des métriques pour d’autres contextes au-delà de la page d’accueil, tels que l’administrateur et la publication unique.
Jusqu’à présent, la réponse à la proposition a été positive, car la seule alternative consiste à s’appuyer sur des individus pour découvrir manuellement les nouveaux goulots d’étranglement de performance et les signaler. De meilleurs outils aideront à identifier ces problèmes plus rapidement, avant qu’ils ne soient déployés auprès de millions de personnes.
« Compte tenu de l’importance que les plates-formes CMS homologues accordent à la » publicité « de leurs performances et à leur comparaison avec les leaders de l’industrie, investir dans des outils pour garantir que WordPress continue de fonctionner de manière optimale est tout à fait logique », a déclaré Dan Soschin, contributeur marketing de WordPress. « Et, compte tenu du nombre de sites alimentés par WordPress, même des gains de performances mineurs (y compris ceux qui ne sont pas perceptibles par la plupart des gens) ajoutent beaucoup de valeur aux hébergeurs Web et réduisent les charges/bande passante globales du trafic Internet. »
Source link