Dans le généré d’une page web, il est assez fréquent de relever la présence d’une multitude de scripts.
Quelque soit le logiciel utilisé, vous pourrez observer le même phénomène.
Je vous propose d’étudier plus attentivement les causes et conséquences de ceci, et de voir comment éviter ces dernières.
Exemple une page web de Piwigo (que je connais encore fort bien):
<script type="text/javascript">
Shadowbox.init();
</script>
<script src="plugins/paMOOramics/js/mootools.js" type="text/javascript" charset="utf-8"></script>
<script src="plugins/paMOOramics/js/pamoorama0.3.js" type="text/javascript" charset="utf-8"></script>
<script src="plugins/grum_plugins_classes-2/ajax.js" type="text/javascript"></script>
<script type="text/javascript"> function roll_over_piclens(img_name, img_src){document[img_name].src = img_src;}</script>
<script type="text/javascript" src="./plugins/pwgCumulus/js/swfobject.js"></script>
Dans le cas présent, il s’agit d’un problème de plugins et nullement de Piwigo lui-même.
Le premier script, HDShadowbox, est présent dans toutes les pages picture.php, même si la page ne propose aucune image en haute définition, c’est pourtant sa seule raison d’agir.
paMOOramics est un contre exemple, il est présent uniquement dans les pages où il est réellement utile.
Le script grum_plugins_classes-2 (avec Piwigo 2.0) n’est pas utilisé dans les pages picture.php, son successeur pour Piwigo 2.1 ne génère plus ce script prouvant bien qu’il est possible de remédier au problème.
Je vous fais grâce de piclens ou de pwgCumulus qui n’ont en général rien à faire en page picture.php. Sachez qu’ils ne sont pas des exceptions et les plugins du même acabit sont nombreux.
Pourtant Piwigo présente l’incommensurable avantage de disposer de {known_script id=…} et de {html_head}.
Ces balises sont spécifiques à Piwigo, et Smarty devrait bien s’en inspirer. Elles simplifient radicalement la vie de tous les développeurs de plugins.
Il leur suffit d’incorporer directement ces balises avec les paramètres qui vont bien dans le template.
Dès lors si le template est mis en œuvre les scripts seront remontés dans le « head » de la page.
{html_head} … {/html_head} remonte le contenu avant la balise /head (également utile pour les styles).
{known_script id=…} évince les doubles inclusions d’un même script (exemple: un même framework par plusieurs plugins) et bien entendu remonte le script avant le /head.
Par exemple, pour pwgCumulus, actuellement nous avons dans pwgCumulusContent.class.php, ceci :
'src' => PWG_CUMULUS_PLUGIN_JS. '/swfobject.js'
),
$GLOBALS['template']->smarty
);
alors que dans le tags.tpl, il suffirait de coder:
Si le template est sollicité alors le module swfobject.js sera présent dans la page, dans tous les autres cas il n’apparaitra pas.
C’est super simple, c’est même plus lisible que les balises natives de Smarty.
Ainsi le script swfobject.js n’encombrera pas les navigateurs de vos visiteurs au moins pour la page en cours.
En principe, par leur présence dans une page web, les javascripts sont chargés par le navigateur, et analysés au niveau syntaxique.
Le fait d’éviter la présence d’un javascript inutile, multiplié par le nombre de visites (et donc de requêtes http), améliorera la disponibilité de votre bande passante et la vitesse d’affichage de vos pages.
La solution pour Piwigo doit pouvoir s’appliquer à tous les CMS, et autres systèmes basés sur l’usage de plugins et de frameworks.
WordPress: L’application propose une fonction assez proche de celle de Piwigo (fonction wp_enqueue_script), c’est seulement un peu plus compliqué. Cette fonction gère la dépendance au script parent et à la version. Pourtant la solution de Piwigo présente de nombreux aspects intéressants et avantages:
- Le premier plugin qui définit un script en fixe la version, il suffit aux auteurs de plugins de jouer sur les priorités des hooks (handlers, triggers), c’est plus simple.
- L’usage d’un moteur de template permet de remonter simplement les scripts en « head » lesquels n’ont vraiment rien à faire dans le « body » de la page.
- Les pages sont allégées des scripts inutiles, elles sont plus simples à relire, et plus faciles à déboguer pour ceux qui font du support.
- Vous obtenez une réduction du nombre de requête HTTP.
- Vous avez moins de scripts à analyser par les navigateurs et moins de risques de conflits entre les scripts.
Bonne interprétation.
