L’équipe de performance de WordPress a publié un résumé d’une analyse des performances de base qu’ils ont complété afin d’identifier et de prioriser les domaines d’amélioration. Dans le cadre de ce processus, les contributeurs ont créé un méthodologie avec un ensemble standard d’outils qui peuvent être utilisés pour collecter et partager des données de profilage pour divers composants de l’application.
L’équipe a testé un thème classique (Twenty Twenty-One) et un thème bloc (Twenty Twenty-Three) configurés avec le Données du test unitaire thématique. Ils ont testé des fonctionnalités prêtes à l’emploi, en plus de différents scénarios tels qu’une page d’accueil affichant les derniers messages, une page de texte uniquement, une page avec un grand nombre d’images et de blocs par défaut, et une page d’accueil et une page de base avec traduction. .
Ces tests ont révélé de nombreux problèmes de performances que l’équipe a documentés avec des tickets de suivi associés et détaillés dans le résumé des conclusions. La première priorité identifiée pour l’amélioration est le chargement des modèles pour les thèmes classiques.
Bien que les contributeurs de WordPress progressent sur la feuille de route du projet pour l’éditeur de blocs, avec la plupart des fonctionnalités de la version principale axées sur l’édition de site, l’adoption du thème de bloc n’est pas là où l’on pourrait s’attendre à ce qu’elle soit plus de quatre ans après l’arrivée de Gutenberg dans le noyau.
« La majorité des sites Web utilisent toujours l’architecture de thème classique, donc les améliorations apportées ici pourraient avoir le plus grand impact horizontal », a déclaré Joe McGill, sponsor principal de WordPress sponsorisé par 10-up, dans le résumé.
McGill référencé données collectées en avril 2023 pour le HTTPArchive qui utilise une requête basée sur une nouvelle métrique personnalisée HTTP Archive pour détecter l’adoption du thème de bloc. Sur la base de ces informations, l’amélioration du chargement et du rendu des modèles pour les thèmes classiques devrait rester une priorité élevée. La majeure partie du Web alimenté par WordPress fonctionne toujours sur des thèmes classiques.
Le résumé met en évidence les améliorations pour le chargement des modèles qui auraient le plus d’impact :
Dans le thème classique testé, le processus le plus coûteux est lié à la localisation et au rendu des parties du modèle. Cela commence par get_template_part(), inclut le processus de localisation des fichiers de partie de modèle avec locate_template() et le rendu du contenu de chaque partie de modèle. L’ensemble de ce processus représentait environ 30 à 60 % de l’ensemble de la réponse du serveur dans les résultats des tests, une grande partie de ce temps étant consacré à la gestion des vérifications du système de fichiers (par exemple, file_exists() est responsable de 4 à 9 % de tout le temps mesuré et peut probablement être optimisé avec un cache), rendu des blocs de widgets, etc. Étant donné que bon nombre de ces vérifications de système de fichiers ne sont pas susceptibles de produire des résultats différents souvent entre les requêtes, il existe probablement des opportunités de trouver des améliorations substantielles ici.
Ces améliorations sont la première des cinq priorités identifiées par l’équipe de performance à la suite de l’analyse. La deuxième recommandation est d’améliorer le chargement des traductions, car plus de 56% de tous les sites Web WordPress utilisent des traductions.
Les trois autres priorités incluent des améliorations pour les sites alimentés par blocs, les deux premières sonnant comme les opérations les plus coûteuses en termes de performances :
- Améliorer la gestion de l’enregistrement des blocs à partir des métadonnées
- Améliorez la résolution des modèles de bloc
- Améliorer le rendu des widgets de bloc
« Ces efforts nécessiteront probablement des recherches et une conception architecturale supplémentaires avant le début de l’ingénierie », a déclaré McGill. « Tous les autres éléments identifiés pourraient être traités directement via des tickets Trac individuels, dans la mesure où la capacité le permet. »
L’équipe Performance envisage de rendre les outils de profilage des performances plus largement disponibles afin que d’autres contributeurs puissent étendre leur travail. À l’avenir, ils pourraient également envisager de contacter des sociétés d’hébergement pour qu’elles effectuent une analyse de leur infrastructure et examinent des cas d’utilisation supplémentaires, tels que les versions PHP, la configuration de la mise en cache d’objets, etc. Une fois la méthodologie utilisée pour cette analyse bien définie, les futurs efforts d’amélioration des performances pourraient devenir plus fréquents et plus faciles à produire.
Source link