Optimisez le temps de chargement de vos pages en utilisant l’infrastructure de Google
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, Google 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.

99% du temps, vous dĂ©clarez l’import de cette librairie par une directive comme celle-ci:
<script type="text/javascript" src="/js/jQuery.min.js"></script>
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 Google (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 Google 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 Google Ă©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 Google 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 Google, vous supprimez une requĂŞte vers votre serveur (car les requĂŞtes vers Google 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 Google 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 Google 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 Google (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 Google CDN. Voyons donc comment faire.
Première méthode: utilisation de google.load()
<script type="text/javascript"
src="http://www.google.com/jsapi"></script>
<script type="text/javascript">
google.load("jquery", "1.2.6");
google.setOnLoadCallback(function() {
// Placez ici le code d'initialisation
});
</script>
Cette mĂ©thode est somme toute bonne et amĂ©liore la situation par rapport au stockage local. Cependant, la mĂ©thode google.load() semble prendre un peu de temps Ă s’exĂ©cuter (jsapi) avant les requĂŞtes JQuery.

Les puristes pourraient y voir lĂ une faiblesse (1/10 de sec) mĂŞme si cette approche est tout Ă fait valable et bonne.
On peut cependant encore améliorer les performances.
Back to basics (retour aux sources)
Pourquoi ne pas utiliser les bonnes vielles mĂ©thodes (que Google supporte d’ailleurs)?
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js"></script>
<script type="text/javascript">
$(document).ready(function() {
// code d'initialisation
});
</script>
En faisant comme cela, vous évitez le délai introduit par jsapi, mais en plus vous supprimez 3 appels HTTP inutiles.
Conclusion
Google 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 Google 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Ă©).








Citer #1 par Jukien le 13 décembre 2008 - 10:40
Très bel article ; complet, expliquĂ© et argumentĂ©, c’est du bon travail.
Cependant, je suis un peu sceptique. En thĂ©orie, c’est certain, confier ces fichiers Ă l’infrastucture de Google ne peut ĂŞtre que bĂ©nĂ©fique. Mais en pratique, si je regarde mon site web : le fichier le plus long Ă chager est sans aucun doute la publicitĂ© Google Adsense. Et dans près de 90% des cas, le temps de latence pour charger le script JS de cette pub est au moins deux Ă trois fois plus Ă©levĂ© que celui des images ou fichiers que j’hĂ©berge sur mon serveur.
Après, c’est certain, cette publicitĂ© doit ĂŞtre utilisĂ©e par des centaines de milliers de sites web, ce qui n’est certainement pas le cas de JQuery. C’est vrai aussi que la comparaison est peut ĂŞtre hasardeuse : on ne peut pas ĂŞtre certain que Google utilise son CDN (ou du moins, un principe similaire) pour Adsense. C’est d’autant plus vrai que la publicitĂ© Adsense doit probablement communiquer avec un serveur central, listant les annonceurs, etc…
Cependant, avoir des graphiques comparant la latence et le temps de téléchargement entre le CDN de Google et un serveur local (mutualisé et dédié) pourrait être très intéressant.
Citer #2 par Lionel Roux le 13 décembre 2008 - 15:18
@Jukien – Merci Jukien pour ce retour complet et argumentĂ©.
Pour ce qui est de la pub adsense, c’est toujours plus long car la pub est contextuelle, et donc Google doit analyser la page avant de retourner les pubs « ciblĂ©es ».
Ensuite, pour ce qui est des script, c’est surtout lors du premier tĂ©lĂ©chargement que ce sera long, ensuite c’est dans le cache du navigateur. je pense que le gros gain est au niveau des copies locales.
J’ai dans l’idĂ©e que les FAI privilĂ©gient les communications avec les tiers de confiance type Google.
Je ferais un retour qd je l’aurai implĂ©mentĂ© sur ce blog. On verra bien ce que ça donne. Mais tous les sites us que j’ai lu Ă ce sujet sont dithyrambiques.
@bientĂ´t
Citer #3 par Plouceur le 16 décembre 2008 - 13:54
En fait il y a meme un plugin wordpress qui fait ca. Il remplace tous les scripts charges par la fonction enqueue par son equivalent Google AJAX API Library, en evitant les doublons si j’ai bonne memoire. J’ai tente son installation et vu une certaine amelioration, mais j’ai eu d’autres pb, des conflits de jscript apparemment qui sont lies a mon blog plus qu’au plugin qui semble tres bien marcher.
Si ca vous interesse, le plugin est http://blog.clearskys.net/2008/05/28/google-ajax-libraries-api-plugin/
Enoy!
Citer #4 par Lionel Roux le 16 décembre 2008 - 14:51
@Plouceur > Super. Merci je ne connaissais pas. je vais voir ça de ce clic.
Citer #5 par William Rey le 25 février 2009 - 13:32
L’idĂ©e d’utiliser la bande passante du voisin n’est pas nouvelle. Utiliser GOOGLE (ou un autre provider tel que Yahoo qui propose aussi des librairies telles que YUI) semble effectivement une bonne chose, cependant, j’Ă©mets quelques rĂ©serves:
1) on prend le risque d’une indisponibilitĂ© Ă©levĂ©e. En effet, si la disponibilitĂ© d’un serveur est estimĂ© Ă 99,99%, cela fait environ 8 secondes d’indisponibilitĂ© sur 24h soit environ 5 minutes par mois. Pour des sites comme GOOGLE ou YAHOO, cela semble raisonnable. Pour des sites plus petits, on va passer Ă seulement 99,9% de disponibilitĂ© soit 1 heure par mois.
Si vous ne dĂ©pendez que d’un seul site, tout va bien. Si vous dĂ©pendez de plusieurs sites (librairies Ă©parpillĂ©es), vous augmentez le risque de voir votre site moins disponible. N’oubliez pas que cette indisponibilitĂ© s’ajoute Ă celle de votre site.
2) Le changement d’adresse ou de version (mise Ă jour). Vous n’ĂŞtes plus maĂ®tre des informations tĂ©lĂ©chargĂ©es, elles dĂ©pendent de GOOGLE. Si ce dernier dĂ©cide de changer l’adresse des librairies, votre site est mort. De mĂŞme, si GOOGLE effectue une mise Ă jour incompatible, vous risquez de rendre votre site indisponible.
3) Juridique: on y pense moins. Vous accĂ©dez Ă un site externe qui va Ă©ventuellement « pister » le navigateur et/ou l’utilisateur. Il se peut que l’usage des donnĂ©es de connexion faites par GOOGLE soient incompatibles avec les conditions gĂ©nĂ©rales d’utilisation (CGU) de votre site.
4) anti-spam: si GOOGLE dĂ©cide qu’une connexion liĂ©e Ă un utilisateur est un « spam », il peut interrompre l’envoi du script Ă tel ou tel utilisateur sans que vous n’en soyez informĂ©.
Il reste nĂ©anmoins vrai que vous avez Ă©crit un excellent article, très bien documentĂ©. L’utilisation d’un site comme GOOGLE comme « cache » peut effectivement amĂ©liorer sensiblement les performances gĂ©nĂ©rales de votre site en particulier lors de la première visite de l’utilisateur et Ă©viter l’encombrement inutile du cache du navigateur par plusieurs versions du mĂŞme script.
Citer #6 par Lionel Roux le 26 février 2009 - 10:28
@William Rey – Tu as raison sur pas mal de points. NĂ©anmoins, l’approche reste valable pour des sites « amateurs » qui ne peuvent financer les serveurs et la BP comme une entreprise.
Depuis que j’ai installĂ© le plugin qui rĂ©alise cette opĂ©ration, mon site est beaucoup plus prompt Ă rĂ©pondre. Je n’ai pas regardĂ© les statistique en terme de charge serveur, mais ça doit surement jouer un peu. A tout moment je peux revenir en arrière, juste en dĂ©sactivant le plugin, sans changer une ligne de code, ce qui est un confort non nĂ©gligeable.
MĂŞme si les rĂ©cents Ă©vènements avec Google (panne Gmail et blacklist de tous les sites) nous montrent qu’ils ne sont pas infaillibles, ils seront toujours plus « pro » et « rapide » que moi pour rĂ©agir
Sur The Spirit of Wordpress # 2 ! | le blogueur masqué le 16 décembre 2008 - 07:54
[...] Optimisez le temps de chargement de vos pages en utilisant l’infrastructure de Google [...]
Sur Google Edge Caching: le bénéfice se confirme ! - WebSourcing.fr - Le Blog le 16 décembre 2008 - 17:52
[...] Samedi dernier je publiais sur ce blog un billet intitulĂ© “Optimisez le temps de chargement de vos pages en …. [...]
Sur UTILISER GOOGLE POUR CHARGER SES FRAMEWORK AJAX | La Geek Note le 19 décembre 2008 - 20:52
[...] source  [...]
Sur Pingdom analyse et détaille le chargement de vos pages - WebSourcing.fr - Le Blog le 7 janvier 2009 - 07:10
[...] qu’il y a quelques temps je parlais d’optimisation du temps de chargement des pages Web en utilisant l’infrastruc…, j’ai dĂ©cidĂ© de commencer Ă regarder comment allĂ©ger intrinsèquement mon [...]
Sur [Wordpress] GAL Plugin, substituez les versions locales de vos scripts par des versions Google - WebSourcing.fr - Le Blog le 6 février 2009 - 15:31
[...] un prĂ©cĂ©dent article, je vous expliquais pourquoi il est bon d’utiliser l’infrastructure de Google comme un [...]
Sur Minify, combinez, nettoyez, compressez et cachez vos scripts JS et CSS pour un site plus rapide - WebSourcing.fr - Le Blog le 22 mars 2009 - 10:01
[...] est ainsi possible de d’utiliser un CDN pour servir ses scripts (voir Optimisez le temps de chargement de vos pages en utilisant l’infrastructure de Google) ou de nettoyer ses scripts et CSS en supprimant les caractères non nĂ©cessaires (voir AmĂ©liorer [...]