Améliorer la vitesse de chargement d’une application MVC 4.0, 2ème partie.

Nous n’avions pas complètement terminé l’optimisation de notre site à la fin de notre article précédent. Assez normal, le développement des fonctionnalités du site n’étant pas complètement terminées! Comme le site en est maintenant au déploiement public de sa première version, c’est le bon moment de voir comment encore améliorer le vitesse de chargement d’une application Web MVC 4.0 pour grappiller  quelques dixièmes de secondes de plus, et éliminer des erreurs qui pourraient trainer. On va aussi en profiter pour utiliser un outil dont nous n’avons pas parlé jusque-là, Fiddler.

Etat des lieux, vus par Fiddler

Dans l’immédiat, nous n’allons pas nous préoccuper des temps de chargements (souvenez-vous, à la fin de l’article précédent, nous en étions à 1,01 secondes, sans nettoyer le cache), mais de vérifier que nous avons mis en cache et “bundler” tout ce qui pouvait l’être. Si des erreurs sont détectées, nous allons voir si nous pouvons les réparer.

FiddlerInitialLoad

Même si la plupart des nos fichiers sont cachés (indiqué par date et heure d’expiration dans la colonne “caching”), on remarque qu’un certain nombre de fichiers CSS et JavaScripts ne sont pas dans des bundles (normal, ils ont été ajoutés depuis la dernière fois). Je sais aussi, même si Fiddler ne me le dit pas, que ma page principale et les vues partielles comportent du Javascript, alors qu’il est fortement conseillé de mettre ce code dans un fichier séparé, bundlé, de manière à ce qu’il soit aussi optimisé comme le reste des librairies Javascript et JQuery. Fiddler nous signale aussi deux erreurs 404 sur des images. On a du boulot! Sourire

Tout d’abord, voyons un peu Fiddler:

Fiddler_Vuegenerale

Cet article n’a pas vocation a être un tutorial complet sur cet outil, simplement une présentation de la manière dont il peut nous aider ici. Cependant Fiddler est très complet, et je ne peux que vous engager à vous familiariser avec lui. L’auteur a publié un livre, sans doute la meilleure manière d’apprendre à le maitriser (l’outil, pas l’auteur Sourire !)

Les requêtes/réponses Web s’affichent dans la liste à gauche, les divers onglets à droite permettent d’examiner en détail l’un de ces éléments. Si je clique sur la ligne 20 (Erreur 404), l’onglet Inspectors/raw (soit directement l’html retourné par le serveur) me permet de voir qu’effectivement, la ressource n’est pas trouvée:

Fiddler_ImageUnavailable

1ère Etape: corriger les erreurs

Comme je ne fais aucun bundle d’images, il y a de fortes chances que cette image soit référencée depuis un CSS où un Javascript. Voyons ce que Visual Studio nous trouve:

VSFindimageCSS

l’image en question est référencée à 4 endroits, qui sont en fait toujours le même: jquery-ui.css. Le problème, c’est que le répertoire “bundles” dans lequel un sous-répertoire “images” est cherché, n’existe pas! “Bundle” est un répertoire virtuel créé par cette ligne de code:

Je pourrais toujours créer un répertoire “physique” appelé “Bundles”, pas très élégant, où donner un nom de répertoire physique existant au Bundle, mais de mon point de vue ce n’est pas mieux. La solution la plus propre est de ré-écrire les Urls lors du bundling et de la minification, de manière à ne rien changer aux répertoires, mais à ce que ces chemins soient résolus correctement à l’exécution. Heureusement (comme vous pouvez vous en douter) je ne suis pas le seul à avoir ce genre de problèmes. Nous allons appeler à notre secours le “Web Optimization Framework”, un package que l’on peut installer via NuGet:.

image

Il est maintenant possible de modifier mon StyleBundle pour utiliser CssRewriteurlTransform, la méthode qui fait exactement ce que je souhaitais, réécrire les Urls pour le Bundle et la minification!

Fiddler nous prouve que cette modification est la bonne:

image

Les lignes 8 et 9 ( correspondant aux lignes 20 et 21 sur la première copie d’écran) montrent qu’il n’y a plus d’erreur, le fichier étant maintenant cherché dans “Content/css/images” au lieu de “bundles/images”. La méthode CssRewriteUrlTransform a remplacée le chemin relatif par le chemin absolu lors de l’optimisation du bundle. Comme j’en ai profité pour ajouter au Bundle quelques Css, le nombre de fichiers chargé a aussi diminué. Cependant, vous pouvez voir , lignes 6 et 10, qu’il y a encore des fichiers CSS qui ne sont pas dans un Bundle. Il me faut maintenant examiner mes “views” et “partials views” pour m’assurer que TOUS mes CSS et Javascripts sont dans des bundles, y compris le code Javascript/jQuery ajouté en bas de pages, comme ici:

Après ce petit travail, voici la nouvelle version de la méthode RegisterBundle :

Fiddler nous indique un temps total de chargement, sans vider le cache du navigateur, de 804ms (Sélectionnez l’ensemble de la session concernée, et cliquez sur l’onglet statistiques):

image

Qu’en est-il du chargement initial, cache vidé, tel qu’un internaute le ferait lors d’une première visite?

image

Fiddler nous indique un temps total de connexion tcp/ip de 1,836 seconde, et un tableau de performances estimées pour le monde entier. Vu que je suis en bout de ligne ADSL à la campagne, les performances indiquées paraissent assez pessimistes, puisque j’obtiens moins de 2 secondes, au lieu des 2,20 indiquées. En tous cas, par rapport au début de l’article précédent, où nous en étions à 4,47 secondes dans les mêmes conditions, et 2,30 secondes sans vider le cache, le moins que l’on puisse dire est que le résultat est spectaculaire!

J’espère que ces essais vous auront donné l’envie de voir ce que cette optimisation apporterais à vos propres réalisations.

Comme toujours, commentaires bienvenus!

Publié dans .Net, C#, ASP.NET MVC 4.0 Tagués avec : , , , ,

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*

Lettre d’information

Recherche sur le Site

Recherche personnalisée