Chargement du javascript principal sur chaque page? Ou le diviser en pages pertinentes?


13

J'ai un 700kbfichier JS décompressé qui est chargé sur chaque page. Avant, j'avais des 12fichiers javascript sur chaque page, mais pour réduire les requêtes http, je les ai tous compressés 1 file.

Ce fichier est ~130kb gzippedet est servi gzip. Cependant, sur l'ordinateur local, il est toujours déballé et chargé sur chaque page. Est-ce un problème de performances?

J'ai profilé le javascript avec firebug profiler mais je n'ai vu aucun problème. Le problème / l'illusion auquel je suis confronté est qu'il existe des bibliothèques jquery compressées dans ce fichier qui ne sont parfois pas utilisées sur la page actuelle.

Par exemple, jquery datatablesest compressé à 200 Ko et n'est chargé que sur 2 des pages de mon site Web. Un autre est jqplotet c'est un autre 200kb.

J'ai maintenant un 400kbexcès de code qui n'est pas exécuté sur 80%les pages.

Dois-je tout laisser dans un fichier?

Dois-je retirer les bibliothèques jquery et charger uniquement les JS pertinents sur la page actuelle?


Si vous disposez de 700 Ko de code JS, vous devez vraiment le diviser à nouveau et n'inclure que les scripts dont vous avez vraiment besoin. De plus, en utilisant jQuery ("… écrire moins, faire plus ..."), il semble un peu surdimensionné d'avoir un fichier JS aussi énorme. Que diable faites-vous avec une telle masse de JS?
feeela

@feeela jetez un œil à jquery-ui, jquery.datatables. Ceux-là seuls font 400kb ensemble. J'ai d'autres plugins que j'utilise aussi comme jquery.validate, jquery.uniform - ce genre de choses s'additionne. xD
Kyle

Dans ce cas - comme indiqué ci-dessous - vous devez vraiment diviser les scripts et charger uniquement ce qui est nécessaire ...
feeela

Réponses:


6

Vous pouvez utiliser requirejs pour charger dynamiquement les bibliothèques dont vous avez besoin uniquement sur ces pages. Ensuite, vous n'avez qu'à charger le requirejs (qui est d'environ 14k) sur toutes les pages, économisant environ 385kb.

L'intégration est également très simple: il suffit de "boucler" le code que vous avez avec les éléments include requis:

require(["jquery", "jquery.alpha", "jquery.beta"], function($) {
    //the jquery.alpha.js and jquery.beta.js plugins have been loaded.
    $(function() {
        $('body').alpha().beta();
    });
})

1
J'aime vraiment la conception de ce site Web. Je n'ai jamais entendu parler de requirejs. Comment évaluez-vous cela par rapport aux requêtes http? Cela ne met-il pas plus de requêtes http sur la page? (n'est-ce pas mauvais?) Désolé pour mes questions stupides.
Kyle

Bien sûr, il est préférable d'avoir moins de demandes, mais économiser> 350 Ko n'est pas trop mal non plus. Oui, votre site fera une autre demande si vous incluez une autre bibliothèque sur cette page. Si c'est datatablessur un site et jqplotsur un autre, c'est bien. Le chargement de cinq bibliothèques supplémentaires sur 50% des pages ferait disparaître l'avantage, je suis d'accord. Mais dans votre cas, je considère que c'est une très bonne solution (en supposant que le reste d'entre vous reste un fichier compressé).
Michael

Merci Michael. Cette solution est plutôt brillante. Avant j'allais tout diviser sur une seule page mais ça ... C'est mieux que ce que j'avais en tête. Merci pour cette suggestion. Puisque vous connaissez bien requirejs, pensez-vous que requirejs serait suffisant? Je vois sur certains sites Web qu'ils utilisent Google pour charger leur jquery et d' autres bibliothèques, google.load('...').
Kyle

1
Je recommande fortement de charger des bibliothèques communes à partir de Google (ou d'autres sites qui le proposent). Cela présente 2 avantages: a) le fichier lib est mis en cache entre différents sites. Il est probable que l'utilisateur ait visité un site auparavant, qui utilise également jquery chargé à partir de Google. Ce fichier est ensuite chargé à partir du cache, pas à nouveau à partir du serveur! b) Même s'il doit être chargé, il sera beaucoup plus rapide de le charger à partir de Google CDN, qu'à partir de votre propre serveur Web.
Michael

8

Si votre framework / CMS / n'importe quoi a les fonctions appropriées, vous pouvez inclure le script de manière conditionnelle comme le suggère @Michael, mais sans la bibliothèque supplémentaire.

En prenant votre cas de tables de données, par exemple, WordPress peut gérer la situation via quelque chose comme:

// For reference; this isn't functional code.
if (is_page('whatever')) {
    <script src="/path/to/datatables.js"><script>
    <script>
        [Your datatables setup here]
    </script>
}

Il n'y a rien de mal avec RequireJS; il vous suffit d'évaluer si le niveau de complexité supplémentaire qu'il ajoute (et d'apprendre à l'utiliser en premier lieu) compense ce que des outils plus facilement disponibles peuvent faire pour vous. Si vous ne disposez que des deux cas mentionnés ci-dessus, cela pourrait être une meilleure option. Si vous en avez beaucoup plus, alors RequireJS pourrait être une meilleure approche dans l'ensemble.


J'ai un site Web personnalisé que j'ai créé à partir d'un modèle html que j'ai acheté sur themeforest. Le seul problème est que le mec avait comme 6 fichiers JS dispersés et c'était désordonné. J'ai donc mis ceux-ci dans un fichier et qui comprend quelques bibliothèques jqplot, datatables, jquery-ui. Tout cela représente environ 550 à 600 Ko. 100 Ko est mon JS utilisant ces bibliothèques. Je pense que je devrais résoudre ce problème au lieu de charger autant de bibliothèques JS non pertinentes sur chaque page. Merci pour votre suggestion! =)
Kyle

5

700 Ko de JavaScript EST un problème de performances, car il doit être analysé après le chargement de la page. À cause de cela, vous devez vous assurer que seuls les scripts nécessaires sont chargés. Un gros JavaScript peut être OK sur les sites AJAX complets, tels que GMail, lorsque la navigation est gérée en interne sans quitter la seule page. Cependant, même les sites AJAX complets effectuent un chargement JS dynamique pour éviter de charger JS inutile au démarrage (mémoire et vitesse).

Vous avez dit que vous vouliez réduire le trafic http. Vous devez jouer avec la mise en cache HTTP . Le problème est que les modifications apportées au JS peuvent ne pas être visibles jusqu'à l'expiration du cache, si vous définissez un délai d'expiration trop élevé.

Il y a cependant une astuce à laquelle vous ne faites pas référence myscript.js, mais myscript.js?version={myversion}. Après la mise à jour de l'application, vous modifiez {myversion}et forcez le rechargement JavaScript.


Oui, avec cette taille de JS, couplée au fait qu'il s'agit principalement de bibliothèques assez courantes, l'utilisation d'un CDN sera un gros avantage.
Zhaph - Ben Duguid

1

~ 700kb de JavaScript est un problème de performances et s'il est compressé et nous devons voir les règles à suivre lors de l'optimisation du code sont:

  1. Minify Javascripts - Simplement vous compressez et décompressez, ce qui n'a pas réduit le code. Tout d'abord, utilisez le bon outil Minify JS et Minify votre code. Vous êtes 12 fichiers et chaque fichier serait Minify séparément avant de clubbing pour de meilleures performances.

  2. Utilisez le chargement javascript asynchrone , en utilisant le chargement asynchrone entraîne un temps de chargement et un rendu de la page très rapides. L'impact utilisateur est très fort car un bon chargement asynchrone ne bloquera pas le processus de rendu et le temps de chargement de la page ressentie est fortement diminué. Les images et autres éléments affichés régulièrement seront affichés dès qu'aucun javascript n'est chargé.

  3. Utilisez GOOGLE cdn pour JQUERY ; Je pense que vous utilisez JQUERY et que vous le chargez à partir de votre propre site Web, ce qui est également un inconvénient supplémentaire, veuillez utiliser le GOOGLE CDN ​​(gratuit) pour charger JQUERY. Comme il est utilisé par presque tous les 3 sites Web et est donc déjà disponible sur l'ordinateur client en cache.

  4. En-têtes expirés longs personnalisés : Certains comment le site Web est chargé avec un problème de temps de chargement, vous devez donner les expirations longues pour les fichiers HTTP JS, afin qu'ils ne puissent pas être téléchargés à chaque fois, ce qui réduira la demande pour la deuxième fois. Selon mes recherches, le temps de chargement pris sur la deuxième page a plus de sorties par rapport à la première visite de la page.

  5. Vérifiez avec la vitesse de la page : Parfois, d'autres ressources affectent également la vitesse de chargement de la page, vérifiez avec bonté et essayez également d'optimiser d'autres ressources. Comme faire un peu d'étape sur chaque ressource, donnez un temps supplémentaire à notre chargement JS.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.