La librairie OpenLayers est constituée d'un ensemble de classe, de fonctions, de librairies externes, qui sont séparés dans 292 fichiers Javascript. Le principe de la construction de la librairie est de rassembler tous les fichiers pour n'avoir au final qu'un seul .js à mettre sur votre serveur web. Nous allons décrire ici la méthode qui permet de pour choisir quelles parties seront incluses dans le fichier final. Pour ma part j'ai l'habitude d'exclure tous les objets type Marker des cartes qui ne sont composées que de tuiles de bases, on enlèvera de même tous les contrôles inutilisés.

Tout d'abord, récupérez l'archive contenant les sources sur le site du projet, la version à la rédaction de ce billet est la 2.10.

wget http://www.openlayers.org/download/OpenLayers-2.10.tar.gz

Décompressez ensuite l'archive obtenue et placez vous dans le répertoire build qui contient les scripts de construction.

tar xvfz OpenLayers-2.10.tar.gz
cd OpenLayers-2.10/build/

On trouve dans le répertoires les scripts build.py et buildUncompressed.py écrits en python. Les fichiers de profile full.cfg library.cfg, et lite.cfg, le fichier de licence et un traditionnel README.txt qui contient un peu d'aide, juste un peu.

Le script nommé build.py prend 2 options. La première permet de spécifier le fichier de profile à utiliser (par défaut full.cfg) et la deuxième le nom du fichier généré (par défaut OpenLayers.js)

exécution du programme :

./build.py

ou

./build.py full

on note que le fichier de profil est à indiquer sans l'extension .cfg

build.py utilise jsmin (présent dans le répertoire tools/ de l'archive) pour minifier le code généré, si vous ne souhaitez pas le faire il vous faudra alors utiliser le script buildUncompressed.py pour construire votre librairie. La génération non compressée aboutit à un fichier de 2.6M, on réservera cette version pour les devs :-)

Par défault le script build.py utilise le fichier de configuration full.cfg qui comme son nom l'indique contient l'ensemble des librairies et classes du projet OpenLayers ainsi que les inclusions externes. Les fichiers sont placés dans le répertoire lib/ dans la racine de l'archive. La création du build full donne

Total files merged: 269
Compressing using jsmin.

Pour une taille de 929K.

Une compilation avec la configuration plus légère en utilisant le profile lite.cfg aboutit à 128K pour seulement 23 fichiers de sources utilisés, le gain est net et sans appel.

On aboutit avec ce fichier au minimum requis pour afficher une carte dans une page web, un minimum de contôles sont toutefois nécessaires pour permettre à l'internaute d'interagir sur la carte. C'est dans ce sens que j'ai créé le fichier ci-dessous qui me permet d'aboutir à un fichier de 154K ce qui fait tout de même un gain de 80% en taille.

[first]
OpenLayers/SingleFile.js
OpenLayers.js
OpenLayers/BaseTypes.js
OpenLayers/BaseTypes/Class.js
OpenLayers/Util.js

[last]

[include]
OpenLayers/Map.js
OpenLayers/Layer/TMS.js
OpenLayers/Control/Attribution.js
OpenLayers/Control/PanZoom.js
OpenLayers/Control/Navigation.js
OpenLayers/Control/ArgParser.js

[exclude]

Un fichier de profile se décrit en 4 sections qui contiennent chacune un ensemble de nom de fichier faisant référence au répertoire lib/ de la racine. Les fichiers présents dans include sont inclus dans le fichier final quand ceux de la section exclude en sont exclus. Il est possible de laisser la section include vide et de ne seulement spécifier que ceux qui ne seront pas utilisés, dans ce cas tous les fichiers sources sont inclus ; c'est d'ailleurs le choix fait dans le profil full.

Un fichier présent dans la section first sera inclus en début de processus, pour la section last il sera poussé à la fin du fichier, un fichier présent dans l'une de ces 2 sections doit figurer également dans la section include sinon une erreur se produit. La section include à prédominance sur la section exclude, un fichier présent dans les 2 sera inclus au final.

Dans la version par défaut la localisation française n'est pas incluse, on ajoutera la ligne "OpenLayers/Lang/fr.js" dans la section include pour corriger cela, raison de plus pour les francophones de construire eux mêmes leur librairie.

Il ne faut pas voir la finalité de la réduction de taille comme un gain en temps de transferts, au vu du volume de tuiles qui accompagnent une carte cela ne serait pas pertinent. Le gain le plus intéressant se trouve au niveau de l'exécution du code javascript dans le navigateur pour une part. D'autre part moins on à de code exposé, moins on a de bugs potentiels.

Un dernier intérêt à mettre en place cette méthode et vous l'aurez vite compris c'est que vous pouvez inclure votre propre code Javascript dans la lib et ne plus avoir qu'un seul fichier .js à charger pour animer vos cartes, et un fichier de moins, c'est une socket de moins, des octets en moins, une ligne de log en moins ...