CDN Gratuit : utiliser les serveurs frontaux de Google pour créer son Content Data Network

Un CDN (Content Data Network) permet à stocker des données statiques d’un site internet « in the cloud ». Cette méthode offre différents avantages non négligeables :

  • Réduction de la bande passante utilisée sur le serveur principal,
  • Réduction de la charge processeur sur votre serveur, l’économie peut-être consacrée au traitement des fichiers dynamiques,
  • Parallélisation des téléchargements côté client (donc plus rapide),
  • Les fichiers statiques sont servis à partir du serveur le plus proche de l’internaute, les « routes » sont donc plus courtes,
  • Les entêtes envoyées à partir du CDN sont personnalisables, il est donc possible d’envoyer du contenu sans Cookies (cookieless content) ni autres fioritures.

Bref, pour vous la faire courte, l’utilisation d’un CDN est un bon moyen d’accélérer l’affichage de son site tout en délestant son serveur.

Comment ça marche ?

Le principe est simple, le site web fait appel à votre domaine pour tout ce qui est dynamique et tout le contenu statique est appelé via un (ou plusieurs) domaine(s) dédié(s). Votre site utilise donc au moins 2 types d’url : www.mondomaine.ext et www.monCDN.ext.
Bien entendu, il est tout à fait possible de personnaliser l’url du domaine afin d’obtenir une adresse du type monCDN.mondomaine.ext, du coup, on ne touche pas au référencement et on n’en fout pas partout.

Dans la pratique, on peut se dire qu’il va falloir publier le contenu statique d’un côté, et le dynamique de l’autre. Ce pourrait être le cas, mais avec CirruxCache notamment (on y vient, on y vient) le principe est beaucoup plus simple :

  • Vous appelez une image sur le domaine du CDN : www.monCDN.ext/mon-image.png.
  • Soit cette image est présente sur le CDN est elle est envoyée directement au navigateur client,
  • Soit c’est la première fois qu’elle est appelée et le CDN va récupérer l’image sur votre serveur principal, la stocke, et la diffuse.

Bien entendu, des tâches automatiques nettoient régulièrement le CDN de manière à ne pas diffuser de contenu périmé. En gros le plus dur consiste à répartir les URL entre le serveur principal et le CDN, le reste se gère tout seul.

Les préparatifs

  • Si vous n’en possédez pas encore, créez vous un compte gratuit sur Google Apps Engine.
  • Ensuite, il faut créer une nouvelle application dans son compte App Engine. Donnez lui un nom et un titre. Dans les options de stockage « Storage Options (Advanced) » cochez l’option « High Replication ».

Création de la Google App

Le « réceptacle » pour notre application App Engine est créé, maintenant, on passe à l’application en elle-même.

  • Téléchargez et installez (en autorisant la création de liens symboliques sur Linux ou Mac) le Google App Engine SDK pour Python.
  • Téléchargez ensuite le dernier package de CirruxCache et décompressez le dans un coin.
  • Lancez GoogleAppEngineLauncher que vous venez d’installer avec le SDK pour Python et créez une nouvelle application.
  • Faites pointer l’application vers le répertoire de CirruxCache, mais surtout, ne donnez pas de nom à votre application au risque de créer un sous-répertoire ou d’écraser les fichiers de config déjà présents. On enregistre.

Configuration du fichier app.yaml

Cliquez ensuite sur le gros bouton « Edit » pour paramétrer votre appli (ou aller chercher le fichier app.yaml à la racine de CirruxCache) et remplacez la ligne

application: appname

pour lui donner le nom de votre application.

application: test-slt

On enregistre et ce sera tout pour ce fichier (trop dur j’vous dis).

Configuration du fichier config.py

Ouvrez le fichier config.py qui se trouve, lui aussi, à la racine de votre répertoire CirruxCache, via votre éditeur de sources habituel. C’est la partie la plus sensible du truc. Mais rien d’extraordinaire non plus hein ;-)

# EDIT BELOW
urls['default'] = (
		#'(/debug/.*)', 'Debug',
		'(/data/.*)', 'config.Static',
		'/www(/.*)', 'config.Www'
		)

# POP definition
# You can define and configure your Point Of Presence

class Static(cache.Service):
	origin = 'http://static.mydomain.tld'
	maxTTL = 2592000 # 1 month
	ignoreQueryString = True

class Www(cache.Service):
	origin = 'http://www.mydomain.tld'
	allowFlushFrom = ['127.0.0.1']
	forceTTL = 3600 # 1 hour
	ignoreQueryString = True
	forwardPost = False

Ce fichier est composé de deux parties. La première est une liste d’URL associée à une liste de fonctions. Selon l’URL appelée, on exécute telle ou telle fonction (dans notre cas, soit du cache, soit du redirect). Vous trouverez la liste des fonctions et leurs paramètres dans la doc de CirruxCache.

Dans mon cas, je suis sous WordPress, donc mes fichiers statiques sont dans /wp-content/ et dans /wp-includes/. Pour le reste, ce ne sera pas géré par le CDN.
Je vais donc configurer deux types de services : d’une part un cache pour tout ce qui est appelé sur les deux répertoires définis, et du redirect pour tout le reste.

Dans d’autres cas de figure, on aurait très bien pu imaginer un répertoire /images/, un répertoire /css/ et un répertoire /js/ par exemple. On aurait alors eu 4 URL renvoyant pour 3 d’entre-elles sur du cache, et pour les autres vers le site.

Un petit exemple valant mieux qu’un long discours, voici mon fichier de config actuel :

# EDIT BELOW
urls['default'] = (
		'(/wp-content/.*)', 'config.Static',
		'(/wp-includes/.*)', 'config.Static',
		'/(.*)', 'config.Www'
		)

# POP definition
# You can define and configure your Point Of Presence

class Www(redirect.Service):
	origin = 'http://www.souslestoits.net'

class Static(cache.Service):
	origin = 'http://www.souslestoits.net'
	forceTTL = 2592000 # 1 month
	allowFlushFrom = ['127.0.0.1']
	ignoreQueryString = True
	forwardPost = False
	headerBlacklist = ['Set-Cookie']

Vous noterez au passage que pour tout ce qui touche au cache, je vire le header concernant les cookies. On en a pas besoin puisqu’il s’agit de fichiers statiques et on économise un brin de bande passante. Cette ligne n’est pas impérative. Si vous appelez votre CDN sur un nom de domaine différent du site, aucun soucis. Dans mon cas, j’ai préféré l’appeler sur un sous domaine, donc les cookies du domaines ont tendance à se propager.

Tester son CDN

Une fois ces config faites, nous sommes prêts pour lancer l’application. On va tout de même tester avant. Il suffit de cliquer sur le bouton vert « Run » et l’application tourne alors en local sur l’ordinateur.
En vous rendant sur http://localhost:8080/ (le numéro du port est indiqué sur votre GoogleAppEngineLauncher), on doit obtenir une ligne du type :

CirruxCache (0.4.1) / http://code.google.com/p/cirruxcache/

Si c’est le cas, on appelle une image ou un fichier statique concerné par le CDN en remplaçant le nom de domaine par notre http://localhost:8080/. Dans mon cas, ça donne ça :

http://localhost:8081/wp-content/uploads/2011/01/xubuntu_logo1.png

Mon image s’affiche, j’ai réussi mon coup, mon CDN est prêt à être déployé.

Roule ma poule !

Pour le déploiement, c’est très compliqué : il faut cliquer sur le bouton bleu « Deploy » et rentrer les identifiants et mots de passe de son compte Google.
Un nouveau test sur l’application en production en remplaçant cette fois le http://localhost:8080/ par http://leNomDeVotreApplication.appspot.com et le tour est joué.

http://test-slt.appspot.com/wp-content/uploads/2011/01/xubuntu_logo1.png

Faire pointer votre application Google App Engine vers un sous-domaine

On peut en rester là. Appeler d’un côté les fichiers statiques sur http://leNomDeVotreApplication.appspot.com et le reste sur http://mondomaine.ext. Perso, je trouve intéressant d’utiliser un sous domaine pour mon CDN.

Pour ce faire, il vous faudra passer votre domaine sur Google Apps. C’est gratuit jusqu’à 50 utilisateurs et, si c’est juste pour faire pointer votre sous-domaine, vous n’aurez besoin que d’un utilisateur.

Au niveau de votre compte Google App Engine, dans « Application Settings » vous trouverez la rubrique « Domain Setup » qui vous permettra d’ajouter un domaine déjà passé sur Google Apps. Saisissez votre nom de domaine et validez les conditions d’utilisation.

Ajouter un domaine à une Google App

Il faudra ensuite retourner dans l’interface de Google Apps où vous trouverez maintenant votre application dans les « paramètres du service ». On peut maintenant ajouter un sous-domaine. Google sera alors fin-prêt pour recevoir les appels faits sur cette URL.

Faire pointer un domaine vers une Google App

La seconde phase consiste à faire pointer ce sous-domaine vers les serveurs de Google afin qu’il serve votre App. Cette étape là se passera chez votre hébergeur, dans la zone DNS.

Il vous faudra personnaliser un CNAME vers les serveur Google : ghs.google.com. Attention, le temps de propagation des DNS peut aller jusqu’à 72h, donc une fois fait, ça peut prendre un peu de temps avant que ça ne soit visible…

OVH : rediriger un sous-domaine

Et pour la gestion des URL du site alors ?

Si vous êtes sur une architecture propre, le plus simple à mettre en place reste les répertoires dédiés aux CSS, aux images de design et autres JavaScripts.

Pour les CMS, il existe le plus souvent des plugins ou des configurations qui permettent de rediriger facilement les images vers un CDN. Pour DotClear, il existe un plugin développé par Julien Murdy.
Personnellement, sur WordPress, j’ai choisi d’utiliser W3 TotalCache de W3Edge que je trouve très bien ficelé à plus d’un titre.

En guise de conclusion

La méthode a l’air un peu longue vue comme ça, mais c’est essentiellement parce que j’ai voulu détailler un max. Honnêtement, le tout se fait à peu près en une heure en tâtonnant un peu.
Google impose quelques limitations à l’utilisation de Google Apps, notamment au travers de quotas (au delà, l’utilisation est payante). J’attire votre attention sur le fait que les quotas sont quotidiens et non pas mensuels comme on a l’habitude de le voir. Donc du coup, ça peut tout de même supporter une sacrée charge.

Amusez vous bien ! Le premier qui coince laisse un commentaire ;-)

63 commentaires

  • Hey ! Super bon billet , merci d’avoir pris le temps!

  • Et alors il en pense quoi au final, ton blog, après s’être fait enclouder de la sorte ?

  • Merci pour ces informations très utiles car j’héberge mon site à domicile…
    on peut aisément imaginé le gain important qu’apporte cette solution en soulagant de manière dragstique, la charge du serveur HTTP !

    Cependant, je me heurte à une difficulté de base, à savoir, lorsque l’on me demande mon numéro de mobile au moment de la création de l’application, il est systématiquement refusé ?
    (The phone number has been sent too many messages or has already been used to confirm an )
    Alors du coup, je n’ai pas le plaisir de voir tout cela concretement !
    Je précise que j’ai respecté la règle du numéro de mobile, alors je comprends pas, aurai-tu une suggestion à me faire ?

    • Dans ton cas effectivement, déplacer l’hébergement des fichiers statiques peut être super intéressant (et puis ça laisse un peu de bande passante pour surfer ;-)

      Au niveau du numéro de mobile, je n’ai pas eu de soucis de mon côté. Tu n’a reçu aucun texto de Google du coup ?
      Peut-être possède-tu déjà un compte AppEngine joint à ce numéro (ça par contre, je me suis déjà fait avoir) ? Normalement, c’est un seul compte AppEngine par personne, d’où l’utilisation du numéro de mobile. Dans ce cas là, le téléphone d’un copain peut être utile (c’est pas bien… mais c’est efficace).

      Sinon, retrouver le compte avec lequel tu aurais éventuellement déjà essayé un truc il y a quelques mois / années…
      Théoriquement, Google vérifie le numéro de portable en t’envoyant un code à la 1ere appli. Après, tu as le droit d’en créer une dizaine sans qu’il ne te redemande quoi que ce soit.
      Bonne chance en tout cas, ce serait vraiment dommage que tu soit obligé de renoncer juste pour une histoire de numéro de téléphone.

  • C’est drôle, j’avais un doute concernant un ancien compte gmail !
    entre-temps, j’ai retrouvé le code SMS, mais cette fois-ci, c’est le compte que j’ai utilisé, bon ben, reste plus qu’a fouiller ( et encore, le mot est faible… )
    Encore, merci pour le billet et les infos supplémentaires et bonne continuation.

  • Salut, une petite mise au point pour te remercier.
    Après avoir retrouvé le compte qui a servi une première fois pour Google apps,
    j’ai entrepris et suivi à lettre les instructions de ce billet :)

    J’ai effectué toutes les étapes, à l’exception de la dernière ( problème particulier… )
    celles-ci se sont déroulés sans encombres jusqu’au test du CDN et de son déploiement.
    J’avais un petit soucis à savoir s’il fallait que l’application tournant sous Phyton, devait être constament en fonctionnement, car avec un serveur tournant sous Windows 2008, (couplé à un serveur Apache) lorsque l’on ferme la session, les applications en font autant.
    Et finalement, je me suis aperçu que ce n’était pas nécéssaire, dès lors que que le déploiement du CDN à été lancé.

    Alors je confirme, il faut bien attendre que la propagation se fasse avant que les images ne commence à réapparaîtrent… sinon ca donne une belle page d’acceuil avec pleins de trous en lieu et place des images (pas cool!)…

    J’utilise la plateforme de blog wordpress pour mon site WordPress auto-hébergé (in my home) et pour gérer le CDN, le cache que j’avais mis en place, n’est pas compatible avec cette option, donc je suis parti en quête d’un plugin gérant le CDN et j’ai opté pour WP Super Cache, ca n’a pas marché du premier coup, pour cause de compatibilité avec eaccelerator et memcache, j’ai d’ailleurs désactivé ce dernier et (oh! miracle, ca marche !!!).

    Je voulais te faire profiter de mes recherches, puisque tu utilise WordPress, j’ai pu glané cette info, une modification à faire dans le .htaccess, pour obliger WordPress à envoyer les données sur le,les serveurs CDN de Google, voici le lien:
    http://blog.gaetan-grigis.eu/systeme/administration/mise-en-place-dun-cdn-via-google-app-engine/

    Pour terminer, la dernière opération qui consiste à changer le, les CNAME chez l »hébergeur, dans mon cas, ce n’est pas possible, car je possède un nom de domaine gratuit avec un minimum d’options possibles (et… pas de CDN). Donc j’utilise comme tu le démontre dans ton article, le nom de mon application suivi du nom du serveur CDN.

    Voilà, j’ai été un peu long, mais c’est pour une bonne cause,
    salut et encore merci…

    • Merci bien pour ce petit retour.

      Juste peut-être une petite astuce sur l’utilisation du fichier htaccess pour renvoyer vers le CDN. C’est tout bête, mais ça fait une redirection de plus. Avec WP Total Cache, elle n’est pas obligatoire : tu as la possibilité (dans le menu performance => CDN) de donner directement l’URL de ton CDN. A partir de là, WP Total Cache envoi vers ton CDN tous les fichiers statiques en provenance des dossiers que tu as spécifié (le wp-content par exemple). Tu gagne une redirection… par fichier !
      Tient, au passage aussi, WP Total Cache peut gérer aussi le cache via la mémoire vive si tu veux le réactiver, tu trouvera ça dans les paramètres.

      Au niveau de CirruxCache, le principe de Google Apps est justement d’héberger l’application. Donc aucun soucis pour fermer la session tranquillement. Le GoogleAppEngineLauncheur n’est là que pour la configuration et le lancement.

      N’hésite pas au besoin ;-)

  • Bonjour,

    merci pour cet article. Je l’ai suivi avec succès mais j’ai l’impréssion que le cache n’est pas effectif, en effet lorsque je raffraichit ma page dans laquelle se trouve des images stockées dans le cdn, j’ai systématiquement une entrée dans les logs de mon serveur.
    Est-ce normal ?

    Merci encore !

    • Par Serge 

      @Lio : Désolé pour le manque de réactivité ces 3 derniers jours, j’étais en mode 18h/jour, ça ne m’a pas laissé tout le temps que j’aurais souhaité.

      Pour tes entrées logs, plusieurs réponses possibles :
      – Est-ce que tu utilise un système de cache est est-ce que tu l’a rafraîchis pour qu’il prenne en compte les appels vers le CDN ?
      – Est-ce que ton CDN a un temps de rafraîchissement du cache suffisant long ?
      – Est-ce que tu as une entrée dans les logs si tu appelle directement une image par son URL statique 2 fois de suite (auquel cas, ça vient de CirruxCache, sinon, c’est la config du site) ?

      N’hésite pas à laisser l’adresse de ton site internet pour que nous puissions jeter un oeil dans le code ;-)

  • Salut,
    Ben moi ça ne marche pas, le test ne fonctionne pas, j’ai ce message :

    App Engine program
    C:\CirruxCache\cirruxcache-0.4.2\dev_appserver.py not found.
    Cannot run projet C:\CirruxCache\cirruxcache-0.4.2\. Please confirm these values in your Preferences, or take an appropriate measure to fix it (e.g. install python).

    si tu pouvez m aiguiller ça serais cool
    Marciiii
    Yann

    • Hello Yann,
      Je viens de prendre le temps de faire quelques tests parce que je n’ai jamais rencontré de type d’erreur (OS Linux, liens symboliques, toussa toussa).
      Ce qui est étrange dans ton cas, c’est qu’il cherche le dev_appserver.py à l’interieur du répertoire de CirruxCache alors qu’il devrait le chercher à l’intérieur de celui de l’AppEngine.
      Je serais tenté de dire que l’AppEngine de Google s’est mal installé et qu’il lui manque certains morceaux…
      Regarde dans les options ou les préférences si tu n’as pas moyen de renseigner l’emplacement du moteur de l’AppEngine.
      Sinon désinstallation, réinstallation et croisements de doigts ;-)
      N’hésite pas à tenir au jus si ça continue à coincer.

  • Par yesman 

    Salut,

    Tres intéressant comme tuto mais pourrais tu préciser comment tu régles W3 total cache pour fonctionner avec ce CDN ? Car il y a des CDN pre-configurer Maxcdn,amazon ou des serveur tierce (connexion FTP) et je vois pas trop comment tu as pu configurer cela.
    Si tu pouvait nous éclairer sur ce point.

    • Par Serge 

      CirrusCache fonctionne en se « nourrissant » tout seul, c’est à dire qu’en fonction de l’URL appelée, s’il ne possède pas l’élément, il va le chercher sur le site d’origine. Donc côté remplissage, il n’y a pas de configuration ce qui simplifie pas mal le truc.
      La config de W3 TC consiste surtout à répartir les URL entre le CDN et le serveur d’origine.
      Dans la config générale, j’ai placé le « CDN Type » sur « Miorror » afin qu’il considère que tous les éléments statiques du site se trouvent dupliqués sur le CDN.
      Dans la configuration spécifique du CDN, j’ai laissé le « SSL support » sur « auto », j’aurais pu le passer sur « disable » pour faciliter la mise en cache des éléments côté client.
      Le plus important est certainement le champ « Replace site’s hostname with » où il faut aller placer l’adresse du CDN. Dans l’exemple du billet, ce serait « test-slt.appspot.com » ou « static.mydomain.tld ».
      A ce moment là, le CDN est actif pour W3 TC. Il faudra juste lui préciser quels sont les fichiers (« wp-include », « theme files », etc.) qui doivent passer par le CDN dans la partie « General » de la configuration du CDN.
      J’espère t’avoir éclairé sur la config, mais surtout s’il te reste des interrogations, n’hésite pas ;-)

  • Bonjour,

    J’ai franchi toutes les étapes avec succès, mais je coince sur le dernier test:

    http://viajarcuba.appspot.com/wp-content/uploads/2011/02/CASA-1-100×100.jpg

    se transforme en :

    http://www.alquilercasacuba.infowp-content/uploads/2011/02/CASA-1-100×100.jpg

    Il y a un problème de slash, alors que le même test avec wp-includes fonctionne bien.

    • Par Serge 

      Apparemment ton CirruxCache fonctionne parfaitement bien. Je soupçonne un gratouillage intempestif dans le HTACCESS.
      Un appel vers « http://alquilercasacuba.info/wp-content/uploads/2011/02/CASA-1-100×100.jpg » me renvoie vers l’appspot. Normalement il devrait me servir l’image (comme il doit la servir à Google). Jette un oeil sur tes redirections, tu dois avoir une petite ligne en trop ;-)

  • Hola,

    Je viens de m’apercevoir que cette image n’était peut-être pas un bon exemple (?), vu qu’elle n’est paen ligne en réalité. Avec par exemple « http://viajarcuba.appspot.com/wp-content/uploads/2011/02/la-habana-casa-estrella-sala-estar2.jpg », le test est bon. Avec « http://alquilercasacuba.info/wp-content/uploads/2011/02/la-habana-casa-estrella-sala-estar2.jpg », également.
    Le problème de slash a disparu, je ne sais pas trop bien comment j’ai fait (un peu compliqué pour moi le htaccess, surtout que j’utilise W3TC)…
    Cependant, deux points :
    1. sur Firefox le site ne s’affiche plus avec ma police @fontface (les polices se trouvant dans un dossier « font » dans mon thème, je suppose qu’elles sont envoyées au CDN)
    2. est-ce que le CDN est vraiment opérationnel? Les tests avec Yslow (je suis un maniaque de ces joujous) m’indiquent toujours la note F pour le CDN

    Merci !

    • Par Serge 

      J’ai rencontré le même problème avec les polices effectivement. L’idée consiste à utiliser soit une police dispo sur Google Web Fonts, soit de sortir le répertoire des polices du CDN en attendant une résolution du bug de la part de CirruxCache. Le problème ne porte que sur les polices du type Woff (donc Firefox). J’ai l’impression que le fichier de police n’est pas transmis en binaire.

      Sur le fait que le CDN soit opérationnel, YSlow ne reconnait effectivement pas GoogleApps comme un CDN, j’avais remarqué ça aussi. Yahoo ferait-il un petit pied de nez à Google ?
      Si tu utilise http://www.webpagetest.org pour tester, ça marche. De mémoire, Page Speed (l’outil Google) le reconnaît aussi.
      D’un autre côté, le principe de GoogleApps en High Replication, soyons d’accord, c’est le CDN à la base ;-)

      Sinon, pour ton problème de slash, quand tu te perd un peu dans les modifs de site, d’url et autres bizarreries de redirections, n’oublie pas de bien vider ton cache CirruxCache et celui de W3TC, je me suis fait avoir bon nombre de fois comme ça. Une vilaine impression que rien ne change…

  • bon alors j’aurai jamais 100/100 avec YSlow pour les options Yslow(V2) et Classic… :)
    Choses obscures pour moi dans ta réponse: « le principe de GoogleApps en High Replication, soyons d’accord, c’est le CDN à la base »… Je ne comprends pas vraiment ce que tu veux dire par là… Est-ce une invitation à créer mon sous-domaine avec google apps? J’ai cru comprendre que cela était meilleur pour éviter le duplicate content?
    Sinon, je passe mon temps à vider le cache de W3TC, bien sûr, par contre j’avais pas capté qu’on pouvait aussi vider celui de CirruxCache… Pourrais-tu m’indiquer la manip?
    Pour conclure, je reste encore sceptique avec le CDN, car j’ai l’impression que mon site rame un peu depuis que je l’ai installé… A propos de W3TC: depuis la dernière actualisation, tu n’as pas eu des problèmes de minifiacation? Pero, j’ai laissé tomber la minif css (perte des feuilles de style sous chrome, opera et safari) et la js (perte des cartes google) alors qu’auparavant ça marchait très bien… Par ailleurs, en affichant le code source de mes pages, alors que j’avais encore la minification activée, je constatais que mes feuilles de style n’étaient pas rassemblées en une seule dans un fichier créé par W3TC, bref : l’impression que la minif ne fonctionne plus du tout avec W3TC ou alors quelque chose m’échappe, ce qui ne me surprendrait pas :)

    • Par Serge 

      High replication : le principe de cette configuration consiste à répliquer les contenus de l’app sur un maximum de serveurs. Or si Google place le contenu sur différents serveurs, c’est pour pouvoir y accéder de différents endroits. C’est bel et bien un CDN.
      Au niveau du sous-domaine, oui, je t’invite à le faire, mais pas pour des raisons de duplicate content. De ce côté là, le CDN stocke du fichier statique, donc des images, des CSS, il renvoi vers le site d’origine pour les contenus texte. Pas de risque de duplication de contenu donc. En revanche, au niveau référencement, ça te permet de changer de CDN un jour (ou d’abandonner l’idée peut-être) tout en conservant le référencement des contenus statiques sur ton sous-domaine. En gros, si un jour l’envie de prend, tu peux simplement renvoyer ton sous domaine sur les images du site ;-)

      Pour vider le cache de CirruxCache (ou gérer certains trucs), tu appelle ta GoogleApp en ajoutant /_admin/ dans l’URL. L’identification sera celle de ton app. Il suffit ensuite de lui donner l’URL du fichier à nettoyer.
      Tu as aussi toute l’interface de gestion de ton app à disposition sur https://appengine.google.com/

      Je n’ai pas rencontré de problème particulier sur W3TC. Après, je dois avouer que ce n’est pas celui que j’utilise en prod (WP Super Cache + DB Cache Reloaded). Ceci étant, côté minification, rien ne vaut un bon travail à la mimine. W3TC le fait, mais il faut faire attention à l’ordre des fichiers, il est pointilleux. Et il y a régulièrement un ou deux fichiers qui coincent…

  • Regarde ce que je viens de trouver dans la FAQ de W3TC :
    « If you want an accurate score for your web site, you can add your CDN hostnames to YSlow using Firefox’s preferences. Here are the steps to follow:
    Go to about:config in Firefox. You’ll see the current list of preferences.
    Right-click in the window and choose New and String to create a new string preference.
    Enter extensions.yslow.cdnHostnames for the preference name.
    For the string value, enter the hostname of your CDN, for example, mycdn.com. Do not use quotes. If you have multiple CDN hostnames, separate them with commas.

    If you specify CDN hostnames in your preferences, they’ll be shown under the details for Rule 2 in the Performance view. »

    Je vais essayer…

    • Par Serge 

      Oui, ça fonctionne. Je l’avais déjà fait. Mais c’est toujours un peu frustrant d’avoir à lui dire qu’on a finalement bien fait un truc, c’est quand même plus sympa quand il nous le dit tout seul du premier coup ;-)

  • oui c’est vrai… Sauf que malgré ça la note n’a pas changé ! :(
    Mon site rame décidément trop depuis que j’ai installé le CDN, je vais devoir le mettre en stand-by en attendant de revenir sur le problème

  • oublié de préciser avant: merci beaucoup pour ton aide !

  • J’ai juste désactivé la mise en cache du CDN dans W3TC et _ça va un peu mieux point de vue vitesse du chargement, même si c’est pas top il me semble… Et la police @fontface est revenue…
    Ce plugin W3TC est très puissant mais aussi hypersensible !

  • Salut Serge,
    depuis Février dernier, ca roule avec le CDN de gogole…
    Cependant, j’aimerais apporter un petit plus pour ceux qui utilisent WordPress,
    il y a un plugin que l’on peut comparer a celui d’un CDN, bien qu’à l’origine il ne soit pas prévue a cet effet. Je veux parler de (ImageShack Transloader) http://www.dowordpress.com.br/plugins/imageshack-transloader/ ou sur WordPress, http://wordpress.org/extend/plugins/imageshack-transloader/

    Ce plugin transfère toutes les images du billet, au moment de sa publication, sur un compte ImageShack.us, il suffit de créer un compte gratuit et c’est parfait.
    Je lui donne une note supérieure a celle de Google, car les réponses de leurs serveurs sont beaucoup plus rapides. En faisant des tests avec Google, les résultats étaient plutot décevants, et trés souvent les images s’affichaient plus rapidement à partir de mon serveur.
    Le gain principal étant la charge, processeur et mémoire, mais depuis couplé à ImageShack, j’ai carrément divisé par deux voir plus le temps de réponse et d’affichage de la page !

    C’est pourquoi je le recommande vivement.
    J’ai aussi changé de cache, mais j’y reviendrais une autre fois…
    J’espère avoir apporté un peu d’eau à ton moulin !
    et je m’adresse a tes lecteurs, si vous avez d’autres petites soluces dans ce genre, faites-passer…

    • Par Serge 

      Merci beaucoup Claude pour ton commentaire enrichissant. Je ne connaissais pas ImageShack, ça a effectivement l’air pas mal pour héberger les images (mais il manquera les CSS et les JS ;-) ! Google est très bien pour créer un cdn sans bourse délier, ceci dit, il accuse parfois quelques lenteurs, j’en conviens, surtout quand on est déjà hébergé chez un bon prestataire. Il y a aussi un très bon article du grand-monsieur qui parle de Cloudfalre, il faut que je teste : http://korben.info/cloudflare.html
      Niveau cache, j’ai aussi changé de méthode, mais je ne suis toujours pas super-satisfait par rapport aux vitesses de réactions que j’ai connu avec Dotclear. Si tu as des pistes sur le sujet, je suis preneur !

  • Bonjour, merci pour cet article très clair et intéressant.

    Je débute dans le sujet et voulais savoir ce que vous pensiez d’une configuration de ce genre dans le mappage des URLs :

    '(?i)([\w\d\-/]+\.(?:js|css|jpe?g|png|gif|ico|htc|ogg|mp4|webm|ttf|otf|woff|eot|svg))', 'config.Static'

    Parce que ça m’a l’air de fonctionner en local mais je n’aimerais pas proposer quelque chose de mal conçu…

    L’idée c’est que les fichiers statiques ne sont malheureusement pas toujours bien proprement rangés dans des répertoires dédiés, dans quel cas une configuration basée sur les extensions serait bien pus pratique non ?

    Merci par avance :)

  • Salut Serge,
    de retour…
    lors de mon dernier message, j’ai oublié de préciser que je cumule le CDN de Google et les serveurs de Imageshack.us, ce qui sous entend que tous les fichiers et dossiers du répertoire wp-content continue d’être transmis sur mon cdn, cgweb.appspot.com et en parralelle les images de tous les nouveaux billets sur Image Shack et pour te dire, je n’ai pas trouvé mieux pour le moment.

    Bon pour l’instant, j’oublie les performances du site, à cause d’une panne matériel de mon serveur…

    Ce dont je voulais parler, c’est du cache pour WordPress, j’ai du abandonner WP Super Cache, car trop de difficultées de réglages, de plus lors des tests, j’ai la base de données qui à été altérée !
    résultat: à la corbeille !!!
    J’ai utilisé en premier un cache nommé : WP File Cache
    http://wordpress.org/extend/plugins/wp-file-cache/
    verdict, plutot satisfaisant, mais depuis quelques temps j’utilise un autre plugin de cache :

    Quick Cache Plugin For WordPress®
    http://www.primothemes.com/post/product/quick-cache-plugin-for-wordpress/
    http://wordpress.org/extend/plugins/quick-cache/screenshots/
    configuration simple, pas de conflits et performances au rendez-vous et à moins de trouver mieux, je ne suis pas prêt de le remplacer.

    Info supplémentaire, jai aussi un autre plugin qui permet de réduire le nombre de requêtes a la BDD en les mettants en cache: DB Cache Reloaded Fix
    http://wordpress.org/extend/plugins/db-cache-reloaded-fix/
    là aussi, no conflicts entre Quick Cache et DB Cache, au contraire, à croire qu’ils ont étés fait pour bosser ensembles !

    J’ai cependant remarquer une chose valable pour la majorité des systèmes de cache, ils ont la facheuse tendance à écrire les fichiers temporaires dans des sous-dossiers de WP-Content, ce qui peut poser problème lors de l’affichage en provenance du CDN.
    mon conseil d’utilisateur (averti) car je n’ai pas les compétences d’un programmeur, il faut déplaçer le dossier temporaire en amont afin qu’il ne soit pas contenu dans celui de wp-content…

    Au besoin, avec le peu de connaissances que j’ai en PHP, j’ai modifié le/les scripts de cache.

    Voilà pour ces infos, j’essairai de faire un billet à ce sujet avec prise de tête… heu !, de capture d’écran et les explications qui vont avec…
    bonne continuation…

  • Bonjour,

    J’ai lu le blog et je n’ai pas compris le but! J’ai déjà un compte Google App Engine mais avec une application encore vide dedans!

    Le but est-il de feindre Google en n’utilisant App Engine que comme un CDN?

  • Bonjour,
    Cette méthode fonctionne parfaitement (fait sur mon site personnel) .
    1) dans le fichier config.py, section « urls[‘default’] » j’ai indiqué
    ‘(/images/.*)’, ‘config.Static’,
    ‘(/css/.*)’, ‘config.Static’,
    ‘(/font/.*)’, ‘config.Static’,
    ‘/(.*)’, ‘config.Www’
    Ainsi toutes mes références vers /images/, /css/ et /font/ sont chargées via le(s) CDN

    2) dans le fichier config.py, section « Www(cache.Service) » mettre des éspaces et non un tabulateur

    3) Les résultats sont probants (http://www.webpagetest.org/ le 14/10/2011)
    avant utilisation 98/100 DAAAAX
    après la mise en place 98/100 BAAAAV. Le « First Byte Time » a profité des CDN.

    Je dis respect !

    Emile

  • Je suis arrivé à 99/100 BAAAAV. Mais je doute que le CDN influence le « First Byte Time »
    http://www.webpagetest.org/result/111019_6D_1XZJF/
    Emile

  • Merci pour l’article super intéressant et j’ai découvert de bons plugins wp dans les commentaires :)

  • Bonjour,

    Je suis très intéressé par votre méthode. Mais tout de même : Est-ce réellement efficace ? Voit-on vraiment la différence ? J’ai fais un tet avec WebPageTest pour votre page d’accueil, celle-ci prend 9,461s en « Fully Loaded », beaucoup moins en « Document Complete » il est vrai. Gtmetrix, un autre outil de mesure, vous est par contre nettement plus favorable (2s).

    • @Olivier : Rassurez moi, pour WebpageTest, le test à été réalisé à partir de Dulles au USA ? Sinon je retourne de suite bosser mon optimisation.
      Plus sérieusement, les tests actuels ne reflèteront pas les avantages du cloud Google et pour cause, je ne l’utilise plus. Je passe aujourd’hui par CloudFlare qui est plus simple et plus transparent à mettre en place (juste un jeu de DNS), il faut que j’écrive un billet dessus (déjà promis plus haut). Dans mon cas, je me sers toujours des CDN pour les fichiers statiques, donc je gagne, mais certainement pas autant que si je m’en serais aussi pour les pages en elles-mêmes. De ce côté là, j’utilise WP-Super-Cache. Il fait ce qu’il peut, mais la page Php est toujours appelée de mon serveur, ce qui peut expliquer une certaine latence sur un test à partir d’un point éloigné. Attention aussi à ma page d’index, elle est fourbe et fait notamment intervenir des vidéos hébergés par d’autres techno.
      Perso, je suis intimement convaincu du bienfait des CDN. Le hic, c’est généralement leur prix. N’hésitez pas à faire un petit test avec CloudFlare (www.cloudflare.com), ça ne devrait vous prendre qu’une dizaine de minutes et je suis preneur de vos résultats ;-)

  • Merci de votre retour, personnellement j’ai installé wp super cache avec les options de configurations minimum, et c’est vraiment efficace. J’ai remarqué que ce qui grévait le plus mes performances était l’ajout de scripts dans le fichier functions.php et je ne sais pas pourquoi (j’ai créé mon thème moi même)…

    Du coup ce fichier ne comprend que le strict minimum. Je recherche cependant des solutions pour optimiser mon site. Pour le test sur http://www.cloudflare.com il faut s’inscrire… je verrais.

    • Selon ce que vous demandez à votre fichier functions.php, il peut prendre un peu de temps à s’exécuter, WP-Super-Cache peut en grande partie régler ce problème, notamment via le préchargement des pages. n’hésitez pas à vous pencher sur les options de ce plugin, il y a plein de choses sympa.
      J’ai récemment lu un excellent article de Daniel Roch sur l’optimisation des thèmes WordPress si cela vous intéresse : http://www.seomix.fr/optimisez-vitesse-wordpress-theme/ Une lecture un peu « dodue » mais très enrichissante.

  • Par jerome 

    Bonjour
    je suis en train de mettre en place le CDN, mais je me demande : ou installe-t’on le package SDK python. Sur le serveur web normal ? (question peut-être)

    • @Jérôme : Sur ton ordinateur.
      Le SDK est le logiciel qui va permettre de préparer en local l’application qui sera ensuite envoyée sur les serveurs de Google.
      Il en va de même pour l’ensemble des éléments de la rubrique « préparatifs » : tout se passe sur l’ordinateur de développement. Seuls les résultats seront envoyés en ligne.

      • Par jerome 

        ok merci
        je n’étais pas sûr.
        Merci pour la réactivité.

        • Par jerome 

          Encore une question.
          Ca marche tellement bien pour les images que je serais tenté de mettre les css et les js également en accès par le CDN.
          Est-ce une bonne idée ?

          • Oui, c’est une bonne idée pour tout ce qui est statique. CSS, JS, IMG, SWF, etc…
            Attention cependant à la mise à jour d’un CSS ou d’un JS par exemple, il faudra soit purger le fichier du cache du CDN, soit attendre son expiration.

  • Par jerome 

    Bonjour
    y a t’il récursivité des sous dossiers dans la configuration des dossiers dans le fichier config.py du SDK.
    Je veux dire, si j’ai un dossier :
    /images/mini
    /images/big
    /images/special
    et que je mets ‘(/images/.*)’, ‘config.Static’,
    aurais-je un traitement des images de tous les sous dossiers ?
    ou fait-il que je mette
    ‘(/images/big/.*)’, ‘config.Static’,
    ‘(/images/mini/.*)’, ‘config.Static’,
    ‘(/images/special/.*)’, ‘config.Static’,
    Merci encore
    après je me fais oublié ;-)

    • Bonjour Jérôme,
      ‘(/images/.*)’ suffira. Le serveur recherche cette chaîne dans l’URL. Donc cette partie de chaîne sera reconnue dans tous les sous dossiers. Pas de problème de ce côté là.
      N’hésite pas si besoin, c’est à ça que servent les blogs ;-)

      • Par jerome 

        Merci Serge
        je n’arrête pas de jouer avec le CDN. C’est vraiment pratique et rapide.
        Question : comment forcer un vidage du cache du CDN pour forcer une mise à jour d’un fichier CSS (par exemple)

  • Par jerome 

    réponse trouvée dans cette même page !
    url de l’app/_admin/
    sorry
    a+

  • Par Jessy 

    bonsoir , j’ai suivie votre tutoriel (complètement), cela fonctionne , j’utilise W3C et je ne sais pas quoi choisir comme option pour les CDN je ne sais pas si cela a de l’importance mais j’aimerai avoir votre avis
    Voici l’image : http://www.imagup.com/data/1152472267.html
    J’ai choisi au pif ne sachant pas quoi prendre … je voudrai votre avis .
    Cependant mon site ne s’affiche rapidement , je voudrai que ce soit quasiment instantané . (cependant c’est pas mal pour l’offre gratuite de Google , peut être prendre la payante aiderait ? meilleur serveur ?)
    Quel est selon vous le meilleur CDN à une prix raisonnable .. pour un chargement très rapide .

  • Trés bon tuto, assez simple à mettre en oeuvre et gain très important : un grand merci !

  • Salut et merci pour le tuto,

    Malheureusement, de mon côté cela bloque au niveau du déploiement. Je dois avouer que le test en localhost ne fonctionne pas non plus.

    Voici l’erreur déploiement : 2013-12-13 23:49:16 Running command: « None »

    Un ptit coup de main serait pas de refus,

    Zedd du site http://www.avisdupublic.net

    • Oki c’est bon sauf pour pour W3TC , j’ai beau mettre mirror et mon appli.appspot.com il me dit qu’il ne le trouve pas (je n’ai pas fait la partie sous domaine, est ce la cause ?)

      • La partie sous-domaine permet de personnaliser le résultat et de masquer la présence de Google, donc de changer de CDN en cas de besoin. Elle ne sera pas impérative en soi, techniquement, ça fonctionne avec un sous-domaine de Google.
        Si le premier test de la partie « Roule ma poule » de mon billet (un appel d’URL de type http://test-slt.appspot.com/wp-content/uploads/2011/01/xubuntu_logo1.png) fonctionne, c’est que la partie W3TC n’est pas configurée comme il se doit.
        Sinon, c’est la partie CDN qui coince.
        Attention à bien utiliser l’URL « appli.appspot.com » avec le nom de votre app à vous, typiquement mon-app-a-moi.appsport.com.
        Perso, j’ai fini par me rabattre vers CloudFlare par fainéantise ;-)

        • Salut Serge et merci du passage.
          J’ai fait la même chose et je n’ai pas trouvé de grande amélioration avec CloudFlare. Ma note Yslow est montée et celle e page speed est beaucoup descendue. En même temps, le site a beaucoup d’image dès le /home donc pas facile pour monter les stats.

          Merci du SAV.

          P.S. Je ferai un billet avec un link sur votre méthode, elle peut être utilie à la communauté.

          Zedd du site http://www.avisdupublic.net

          • Ah… je vais peut-être mettre à profit les congés de Noël pour regarder mes scores de plus près alors… Merci du tuyau !
            Et si la méthode fonctionne toujours et qu’elle peut être utile à quelqu’un n’hésitez pas pour le lien ce sera bien entendu avec grand plaisir ;-)

  • Bonsoir.
    Je voulais vous remercier pour votre super article. très intéressant. je voulais juste savoir pour la fin du tutoriel, il y a t il quelque chose a installer sur l appli google, les redirections sont elles faites automatiquement ? la fin du tuto est un peu flou pour moi. Je suis sous wordpress,mais j utilise wp-rocket pour la mise en cache et il ne prend pas en compte les CDN . comment puis je faire pour rediriger vers google ?
    Merci .
    Miguel

    • Bonsoir,
      Merci pour votre compliment. Ce billet décrit essentiellement la mise en place du CDN, donc la duplication automatique du contenu statique en un autre point de stockage. Il vous faudra donc appeler le contenu statique à partir de cet autre endroit et je comprends pleinement qu’en utilisant wp-rocket, vous n’ayez pas envie de passer par un autre outil de cache.
      Dans votre cas, j’aurai tendance à vous conseiller de réécrire les liens vers les fichiers statiques directement au sein de WordPress, avant la mise en cache. L’idée sera d’appeler le HTML sur votre serveur et que la page renvoyée fasse référence à votre CDN pour tout ce qui concerne les images, les CSS, etc.
      Des plugins du type « WordPress CDN Rewrite » vous permettent ce genre de choses. Ils enverront les URL réécrites et ce sont ces dernières qui seront mises en cache par wp-rocket. Du coup, vous n’aurez pas le moindre ralentissement à la lecture des pages mises en cache tout en bénéficiant des effets du CDN en prime.
      Je n’ai pas testé « WordPress CDN Rewrite » mais c’est le principe de fonctionnement et de réécriture pré-cache qu’il faut retenir.
      J’espère que ces quelques lignes vous auront aidé sur la finalisation. N’hésitez pas si ce n’était pas le cas.

  • Bonsoir Serge.
    Encore un super merci pour votre aide. j ai donc instalé WordPress CDN Rewrite et fait plusieurs tests.
    J ai juste un doute sur l’adresse a renter pour les redirections. serait il possible que cela donne quelque chose comme cela ? ( http://static. MonMomDeDomaine.com ) redirigé sur ghs.googlehosted.com ?
    Mais dois je aussi créer un sous domaine ( static. MonMomDeDomaine.com ) chez mon hébergeur ?
    je patoge un max là. je viens de prende un gompte googla apps mais j avoue avoir du mal a finalisé la procédure pour les redirections.
    Ou puis m’assurer que les redirections ont bien été prise en compte ? Heeeeeelllll p :)

    merci. Miguel

Ajouter un commentaire