Utiliser wget et ftp pour cacher et améliorer les performances d’un réseau de sites

Il y a quelques semaines, un ami m’a interrogé sur une problématique très précise. Il voulait améliorer la vitesse de chargement de ses sites, sans avoir davantage de frais en serveurs et sans se lancer dans des optimisations complexes.

Il a plusieurs centaines de sites web, tous hébergés sur des serveurs mutualisés. Tous fonctionnent sous wordpress, et il n’en peut plus des problèmes de vitesse qu’il rencontre : que ce soit pour faire les mises à jour ou pour accueillir ses visiteurs.

Cache Cash

Le premier réflexe a été de lui conseiller d’installer un plugin de cache sur tous ses wordpress (hyper cache en l’occurrence).
Très content sur le coup, il est revenu pleurer sur mon épaule après quelques jours :

Mes visiteurs sont contents, mon SEO aussi, mais je sens que mon administration n’est pas tout à fait du même avis

Et il n’a pas tort le bougre. Sur du petit mutu, l’admin WordPress n’est pas toujours un modèle de vitesse.

Wget, Lftp et taches cron

Alors je lui ai proposé une solution un peu plus complète :

• prendre un serveur dédié
• remplacer tous ses hébergements mutualisés par des hébergements plus légers encore.

Bizarre ?

Je lui ai recommandé d’utiliser le dédié pour installer tous ses sites wordpress, et ainsi profiter d’un bon serveur pour avoir une administration rapide. Avec une nuance : les sites ne sont pas installés sur le nom de domaine final. Il a pris un ndd générique et a fait des centaines de sous-domaines.

Ensuite, je lui ai fait mettre en place un htacces/htpasswd pour protéger son nom de domaine sur son dédié. Et une tache cron s’exécute une fois par jour, avec deux fonctions :

• Générer une copie intégrale de chaque site, en html statique.
• Envoyer la copie sur le serveur mutualisé cible, via ftp.

De cette façon, les serveurs mutualisés hébergent uniquement des fichiers statiques, ce qui permet de trouver des hébergements vraiment très bas prix, capables de fournir un service rapide et efficace.

Ainsi Cron, Cron, Cron…

En pratique, voici la commande cron qui va bien :

6 6 * * * /usr/bin/wget -r -k -np --http-user=LOGIN --http-password=PASSWORD --directory-prefix="/var/www/stockage/" http://www.example.org

Traduction : A 06h06 du matin, on lance un wget récursif, configuré pour corriger les chemins d’urls (ça permet de rendre le site indépendant de son nom de domaine), en indiquant les identifiants à fournir à la protection htaccess, et l’emplacement où stocker les fichiers grâce à directory-prefix.

Trois petits tours et puis s’en vont

C’est bien beau, mais comment faire pour envoyer les fichiers sur le serveur mutualisé ?

Facile, on utilise un autre cron :

7 7 * * * /usr/bin/lftp -e "mirror -R /var/www/stockage/www.example.org /REPERTOIRE_CIBLE_DU_MUTUALISE; exit" -u LOGIN_FTP,PASSWORD_FTP ftp://HOTE_FTP

Cette fois à 07h07 on lance un lftp qui va faire un mirroring du site préalablement collecté vers l’hébergement mutualisé.

Il n’y a plus qu’à faire la même chose pour chacun des sites, et voilà une affaire rondement menée : une admin rapide, des visiteurs heureux, des sites sources tous sur le même serveur, donc plus pratiques à administrer et au passage, un Google ravi.

Bien entendu, si la manipulation a souvent pour mérite d’améliorer la vitesse de chargement des sites, elle a aussi des inconvénients :

• on ne peut plus utiliser les commentaires wordpress, il faut installer un plugin de commentaires externalisés, de type Disqus ou Facebook.
• les mises à jour ne sont plus en temps réel.
• si les sites sont gros, leur récupération via wget peut-être un peu longue.
• C’est une optimisation marginale, qui répond à une problématique de cout / performance / effort particulière. Il y a souvent d’autres leviers à actionner pour obtenir des gains de performances bien plus prononcés.

C’est tout pour aujourd’hui ! Merci de m’avoir lu !