我已经开始添加将页面呈现到内部Web应用程序页脚所花费的时间。目前它看起来像这样
在0.062秒内渲染
偶尔我会像这样得到渲染时间
在0.000秒内渲染
目前，它仅仅是指导用户判断页面是否可以快速加载，如果页面花费17秒而不是通常的0.5，它们可以快速通知我们。我的问题是时间应该是什么格式？我应该切换到
等语句在不到一秒的时间内呈现
我喜欢看到十分之一秒，但上面的第二个例子对任何人都没用，实际上它只是突出了我用来查找渲染时间的计算限制。我宁愿不让用户看到它！欢迎任何答案，包括页面上是否应包含任何内容。
答案 0 :(得分：2)
“立即渲染”听起来比“在不到一秒钟内渲染”更好。
答案 1 :(得分：1)
不是依靠您的用户查看页脚并告知您该值是否超过某个耐心阈值，而是将页面呈现时间记录在服务器上的日志文件中可能更好。获得所有原始数据后，您可以查找特定页面，这些页面的渲染时间往往比平时要长。
通过更详细的日志记录，您还可以测量数据库查询中的已用时间，或者如果您的Web应用依赖外部系统，则可以测量。
答案 2 :(得分：1)
我不确定告诉用户服务器渲染页面需要多长时间。你可能值得记录这类信息，但他们并不关心。
如果需要0.001秒的服务器来绘制页面，但是加载它需要17秒（由于网络，javascript，页面大小，垃圾PC等），他们的感知将是后者。< / p>
然后再次添加渲染时间可能会帮助您通过“与本地网络管理员交谈”响应来避免对任何令人感到缓慢的查询。
鉴于您知道测量的准确性，您可以将0.000文本设置为“在不到千分之一秒内渲染”
答案 3 :(得分：0)
我认为我过分强调这是针对用户的。
我知道通过在web.config中使用trace，我可以获得有关页面呈现时间的准确信息以及访问数据库的时间。
我们过去遇到的问题是应用程序在网络上运行速度太慢，尽管现在已经修复了我正在为新应用程序添加标签，以便用户意识到这是我们正在认真对待的事情，这是一个非常简单的指标开发者。
考虑到所有这一点，我喜欢“立即渲染”并写出很多意义所以我会接受你的回答和kokos'。
由于