Dois-je combiner des fichiers js / css en un seul fichier?

11

Les modules complémentaires YSlow et Page Speed ​​de Google recommandent de combiner les fichiers de script (et de style) en un seul fichier chacun pour réduire le nombre de demandes HTTP, et je peux certainement voir l'intérêt de cela lorsque les fichiers de script sont cohérents sur l'ensemble du site, mais pour une application Web qui a des exigences différentes sur le site.

La façon dont je le vois, il y a quelques options:

  1. Combinez tous les fichiers utilisés sur le site, et chaque page obtient le même fichier combiné - l'inconvénient est le contenu inutilisé qui encombre le script (et un premier chargement plus lourd (également rechargé lorsque tout script de composant change))

  2. Combinez les fichiers par page - l'inconvénient est que chaque page avec des exigences différentes obtient un fichier combiné différent (premier chargement plus lourd pour chaque type de page)

  3. Ignorez l'interprétation stricte `` un seul fichier '' des recommandations et chargez la page dans plusieurs fichiers, le cas échéant, la mise en cache annule, espérons-le, le nombre de demandes HTTP dans le cas général - l'inconvénient est le nombre de demandes HTTP sur chaque page

Pensées?

optimization css javascript Cebjyre
la source
Vous le faites mal. Soit séparer les parties en fichiers individuels et prendre le coup d'échauffement (causé par un plus grand nombre de demandes et de cache froid) ou combiner par programme les fichiers source côté serveur et servir seulement 1 page js, css, html par lien dur. Mélanger des fichiers avec différents types MIME = mauvais.
Evan Plaice
Et ... comme @Larry Smithmier l'a dit dans sa réponse, utilisez un CDN (ex. Google) pour fournir des bibliothèques communes (ex. Jquery) pour éviter complètement les coûts initiaux de réchauffement du cache pour ces fichiers.
Evan Plaice

Réponses:

11

L'option 2 est la pire; cela signifie que chaque page avec une combinaison différente de scripts JS nécessaires entraînera une demande HTTP. Cela rendra les performances bien pire.

L'option 1 est la meilleure. Finalement, la plupart des utilisateurs visiteront la plupart des "types" de page de votre site Web, il est donc toujours avantageux de tout combiner en un seul fichier, à l'exception peut-être des gros fichiers JS qui sont nécessaires dans quelques pages rarement visitées.

Le premier accès à la page peut être plus lent qu'avec différents fichiers, mais cela vaut toujours la peine, car tous les autres accès à la page utiliseront le JS global mis en cache.

Un conseil cependant; fusionnez-les automatiquement si vous ne l'êtes pas déjà!

Thomas Bonini
la source
2
Bien que vous deviez être très conscient de l'impression initiale donnée par votre page d'accueil / vos pages de destination. Si la première page qu'un visiteur voit est lente à charger, il se peut qu'il ne prenne pas la peine de regarder une deuxième page.
pelms
Une autre option, surtout si votre site dépend fortement d'une page de destination ou d'une première impression forte, serait de minimiser la taille des fichiers diffusés sur cette première page, puis de diffuser les fichiers combinés sur une page sur deux.
Travis Northcutt du
4

Je combine généralement le «Javascript global» - jQuery et les plugins communs - dans un seul fichier, puis je propose des plugins supplémentaires en tant que fichiers séparés lorsque cela est nécessaire.

Par exemple, un site sur global.jslequel je gère de nombreuses pages contient des tableaux de données, j'ai donc un avec jQuery, DataTables et SuperFish (pour mon menu). Il y a deux pages sur le site qui utilisent une "lightbox" donc j'ai un script séparé pour ces deux pages.

Pour CSS, je ne sers qu'un seul fichier pour l'ensemble du site et j'essaie de rendre le CSS aussi général que possible - la plupart des pages n'ont que quelques éléments CSS uniques.

Chèvre mécontente
la source
1

Bien qu'il soit certainement recommandé d'utiliser le moins de fichiers possible, vous pouvez constater que vous avez un partage entre les fonctionnalités requises au chargement de la page et les fonctionnalités qui peuvent être différées via un chargement asynchrone.

Si suffisamment de votre JS peut être poussé dans la deuxième catégorie, vous pouvez améliorer la vitesse de chargement initiale perçue de la page, créant une meilleure expérience pour vos utilisateurs.

JasonBirch
la source
1

Je ne suggérerais pas de les combiner tous. Si vous utilisez une bibliothèque commune, vous pouvez utiliser un CDN pour livrer vos javascripts. Vous pouvez ensuite profiter de la mise en cache du navigateur (en supposant que d'autres sites utilisent le même CDN) et de la distribution distribuée. Microsoft et Google ont chacun des solutions (que je n'ai pas utilisées honnêtement non plus, mais je vais certainement commencer) et il peut y en avoir d'autres. Sur une note connexe, SO a cette question:

Quand le navigateur efface-t-il automatiquement le cache JavaScript?

et la première réponse est l'or massif.

Larry Smithmier
la source
2
J'utilise déjà la bibliothèque jQuery hébergée par Google, mais je voulais dire que cette question fait référence à des fichiers spécifiques au site (c'est-à-dire pour les sites d'échange de pile, lorsque vous posez une question, vous avez le script pour rechercher des questions similaires, le script à rendre le démarque et les suggestions de balises, qui peuvent toutes être développées dans des fichiers séparés). Soit dit en passant, si vous utilisez les js hébergés par Google jQuery, alors que 1.4 et 1.4.2 vous donneront tous les deux le même contenu (pour le moment), 1.4.2 est mis en cache pendant un an, mais 1.4 n'est mis en cache que pendant une heure.
Cebjyre
astuce cool! merci pour la perspicacité dans la durée de mise en cache sur le jQuery hébergé.
Larry Smithmier