blocks|key|1136174|text|这个问题没有“正确”的答案--越快越好。就我个人而言，我通常的目标是<+200ms，尽管我从经验中知道，除了简单的应用程序之外，在Rails中实现这一目标是相当困难的。试着找出你的瓶颈在哪里，并缓存你能缓存的东西。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1136175|编辑:在页面生成时间和页面呈现时间之间似乎存在一些混淆。显然，快速呈现页面是我们的目标，而在大多数站点上，减少HTTP请求、压缩CSS/JS等操作都能让您获得最大的快速收益。但是，如果页面本身需要4-5秒才能生成，那么你可能是对的，你应该从你的应用程序开始。|1136176|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

There's no 'right' answer to this - the faster the better. Personally I normally aim for &lt; 200ms, although I know from experience that it can be quite difficult to achieve this in Rails on anything but simple apps. Try and figure out where your bottlenecks are and cache what you can.

Edit: There seems to be some confusion between page generation time and page render time. Obviously a quick page render is the goal, and on most sites doing things like reducing HTTP requests, gzipping CSS/JS are where you can get most of your quick wins. But if the page itself can take 4-5 seconds to generate, then you're probably right that your app is where you should start.

blocks|key|1133698|text|测量你的apdex分数，看看它的表现如何。这会给你一个粗略的标记。在此基础上，您可以决定如何提高性能。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1133699|它还取决于您的站点是什么；是业务的系统应用程序还是软件即服务(SaaS)？如果它是一个系统应用程序，则强制用户使用它来协商性能。如果它是一个SaaS，那么你的apdex分数越高，你失去用户兴趣的机会就越大。|1133700|有一些宝石可以衡量性能，并报告您的apdex是什么。|1133701|这里有更多的信息：http://apdex.org/blog/?p=630|offset|length|1133702|entityMap|0|LINK|mutability|MUTABLE|url|http://apdex.org/blog/?p=630^0|0|0|0|9|S|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@$H|V|I|W|1|X]]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

Measure your apdex score and see how it is performing. That will give you a rough indiciation. From there, you can decide how you want to increase performance.

It also depends on what your site is; an system application for a business or software as a service (SaaS)? If it's a system application, the users are forced to use it to performance can be negotiated. If it is a SaaS, then the higher your apdex score, the more chance you have of losing your user's interest.

There are a few gems out there that measure performance and report on what your apdex is.

Here's a little more info: <a href="http://apdex.org/blog/?p=630" rel="nofollow">http://apdex.org/blog/?p=630</a>

blocks|key|1136205|text|这取决于是否在2.5-4秒内什么都没有显示，或者用户从一开始就已经看到了页面的一部分，并且在2.5-4秒后完全完成加载。在这种情况下，用户不会体验到2.5-4秒的负载。以http://www.nytimes.com/网站为例，我马上就能看到它的大部分内容，但根据Web+Inspector的说法，它需要1.94秒才能完全加载。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1136206|请记住，速度还将取决于浏览器、计算机和互联网连接。对你来说快的可能对其他人来说就慢了。|1136207|entityMap|0|LINK|mutability|MUTABLE|url|http://www.nytimes.com/^0|2D|N|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

It depends on whether nothing is displayed for 2.5-4 seconds, or that the user already sees (a part of) the page from the start, and it finishes loading completely after 2.5-4 seconds. In that case the user doesn't experience a 2.5-4 second load. Take the <a href="http://www.nytimes.com/" rel="nofollow">http://www.nytimes.com/</a> website; I see most of it right away, but according to the Web Inspector it takes 1.94 seconds for it to be loaded completely.

And keep in mind that the speed will also depend on the browser, computer, internet connection. What's fast for you might be slower for others.

blocks|key|1882912|text|关于从查询到渲染的时间和用户体验，有大量的研究数据。我建议你读一读this+useit.com+article。毕竟，谷歌在其搜索结果中整合了页面速度是有原因的;)|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1882913|1882914|今天的3个响应时间限制与1993年我写的时候是一样的(基于人类因素先驱40年的研究)：|blockquote|1882915|1882916|1882917|1882918|0.1秒给人一种即时响应的感觉-也就是说，结果感觉像是用户造成的，而不是计算机造成的。这种级别的响应性对于支持直接操作的感觉是至关重要的(直接操作是增加用户参与度和控制力的关键图形用户界面技术之一-有关它的更多信息，请参阅我们的界面设计原则研讨会)。|unordered-list-item|1882919|1秒使用户的思维保持无缝。用户可以感觉到延迟，因此知道计算机正在生成结果，但他们仍然感觉到总体体验的控制，他们正在自由移动，而不是等待计算机。这种响应性是良好导航所必需的。|1882920|10秒会吸引用户的注意力。从1到10秒，用户肯定会感觉到电脑的摆布，并希望它更快，但他们可以处理它。10秒后，他们开始思考其他事情，一旦计算机最终做出反应，他们的大脑就更难回到正轨。|1882921|1882922|10秒的延迟通常会让用户立即离开网站。即使他们留下来，他们也更难理解发生了什么，这使得他们不太可能在任何困难的任务中取得成功。|1882923|作为一条经验法则，认为您应该始终以优化时间与所获得的时间之间的平衡为目标。当你的图像没有正确压缩，或者你的脚本/css没有组合时，不要花费几天的时间来优化一个例程。是的，越快越好，但是通过设置智能缓存生成页面的90%25的收益超过了调整算法一周后的10%25的收益。|1882924|此外，当框架必须加载所有内容时，不要过多地关注第一次渲染时的情况，而是使用压力测试，无论是否缓存，以模拟各种情况。|1882925|现在，有一些数据；我工作过的一些最新网站使用了DotNetNuke，一个巨大的开源内容管理系统，以及Asp.Net+MVC，在那里你可以更接近金属。对于DotNetNuke，平均数据库查询的平均页面时间为600-700毫秒。对于Asp.net+MVC，它是70-100毫秒...用户真的很喜欢第二个:)|1882926|entityMap|0|LINK|mutability|MUTABLE|url|http://www.useit.com/alertbox/response-times.html^0|X|M|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@$A|19|B|1A|1|1B]]|C|$]]|$1|D|3|-4|5|6|7|1C|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|1D|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|1E|8|@]|9|@]|C|$]]|$1|I|3|-4|5|6|7|1F|8|@]|9|@]|C|$]]|$1|J|3|-4|5|6|7|1G|8|@]|9|@]|C|$]]|$1|K|3|L|5|M|7|1H|8|@]|9|@]|C|$]]|$1|N|3|O|5|M|7|1I|8|@]|9|@]|C|$]]|$1|P|3|Q|5|M|7|1J|8|@]|9|@]|C|$]]|$1|R|3|-4|5|6|7|1K|8|@]|9|@]|C|$]]|$1|S|3|T|5|6|7|1L|8|@]|9|@]|C|$]]|$1|U|3|V|5|6|7|1M|8|@]|9|@]|C|$]]|$1|W|3|X|5|6|7|1N|8|@]|9|@]|C|$]]|$1|Y|3|Z|5|6|7|1O|8|@]|9|@]|C|$]]|$1|10|3|-4|5|6|7|1P|8|@]|9|@]|C|$]]]|11|$12|$5|13|14|15|C|$16|17]]]]

There's a huge amount of research data regarding the time from query to rendering and user's experience. I'd recommend reading <a href="http://www.useit.com/alertbox/response-times.html">this useit.com article</a>. After all Google integrated page speed in its results for a reason ;)

<blockquote>
 The 3 response-time limits are the
 same today as when I wrote about them
 in 1993 (based on 40-year-old research
 by human factors pioneers):
 
 <ul>
 <li>0.1 seconds gives the feeling of instantaneous response — that is, the
 outcome feels like it was caused by
 the user, not the computer. This level
 of responsiveness is essential to
 support the feeling of direct
 manipulation (direct manipulation is
 one of the key GUI techniques to
 increase user engagement and control —
 for more about it, see our Principles
 of Interface Design seminar).</li>
 <li>1 second keeps the user's flow of thought seamless. Users can sense a
 delay, and thus know the computer is
 generating the outcome, but they still
 feel in control of the overall
 experience and that they're moving
 freely rather than waiting on the
 computer. This degree of
 responsiveness is needed for good
 navigation.</li>
 <li>10 seconds keeps the user's attention. From 1–10 seconds, users
 definitely feel at the mercy of the
 computer and wish it was faster, but
 they can handle it. After 10 seconds,
 they start thinking about other
 things, making it harder to get their
 brains back on track once the computer
 finally does respond. </li>
 </ul>
 
 A 10-second delay will often make
 users leave a site immediately. And
 even if they stay, it's harder for
 them to understand what's going on,
 making it less likely that they'll
 succeed in any difficult tasks.
</blockquote>

As a rule of thumb, think that you always should aim for a balance of optimization time vs time gained. Don't spend days optimizing the hell out of one routine when your images aren't compressed correctly, or your scripts/css not combined. Yes, faster is better, but a 90% gain in generating the page by setting up a smart cache beats a 10% gain after one week tweaking the algorithm.

Also don't look too much into the first-render-time when the framework has to load everything, but use stress-testing, cached or not, to simulate various situations.

Now, some data; some of the latest sites i worked on used DotNetNuke, a huge open-source CMS, and Asp.Net MVC where you nearer to the metal. Average page time with average db queries was 600-700 milliseconds for DotNetNuke. For Asp.net MVC, it's 70-100 milliseconds... Users really like the second one :)

blocks|key|1136269|text|我个人的原则--页面不能超过0.05秒，否则你就有麻烦了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1136270|只要你编写了正确的代码，你就不需要花太多时间在优化上，就可以保持在0.05以下。|1136271|如果你坚持使用巨型框架，那么你就不走运了。|1136272|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

My personal rule - no page should take more than 0.05 seconds, or you are in troubles.

As long as you write proper code, you don't need to spend much time on optimization to stay under 0.05.

If you stick to giant frameworks, then you are out of luck.

I'm working on web app (Rails 3 based). And I really don't like the time it takes to generate the page - depending on the displayed data it takes up to 2.5 and even 4 seconds.

So I just was wondering what is the average reasonable time for generating page in your apps. Saying you check the generation time, e.g. it's 750ms and think "Ok, that should be fine even without caching". Or when you see 1.5sec you think "Oh my God, the user won't wait so long and leave the site"

What's the reasonable time for generating web page?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我正在开发web应用程序(基于Rails3)。我真的不喜欢生成页面的时间--根据显示的数据，它需要2.5秒甚至4秒。所以我想知道在你的应用程序中生成页面的平均合理时间是多少。如果你检查生成时间，比如它是750ms，然后想“好吧，即使没有缓存也没问题”。或者，当你看到1.5秒时，你会想“天哪，用户不会等这么久就离开网站的...

问生成网页的合理时间是什么？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问生成网页的合理时间是什么？EN