Les requêtes de WordPress sont déjà assez optimisées de base, et elles utilisent les mécanismes de mise en cache lorsqu’ils sont disponibles. Il est essentiel que WordPress fasse cela, en prenant en considération la quantité et la nature des données qui sont retournées par une requête typique. À titre d’illustration, examinons les données renvoyées par cette requête get_posts basique :
$query = get_posts( array( 'posts_per_page' => 1 ) );
C’est une requête très simple qui va renvoyer l’article de + récent. Voici un exemple des données qui ont été renvoyées :
Array ( [0] => WP_Post Object
(
[ID] => 1
[post_author] => 1
[post_date] => 2021-09-25 20:44:47
[post_date_gmt] => 2021-09-25 20:44:47
[post_content] => Contenu de l'article
[post_title] => Titre de l'article
[post_excerpt] =>
[post_status] => publish
[comment_status] => open
[ping_status] => open
[post_password] =>
[post_name] => hello-world
[to_ping] =>
[pinged] =>
[post_modified] => 2021-10-16 17:22:34
[post_modified_gmt] => 2021-10-16 17:22:34
[post_content_filtered] =>
[post_parent] => 0
[guid] => http://site.local/?p=1
[menu_order] => 0
[post_type] => post
[post_mime_type] =>
[comment_count] => 1
[filter] =>
)
)
Regardez toutes ces données pour un seul article (sans compter les métadonnées et les données sur les termes qui ont été référencées). Parce que WordPress utilise la mise en cache, les requêtes typiques comme celle-ci donnent de bonnes performances. Mais lorsque vous commencez à utiliser WordPress pour des requêtes avancées et qu’il y a beaucoup d’articles à consulter (par exemple, 10 000 articles), votre requête rapid peut rapidement devenir très gourmande en ressources
Efforts déployés pour améliorer la requête
Lorsqu’on a affaire à un grand nombre de posts, il existe heureusement des moyens de contourner certains de ces goulets d’étranglement dans la requête. Examinons-en quelques-unes.
Si vous n’avez pas besoin de paginer votre travail, ne vous en préoccupez pas !
La pagination n’est pas nécessaire pour toutes les requêtes. Lorsqu’il s’agit de pagination, WordPress utilise la fonction intégrée SQL CALC FOUND ROWS pour chaque requête, que vous ayez besoin ou non de paginer.
Par conséquent, pour contourner ce problème, il existe un paramètre pratique que nous pouvons utiliser, appelé « no found rows », qui nous permet de désactiver entièrement cette fonction.
Gardez à l’esprit que pour utiliser ce paramètre, votre requête ne doit pas dépendre de la pagination de quelque manière que ce soit, sinon la pagination sera corrompue.
Voici comment nous le mettons en pratique :
$query = new WP_Query( array( 'posts_per_page' => 1, 'no_found_rows' => true ) );
Récupérer seulement les ID des articles
Que se passe-t-il si vous n’avez besoin que d’une liste d’identifiants d’articles pour travailler ? Si tout ce dont nous avons besoin est un tableau d’identifiants d’articles, il serait inefficace pour nous de récupérer toutes les données qui sont généralement retournées par la fonction get posts.
Nous avons de la chance, car il existe un autre paramètre que nous pouvons utiliser, appelé « fields », et en l’utilisant, nous pouvons spécifier que nous ne voulons que les ID des messages, comme indiqué ici :
SQL CALC FOUND ROWS, bien qu’elle soit pratique et qu’elle ne prenne en compte qu’une seule requête, est sensiblement plus lente que l’utilisation de la requête supplémentaire COUNT. Ceci est particulièrement vrai dans les situations où nous avons déjà défini nos clauses WHERE, ORDER et LIMIT (ce que fait WordPress).
Par conséquent, pour contourner ce problème, il existe un paramètre que nous pouvons utiliser appeler « no found rows », qui nous permet de désactiver complètement cette fonction.
Gardez à l’esprit qu’afin d’utiliser ce paramètre, votre requête ne doit pas dépendre de la pagination de quelque manière que ce soit ; sinon, la pagination sera corrompue.
Voici comment nous le mettons en pratique :
$query = get_posts( array( 'posts_per_page' => 1, 'fields' => 'ids' ) );