La plus efficace des configurations multi-pages de RequireJS et Almond

Question

J'ai plusieurs pages sur un site utilisant RequireJS, et la plupart des pages ont une fonctionnalité unique. Toutes ces pages partagent un grand nombre de modules communs (jQuery, Backbone, etc.) ; toutes ont également leurs propres modules uniques. Je me demande quelle est la meilleure façon d'optimiser ce code à l'aide de r.js . Je vois un certain nombre d'alternatives suggérées par différentes parties de la documentation et des exemples de RequireJS et d'Almond - donc j'ai dressé la liste suivante des possibilités que je vois, et je demande laquelle est la plus recommandée (ou s'il y a une autre meilleure façon) :

1. Optimiser un seul fichier JS pour l'ensemble du site en utilisant Amande qui se chargerait une fois et resterait ensuite en cache. L'inconvénient de cette approche très simple est que je chargerais sur chaque page du code dont l'utilisateur n'a pas besoin pour cette page (c'est-à-dire des modules spécifiques à d'autres pages). Pour chaque page, le JS chargé serait plus important qu'il ne l'est en réalité. besoins pour être.
2. Optimiser un seul fichier JS pour chaque page qui comprendrait à la fois le module commun et le module spécifique à la page. De cette façon, je pourrais inclure Almond dans le fichier de chaque page et je ne chargerais qu'un seul fichier JS sur chaque page -- ce qui serait significativement plus petit qu'un seul fichier JS pour l'ensemble du site. L'inconvénient que je vois, cependant, est que les modules communs ne seraient pas mis en cache dans le navigateur, n'est-ce pas ? Pour chaque page où l'utilisateur se rend, il devra retélécharger la majeure partie de jQuery, Backbone, etc. (les modules communs), car ces bibliothèques constitueraient une grande partie de chaque fichier JS unique d'une page. (Cela semble être l'approche de la Exemple de page multiple RequireJS sauf que l'exemple n'utilise pas d'amande).
3. Optimiser un fichier JS pour les modules communs, puis un autre pour chaque page spécifique . De cette façon, l'utilisateur mettrait en cache le fichier des modules communs et, en naviguant entre les pages, ne devrait charger qu'un petit fichier JS spécifique à la page. Dans cette option, je vois deux façons de la terminer, pour inclure la fonctionnalité RequireJS : a. Charger le fichier require.js avant les modules communs sur toutes les pages, en utilisant l'attribut data-main ou une syntaxe normale <script> tag -- pas du tout d'amande. Cela signifie que chaque page aurait trois fichiers JS : require.js, modules communs, et modules spécifiques à la page. b. Il semble que cette phrase suggère une méthode pour brancher Almond dans chaque fichier optimisé ---- de sorte que je n'aurais pas à charger require.js, mais plutôt à inclure Almond dans mes modules communs ET mes modules spécifiques à la page. Est-ce que c'est correct ? Est-ce plus efficace que de charger require.js en premier ?

Merci pour tout conseil que vous pourrez me donner sur la meilleure façon de procéder.

Answer 1

Je pense que vous avez répondu à votre propre question assez clairement.

Pour la production, nous le faisons - ainsi que la plupart des entreprises avec lesquelles j'ai travaillé. option 3 .

Voici les avantages de la solution 3, et pourquoi je pense que vous devriez l'utiliser :

• Il utilise le la plupart des cachettes toutes les fonctionnalités communes sont chargées une fois . Il prend le moins de trafic et génère les temps de chargement les plus rapides lors de la navigation sur plusieurs pages. Les temps de chargement de plusieurs pages sont importants et même si le trafic de votre côté n'est peut-être pas significatif par rapport aux autres ressources que vous chargez, les clients apprécieront vraiment les temps de chargement plus rapides.
• C'est le plus logique, puisque la plupart des fichiers du site partagent des fonctionnalités communes.

Voici un avantage intéressant pour la solution 2 :

• Vous envoyez le moins de données possible à chaque page. Si beaucoup de vos visiteurs ne viennent qu'une seule fois, par exemple sur une page de renvoi, c'est votre meilleur choix. L'importance des temps de chargement ne peut être surestimée dans les scénarios orientés vers la conversion.

• Vos visiteurs sont-ils assidus ? quelques études suggèrent que 40 % des visiteurs arrivent avec un cache vide.

Autres considérations :

• Si la plupart de vos visiteurs ne consultent qu'une seule page, envisagez l'option 2. L'option 3 est idéale pour les sites où les utilisateurs moyens visitent plusieurs pages, mais si l'utilisateur visite une seule page et que c'est tout ce qu'il voit - c'est votre meilleure option.

• Si vous avez beaucoup de JavaScript. Envisagez d'en charger une partie pour donner à l'utilisateur une indication visuelle, puis chargez le reste de manière différée et asynchrone (avec l'injection de la balise script, ou directement avec require si vous l'utilisez déjà). Le seuil à partir duquel les gens remarquent que quelque chose est "maladroit" dans l'interface utilisateur est normalement d'environ 100 ms. Un exemple de ceci est le "chargement..." de GMail.

• Étant donné que les connexions HTTP sont Keep-Alive par défaut dans HTTP/1.1 ou avec un en-tête supplémentaire dans HTTP/1.0 , l'envoi de fichiers multiples est moins problématique qu'il y a 5-10 ans. Assurez-vous que vous envoyez le Keep-Alive de votre serveur pour les clients HTTP/1.0.

Quelques conseils d'ordre général et du matériel de lecture :

• Minimisation du JavaScript est indispensable. r.js, par exemple, le fait très bien et vous avez bien réfléchi avant de l'utiliser. r.js permet également de combine JavaScript, ce qui est un pas dans la bonne direction.
• Comme je l'ai suggéré, différer JavaScript est également très important et peut améliorer considérablement les temps de chargement. Le report de l'exécution améliorera votre temps de chargement regardez rapide qui est très important, beaucoup plus important dans certains scénarios que le fait de charger rapidement.
• Tout ce que vous peut à partir d'un CDN comme les ressources externes que vous devrait charger à partir d'un CDN. Certaines bibliothèques que les gens utilisent aujourd'hui, comme jQuery, sont assez volumineuses (80 kb), les récupérer à partir d'un cache pourrait vraiment vous être utile. Dans votre exemple, je voudrais pas Je ne chargerais pas Backbone, underscore et jQuery depuis votre site, je les chargerais plutôt depuis un CDN.

Answer 2

J'ai créé un dépôt d'exemples pour démontrer ces 3 types d'optimisation.

Il peut nous aider à mieux comprendre comment utiliser les services de l'UE. r.js .

https://github.com/cloudchen/requirejs-bundle-examples

Answer 3

Pour info, je préfère utiliser l'option 3, en suivant l'exemple dans https://github.com/requirejs/example-multipage-shim

Je ne suis pas sûr que ce soit le plus efficace.

Cependant, je trouve ça pratique parce que :

• Il suffit de configurer le require.config (sur les différentes bibliothèques en un seul endroit)
• Pendant l'optimisation de r.js, décidez ensuite quels sont les modules à regrouper comme communs.

Answer 4

Vous pouvez utiliser n'importe quel réseau de diffusion de contenu (CDN) comme MaxCDN pour s'assurer que vos fichiers js sont servis à tout le monde. Je vous suggère également de placer vos fichiers js dans le pied de page de votre code html. J'espère que cela vous aidera.

Answer 5

Je préfère utiliser l'option 3, et je peux sûrement vous dire pourquoi.

1. C'est le plus logique.
2. Il utilise le plus de cache, toutes les fonctionnalités communes sont chargées une fois. Il absorbe le moins de trafic et génère les temps de chargement les plus rapides lors de la navigation sur plusieurs pages. Les temps de chargement de plusieurs pages sont importants et même si le trafic de votre côté n'est peut-être pas significatif par rapport aux autres ressources que vous chargez, les clients apprécieront vraiment les temps de chargement plus rapides.

J'ai listé des options bien meilleures pour la même chose.