Hébergement et extensions WordPress
Rendre WordPress rapide et sécurisé : liste de contrôle des performances et des extensions
WordPress n’est jamais plus rapide ni plus sécurisé que l’environnement qui l’exécute. Voici la liste de contrôle pratique que nous appliquons à chaque site WordPress que nous hébergeons : ce qu’il faut mettre en cache, ce qu’il faut sécuriser et quelles extensions méritent leur place par rapport à celles rendues redondantes par la plateforme.
WordPress ne vaut que par ce qui l’exécute
WordPress propulse une grande partie du web grâce à sa flexibilité, mais cette souplesse explique aussi ses lenteurs et 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 logicielle au premier venu, et vous incite à empiler les extensions jusqu’à ce que les performances s’effondrent et que la surface d’attaque n’explose en toute discrétion. Rien de tout cela n’est un défaut propre à WordPress, mais plutôt la conséquence de son exécution sur une infrastructure qui n’apporte aucune aide.
La bonne nouvelle est qu’une même poignée de décisions permet de résoudre la majeure partie des problèmes, et il s’agit de décisions relatives à l’infrastructure technique plutôt qu’au contenu. Mettez en cache de manière agressive au bon niveau, gardez la base de données hors du chemin critique, n’exécutez que les rares extensions qui justifient réellement leur présence, maintenez tout à jour et isolez le site afin que tout incident reste circonscrit. Cet article constitue cette liste de vérification, dans l’ordre où nous l’appliquons à chaque site WordPress de la plateforme.
Mettez en cache sur le serveur, pas seulement dans un plugin
Le levier le plus important pour la vitesse de 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 entière sert la page finalisée directement depuis le serveur web lors de la visite suivante, en évitant tout ce démarrage. L’emplacement de ce cache a son importance : une extension de mise en cache réside dans PHP, PHP démarre donc 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 vider instantanément.
Chaque site WordPress que nous hébergeons fonctionne sur LiteSpeed Enterprise avec LSCache au niveau du serveur, et notre propre extension de cache connecte WordPress à celui-ci correctement dès le départ — préinstallée et mise à jour automatiquement, c’est donc une chose de moins à configurer ou à maintenir à jour. Sur une source autre que LiteSpeed, la même extension n’émet simplement aucun en-tête de page entière et reste discrète 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 vérification : un seul cache de page entière, sur le serveur, et ne superposez pas une deuxième extension de cache par-dessus — elles entrent en conflit.
Le cache d’objets et la base de données
Toutes les requêtes ne peuvent pas être des pages statiques. Les sessions connectées, l’administration, la recherche, les paniers et tout fragment personnalisé doivent exécuter PHP, et pour ceux-ci, l’objectif ne consiste plus à contourner l’application mais à contourner 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, afin que les mêmes options, données transitoires et recherches ne soient pas interrogées dans la base de données à chaque visite. L’effet se manifeste précisément là où le cache de page complète ne peut pas intervenir : une administration plus rapide, des paniers plus rapides et une charge de base de données nettement réduite lors des pics de trafic.
Le terme essentiel est « par site » (per-site). Un cache d’objets partagé (shared object cache) signifie qu’un site très fréquenté ou mal conçu peut expulser les données en cache de tous les autres et priver ses voisins de base de données ; un cache dédié par site, associé à des limites de base de données par site, permet de circonscrire l’impact d’un incident. Sur votre liste de contrôle, considérez le cache d’objets persistant comme indispensable pour tout site comportant des utilisateurs connectés ou une boutique, et méfiez-vous des hébergements où il est mutualisé entre plusieurs clients.
Les extensions qui valent la peine d’être utilisées — et celles que la plateforme remplace
Chaque extension que vous ajoutez est du code qui s’exécute lors des requêtes et une porte par laquelle quelqu’un pourrait entrer un jour ; l’objectif sincère consiste donc à utiliser le moins d’extensions possible pour un maximum de fonctionnalités. Un bon hébergeur élimine le besoin de toute une catégorie d’entre elles : grâce à la mise en cache au niveau du serveur, à un cache d’objets géré et aux sauvegardes de la plateforme, vous n’avez pas besoin d’une extension de mise en cache, d’une extension distincte de cache d’objets ou d’une extension de sauvegarde — ces tâches sont mieux exécutées sous WordPress, et les exécuter par-dessus ne fait qu’ajouter des conflits et de la surcharge.
Ce qu’il reste d’utile à exécuter, c’est ce petit ensemble qui apporte une véritable valeur ajoutée : les extensions dont votre site a réellement besoin pour fonctionner, et — sur notre plateforme — les deux extensions de qualité dépôt que nous développons et intégrons à chaque site. Notre extension de mise en cache connecte WordPress au cache du serveur et gère la purge intelligente afin qu’une modification ne vide que les pages nécessaires. Notre extension d’empreinte supprime les marqueurs qu’une installation WordPress par défaut diffuse — la version et la balise generator, les points de terminaison de découverte, XML-RPC, les pingbacks et l’en-tête powered-by — à chaque déploiement, évitant ainsi qu’une mise à jour d’extension ou de thème ne les réactive discrètement. Toutes deux sont conçues selon les normes du répertoire d’extensions de WordPress.org, sont gratuites et se mettent à jour automatiquement.
Garder WordPress sécurisé et à jour
La plupart des failles de sécurité de WordPress ne relèvent pas de l’exploit ; elles sont anciennes. Un cœur de système, un thème ou un plugin obsolète comportant une vulnérabilité connue et publiée constitue de loin le moyen le plus fréquent par lequel les sites sont touchés, ce qui fait du maintien à jour la tâche de sécurité la plus précieuse qui soit — et la plus fastidieuse, raison pour laquelle elle est souvent négligée. L’hébergement infogéré devrait vous décharger de cette tâche : en appliquant les correctifs sur la pile logicielle sous-jacente de WordPress et en sécurisant le déploiement des mises à jour du cœur et des plugins, grâce à la mise à disposition d’une copie de staging pour les tester et d’une sauvegarde pour les restaurer.
Au-delà de la mise à jour constante, attendez-vous à ce que les limites soient appliquées pour vous : analyse des logiciels malveillants activée par défaut afin qu’une infection soit interceptée plutôt que découverte par un visiteur, 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 les règles d’hygiène élémentaires — identifiants robustes, principe du moindre privilège, suppression des extensions que vous n’utilisez plus — mais cela signifie 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 intégrée par défaut ou s’agit-il d’un pack à acheter ?
WooCommerce et les pages que vous ne devez jamais mettre en cache
Une boutique est l’endroit où la mise en cache agressive offre ses meilleurs résultats et cause ses pires dégâts si elle est mal pensée. Les pages de catalogue, de produits et de catégories sont les pages les plus visitées et les plus faciles à mettre en cache dont vous disposez, et les distribuer depuis le cache de page entière est la meilleure chose que vous puissiez faire pour la rapidité 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-le et un acheteur verra le panier de quelqu’un d’autre, ce qui constitue à la fois un dysfonctionnement de la boutique et une atteinte à la vie privée.
La méthode pour obtenir les deux consiste à mettre la page en cache et à ménager des espaces réservés pour les éléments dynamiques. Edge Side Includes génère le fragment du panier, les totaux du mini-panier et l’état du compte par requête pendant que le reste de la page est servi depuis le cache, et cart, checkout, my-account ainsi que toute page nonce ou session sont exclus par défaut. La fraîcheur des données est gérée par une purge automatique intelligente qui se déclenche lors de la modification d’un produit, d’un prix ou d’une commande, évitant ainsi qu’un prix obsolète ne persiste. Si vous utilisez WooCommerce, voici le point de la liste de contrôle à respecter scrupuleusement : une vitrine rapide issue du cache, un panier dynamique par utilisateur, et aucune donnée personnelle mise en cache.
Foire aux questions
Ai-je encore besoin d’une extension de mise en cache comme WP Rocket ?
Non. La mise en cache de page entière est gérée au niveau du serveur web par le LSCache de LiteSpeed, notre propre extension de cache y connecte WordPress et prend en charge la purge intelligente, et un cache d’objets Redis par site fonctionne en arrière-plan. Ajouter une seconde extension de mise en cache de page entière entre généralement en conflit avec le cache au niveau du serveur plutôt que d’aider, ce n’est donc ni nécessaire ni recommandé.
Quels plugins la plateforme rend-elle superflus ?
Les extensions de mise en cache, les extensions distinctes de cache d’objets et les extensions de sauvegarde sont ici redondantes, car ces tâches sont effectuées sous 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 qui mérite d’être conservé, ce sont les extensions dont votre site a véritablement besoin pour fonctionner, ainsi que nos deux extensions gratuites de cache et de footprint, fournies préinstallées.
La mise en cache risque-t-elle de perturber mon panier WooCommerce ou les pages destinées aux utilisateurs connectés ?
Non. Les pages Cart, checkout, my-account ainsi que toutes les pages de nonce ou de session sont exclues du cache par défaut, et Edge Side Includes maintient le fragment de panier et les totaux à jour sur les pages par ailleurs mises en cache. Les acheteurs voient toujours leur propre panier et un processus de commande fonctionnel tandis que la vitrine continue de se charger depuis le cache, et une purge automatique intelligente vide les pages concernées lorsqu’un produit, un prix ou une commande est modifié.
Comment maintenez-vous WordPress sécurisé sans que j’aie à le gérer ?
Nous appliquons les correctifs à la pile sous-jacente de WordPress, sécurisons l’application des mises à jour du cœur et des extensions grâce à des environnements de préproduction et à la restauration en un clic, activons par défaut l’analyse des logiciels malveillants et la protection DDoS, isolons chaque site afin qu’une éventuelle compromission ne puisse se propager, et émettons et renouvelons automatiquement les certificats TLS. Cela élimine l’infrastructure en tant que maillon faible ; l’hygiène de base, telle que l’utilisation d’identifiants robustes et la suppression des extensions inutilisées, reste à votre charge.
Connexe
Essayez-le gratuitement pendant 14 jours
Lancez vos premiers sites gratuitement pendant 14 jours — sans carte bancaire. Vous transférez un site ou un réseau existant ? Les migrations sont gratuites et illimitées.
Commencer gratuitement