Réduire les requêtes de base de données aux tables utilisateur?
J'essaie de trouver un moyen stratégique de collecter de grandes quantités de données usermeta (et de les afficher à l'écran) tout en limitant les requêtes dans la base de données. Certaines pages, comme la page d'accueil, les pages simples et les pages de catégories, se chargent en moins d'une demi-seconde avec 40 à 60 requêtes. Les autres pages contenant de grandes quantités d’usermeta se chargent en 5-6 secondes avec 200 à 220 requêtes.
Existe-t-il une "bonne pratique" pour extraire toutes les données utilisateur avant le chargement du site Web (ou lors du premier chargement d'un site Web), puis exploiter ces informations (IE, un tableau multidimensionnel basé sur l'ID utilisateur) pour tous les autres systèmes basés sur l'utilisateur? des requêtes sur le site? Les informations seraient-elles sauvegardées lors de la visite (mises en cache sur le navigateur) ou faudrait-il utiliser l'API transitoire?
Des pensées?
Vous avez fait beaucoup de déclarations ici, alors examinons-les petit à petit.
tout en limitant les requêtes de base de données
Le montant des requêtes n'est pas directement un problème, le temps qu'elles prendre est. Une seule requête très lente peut prendre plus de temps que des centaines de requêtes très rapides.
avant le chargement du site Web (ou la première fois qu'un site Web se charge)
Puisque WP est PHP application, chaque charge comprend un cycle complet et n'est pas persistante. Il n'y a pas de "première fois", car il part de rien à chaque chargement. Les seules parties persistantes sont celles qui sont enregistrées dans la base de données ou autrement.
Les informations seraient-elles sauvegardées lors de la visite (mises en cache sur le navigateur) ou faudrait-il utiliser l'API transitoire?
La mise en cache du navigateur, bien qu'importante, ne contribue en rien à améliorer les performances du site lui-même. Les transitoires constituent précisément un type de stockage persistant adapté à de tels cas d'utilisation.
Cependant, comme d'habitude avec les tâches de performance, il est difficile de recommander quoi que ce soit sans profiler l'opération lente. Il est extrêmement facile de faire des hypothèses erronées sur les raisons de la lenteur des performances et du temps perdu à essayer de les résoudre.