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="https://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="https://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é).