Un site média avec un catalogue de contenus dépassant les 100 000 articles nous a demandé un audit de sa recherche interne, jugée trop lente et peu pertinente par les visiteurs. La recherche native de WordPress, basée sur des requêtes LIKE en SQL, montrait ses limites : plusieurs secondes de temps de réponse sur certains termes courants, et des résultats peu pertinents, classés essentiellement par date plutôt que par pertinence réelle. Nous avons comparé trois solutions sur ce même catalogue, dans des conditions identiques.
Pourquoi la recherche native de WordPress s’effondre à cette échelle
La fonction de recherche par défaut de WordPress génère une requête SQL avec des clauses LIKE '%terme%' sur le titre et le contenu, une opération que MySQL ne peut pas indexer efficacement : chaque recherche impose un balayage complet de la table wp_posts. Au-delà de quelques dizaines de milliers de contenus, ce balayage devient visiblement lent, en particulier si plusieurs recherches surviennent simultanément.
Le protocole de comparaison
Les trois solutions ont été testées sur le même catalogue de 100 000 contenus, avec le même jeu de dix requêtes de recherche représentatives (termes courants, termes rares, requêtes à plusieurs mots). Nous avons mesuré le temps de réponse moyen et évalué la pertinence perçue des trois premiers résultats sur chaque requête.
| Solution | Temps de réponse moyen | Infrastructure requise | Pertinence perçue |
|---|---|---|---|
| Recherche native WordPress | 2,4 s | Aucune (MySQL seul) | Faible |
| Relevanssi | 310 ms | Aucune (MySQL seul) | Bonne |
| SearchWP | 240 ms | Aucune (MySQL seul) | Très bonne |
| ElasticPress | 45 ms | Cluster Elasticsearch dédié | Très bonne |
ElasticPress : la performance au prix de l’infrastructure
ElasticPress s’appuie sur Elasticsearch, un moteur de recherche externe à MySQL, qui indexe le contenu dans une structure conçue spécifiquement pour la recherche full-text à grande échelle. Le gain de performance est net, mais il vient avec une contrainte réelle : un cluster Elasticsearch à héberger et maintenir, séparément du serveur WordPress, avec son propre coût d’infrastructure et sa propre charge opérationnelle (mises à jour de sécurité, supervision, sauvegardes).
wp elasticpress index --setup --network-widePour une structure disposant déjà de compétences DevOps ou d’un budget infrastructure dédié, ce coût reste largement justifié par le gain de performance et de pertinence obtenu, en particulier sur des catalogues qui continuent de croître.
SearchWP et Relevanssi : rester dans MySQL avec une indexation optimisée
Ces deux extensions améliorent la recherche sans quitter MySQL : elles construisent leur propre index optimisé, avec des tables dédiées et des mécanismes de pondération de pertinence, plutôt que de s’appuyer sur les requêtes LIKE natives. Le gain de performance, bien réel, reste inférieur à celui d’Elasticsearch, mais sans aucune infrastructure supplémentaire à gérer.
Sur ce comparatif, SearchWP a légèrement devancé Relevanssi en temps de réponse et en pertinence perçue, notamment grâce à des options de pondération plus fines par type de champ (titre, extrait, métadonnées personnalisées). Relevanssi reste néanmoins une option solide et dispose d’une version gratuite fonctionnelle, contrairement à SearchWP, entièrement payant.
Points de vigilance avant de trancher
- Vérifiez la taille réelle du catalogue et sa croissance prévisible sur les deux prochaines années, pas seulement son état actuel.
- Évaluez la compétence disponible en interne ou chez l’hébergeur pour maintenir un cluster Elasticsearch si vous partez sur ElasticPress.
- Testez la pertinence sur vos propres requêtes les plus fréquentes, pas uniquement sur un jeu de test générique.
- Budgétisez la réindexation complète, nécessaire après tout changement de structure de contenu important.
Verdict
Pour une structure sans compétence infrastructure dédiée et un catalogue sous quelques centaines de milliers de contenus, SearchWP ou Relevanssi couvrent largement le besoin, avec un rapport simplicité-performance très favorable. ElasticPress se justifie au-delà, ou dès que la recherche devient un point d’entrée stratégique du site (un site média fortement dépendant de sa recherche interne, par exemple), à condition d’accepter le coût d’infrastructure et de maintenance qui l’accompagne.
La meilleure solution de recherche n’est pas la plus puissante dans l’absolu, c’est celle dont l’équipe peut réellement assumer la maintenance dans la durée.
