Forum CMS Made Simple FR
Bonnes pratiques JS/CSS des modules et performances - Version imprimable

+- Forum CMS Made Simple FR (https://forum.cmsmadesimple.fr)
+-- Forum : Général (https://forum.cmsmadesimple.fr/forum-3.html)
+--- Forum : Général (https://forum.cmsmadesimple.fr/forum-10.html)
+--- Sujet : Bonnes pratiques JS/CSS des modules et performances (/thread-2315.html)


Bonnes pratiques JS/CSS des modules et performances - heriquet - 25/10/2012

Citation :#~~~~~ DEBUT BLOC A NE PAS SUPPRIMER ~~~~~
#~ Version du CMS: 1.11.2.1
#~ Url du site :
#~ Hébergeur / Soft :
#~ Informations Système :
#~~~~~ FIN BLOC A NE PAS SUPPRIMER ~~~~~



Bonjour à tous,

Je voulais sonder un petit peu les visiteurs du forum par rapport à la structure du code HTML et le placement des éléments CSS/JS dont nécessitent les modules.

Actuellement, chaque module insère les fichiers dont il a besoin, via le filesystem (ex: Gallery) ou la DB (ex: FormBuilder).

C'est pratique pour les intégrateurs sans grande connaissance de ce qui se passe au niveau du code, mais lorsqu'on regarde d'un peu plus près, cela n'aide pas toujours pour les recommandations en terme de performances.

Il faut donc "mettre les mains dedans" et retravailler le tout. Mais qu'est-ce qui est le mieux ?

Si je résume, les "critiques" de PageSpeed ou de YSlow pointent régulièrement du doigt :
- L'ordre des scripts (CSS doit être avant JS)
- Le nombre de css/scripts élevé (combiner les ressources)
- Le poids des scripts, pas toujours optimisé et certainement pas avec les versions livrées par les modules.
- Placer les scripts JS en bas de document
- etc

Donc en conclusion, si on veut améliorer tout cela, on est obligé de remonter ses manches et d'effectuer quelques opérations soi-même, mais qui "cassent" un peu la séparation des ressources entre les modules, bien pratique lorsqu'on veut retirer un module.

En ce qui me concerne, lorsque par exemple j'utilise le module Gallery, je fais mon choix de librairie, je place le CSS dans les CSS du gabarit afin qu'il soit combiné et compressé par cms_stylesheet. Ensuite je place le fichier JS (et le code JS qui appelle les fonctions JS d'animation de la galerie) en bas du template Smarty (directement ou via un bloc de contenu global) afin de respecter la recommandation.

C'est efficace en terme de performances, mais moins pour la maintenance (ce qui dans mon cas ne pose pas de souci étant donné que je sais ce que je fais).

Quel est votre retour par rapport à ces pratiques ? Faites-vous autrement ? Mieux ? Qu'en pensez-vous ?

Heriquet

Bonnes pratiques JS/CSS des modules et performances - Ouik - 26/10/2012

J'agis au cas par cas, selon les besoins, et la maintenance à venir. Le fait de combiner les css et les js permet en effet moins de requêtes, mais est plus difficile à maintenir, notamment à chaque mise à jour de bibliothèque js. D'autre part, si tu ajoute css / js dans les feuilles de style et scripts de base pour un module qui ne sert que sur une page (par exemple), c'est du boulot en plus, des fichiers + lourds pour 1 seule page. Donc l'intérêt est pour moi limité dans ce cas.

Sinon pour ce qui est des js en bas de page, j'ai appris la semaine dernière à Paris Web que c'était contre-productif sur iOS... rien n'est simple.

Je pense qu'il n'y a pas une seule réponse, comme le responsive d'ailleurs qui n'est pas adapté à chaque fois.

Donc de mon côté, je ne le fais pas systématiquement.

Bonnes pratiques JS/CSS des modules et performances - heriquet - 26/10/2012

Bah je pense aussi qu'il y a un minimum à faire et que pour le reste, c'est du cas-le-cas :-).

Avoir un seul fichier JS par page en fonction des besoins en revient à avoir un gros fichier par page, ce qui peut être moins bien pour la vitesse de navigation que plusieurs fichiers plus petits, mais avec une date d'expiration "lointaine".

Enfin y a toujours moyen de débattre longtemps sur ce sujet Smile. Et au final le meilleur bench mark est encore la perception réelle de l'utilisateur final :-).

Bonnes pratiques JS/CSS des modules et performances - Ouik - 26/10/2012

Oui, et c'est là où le responsive doit être particulièrement bien conçu pour ne pas pénaliser la vitesse d'affichage sur des réseaux peu performants ; ou utiliser une alternative comme une version mobile du site par exemple.

Bonnes pratiques JS/CSS des modules et performances - heriquet - 26/10/2012

Oui mais pour la version mobile spécifique, ca a quand-même un plus gros impact sur le budget que le RWD non ?

Bonnes pratiques JS/CSS des modules et performances - Ouik - 29/10/2012

oui, ça dépend aussi de l'importance du client / site.