Performances d'analyse Javascript et CSS

Question

J'essaie d'améliorer les performances d'une application Web. J'ai des métriques que je peux utiliser pour optimiser le temps nécessaire pour retourner la page HTML principale, mais je suis préoccupé par les fichiers CSS et JavaScript externes qui sont inclus à partir de ces pages HTML. Ceux-ci sont servis statiquement, avec les en-têtes HTTP Expires, mais sont partagés entre toutes les pages de l'application. Je suis préoccupé par le fait que le navigateur doit analyser ces fichiers CSS et JavaScript pour chaque page affichée et donc avoir tous les CSS et JavaScript pour le site partagé dans les fichiers communs aura une incidence négative sur les performances. Devrais-je essayer de scinder ces fichiers de sorte que je lise chaque page à partir du CSS et du JavaScript nécessaires pour cette page, ou est-ce que je n'aurais que peu de retour pour mes efforts?

Existe-t-il des outils qui pourraient m'aider à générer des métriques pour cela?

Answer 1

Contexte: Il est vrai que les frais généraux HTTP est plus important que l'analyse syntaxique JS et CSS, sans tenir compte de l'impact de l'analyse sur les performances du navigateur (même si vous avez moins d'un meg de JS) est une bonne façon de vous procurer en difficulté. YSlow, Fiddler, et Firebug ne sont pas les meilleurs outils pour surveiller la vitesse d'analyse.

À moins qu'ils n'aient été mis à jour très récemment, ils ne séparent pas le temps nécessaire pour récupérer JS sur HTTP ou charger à partir du cache et le temps passé à analyser la charge utile JS.

La vitesse d'analyse est un peu difficile à mesurer, mais nous avons poursuivi cette mesure un certain nombre de fois sur des projets sur lesquels j'ai travaillé et l'impact sur les pageloads était significatif même avec ~ 500k de JS. De toute évidence, les navigateurs les plus anciens en souffrent le plus ... espérons que Chrome, TraceMonkey et d'autres éléments de ce genre aident à résoudre cette situation.

Suggestion: En fonction du type de trafic que vous avez sur votre site, il peut être bien utile de votre temps pour partager votre charge utile JS donc quelques gros morceaux de JS qui ne seront jamais utilisés sur une des pages les plus populaires ne sont jamais envoyés au client. Bien sûr, cela signifie que lorsqu'un nouveau client atteint une page où ce JS est nécessaire, vous devez l'envoyer par le fil. Cependant, il se peut que, par exemple, 50% de votre JS ne soit jamais utilisé par 80% de vos utilisateurs en raison de vos habitudes de trafic. Si tel est le cas, vous devez certainement utiliser des charges JS compactes et plus petites uniquement sur les pages où le JS est nécessaire. Sinon, 80% de vos utilisateurs subiront des pénalités d'analyse JS inutiles sur chaque pageload.

Bottom Line: Il est difficile de trouver le bon équilibre de la mise en cache JS et plus petits, des charges utiles emballés, mais en fonction de votre modèle de trafic, il est certainement bien utile d'envisager une autre technique que fracassant tous vos JS dans chaque pageload.

Answer 2

Je crois que YSlow le fait, mais sachez que, sauf si toutes les demandes sont sur une connexion de bouclage, vous ne devriez pas vous inquiéter. La surcharge HTTP des fichiers décomposés aura un impact sur les performances plus important que l'analyse syntaxique, sauf si vos fichiers CSS/JS dépassent plusieurs mégaoctets.

Answer 3

Pour ajouter à la bonne réponse de kamen, je dirais que sur certains navigateurs, le temps d'analyse pour les ressources js plus volumineuses croît de façon non linéaire. Autrement dit, un fichier JS de 1 meg sera plus long à analyser que deux fichiers de 500 Ko. Ainsi, si une grande partie de votre trafic concerne des personnes susceptibles de mettre en cache votre JS (visiteurs de retour) et que tous vos fichiers JS sont stables dans le cache, il peut être judicieux de les supprimer même si vous finissez par les charger. chaque pageview.