Je travaille sur l'application Web (Rails 3 basé). Et je n'aime vraiment pas le temps nécessaire pour générer la page - en fonction des données affichées, elle prend jusqu'à 2,5 et même 4 secondes.
Donc, je me demandais simplement quel est le temps moyen raisonnable pour générer une page dans vos applications. Dire que vous vérifiez le temps de génération, par exemple C'est 750ms et penser "OK, ça devrait aller même sans mise en cache". Ou lorsque vous voyez 1.5sec, vous pensez "Oh mon Dieu, l'utilisateur n'attendra pas si longtemps et laissez le site"
5 Réponses :
Il n'y a pas de réponse «droite» à cela - plus le mieux est rapide. Personnellement, je vise normalement <200ms, bien que je sache de l'expérience qu'il peut être assez difficile de réaliser cela dans des rails à autre que des applications simples. Essayez de déterminer où vos goulots d'étranglement sont et cachent ce que vous pouvez.
Edit: Il semble y avoir une certaine confusion entre la génération de page et le temps de rendu de la page. Évidemment, une page rapide rendu est l'objectif, et sur la plupart des sites faisant des choses comme la réduction des demandes HTTP, Gzipping CSS / JS est l'endroit où vous pouvez obtenir la plupart de vos victoires rapides. Mais si la page elle-même peut prendre 4-5 secondes pour générer, alors vous avez probablement raison que votre application soit l'endroit où vous devriez commencer.
Je pense que l'un des temps les plus importants est l'utilisateur perçu temps. Beaucoup d'optimisations actuellement appliquées sur des sites Web ne prennent pas compte du code, mais plutôt de se concentrer sur la chargement asynchrone de JavaScript et du téléchargement parallèle de Ressources.
Mesurez votre score APDEX et voyez comment cela se passe. Cela vous donnera une indication approximative. De là, vous pouvez décider de la manière dont vous voulez augmenter la performance.
Cela dépend aussi de ce que votre site est; une application système pour une entreprise ou un logiciel en tant que service (SaaS)? Si c'est une application système, les utilisateurs sont obligés de l'utiliser pour des performances peuvent être négociés. S'il s'agit d'un SaaS, alors plus votre score APDEX est élevé, plus vous avez de chances de perdre l'intérêt de votre utilisateur.
Il y a quelques joyaux qui mesurent la performance et de faire rapport sur ce que votre APDEX est.
Voici un peu plus d'informations: http://apdex.org/blog/?p=630 < / a>
Cela dépend de la question de savoir si rien n'est affiché pendant 2,5 à 4 secondes, ou que l'utilisateur voit déjà (une partie de) la page du début, et elle finit complètement après 2,5 à 4 secondes. Dans ce cas, l'utilisateur n'a pas l'expérience d'une charge de 2,5 à 4 secondes. Prenez le http://www.nytimes.com/ site web; Je vois la plupart d'entre eux tout de suite, mais selon l'inspecteur Web, il faut 1,94 secondes pour qu'il soit chargé complètement.
et gardez à l'esprit que la vitesse dépendra également du navigateur, de l'ordinateur, de la connexion Internet. Ce qui est rapide pour vous pourrait être plus lent pour les autres.
Il y a une énorme quantité de données de recherche sur le moment de la requête au rendu et à l'expérience de l'utilisateur. Je recommanderais de lire Cet article useit.com . Après toute la vitesse de la page intégrée de Google dans ses résultats pour une raison;)
Les 3 limites de temps de réponse sont les même aujourd'hui que quand j'ai écrit à leur sujet En 1993 (basé sur des recherches de 40 ans par des facteurs humains pionniers):
- 0,1 seconde donne le sentiment de réponse instantanée - c'est-à-dire la résultat se sent comme si c'était causé par l'utilisateur, pas l'ordinateur. Ce niveau de la réactivité est essentiel pour Soutenir le sentiment de direct manipulation (la manipulation directe est une des techniques clés de l'interface graphique à augmenter l'engagement et le contrôle de l'utilisateur - Pour plus de choses à ce sujet, voir nos principes du séminaire de conception d'interface).
- 1 seconde maintient le flux de la pensée de l'utilisateur sans soudure. Les utilisateurs peuvent sentir un retarder, et ainsi connaître l'ordinateur est générer le résultat, mais ils sentir en contrôle de l'ensemble expérience et qu'ils bougent librement plutôt que d'attendre sur le ordinateur. Ce degré de la réactivité est nécessaire pour le bien Navigation.
- 10 secondes garde l'attention de l'utilisateur. À partir de 1 à 10 secondes, utilisateurs se sentir vraiment à la merci de la ordinateur et souhait que c'était plus rapide, mais Ils peuvent le gérer. Après 10 secondes, Ils commencent à penser à d'autres choses, ce qui rend plus difficile d'obtenir leur cerveaux sur la piste une fois l'ordinateur enfin réagit.
Un délai de 10 secondes fera souvent Les utilisateurs quittent un site immédiatement. Et Même s'ils restent, il est plus difficile de eux pour comprendre ce qui se passe, rendre moins probable qu'ils vont réussir dans toutes les tâches difficiles.
En règle générale, pensez que vous devriez toujours viser une balance du temps d'optimisation vs gagné. Ne passez pas des jours à optimiser l'enfer d'une routine lorsque vos images ne sont pas correctement comprimées, ou vos scripts / CSS non combinés. Oui, plus vite est meilleur, mais un gain de 90% dans la génération de la page en configurant un cache intelligent bat un gain de 10% après une semaine modifier l'algorithme.
Ne ressemble également pas trop au premier moment du rendu lorsque le cadre doit tout charger, mais utilisez des tests de stress, mis en cache ou non, de simuler diverses situations.
Maintenant, certaines données; Certains des derniers sites que j'ai travaillés sur DotNetNuke d'occasion, un énorme CMS open-source et ASP.NET MVC où vous êtes plus proche du métal. L'heure moyenne de la page avec les requêtes moyennes de DB était de 600 à 700 millisecondes pour DotNetNuke. Pour ASP.NET MVC, il est 70-100 millisecondes ... Les utilisateurs aiment vraiment le second :)
Ma règle personnelle - Aucune page ne doit prendre plus de 0,05 seconde, ou vous êtes dans des problèmes.
Tant que vous écrivez un code approprié, vous n'avez pas besoin de passer beaucoup de temps à l'optimisation pour rester moins de 0,05.
Si vous vous tenez à des cadres géants, vous n'avez pas de chance.
Wow, vous avez des sites qui sont si rapides, félicitations! Vous devez mettre en cache l'enfer de vos demandes de DB, je suppose. Que travaillez-vous, un cadre barré?
Par curiosité, pouvez-vous personnellement dire la différence entre 0,1 seconde et 0,05 secondes? Si oui, la différence vous dérange-t-elle vraiment? Je ne demande que parce que .05 semble être un nombre arbitraire incroyable.
Oui, cela compte quand vous commencerez à obtenir une charge réelle. Ce n'est pas un baremetal, il ne fait que des caches légers et de mémoire.
Oui si vous utilisez STATIC HTML, vous pouvez atteindre 0,05, sinon vous n'avez pas de chance
Vous pouvez atteindre 0,05 avec des pages dynamiques complexes. Il faut juste écrire le code correctement. Et même 0,01 n'est pas une grosse affaire.
Je vois .. Apparemment, les utilisateurs de «cadres géants» qui ne peuvent pas obtenir moins de 0,5 sensement insulté ...
@Barsmonster Pourrions-nous avoir un exemple d'une de vos pages?
Je vais uppoter ça. J'ai 0,002 secondes sur les pages qui ne sont pas gérées par un CMS (et Couchccms est un très léger). Sur ceux qui dépend de 0,05 seconde (une page d'article) à 0,15 seconde (tableau des matières avec tous les articles répertoriés).
UPVOTE. Vint ici lors de la recherche si ma génération de page dynamique de 0,002-0.005 secondes est trop lente. Apparemment, c'est assez rapide. (Code personnalisé, pas de CMS, pas de mise en cache)
Que fait votre demande?
@Gumbo, il affiche diverses données de statistiques
De toute évidence, vous devriez essayer de le rendre aussi rapide que possible, mais la vitesse dépend vraiment de ce que vous faites. Aussi, décomposez les temps en parties. Par exemple, il y aura du temps pour l'accès à la base de données et une heure pour le rendu de la page. Lequel prend-il beaucoup de temps? S'il s'agit de rendu, vous utilisez probablement beaucoup de JavaScript. Le JavaScript peut-il être séparé en une requête AJAX que la charge après la charge de la page est chargée dans le navigateur. Si c'est la base de données, assurez-vous de faire tout ce que vous devez faire pour optimiser. Chargement impatient, index appropriés, etc.
Vous ne devriez pas essayer de le rendre "aussi vite que possible", vous devriez essayer de le rendre "assez rapide"