Héberger un site WordPress performant sur un micro serveur Cloud, c’est possible!

Karl Johnson
5 min readApr 14, 2020

--

Bien qu’il est le CMS le plus populaire sur le Web avec plus de 90% des parts du marché, WordPress est loin d’être reconnu comme une plateforme performante. Les thèmes WordPress étant remplis de fonctions facilitant la conception de son site Web et la multitude d’extensions installées par les agences Web pour ajouter des fonctionnalités affectent grandement les performances en rendant les requêtes Web de plus en plus lourdes en CPU et mémoire au niveau PHP et MySQL. Par dessus cela, une extension de traduction comme WPML vient ajouter une autre couche de requêtes vers la base de données, résultant à un site lent qui affecte la patience des visiteurs et ses performances SEO. L’hébergement est aussi à prendre en compte puisque la plupart des instances WordPress sont déployées sur des serveurs cPanel surchargés de clients.

Sachant cela, est-ce possible d’héberger un site WordPress sur un micro serveur Cloud qui revient au même prix qu’un hébergement partagé, tout en profitant des avantages d’être sur son propre serveur privé? Est-il possible d’absorber un pic de traffic lors d’un événement avec si peu de mémoire? Confirmons le tout avec des benchmarks.

Obtenir de bonnes performances avec WordPress

Il est normal de ressentir des lenteurs après l’ajout d’une ou plusieurs extensions sur son site WordPress, surtout avec un hébergement partagé. Le code PHP devenant de plus en plus lourds et le nombre de requêtes SQL grandissant, il est nécessaire d’optimiser le site et son environnement pour qu’il demeure navigable.

Configuration de cache

Il existe différentes extensions de cache pour WordPress, sont-elles vraiment efficaces? Certaines sont trop volumineuses (W3 Total Cache), ou n’en font pas assez (WP Super Cache), d’autres sont dispendieuses (WP-Rocket); il n’y a pas d’extensions parfaites. De plus, une lourde extension supplémentaire d’installée sur le WordPress n’est pas nécessairement souhaitable.

Nginx offre son propre système de cache qui est beaucoup plus efficace car il ne dépend pas de PHP et est donc encore plus léger. Une configuration de cache pour WordPress est déjà disponible avec nginx-more et s’active en une seule ligne tel que documentée, voir exemple ci-bas:

server {
listen 80;
listen 443 ssl http2;
server_name aerisnetwork.com www.aerisnetwork.com;
include conf.d/custom/ssl-aerisnetwork.com.conf;
include conf.d/custom/restrictions.conf;
include conf.d/custom/fpm-wordpress-cache.conf;
}

La configuration par défaut met en cache chaque page pendant 20 minutes à l’exception des administrateurs du WordPress et des requêtes qui ne devraient pas être mises en cache. Un visiteur active donc le cache de la page pour tous les prochains visiteurs pendant 20 minutes et ainsi de suite. Ce délais peut être augmenté à des heures voir des jours, en autant que l’extension nginx-helper soit installée pour automatiquement purger le cache d’une page qui est modifiée. Le statut du cache par page peut être vérifié via les en-têtes:

14:39:06 ➜  ~ curl -s -I "https://aerisnetwork.com" |grep -i x-cache
x-cache: HIT
14:39:07 ➜ ~

Configuration d’un CDN

L’ajout d’un CDN est un incontournable, peu importe le CMS ou le framework utilisé. Il est important d’offloader toutes les requêtes statiques (images, css, javascript, fonts, etc.) vers un service de CDN qui lui distribuera les éléments à travers son réseau de serveurs mondial, optimisant non seulement les performances selon la position géographique du visiteur mais aussi en laissant le serveur Web (nginx) s’occuper seulement des requêtes dynamiques.

Le choix du fournisseur CDN est propre à chacun, selon l’extension WordPress utilisée ou les points de présences offerts par celui-ci. De notre côté, nous utilisons celui de AWS, CloudFront. Il faut prendre le temps de bien le configurer, notamment les expirations sur les fichiers, pour assurer qu’il soit efficace. Une fois en place, le Developper Tools de Google Chrome permet de confirmer que seulement la requête au site (/) passe par le serveur Web, toutes les autres requêtes étant envoyées à CloudFront:

Confirmation de l’utilisation du CDN CloudFront

CloudFront ajoute aux en-têtes le statut du cache et la localisation du POP qui retourne la requête. Il faut s’assurer que l’élément est bien en cache chez CloudFront et que le POP est près de sa localisation:

14:07:40 ➜  ~ curl -s -I "https://cdn-wp.aerisnetwork.com/wp-content/uploads/2020/02/aerisnetwork_logo_cmyk_neg.svg" |grep -i "x-cache\|x-amz-cf-pop"x-cache: Hit from cloudfront
x-amz-cf-pop: YUL62-C1
14:07:49 ➜ ~

Test de charge / Simulation de pic de traffic

Plusieurs outils de benchmarking sont disponibles pour vérifier si notre site Web sous WordPress peut tenir le coup face à des pics de traffic. Ci-bas, voici les résultats d’une simulation de 200 visiteurs pendant 30 secondes générant 40 requêtes par seconde sur le site.

Données du benchmark:

  • Micro serveur Cloud avec 1 processeur et 1Gb de mémoire
  • Nginx-more 1.16.1
  • PHP 7.3 / MariaDB 10.4
  • 200 connections / 40 requêtes par seconde / 30 secondes

Résultats de la simulation

Benchmark WordPress on nginx-more — Connections
Test de charge WordPress avec nginx-more :: Connections
Benchmark WordPress on nginx-more — Query per seconds
Test de charge WordPress avec nginx-more :: Requêtes par seconde
Benchmark WordPress on nginx-more — Errors
Test de charge WordPress avec nginx-more :: Erreurs et Interruptions

Statistiques de cache en temps réel

Statistiques en temps réel de nginx

Interpretation des résultats

Le graphique Errors/Timeouts confirme qu’il n’y a eu aucune erreur ni interruption pendant le test de charge; le serveur a bien tenu le coup. Le module Nginx Vhost Traffic Status disponible avec nginx-more donne un bon aperçu de ce qui se passe pendant la simulation du pic de traffic. Des 100 requêtes par seconde sur le site, 100% atteignent le cache de nginx (HIT).

Nous pouvons aussi jeter un oeil aux statistiques Grafana du serveur pour vérifier l’utilisation de la mémoire pendant les tests:

Statistiques Grafana :: Nginx
Statistiques Grafana :: Mémoire disponible

Puisqu’aucune requête n’est envoyée à PHP grâce au cache, l’utilisation de la mémoire n’est pas affectée par le pic de traffic. Aucune inquietude de faire face à un Out Of Ram (OOM.)

Conclusion

L’hébergement d’un site WordPress sur serveur Cloud plutôt que partagé offre la flexibilité de bien optimiser son environment pour résister aux pic de traffic et propose une bien meilleure expérience à ses visiteurs avec une navigation rapide. Avec l’ajout de cache et d’un CDN, un tout petit serveur Linux sera suffisant pour propulser vos sites WordPress, tout en isolant vos données sur un serveur privé, benchmarks à l’appui!

Besoin d’assistance pour optimiser votre instance WordPress, son hébergement Web, son niveau de sécurité ou son référencement SEO? N’hésitez pas à me contacter!

--

--

Karl Johnson

I'm an IT architect involved in the hosting business. I spend my free time doing R&D, security, packaging rpms and work on startups!