Configurer un sous-domaine comme « CDN » dans NGINX (+ configuration de WordPress et de W3 Total Cache)

MISE À JOUR : CORS (Cross-origin resource sharing) a été ajouté au « faux » CDN. Basé sur : https://gist.github.com/alexjs/4165271

Dans un scénario classique, vous servez votre site depuis un seul domaine, qui comprend toutes vos pages « générées par le serveur » ainsi que les images et les ressources (JavaScript, CSS et autres fichiers) de votre site.

Cela peut ralentir votre site. La plupart des navigateurs ouvrent au maximum deux à quatre connexions simultanées pour télécharger une page depuis le serveur web, et les autres connexions doivent donc attendre. Il y a aussi un autre problème : votre domaine peut envoyer des cookies avec vos ressources, ce qui peut aussi dégrader les performances de la page.

La meilleure solution à ce problème est d’investir dans un vrai CDN (Content Delivery Network, réseau de diffusion de contenu). Les CDN sont optimisés pour servir des images et des ressources (sans cookies), ils ont leurs propres domaines, ils allègent la charge de votre serveur et ils sont répartis dans plusieurs centres de données (vos utilisateurs téléchargent donc les ressources plus vite, car elles sont proches d’eux).

Le problème : les CDN coûtent de l’argent.

Si vous pouvez vous le permettre, allez-y et prenez-en un (votre page se chargera plus vite). Sinon, vous pouvez obtenir certains avantages d’un CDN en configurant un sous-domaine pour servir ce contenu. Ce n’est pas un vrai CDN, car ce n’est pas un « réseau » (les données ne sont pas réparties dans plusieurs centres de données) et votre serveur doit charger et servir les ressources, mais vous profitez de davantage de connexions simultanées et vous vous débarrassez des cookies. Vous pouvez en voir un exemple sur cette page 🙂

Comme j’utilise NGINX comme serveur web, je vais vous montrer comment y configurer un sous-domaine de « faux CDN ».

Vous devez d’abord créer une nouvelle configuration de sous-domaine/serveur dans « /etc/nginx/sites-available » avec ce contenu :

 1server {
 2    listen   80; ## listen for ipv4
 3    listen   [::]:80; ## listen for ipv6
 4    server_name cdn.yourdomain.com;
 5    access_log /var/log/nginx/cdn.yourdomain.com.access.log;
 6    error_log  /var/log/nginx/cdn.yourdomain.com.error.log;
 7
 8    root /var/www/your/web/folder/;
 9    
10    include sites-available/cdn.conf;
11}

Vous avez deux options :

– utiliser le même dossier de contenu que votre installation ou votre page web actuelle (je le recommande si vous faites cela avec WordPress ou si vous ne voulez pas déplacer ou copier vos fichiers d’un dossier à un autre). Dans ce cas, la ligne « root /var/www/your/web/folder/; » doit pointer vers votre dossier web ou votre installation WordPress actuels.

– configurer un nouveau dossier vide (modifiez la ligne « root /var/www/your/web/folder/; » en conséquence) et y déplacer vos ressources.

Comme vous pouvez le voir, il y a un include (« include sites-available/cdn.conf; »). Je vais vous montrer le contenu du fichier cdn.conf (il comporte quelques ajouts pour les installations WordPress) :

Modifiez la ligne 7 pour rediriger vos utilisateurs vers une page d’erreur, ou créez la page 404.html dans votre dossier web.

Le fichier est commenté, si vous voulez en savoir plus. La configuration apporte quelques avantages, comme :

– Aucune exécution de PHP dans le sous-domaine.

– Cache navigateur maximal pour les images, le CSS et les autres fichiers statiques.

– Aucun cookie envoyé dans le sous-domaine.

Vous devez maintenant créer un lien symbolique du premier fichier que vous avez créé dans « /etc/nginx/sites-enabled » et redémarrer NGINX.

Votre sous-domaine doit maintenant fonctionner. Si vous avez choisi la première option (utiliser le même dossier de contenu que votre installation ou votre page web actuelle), vous pouvez accéder aux mêmes fichiers par votre nouveau sous-domaine. Par exemple, sur mon serveur :

http://jesus.perezpaz.es/wp-content/uploads/2013/03/mc-1-280×300.jpg -> http://cdn-jesus.perezpaz.es/wp-content/uploads/2013/03/mc-1-280×300.jpg

C’est la même image, mais l’une est servie avec la configuration par défaut du serveur et l’autre avec toutes les améliorations du nouveau sous-domaine.

Si vous avez choisi la seconde option, vous pouvez envoyer vos ressources dans le nouveau dossier et voir le sous-domaine fonctionner.

Vous pouvez faire des optimisations plus générales dans votre configuration NGINX. Cherchez sur Internet, il y a de nombreux sites avec ces informations 🙂

Configuration de WordPress et de W3 Total Cache

Vous avez donc maintenant votre nouveau « CDN » en marche et vous voulez l’utiliser dans WordPress… c’est facile 🙂

Je vais utiliser le plugin W3 Total Cache, car je l’utilise déjà pour d’autres améliorations de performance.

Dans la section « General Settings » (Performance > General Settings), activez « CDN » et choisissez « Generic Mirror » comme « CDN Type ». Cliquez sur « Save all Settings ».

Allez dans la section « CDN » (Performance > CDN). Trouvez la section « Configuration » et saisissez votre nouveau sous-domaine dans « Replace site’s hostname with ».

Cliquez sur « Test Mirror » et (si « Test passed » s’affiche) sur « Save all Settings » de nouveau.

Vous pouvez regarder les différentes configurations de cette page (les configurations par défaut doivent bien fonctionner).

Nous avons configuré le nouveau « CDN », qui sera utilisé pour les nouveaux fichiers envoyés et pour les ressources, mais nous pouvons aussi changer les images et les fichiers envoyés des anciens articles.

Pour cela, en haut de la même page (Performance > CDN), vous trouverez un bouton « modify attachment URLs ». Cliquez dessus, saisissez le domaine de votre blog ou de votre page (et non le nouveau sous-domaine « CDN ») dans « Domains to rename » et cliquez sur « Start ». Au bout d’un instant, toutes vos anciennes images seront servies par votre nouveau CDN.