Uglify - une question d'optimisation

Bonsoir à tous,

Je suis actuellement en train de finaliser un projet et je suis sur la phase optimisation.

J'ai plusieurs fichiers JS qui passe à la minification et que je concatène en un seul et unique fichier. C'est un site statique réalisé avec Jekyll et j'ai quelques bouts de scripts qui ne sont exécuté que sur certaines pages.

Ma question est : est-ce que pour quelques ko (le plus gros fais 4.6Ko), je ne me prends pas la tête et je fusionne tout même si qu'une page sur 10 à besoin de ce script.
Ou alors, quitte à faire un appel serveur supplémentaire, je fais un nouveau fichier JS qui ne sera appelé que sur la page qui as besoin de lui ?

Avez-vous d'autres idées / solutions ?

Je sais que normalement il y a un cache et que le fichiers ne sont pas télécharger toutes les deux minutes mais bon, c'est une partie que je ne maitrise pas forcement alors merci pour votre aide
Modifié par MagicCarpet (27 Jan 2015 - 01:02)

Bonjour,

4.6 ko avant compression ? C'est moins après (et pas grand chose, 5 ou 100% du poids d'une image)

Si c'est sur une page susceptible d'être une porte d'entrée (à commencer par la page d'accueil), je concaténerais tout.
Si c'est un type de page qui a tous les scripts "à part", je ferais 2 fichiers (l'un global l'autre chargé que sur ce type de page)
Entre les 2 euh, faudrait comparer la différence de poids du fichier JS une fois gzippé, pas avant compression (et ça dépend©)

EDIT : quel est le poids du fichier, parle-t-on de 10, 100 ou 500 ko ?
Modifié par Felipe (27 Jan 2015 - 10:19)

"Optimiser" signifie "faire le mieux possible" (et non pas "faire au mieux" comme on le croit couramment).
Dans les contrats, les fournisseurs de services informatiques en interdisent l'usage, car il est toujours possible d'améliorer quelque chose dans un programme.
Par ailleurs "le mieux possible" signifie que l'on a un objectif documenté sur ce qui est "mieux" qu'autre chose.

Je m'explique:

Quand j'ai commencé dans le métier, nous avions des ordinateurs très lents et de taille mémoire très faible (du genre 1 microseconde par instruction machine et 16Ko de mémoire centrale). On pouvait choisir, selon les cas, de chercher à réduire la taille des programmes ou leur durée d'exécution, le "meilleur choix" étant justement de trouver un compromis raisonnable.

Par ailleurs il est également important de faire en sorte qu'un programme soit maintenable, ce qui veut dire qu'il est plus gros en taille (aération du code, commentaire, choix de noms de variable permettant de comprendre 2 ans plus tard en un coup d’œil ce à quoi ils correspondent) et prend plus de temps à l'exécution (définition d'objets et de méthodes plutôt que du code en ligne), etc.

Bref pour répondre à ta question:
En première approximation, il est inutile de chercher la petite bête trop loin.
Sauf bien entendu si ton programme contrôle un satellite, un sous-marin, une centrale nucléaire ou le trading en bourse, mais dans ces cas là on programme en assembleur, avec les mêmes critères de compacité et d'arbitrage "CPU/Mémoire" que dans ma jeunesse et pas en PHP, JS et autres weberies.

J'espère ne pas avoir trop radoté...

Edit: le temps que je radotais, Felipe a donné une réponse qui me semble tout à fait sensée
Modifié par PapyJP (27 Jan 2015 - 10:38)

Merci pour vos réponses.

Réponse générale :

Alors, j'ai 6 pages sur ce site (c'est un petit site, d'où mon choix initial avec Jekyll). J'ai donc un script JS général qui contient le code nécessaire à toutes les pages du site. Lui, je ne me pose pas la question, il est linté (mon script perso, pas les bibliothèques) puis concaténé avec le reste des JS et ensuite minifié (uglify s'occupe des deux dernières tâches). Poids de la bête : 39ko (je pense que c'est largement raisonnable étant donné qu'il comporte quelques bibliothèques, notamment quelques unes de Bootstrap).

Ensuite, voir le problème que j'expose tout en haut de ce post, j'ai créé deux fichiers JS supplémentaires et c'est eux qui me préoccupent. J'ai donc un fichier script pour la page d'accueil et un autre pour une autre page. Comme précédemment, ils sont lintés et minifiés mais pas concaténés (pour le moment), ils restent des "solitaires" et uniquement appelés sur les pages concernés. Celui de la page d'accueil fait (au final, donc minifié) 483 octets et l'autre monte à 4ko (toujours minifié).

J'aime bien cette logique vu que chaque script est à sa place et spécifique à chaque page. Cela permet de s'y retrouver, de séparer les composants, etc. Mais entre plus de poids sur un seul fichier final (poids certes très limité) ou un appel serveur supplémentaire, je ne sais pas quel est le meilleur choix. Je profite de ma question aussi pour avoir un avis général sur cette question pour de futur projets.

J'espère vous avoirs donnés un maximum de détails.

@Felipe : Pour info, avant tous les traitements de minifications et autres : le script de la page d'accueil est à 809 octets, celui de l'autre page à 5 Ko et celui qui concerne toutes les pages (le main) est à 973 octets. Attention c'est ce dernier qui est concaténé aux autres, d'où le poids final de 39 Ko.

@PapyJP : j'entends bien et tout est une question de compromis en informatique (et pas que dans ce domaine d'ailleurs). Sans allez chercher la petite bête, je profite de ce genre de problématiques afin de poser des questions et dégager une solution en adéquation en fonction des projets. Je sais que j'ai des résultats de tests Google (qui feront sans doutes l'objet de mes prochains posts) à améliorer, je ne peux donc pas laisser passer le moindre petit écrou de travers

EDIT : j'ai oublié un élément important, le fait d'avoir des JS séparé pour ces pages permet aussi de prévoir l'évolution du site. Si aujourd'hui je suis à 4 Ko pour une page, rien n'interdit de penser que demain je pourrais passer à 40 Ko.
Modifié par MagicCarpet (27 Jan 2015 - 12:19)

MagicCarpet a écrit :
Je sais que j'ai des résultats de tests Google (qui feront sans doutes l'objet de mes prochains posts) à améliorer, je ne peux donc pas laisser passer le moindre petit écrou de travers

C'est quoi des 'tests Google"?
Ne me dites pas que ces incompétents se mettent à délivrer des diplômes?

lol, ah non du tout... Je parlais de ce genre de choses.

Désolé, il est vrai que j'ai pas été clair sur ce sujet.

EDIT : Le site actuel est à 43%, le nouveau à plus de 60 (64 je crois), je vise les 90 minimum... (82 pour le site actuel sur les navigateurs desktop, là aussi, je vise 90 + pour le nouveau)
Modifié par MagicCarpet (27 Jan 2015 - 15:04)

MagicCarpet a écrit :
lol, ah non du tout... Je parlais de ce genre de choses.

Désolé, il est vrai que j'ai pas été clair sur ce sujet.

EDIT : Le site actuel est à 43%, le nouveau à plus de 60 (64 je crois), je vise les 90 minimum... (82 pour le site actuel sur les navigateurs desktop, là aussi, je vise 90 + pour le nouveau)

Est-ce bien raisonnable viser 90+ sur des critères aussi partiels?

Peut être pour le sport, mais franchement je ne vois pas l'intérêt.
Généralement, quand il y a VRAIMENT un problème de perf VISIBLE sur une page Internet, c'est un bug de design, du genre chargement d'une flopée d'images au chargement de la page (ça m'est arrivé encore récemment)

Lorsque j'étais le patron d'équipes de développement (y compris de programmes temps réel), j'avais pondu un article dont le thème était "les trois principales qualités d'un programme sont la maintenabilité, la maintenabilité et la maintenabilité", à savoir:
Sachant que du 'code sans bug" c'es du code dont on n'a pas encore trouvé les bugs
1) les conséquences des bugs éventuels doivent être limitées (ne pas arrêter l'usine parce qu'un agent administratif a déclaré que quelqu'un avait fait 240 heures supplémentaires au lieu de 24h)
3) les bugs doivent être faciles à trouver
3) les bugs doivent être faciles à corriger
Trente ans plus tard je crois que c'est toujours vrai.

Ce n'est que dans des cas très particuliers que la "vitesse" (de quoi du reste?) a un peu d'importance, et dans ce cas là on a des méthodes de travail tout à fait spécifiques et des langages adaptés (Esterel par exemple). Mais là encore le compromis ne se fait jamais au détriment de la maintenabilité.

Sur ce, bonne chance pour la coupe du monde de vitesse!
Modifié par PapyJP (27 Jan 2015 - 19:13)

Non, pour le coup et uniquement sur ce projet, c'est pour le "sport". Pour voir et comprendre comment ça marche et au passage voir si ce genre de test est réellement utile.

Là, mais j'y reviendrais plus en détails, il me dis que j'ai des scripts qui bloquent l'affichage du site et pour éviter ça je dois les virer

Il est gentil mais mes CSS sont dans le Head et les JS juste avant le body, je vois pas comment faire autrement, bref.

Sinon, ta règle de 3 je la prends en compte et bien sur, elle est toujours valable et devrais le rester encore longtemps.

Pour info, je suis avec Grunt et donc je test a chaque sauvegarde tous mes fichiers, via des lint. Ca permet d'éviter un certains nombres de problèmes dès le début.

MagicCarpet a écrit :
Là, mais j'y reviendrais plus en détails, il me dis que j'ai des scripts qui bloquent l'affichage du site et pour éviter ça je dois les virer

Il est gentil mais mes CSS sont dans le Head et les JS juste avant le body, je vois pas comment faire autrement, bref.

Comprends pas: tes scripts doivent être définis à l'intérieur de <head>...</head> soit à l'intérieur de <body>...</body> en aucun cas ils ne peuvent être entre </head> et <body>, et d'ailleurs il ne doit rien y avoir être entre </head> et <body>.

Les CSS sont bien dans le HEAD mais pour les JS je voulais dire avant la balise de fermeture /BODY, j'ai donc bien ce genre de chose : </head><body>, rien entre les deux

Mais je reviendrais dès que je met le site en ligne avec les résultats de Google, ce que j'ai dis plus haut c'est les grandes lignes et sans précisions.