La checklist performance WordPress 2026, du serveur au navigateur

Cette checklist n’a pas la prétention de détailler chaque technique en profondeur, ce que d’autres articles de ce blog font déjà point par point. Elle sert de fil conducteur avant une mise en production ou un audit rapide : vingt-quatre points, dans l’ordre où une requête les traverse réellement, du serveur jusqu’au rendu final dans le navigateur.

Serveur et PHP

1. Version de PHP activement maintenue en matière de sécurité, vérifiable sur la page officielle de support des versions.
2. OPcache activé, avec opcache.memory_consumption dimensionné au nombre réel de fichiers du projet, contrôlable via opcache_get_status().
3. Pool PHP-FPM dimensionné selon la charge attendue, ni sous-dimensionné (files d’attente), ni surdimensionné (mémoire gaspillée).
4. HTTP/2 ou HTTP/3 actif au niveau du serveur web ou du CDN placé devant.
5. Compression Brotli ou au minimum Gzip activée sur les réponses HTML, CSS et JS.

Base de données

1. Taille de wp_options et poids des options en autoload, vérifiable avec wp option list --autoload=on via WP-CLI.
2. Absence de requêtes meta_query lentes sur les tables volumineuses, contrôlée avec EXPLAIN sur les requêtes identifiées par Query Monitor.
3. Index adaptés sur les colonnes réellement filtrées en production, pas seulement les index par défaut du cœur.
4. Purge régulière des transients expirés et des révisions d’articles excédentaires.

Cache

1. Cache de page actif, avec exclusions correctement posées pour les utilisateurs connectés et les zones dynamiques.
2. Cache d’objets persistant (Redis ou Memcached) en place, avec un taux d’éviction vérifié sous les 5 %.
3. Stratégie d’invalidation ciblée après publication, plutôt qu’une purge totale systématique.
4. Warmup des pages principales après toute purge de cache.

Images et assets

1. Formats modernes (WebP ou AVIF) servis automatiquement selon le support du navigateur du visiteur.
2. Attribut sizes cohérent avec la disposition réelle des images, auto utilisé sur les images en chargement différé quand pertinent.
3. Image critique au-dessus de la ligne de flottaison exclue du chargement différé, avec fetchpriority="high" si elle correspond au LCP.
4. Scripts non essentiels au rendu initial chargés en différé ou de façon asynchrone.
5. Polices web préchargées si elles conditionnent le rendu du texte principal, avec font-display réglé pour éviter un texte invisible prolongé.

Scripts et interactivité

1. Absence de tâches JavaScript longues bloquant le fil principal sur les interactions critiques, vérifiée dans le panneau Performance de DevTools.
2. Scripts tiers (tracking, chat, avis clients) audités individuellement pour leur impact réel sur l’INP.
3. Requêtes réseau superflues au chargement initial identifiées et supprimées ou différées.

Mesure et suivi

1. Métriques terrain (LCP, INP, CLS) collectées en continu, pas seulement lues une fois par mois dans Search Console.
2. Alerte automatique en cas de dépassement de seuil sur un gabarit de page donné.
3. Revue de cette liste renouvelée après chaque changement significatif de thème ou d’extensions majeures, pas seulement à la mise en production initiale.

Comment utiliser cette liste au quotidien

Cette checklist n’a de valeur que si chaque point est vérifié avec un outil précis plutôt que jugé « à l’œil ». Elle ne remplace jamais une mesure réelle prise sur le site concerné, dans ses conditions réelles de trafic et de contenu : un site à fort catalogue et un site vitrine simple n’ont pas les mêmes priorités parmi ces vingt-quatre points, même si la structure de la vérification reste identique pour les deux.

En résumé

Une checklist de performance sert de garde-fou, pas de solution miracle. Elle garantit qu’aucun point classique n’est oublié avant une mise en production, mais chaque ligne mérite d’être approfondie selon le contexte réel du site audité, en s’appuyant sur les techniques détaillées dans les articles dédiés à chacun de ces sujets.