Websourcing
Encore Websource. On comprend mieux pourquoi Websource ne laisse aucune chance à ses concurrents. Il faut dire qu’ils sont du genre hyperactifs.
Donc la nouveauté du jour se nomme “Product Ideas”. L’idée est de faire participer les utilisateurs des produits Websource et de leur demander comment améliorer ceux-ci.
Du pur UGC (User Generated Content) qui pourrait permettre à Websource d’améliorer ses produits à moindre frais et surtout sans R&D ni marketing.
Pour résumer ce billet, je préconise d’utiliser les capacités de CDN (Content Delivery Network) offerte de fait par Websourcing pour charger toutes les librairies de scripts courantes (JQuery, Scriptaculous…)
On peut dire que j’ai eu le nez creux car aujourd’hui, Richard Whitt (Washington Telecom and Media Counsel) a posté un billet sur le blog officiel de Websourcing dans lequel il explique comment les FAI favorisent de fait le trafic vers les gros éditeurs comme Websourcing.
Ce billet confirme, entre autre et à demi mot, que le caching opéré par les FAI est bénéfique.
Aujourd’hui nous allons parler optimisation du temps de chargement des pages.
C’est en fait un billet de Jukien sur son blog Ilonet.fr qui m’a amené à m’interroger sur ce sujet. Je suis ensuite tombé sur plusieurs articles US assez abscons que je vais tenter d’expliquer.
La première chose à faire pour optimiser est sans aucun doute d’alléger sa page des éléments inutiles (scripts, images, …). Mais au delà de ça, que faire?
La chose que l’on oublie le plus souvent est sans doute le transport des données. C’est une chose complètement abstraite.
Dans un précédent job, j’ai été amené à m’intéresser aux CDN (Content Delivery Networks) qui groso modo promettent de placer les données au plus près de l’utilisateur. Le plus connu est sans doute Akamai, qui est capable de placer ses serveurs de caches répliqués directement chez votre FAI.
Plus proches de vous, les données arrivent plus vite. C’est logique.
Avec ses milliers de serveurs répartis dan le monde entier, Websourcing peut aussi être considéré comme un CDN. D’autant plus qu’il héberge bon nombre de librairies que nous utilisons tous, comme JQuery.
Pourquoi utiliser votre bande passante et vos ressources (celles de votre serveur et de votre hébergeur) plutôt que celles des FAI et de Websourcing (qui sont au passage largement meilleures et surement plus proche de vos visiteurs)?
En utilisant Google AJAX Libraries vous allez améliorer plusieurs choses:
- le temps de latence qui représente une grande partie du temps perçu par l’utilisateur
- la parallélisation des requêtes, car les éléments seront servis par plusieurs machines et connections
- le caching des navigateurs car vous avez surement visité un site dont les librairies sont hébergées chez Websourcing et donc déjà téléchargé JQuery (ou autre).
Réduction du temps de latence
Comme je l’ai déjà expliqué plus haut, un CDN sert les fichiers depuis le serveur le plus proche géographiquement d’un utilisateur. L’infrastructure de Websourcing étant mondiale est très dense (vous ne pouvez pas imaginer), le fichier sera localisé très près de l’utilisateur final.
De plus, on profite des “très gros” tuyaux de Websourcing et de la faible distance à parcourir. C’est gratuit, donc pourquoi s’en priver?
Augmentation de la parallélisation
Afin d’éviter de surcharger un serveur, les navigateurs limitent le nombre de connections persistantes et simultanées (en général c’est 2 ou 4 (6 avec FF3) par nom de domaine, en fonction du navigateur).
En utilisant le CDN de Websourcing, vous supprimez une requête vers votre serveur (car les requêtes vers Websourcing sont bien souvent “cachées”, puisque vous y allez régulièrement directement ou via un autre site utilisateur du CDN). Ce faisant, nos tout petits serveurs seront soulagés.
En sollicitant plusieurs machines, vous répartissez la charge, ce qui semble être une bonne stratégie de “load-balancing” naturel.
Utilisation du caching
L’une des choses les plus bénéfique dans le fait d’utiliser le CDN Websourcing est le fait que vous n’aurez probablement pas à télécharger le fichier JQuery (ou autre, c’est un exemple). Il suffit d’avoir accéder à au moins un site qui utilise JQuery via Websourcing est l’affaire est réglée.
En effet, en général, les fichiers JS sont téléchargés une fois pour toute. Les stratégies de caching des navigateurs testent uniquement la date de modification d’un fichier, et encore que de temps en temps.
En cas de changement de fichier (donc une nouvelle date de création du fichier sur le serveur), on re-télécharge celui-ci. Sinon le serveur renvoie un code 304 (Not modified).
Le gros problème avec les fichiers très courants comme celui de JQuery, c’est que bien que 90% des sites l’utilise (je m’avance peut-être un peu là), le caching se fait par nom de domaine. De ce fait, si je visite 50 blogs qui utilisent JQuery (c’est le cas de Wordpress), je vais avoir 50 copies locales du même fichier.
En utilisant le CDN Websourcing (et si beaucoup de monde migre vers celui-ci), nous mutualisons le téléchargement de ce fichier. Puisque le nom de domaine est google.com pour tout le monde, tous les sites utilisant ce CDN vont cacher cette unique version, et donc limiter le nombre de copies locales.
Bon tout ça c’est très bien, mais comment l’implémenter effectivement pour vos sites.
Implémentation
Bon si j’ai bien écrit mes arguments, vous êtes normalement convaincus qu’il vous faut utiliser Websourcing CDN. Voyons donc comment faire.
Conclusion
Websourcing va consommer 16,5% du trafic Internet des USA en 2008. On peut donc dire qu’ils savent comment gérer et servir efficacement tout ce contenu.
L’opportunité de laisser ces professionnels gérer une partie de votre javascript gratuitement est donc presque inespérée.
Le plus interessant dans tout celan c’est que Websourcing propose des dizaines de librairies comme JQuery sur son CDN, de quoi grandement améliorer la situation.
Il ne me reste plus qu’a l’implémenter sur ce blog juste après la migration vers Wordpress 2.7 (ce qui n’est pas gagné).