Sur certains de mes sites, nous utilisons des ensembles Javascript/CSS pour réduire le temps de chargement. J'ai toujours utilisé deux paquets pour chaque type (4 au total), donc j'ai
Ma théorie est que JS Bundle 1 et CSS Bundle 1 ne changent jamais. Par conséquent, ils peuvent être mis en cache et réutilisés sur chaque page, alors que JS Bundle 2 et CSS Bundle 2 contiennent le code qui change page. Parfois, ceux-ci peuvent ne contenir qu'une ou deux lignes de code. J'ai utilisé cette méthode pour une entreprise de développement Web à la pige. Ils m'ont dit que c'était mauvais/mauvais et que je ne devrais utiliser qu'un seul paquet pour chaque type de support, car l'utilisation de deux ensembles augmente le nombre de demandes et ralentit la page. Je ne comprends pas pourquoi c'est plus lent que d'utiliser deux paquets.
Juste comme exemple avec Javascript (bien que presque identique pour CSS)
Première page visitée (Say page1.html): 100 Ko de scripts standard utilisés sur chaque page et 5 Ko de scripts personnalisés
Avec ma méthode, un utilisateur devrait télécharger 105 ko de médias en deux requêtes.
Avec leur méthode, un utilisateur devrait télécharger 105 Ko de contenu multimédia sur une requête.
Donc lors de la première visite, j’accepte leur méthode, c’est plus rapide mais
Deuxième page visitée (page2.html): 100 Ko de scripts standard et 3 Ko de scripts personnalisés
Avec ma méthode, les scripts standard seraient déjà mis en cache afin de ne télécharger que 3 Ko de scripts.
Avec leur méthode, l’utilisateur devrait télécharger 103 ko de scripts, uniquement pour les 3 ko de scripts personnalisés.
Pourtant, ils insistent pour que leur méthode soit plus rapide, comment est-ce possible? Je suis sûr que le fait de faire une requête supplémentaire ne peut pas réduire le chargement de page, il est donc plus efficace de retélécharger 100 ko de données déjà existantes, et c'est juste le JS, en ajoutant le CSS qui est plus proche du double
Ils ont probablement * raison.
Il peut être mauvais de diviser votre code JavaScript et CSS en plusieurs fichiers. Même si une partie du code de ces fichiers n’est utilisée que sur une seule page, il vaut la peine de tout conserver dans un seul fichier pour réduire le nombre de demandes de page. Laissez-moi vous montrer pourquoi:
Leur méthode (tous les CSS dans un seul fichier):
Votre méthode (CSS dans plusieurs fichiers):
À chaque chargement de page, vous avez besoin d'une demande de page HTTP supplémentaire pour le CSS personnalisé qui aurait autrement été incluse dans la demande du fichier maître d'origine. Si le code personnalisé de chaque sous-page grossit beaucoup , vous voudrez peut-être tester pour voir ce qui est plus rapide, mais dans le scénario que vous décrivez, je parierais qu'une seule demande de 108 Ko est plus rapide que trois demandes pour un fichier de 100 Ko, 5 Ko et 3 Ko, car les requêtes HTTP sont coûteuses.
Au-delà de cela (et la différence de performances réelle est probablement minime de toute façon), il est plus facile de garder un fichier ouvert lors de l'édition de code que de sauter entre plusieurs fichiers. Un grand site peut rapidement générer 10 fichiers CSS distincts ou plus, et ce n'est jamais amusant à gérer. Pour cette seule raison, il vaut la peine de conserver le code dans un fichier si vous le pouvez.
* Je dis probablement car il y a d'autres facteurs à considérer. par exemple. Il est parfois logique de séparer de gros fichiers CSS et JavaScript. Si une page rarement visitée nécessite 500 Ko supplémentaires de JavaScript, vous pouvez vous opposer à son inclusion dans le fichier JS principal du site. Vous pouvez également utiliser des éléments tels que minify pour réduire le nombre de requêtes HTTP lorsque plusieurs fichiers CSS/JS sont demandés, mais cela ne vous empêche pas de devoir jongler avec tous ces fichiers de votre éditeur de code en premier lieu.
Ma théorie est que
C'est ton problème. Ne théorisez pas - testez. Vous pouvez utiliser le profileur de réseau dans Firebug ou les outils IE dev pour voir exactement, en millisecondes près, quelle méthode est la plus rapide.