Les performances dans Firebug contredisent YSlow

Question

J'ai une simple application Web ASP.Net MVC3. J'ai fait du réglage de performance récemment. J'ai utilisé Firebug dans Mozilla pour revoir la taille et le timing du chargement des ressources. Plus tard, j'ai utilisé YSlow pour dériver une optimisation possible.

Je voudrais limiter la mise au point du concept d'optimisation générale de « & minification regroupement » dans lequel nous rapetisser js & et faisceau css dans & d'un seul css combiné. Selon YSlow, il enregistre des demandes de serveur supplémentaires et également de la bande passante/temps. Cependant, dans mon cas ça contredit! J'utilise SquishIt lib.

Here're mes statistiques (pls revue les images jointes)

Old Login page: Requests(10), Size(434), Load Time in seconds(29), YSlow grade C(78) 
New Login page: Requests(6), Size(414), Load Time in seconds(42), YSlow grade B(88) 

Vieille page originale - Voici la nouvelle page optimisée -

Idéalement, il doit être inversée ! Mais il semble que le fichier js combiné soit prenant plus de temps. J'ai ralenti ma bande passante pour obtenir plus de différence précise et je l'ai testé dans un non-mis en cache (aussi fait Ctrl + F5) pour s'assurer que les deux pages ont une chance équitable. Ils sont sur le même servre avec la même configuration.

Notes: Pls ignorer la dernière reload image dans l'image - je l'ai fait un rafraîchissement. Mon pré-chargement de la librairie jQuery supplémentaire sur la page de connexion afin que les pages suivantes aient des ressources en cache. Vous pouvez ignorer de telles choses mais les pls me font savoir si c'est possible ou est-ce que je fais une erreur?

Encore une requête concernant le groupement & minification - Je crois que ce ne est pas applicable si j'utilise des références CDN pour mes ressources (tehy ne peut pas être fourni). Dans ce cas, qu'est-ce qui est préféré - les références ou le regroupement de CDN?

Answer 1

En général, je pense que vous êtes sur la bonne voie: moins de demandes + plus petite taille totale des demandes = meilleures performances pour la plupart de vos utilisateurs.

dans vos résultats de tests, je pense que vous voyez deux choses:

1. Un inconvénient d'utiliser des fichiers plus volumineux combinés est que vous perdez un certain avantage de téléchargements parallèles. Je ne pense pas que ce soit un contributeur majeur dans votre cas, mais vous pouvez voir dans votre cas d'origine que de nombreux fichiers jquery JS sont téléchargés en parallèle.
2. La charge totale de la page peut varier d'une exécution à l'autre en fonction de la vitesse du réseau et de la charge du serveur. Dans votre cas d'origine, le fichier jquery-ui était de 222 Ko et prenait 27,8 secondes pour environ 8 Ko/s. Dans votre page optimisée, le nouveau JS combiné était de 254 Ko et prenait 41 secondes pour une vitesse de 6,2 Ko/s. C'est un calcul très approximatif, mais je pense que cela pourrait donner une idée des différences que vous avez vues.

Si votre site est disponible sur l'Internet, vous pouvez utiliser un outil comme WebPageTest ou GTmetrix pour exécuter des mesures à partir d'un serveur externe (et emplacements multiples). Pour votre question de CDN par rapport à l'empaquetage, finalement vous pourriez tester certains prototypes de façon à voir ce qui fonctionne le mieux pour vous. Une option aurait de grands fichiers qui changent rarement, comme jQuery provenant du CDN, et tous vos JS hébergés sur votre serveur (inclus). Une chose à garder à l'esprit au sujet de l'hébergement CDN de fichiers statiques, le plus grand avantage vient quand vous avez une base d'utilisateurs répartis géographiquement. Ensuite, ils peuvent tirer parti d'un réseau CDN global, en recevant des fichiers statiques d'un serveur plus proche d'eux (et donc plus rapide). Inversement, si votre base d'utilisateurs n'est pas diffusée dans le monde entier ou s'il s'agit d'une application interne, l'utilisation d'un CDN peut ne pas être très utile.