Discussion :

[Sergejack]

Je remarque souvent le conseil suivant :

Il faut regrouper le code Javascript (et réciproquement CSS) dans un seul gros fichier et ce afin d'accélérer l'affichage du site.

Cela n'est pas faux, hélas les limitations HTTP en font ainsi.

Mais bien que l'affirmation soit correcte, je trouve souvent des cas où cette approche me semble anti-productive.
Je vais vous dire quelques inconvénients qui me viennent à l'esprit.

Par définition (quasi) cette approche nuit à la modularité.
Cette approche pourrait d'ailleurs s’appeler l'approche "Usine à gaz".
Si cette usine à gaz est de taille importante cela aura un effet très indésirable sur le site : la moindre page pèsera très lourd.

À moins que cette usine à gaz ne soit dans le cache du navigateur (ce qui n'est jamais le cas lors de la première visite ou si des limites pour ce cache sont atteintes (!iPhone, ...)) l'accès à la moindre page sera pénalisée par le téléchargement de l'usine.
Et là, il ne faut pas oublier que nous ne sommes pas tous égaux face à la connexion.

Autant les connexions lentes sont de moins en moins fréquentes (remarque: ceci n'est pas une vision mondiale d'internet), autant par le biais des smartphones ces connexions peuvent devenir extrêmement onéreuses.

Ce qui aggrave encore la situation, c'est que si vous changer le moindre boulon de l'usine, ce sera toute l'usine qui aura une nouvelle identité et donc, à la poubelle les mises en cache déjà faite.
Sans métaphore cela s'exprime ainsi : si vous voulez changer la couleur d'un cadre de votre page de login dans votre css alors toute l'usine css sera à recharger. Tandis que si vous aviez une css propre à la page de login, seule ces données là seraient à recharger.


Pour terminer, Si elle vous tient à cœur il existe une astuce pour contourner la limite ci-impliquée de HTTP : les CDN.

ex :
www.monsite.fr
css.monsite.fr -- l'essentiel de vos css
js.monsite.fr -- l'essentiel de vos js
img.monsite.fr -- l'essentiel de vos image

et si vous voulez pousser le vice :
specific.monsite.fr -- des fichiers spécifiques à quelques rare usage (ex. page_login.css, page_login.js)


J'aimerais récolter vos avis sur la question que vous ailliez dans mon sens ou non.

[kOrt3x]

La séparation des différents langages permet une maintenance et un debugage plus simple et plus pratique.

[Sergejack]

La séparation des différents langages permet une maintenance et un debugage plus simple et plus pratique.

Alors, là, je ne suis pas sûr de te comprendre.
"langage" est-il un mot mis par erreur (plutôt que fichier ou autre) ?

[kOrt3x]

Déjà, ça :

css.monsite.fr -- l'essentiel de vos css
js.monsite.fr -- l'essentiel de vos js
img.monsite.fr -- l'essentiel de vos image

C'est pas des répertoires, mais des sous-domains...

Ce que je voulais dire, c'est que pour chaque langage (ou fichier) il faut bien les séparer.

Ex :

/index.html
/images/
/style.css OU /css/style.css
/javascript.js OU /js/javascript.js

Comprends-tu mieux ?

[Sergejack]

Ha oui mais les sous domaine c'est pour faire du (pseudo) CDN.

Si tu accès au même site par différent nom de domaine, tes requêtes HTTP se feront en parallèle (une par nom de domaine exploité) plutôt que séquentiellement.

Quand on possède un nom de domaine on peut faire autant de sous-domaines que l'on veut.
Dès lors, pourquoi s'en priver ?

Je ne donne pas de conseils sur l'arborescence dans ce sujet, je donne juste le conseil de garder les fichiers js et css séparés plutôt que de faire un gros "toutenun.js" et un gros "touten un.css".

[jpvincent]

Mon avis sur la fusion / séparation des fichiers :

- pour réduire le temps d'affichage il FAUT regrouper les fichiers
- des fichiers massifs ne sont pas maintenables à moyen terme et comme tu le dis ça peut être contre productif dans certains cas

solution :
- côté développement, continuer à séparer un maximum ses fichiers. Pour le JS par exemple, je faisais un fichier par classe, comme ce qui se fait généralement server-side. Pour le CSS, j'ai toujours fait 1 fichier par zone ou module
- lors de la mise en production, concaténer automatiquement tous ces fichiers pour n'en avoir plus qu'un seul
ça oblige à avoir un processus de mise en production scripté, mais pour les sites modernes ça me semble indispensable : le fichier final concaténé peut en plus être versionné, minifié et gzippé avant d'être poussé sur des serveurs statiques

si tu as peur que le JS soit trop massif (genre au dessus de 200ko minifié sans gzip), alors il faut passer à l'étape suivante : connaître pour chaque module de la page le javascript nécessaire, et ne l'inclure qu'à la demande, de manière non bloquante. Il y

tout ça est résumé dans ces slides : [ame="http://www.slideshare.net/jpvincent/inclure-du-javascript-de-manire-performante"]Inclure du Javascript de manière performante@@AMEPARAM@@ssplayer2.swf?doc=slidesinclusionjs-101018044717-phpapp01&stripped_title=inclure-du-javascript-de-manire-performante@@AMEPARAM@@slidesinclusionjs-101018044717-phpapp01@@AMEPARAM@@inclure-du-javascript-de-manire-performante[/ame]
je parle un peu plus de ces slides ici :
http://braincracking.org/2010/07/22/...ni-conference/

[Sergejack]

Il y a bien peu de votes au sondage.

C'est un oubli de ceux qui auront lu ce sujet ou j'ai mal choisi les options présentées ?

[PoichOU]

Bonjour,

sujet intéressant je trouve même s'il y a peu d'écho ...

- côté développement, continuer à séparer un maximum ses fichiers.
- lors de la mise en production, concaténer automatiquement tous ces fichiers pour n'en avoir plus qu'un seul

Pour moi tout est dit ! entièrement d'accord avec cette solution

PoichOU

[estmars]

j'ai mis oui pour une version stable, mais je ne le ferai pas tout le temps car trop contraignant.

en revanche, ce que je trouve intéressant, c'est de ne sélectionner UNIQUEMENT que les css et les javascripts dont on va avoir besoin.

Par exemple sur une page Accueil, on aura besoin des images d'accueil avec leur style, je le traduirais par un accueil.css, et dans le header on passe en paramètre les css et javascript que l'on veut ajouter pour chaque page.

[estmars]

Bonjour, après m'être penché un peu sur le sujet, et quelques tests sur firebug et l'onglet réseau, j'ai du mal à en tirer une conclusion.

alors j'imagine que firebug n'est peut être pas l'idéal et que les résultats varient en fonction du réseau ou je ne sais quoi, même après vidage du cache systématique.

Mais bien souvent, un fichier javascripts minimisé, concaténé, commentaires enlevés, de 112 ko peut mettre plus de temps à charger en moyenne sur x tests, que les 18 fichiers javascripts d'origine de taille totale 235 ko.

mais j'ai parfois tout et son contraire dans mes résultats. Vous n'auriez pas une idée pour faire des tests plus sûrs et fiables?

[jpvincent]

les résultats de tes tests sont bizarres, même si on ne regarde que le téléchargement simple.
Lance webpagetest.org, qui est assez stable au niveau réseau, sur tes pages de test (publiques) et tu verras bien si il y a une différence. Tu peux aussi varier le débit histoire de voir si ça change quelque chose

[estmars]

Bonjour, non mais comme on est beaucoup sur le réseau, je pense vraiment que c'est loin de refléter la réalité parce que comme je disais, d'un test à l'autre, j'ai tout et son contraire, et à un moment, vider le cache ne suffit plus. Au passage webpagetest a l'air pas mal du tout quand même. Merci

[FlyersWeb]

Je suis d'accord avec jpvincent et PoichOU. Il faut séparer la phase de développement de la phase de production (tout comme n'importe quel logiciel).
L'intérêt de mettre ensemble les fichiers css et javascript est de diminuer le nombre de requêtes (HTTP et donc TCP) au serveur. Cela a pour effet d'augmenter le temps de réponse du serveur.

Sachant qu'aujourd'hui les temps de réponse des serveurs sont pris en compte par les référenceurs des moteur de recherche, je pense que c'est presque une faute professionnelle de ne pas minimiser les temps de réponse serveur...

Vous pouvez d'ailleurs voir comment minimiser les temps de réponse avec l'outil pagespeed de google : https://developers.google.com/pagespeed/

Voilà mon point de vu en la matière ^^

[randriano]

Cela n'est pas faux, hélas les limitations HTTP en font ainsi.

Mais bien que l'affirmation soit correcte, je trouve souvent des cas où cette approche me semble anti-productive.
Je vais vous dire quelques inconvénients qui me viennent à l'esprit.

Par définition (quasi) cette approche nuit à la modularité.

Tous les trucs du WPO (Web Page Optimization) nuit à la modularité de la programmation puisqu'il faut par exemple associer tous les fichiers de l'image, du css aux fichiers JS. On minimise et compresse tout!

Il n'y a pas de mal à ça! Pourquoi?

Parce que le travail de WPO sera fait à l'aval du développement du site web!

Côté production, on fait toujours les css, les js bien séparés selon leurs rôles.
Mais il faut monter une dernière équipe (composée de 1 ou 2 développeurs) qui fera à la fin le WPO: fait des sprites CSS pour les images, minimise les JS et CSS, les associe, etc.