Hébergement et extensions WordPress
Rendre WordPress Rapide et Sécurisé : Une Liste de Contrôle des Performances et des Extensions
WordPress n'est jamais plus rapide ni plus sûr que ce qui le fait fonctionner. Voici la liste de contrôle pratique que nous appliquons à chaque site WordPress que nous hébergeons : quoi mettre en cache, quoi sécuriser, et quels plugins méritent leur place par rapport à ceux que la plateforme rend superflus.
WordPress ne vaut que par ce qui le fait tourner
WordPress fait tourner une grande partie du web en raison de sa flexibilité, mais cette même flexibilité est aussi la cause de sa lenteur et de ses failles de sécurité : une installation par défaut interroge la base de données des dizaines de fois par page, diffuse sa version et sa pile technique à quiconque y regarde de près, et vous incite à accumuler les extensions jusqu'à ce que les performances et la surface d'attaque augmentent insidieusement. Rien de tout cela ne relève d'un défaut inhérent à WordPress, mais plutôt des conséquences de son hébergement sur une infrastructure qui n'apporte aucune aide.
La bonne nouvelle, c'est qu'une poignée de décisions similaires résout la majeure partie du problème, et qu'il s'agit de choix liés à la pile technique plutôt qu'au contenu. Mettez en cache agressivement au bon niveau, évitez de solliciter la base de données dans le chemin critique, n'exécutez que les rares plugins qui méritent vraiment leur place, maintenez tout à jour et isolez le site pour qu'un éventuel problème reste cantonné. Cet article présente cette liste de contrôle, dans l'ordre où nous l'appliquons à chaque site WordPress sur la plateforme.
Mettez en cache au niveau du serveur, pas seulement dans un plugin
Le principal levier de vitesse sur WordPress consiste à ne pas exécuter WordPress du tout pour la plupart des visites. Une requête standard démarre WordPress, exécute vos extensions et interroge la base de données avant d'envoyer le moindre octet ; un cache de page complète sert la page finale directement depuis le serveur web dès la visite suivante, en évitant tout ce démarrage. L'emplacement de ce cache a son importance : une extension de cache s'exécute au sein de PHP, ce qui signifie que PHP démarre toujours avant que le cache ne puisse répondre, tandis qu'un cache au niveau du serveur répond plus tôt dans la requête et conserve les pages sous une forme que le serveur peut diffuser instantanément.
Chaque site WordPress que nous hébergeons fonctionne sur LiteSpeed Enterprise avec LSCache au niveau du serveur, et notre propre plugin de cache connecte WordPress à celui-ci correctement dès son installation — préinstallé et mis à jour automatiquement, ce qui fait un élément de moins à configurer ou à maintenir à jour. Sur une origine autre que LiteSpeed, le même plugin émet simplement aucun en-tête de page complète et s'efface pendant que le cache d'objets continue de fonctionner, de sorte qu'un site migré n'est jamais laissé à moitié configuré. La règle pratique pour votre propre liste de contrôle : un seul cache de page complète, au niveau du serveur, et ne superposez pas un deuxième plugin de cache par-dessus — ils entrent en conflit.
Le cache d'objets et la base de données
Toutes les requêtes ne peuvent pas être une page statique. Les sessions connectées, l'administration, la recherche, les paniers et tout fragment personnalisé doivent exécuter PHP, et pour ceux-ci, l'objectif passe de l'évitement de l'application à l'évitement de la base de données. Un cache d'objets par site — Redis, dans notre cas — conserve en mémoire les résultats des lectures répétées de la base de données, de sorte que les mêmes options, transients et recherches ne sont pas interrogés dans la base de données à chaque accès. L'effet se fait sentir précisément là où le cache de page entière ne peut pas aider : une administration plus rapide, des paniers plus rapides et une charge de base de données considérablement réduite sous le trafic.
Le mot qui compte est « par site ». Un cache d'objets partagé signifie qu'un site très sollicité ou mal conçu peut évincer les données mises en cache de tous les autres et affamer la base de données de ses voisins ; un cache dédié par site, associé à des limites de base de données par site, permet de contenir cette zone d'impact. Sur votre liste de contrôle, considérez un cache d'objets persistant comme indispensable pour tout site comportant des utilisateurs connectés ou une boutique, et méfiez-vous de l'hébergement où il est partagé entre plusieurs locataires.
Les extensions qui valent la peine d'être utilisées — et celles que la plateforme remplace
Chaque plugin que vous ajoutez représente du code qui s'exécute lors des requêtes et une porte par laquelle quelqu'un pourrait un jour s'introduire. L'objectif honnête est donc d'avoir le moins de plugins possible qui font le maximum. Un bon hébergeur supprime le besoin de toute une catégorie d'entre eux : avec la mise en cache au niveau du serveur, un cache d'objets géré et des sauvegardes sur la plateforme, vous n'avez pas besoin d'un plugin de mise en cache, d'un plugin de cache d'objets séparé ou d'un plugin de sauvegarde — ces tâches sont mieux exécutées en amont de WordPress, et les exécuter par-dessus ne fait qu'ajouter des conflits et de la surcharge.
Ce qui vaut la peine d'être conservé se résume au petit ensemble qui apporte de vraies fonctionnalités : les extensions dont votre site a réellement besoin pour fonctionner, et — sur notre plateforme — les deux extensions de niveau dépôt que nous créons et livrons avec chaque site. Notre extension de cache connecte WordPress au cache du serveur et gère un nettoyage intelligent afin qu'une modification ne réinitialise que les pages nécessaires. Notre extension de footprint supprime les indices qu'une installation par défaut de WordPress diffuse — la version et la balise generator, les points de terminaison de découverte, XML-RPC, les rétroliens et l'en-tête powered-by — à chaque déploiement, de sorte qu'une mise à jour d'extension ou de thème ne puisse pas les réintroduire discrètement. Toutes deux sont conçues selon les normes du répertoire d'extensions WordPress.org, sont gratuites et se mettent à jour automatiquement.
Garder WordPress sécurisé et à jour
La plupart des compromissions de WordPress ne sont pas sophistiquées ; elles sont anciennes. Un cœur, un thème ou une extension obsolètes présentant une vulnérabilité connue et publiée constituent de très loin le moyen le plus courant par lequel les sites sont touchés, ce qui fait des mises à jour régulières la tâche de sécurité la plus importante qui soit — et la plus fastidieuse, raison pour laquelle elle est souvent ignorée. L'hébergement géré doit vous libérer de cette charge : en appliquant des correctifs à la pile sous WordPress, et en rendant les mises à jour du cœur et des extensions sûres à appliquer en vous fournissant une copie de staging pour les tester et une sauvegarde pour y revenir.
Outre la rapidité, attendez-vous à ce que la sécurité soit garantie par défaut : analyse des logiciels malveillants activée pour intercepter une infection avant qu'un visiteur ne la découvre, isolation pour qu'un site compromis ne puisse pas en atteindre un autre, protection DDoS en périphérie et TLS partout avec des certificats renouvelés automatiquement. Rien de tout cela ne remplace une hygiène de base — identifiants robustes, accès au moindre privilège, suppression des plugins que vous n'utilisez plus —, mais cela garantit que l'infrastructure n'est pas le maillon faible. Sur votre liste de contrôle, la question à poser à tout hébergeur est simple : la sécurité est-elle incluse par défaut, ou s'agit-il d'une option payante ?
WooCommerce et les pages que vous ne devez jamais mettre en cache
Une boutique est l'endroit où la mise en cache agressive rapporte le plus gros gain et fait le plus de dégâts si elle est naïve. Le catalogue, les pages de produits et de catégories sont les pages les plus visitées et les plus aptes à être mises en cache, et les servir depuis un cache de page entière est la meilleure chose à faire pour la vitesse d'une boutique. Mais les pages du panier, de commande et de compte sont personnelles et ne doivent jamais être servies depuis un cache partagé — faites cela et un acheteur verra le panier de quelqu'un d'autre, ce qui constitue à la fois un dysfonctionnement de la boutique et une violation de la vie privée.
La solution pour obtenir les deux est de mettre la page en cache et d'y intégrer des zones dynamiques pour les éléments en temps réel. Les balises Edge Side Includes affichent le fragment du panier, les totaux du mini-panier et l'état du compte à chaque requête tandis que le reste de la page est servi depuis le cache, et le panier, la commande, mon-compte ainsi que toutes les pages de nonce ou de session sont exclus par défaut. La fraîcheur est gérée par un système de purge automatique intelligent qui s'active lorsqu'un produit, un prix ou une commande est modifié, de sorte qu'aucun prix obsolète ne subsiste. Si vous utilisez WooCommerce, c'est l'élément de la liste de vérification à paramétrer parfaitement : une vitrine rapide grâce au cache, un panier dynamique par utilisateur, et aucune donnée personnelle jamais mise en cache.
Foire aux questions
Ai-je encore besoin d'un plugin de mise en cache comme WP Rocket ?
Non. La mise en cache de pages complètes est gérée au niveau du serveur web par LSCache de LiteSpeed, notre propre plugin de cache connecte WordPress à celui-ci et gère la purge intelligente, et un cache d'objets Redis par site se trouve en amont. L'ajout d'un deuxième plugin de mise en cache de pages complètes par-dessus entre généralement en conflit avec le cache au niveau du serveur plutôt que d'aider, il n'est donc ni nécessaire ni recommandé.
Quels plugins la plateforme rend-elle inutiles ?
Les plugins de mise en cache, les plugins de cache d'objets séparés et les plugins de sauvegarde sont tous superflus ici, car ces tâches sont effectuées en amont de WordPress — mise en cache au niveau du serveur, cache d'objets géré par site et sauvegardes de la plateforme. Les supprimer réduit les conflits et la surface d'attaque. Ce qu'il reste utile d'exécuter, ce sont les plugins dont votre site a réellement besoin pour fonctionner, ainsi que nos deux plugins gratuits de cache et de footprint, qui sont préinstallés.
Le cache risque-t-il de perturber mon panier WooCommerce ou mes pages de connexion ?
Non. Le panier, la commande, mon-compte et toutes les pages de jeton (nonce) ou de session sont exclus du cache par défaut, et les inclusions Edge Side (ESI) maintiennent le fragment de panier et les totaux actifs sur les pages par ailleurs mises en cache. Les acheteurs voient toujours leur propre panier et un tunnel de commande opérationnel pendant que la vitrine se charge depuis le cache, et la purge automatique intelligente efface les pages concernées lorsqu'un produit, un prix ou une commande est modifié.
Comment gardez-vous WordPress sécurisé sans que j'aie à le gérer ?
Nous protégeons la pile sous WordPress, sécurisons l'application des mises à jour du cœur et des extensions grâce au staging et à la restauration en un clic, exécutons par défaut des analyses de logiciels malveillants et une protection DDoS, isolons chaque site pour empêcher la propagation d'une compromission, et émettons et renouvelons automatiquement les certificats TLS. Cela élimine l'infrastructure comme maillon faible ; les mesures d'hygiène de base telles que l'utilisation d'identifiants robustes et la suppression des extensions inutilisées restent de votre ressort.
Associé
Essayez-le gratuitement pendant 14 jours
Lancez vos premiers sites gratuitement pendant 14 jours — sans carte. Vous déplacez un site ou un réseau existant ? Votre première migration est offerte.
Commencer gratuitement