Discussion :

[_skip]

Bonjour,

J'ai pour habitude de stocker les codes javascript réutilisables dans des fichiers externes et les codes plus locaux à une page (genre ceux qui référencent des IDs et des éléments spécifiques) directement inline dans des balises script en fin de document.

Je peux constater sur d'autres forums (stackoverlow pour ne pas le citer) que de plus en plus de gens suggèrent d'externaliser systématiquement tout le JS dans des fichiers externes. Soi-disant ce serait meilleur pour le caching (mais à ma connaissance c'est tout de même au prix d'une connection supplémentaire, il me semble que google page speed suggérait plutôt d'embarquer quand je l'utilisais) et c'est facilement optimisable et minifiable.

Dans mon cas cela voudrait dire une quinzaine de fichiers JS supplémentaires, cependant je dois reconnaître que mes balises script sont parfois grandes et que le mélange html et js embarqué est parfois un peu pénible à la lecture. Un peu de séparation serait donc bienvenue... Pour être honnête, je ne sais pas trop s'il y a des bonnes pratiques admises par tous en la matière. Je réfléchis aussi à utiliser un loader au cas où je me mettrai à beaucoup externaliser, je sais pas trop...

Vous qui avez l'habitude, quelles sont vos stratégies d'externalisation?

[boboss123]

salut,

Je ne suis pas sure que l'on puisse définir une règle générale tellement les systèmes sont hétérogènes (surtout avec l'augmentation des appareils mobiles).

Sur les systèmes embarqués, le nombre de connexion est très limité : il faut donc limiter le nombre de fichier au maximum ...

Si tu mets tous tes éléments "static" dans un seul fichier, tu auras donc des perf optimales (le cache marchera et tu aura un nombre de connexion réduites).
=> par contre pour la maintenance du code, ce n'est pas top pour s'y retrouver.

Remarque : les pages static peuvent etre compressée à l'avance (GZIP) ce qui aussi améliore les perf

[_skip]

Hello,
Je te remercie pour ta réponse, j'ai pas répondu tout de suite pour laisser le temps aux autres mais je crois que c'est tout ce que j'aurai.
++

[SpaceFrog]

c'est tout de même au prix d'une connection supplémentaire

pour le premier chargement
les autres connections se faisant vers le cache

[roood]

Si tu as une quinzaine de fichier, je te conseil d'utiliser require.js pour charger tout dans la page.

Ça donne l'habitude de coder tout en petit modules indépendant, puis ils pourront être compatible avec Node.js si un jour tu voudrais les porter sur le serveur.

De plus, ça prend une simple commande dans ton terminal pour executer r.js qui condense tout en 1 fichier. Et tu peux faire plusieurs "build" pour tes differentes pages

[sekaijin]

Il y a deux caches à prendre en compte.

solution 1 html purement statique + js inline

1ere ouverture:
connexion -> download -> mise en cache web -> compilation js -> mise en cache js -> exécution

ouverture suivantes:
lecture dans le cache web -> compilation js -> mise en cache js -> exécution

solution 2 html dynamique + js inline

toutes les ouvertures
connexion -> download -> mise en cache web -> compilation js -> mise en cache js -> exécution

solution 3 html statique + js externe

1ere ouverture:
connexion -> download -> mise en cache web -> affichage
connexion -> download -> compilation js -> mise en cache js -> exécution

ouverture suivantes:
lecture dans le cache web -> affichage
lecture dans le cache js -> exécution

solution 4 html dnamique + js externe

1ere ouverture:
connexion -> download -> mise en cache web -> affichage
connexion -> download -> compilation js -> mise en cache js -> exécution

ouverture suivantes:
connexion -> download -> mise en cache web -> affichage
lecture dans le cache js -> exécution

en conclusion lorsque le js est externe il est compilé et mis dans le cache js déjà compilé
il est donc dispos pour tous les appel suivants, il est simplement exécuté.
c'est pour cette raison qu'on voit des appli qui n'ont qu'une seul JS contenant tout le code même si tout n'est pas utilisé dès le début.

le cas le pire (et pourtant celui que l'on voit le plus souvent) le js enbarqué dans du html dynamique (génré)
dans ce cas le js est rechargé à chaque appel mais en plus il est recompilé à chaque fois avant d'être exécuté.

perso je penche donc toujours vers l'externalisation.
mais je suis quelqu'un de pargmatique
si le js est tout petit (juste quelque ligne) le coût de recompilation est négligeable.

dans mes dev j'ai généralement un seul html qui est

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
<html>
  <head>
    <link href="app.css" />
    <script src="app.js" />
  </head>
  <body />
</html>

la question ne se pose donc pas.

A+JYT

[_skip]

Merci,
Mais cela peut aller jusqu'à un fichier par page quasiment, c'est jouable? Ou alors un loader est-il nécessaire?

[sekaijin]

l'intérêt du cache ne se fait sentir que si on s'en ressert

Il faut donc trouver l'équilibre entre 1 seul gros fichier js qui contient tout et qui mets du temps à se charger la première fois, mais qui te garanti un accès rapide par la suite, et une multitude de petits scripts qui sont rapide à charger, mais on en charge souvent.

Un détail sur les moteurs js modernes. Ils utilisent tous aujourd'hui un compilateur. Mais aussi des optimisations.

Lorsque un fichier js est chargé il est analysé, mais pas compilé. Le moteur garde cette analyse sous le coude.
Toutes les définitions globales sont mises en cache, mais pas nécessairement leur contenu.
Ainsi une fonction va être déclarée, mais pas compilée. Le moteur va juste garder le fait que la fonction existe et l'associer avec l'analyse de la portion de code la définissant.
Cela évite de traiter l'ensemble du fichier js.

Dès qu'une définition est accédée, le moteur regarde si elle est compilée si oui il l'utilise sinon il remplace la portion de code analysé par le code généré par la compilation.

Lorsqu’on regarde le temps passé par le navigateur sur le chargement d'un très gros fichier js on s'aperçoit souvent que le temps de téléchargement est très supérieur au temps de passing.
C’est en grande partie dû à ce processus.

Le contenu même du fichier influe. Si on trouve au niveau global beaucoup de définitions, l'analyse et la compilation seront plus longues que si on ne trouve qu'une définition.

Mais ce n'est que partie remise, car dès l'utilisation il va falloir compiler.

Perso, je regarde le temps de téléchargement de mon js (je n'ai pas de HTML) c'est lui qui va en grande partie définir le temps de chargement de l'appli. il ne faut pas qu'il soit rédhibitoire.
S'il est trop important, je fais deux ou trois fichiers et je découpe en fonction des domaines fonctionnels de l'appli.

Dès que l'utilisateur active un élément d'un domaine, je charge le fichier contenant tout le code nécessaire à ce domaine.

A+JYT