web-dev-qa-db-fra.com

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

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

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

J'ai profilé le javascript avec le profileur firebug mais je n'ai pas rencontré de problèmes. Le problème/illusion auquel je suis confronté est qu'il y a des bibliothèques jquery compressées dans ce fichier qui ne sont parfois pas utilisées sur la page en cours.

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

J'ai maintenant 400kb d'excès de code qui n'est pas exécuté sur 80% des pages.

Dois-je tout laisser dans 1 fichier?

Dois-je extraire les bibliothèques jquery et ne charger que les fichiers JS pertinents sur la page en cours?

javascriptjquerypage-speedhttpload
13
Kyle

Vous pouvez utiliser requirejs pour charger dynamiquement les bibliothèques dont vous avez besoin uniquement sur ces pages. Ensuite, il vous suffit de charger le requirejs (environ 14 Ko) sur toutes les pages, ce qui vous fait économiser environ 385 Ko.

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

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

Si votre framework/CMS/que ce soit dispose des 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 données, par exemple, WordPress pourrait 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; vous devez simplement évaluer si le niveau supplémentaire de complexité qu'il ajoute (et apprendre à l'utiliser dès le départ) compense ce que des outils plus facilement disponibles peuvent faire pour vous. Si vous n’avez que les deux cas que vous avez mentionnés ci-dessus, cela pourrait être une meilleure option. Si vous avez encore beaucoup à faire, RequireJS pourrait être une meilleure approche dans l'ensemble.

8
Su'

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

Vous avez dit que vous vouliez réduire le trafic http. Vous devriez jouer avec 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 une astuce, cependant, que vous ne faites pas référence à myscript.js, mais à myscript.js?version={myversion}. Après la mise à jour de l'application, modifiez le {myversion} et forcez le rechargement de JavaScript.

5
Danubian Sailor

~ 700 Ko de JavaScript est un problème de performances. Si vous compressez, nous devons voir les règles à suivre pour optimiser le code:

  1. Minify Javascripts - Vous effectuez simplement une compression et une décompression, ce qui n'a pas réduit le code. Utilisez tout d'abord le bon outil Minify JS et Minify your code. Vous avez 12 fichiers et chaque fichier doit être réduit séparément avant la matraquage pour une meilleure performance.

  2. tilisez le chargement javascript asynchrone, en utilisant le chargement asynchrone, le temps de chargement et le rendu de la page sont très rapides. L'impact sur l'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 ressenti sera considérablement réduit. Les images et autres éléments affichés sont affichés régulièrement et aucun code javascript n'est chargé.

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

  4. Custom long Expires Headers: Quelque soit le sens du chargement du site Web, vous devez donner les fichiers JS expirés longtemps pour HTTP, 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 que la première visite d'une page.

  5. Vérifier avec la vitesse de la page: Parfois, d'autres ressources ont également une incidence sur la vitesse de chargement de la page. Vérifiez également et essayez d'optimiser d'autres ressources. En faisant un peu d’étape sur chaque ressource, donnez un temps supplémentaire au chargement de notre JS.

1
Vineet1982