我正在尝试量化“站点缓慢”。在过去,您只需确保您的 HTML 是轻量级的、图像经过优化并且服务器不会超载。在建立在现代内容管理系统之上的高端网站中,存在更多变量:第三方广告、跟踪器和各种其他标注、CDN 的性能(有趣的是,有时内容交付网络会使事情变得更糟)、javascript 执行、css 过载,以及各种服务器端问题,如长查询。
显而易见的答案是每个开发人员都清除缓存并不断查看 Firebug 插件的“网络”部分。您还使用了哪些其他方法来衡量“网站拖屁股”?
我正在尝试量化“站点缓慢”。在过去,您只需确保您的 HTML 是轻量级的、图像经过优化并且服务器不会超载。在建立在现代内容管理系统之上的高端网站中,存在更多变量:第三方广告、跟踪器和各种其他标注、CDN 的性能(有趣的是,有时内容交付网络会使事情变得更糟)、javascript 执行、css 过载,以及各种服务器端问题,如长查询。
显而易见的答案是每个开发人员都清除缓存并不断查看 Firebug 插件的“网络”部分。您还使用了哪些其他方法来衡量“网站拖屁股”?
Yslow是一个可以帮助你的工具(浏览器扩展)。
YSlow 根据 Yahoo! 的高性能网站规则分析网页以及网页速度慢的原因。
一般来说,“页面加载时间”确实不容易定义。这取决于您使用的浏览器,因为不同的浏览器可能会并行执行更多请求,因为 javascript 在不同的浏览器中具有不同的速度,并且因为渲染时间不同。
因此,您只能使用您感兴趣的浏览器真正测量您的真实页面加载时间。页面加载的结束也可能难以定义,因为在页面上所有内容都可见之后可能会有 Ajax 请求。这是否计算页面加载?
最后但并非最不重要的一点是,实际页面加载时间可能并不重要,因为“感知性能”才是最重要的。对于用户来说,重要的是什么时候她有足够的信息来继续
我不知道有任何方法(至少我不能告诉你:])可以自动测量您的页面感知加载时间。
对 IE使用AOL Pagetest,对 firefox 使用 YSlow(链接见上文),以获得加载时间的“感觉”。
为自己安装一个合适的调试代理(我强烈推荐Charles)
您不仅可以查看响应时间/大小的完整细分,还可以保存数据以供以后分析/比较,以及摆弄请求/响应等。
(编辑:Charles 对调试 SOAP 请求的支持值得其共享软件费用的微薄 - 仅本周就为我节省了半天的脱发时间!)
我经常使用webpagetest.org,您可以使用它在不同的位置、在不同的浏览器(虽然只有msie 7-9)上使用不同的设置(迭代次数、连接速度、第一次运行与第二次访问,不包括特定的)执行性能测试如果需要,请求,如果需要凭据,...)。
结果是一个非常详细的页面加载时间报告,还提供了如何优化的建议。
它真的是一个很棒的(免费)工具!
上次我在一个大容量网站上工作时,我们做了几件事,包括:
如果您想快速浏览一下,比如说第一个近似值,我会选择 YSlow,看看影响您的应用程序页面加载时间的主要因素是什么。
PageSpeed是 Google 出品的在线查询工具,非常准确可靠:
如果是 asp.net,您可以使用 Trace.axd。
雅虎提供 yslow 可以很好地检查 javascript
YSlow 如上所述。
并将其与 Fiddler 结合使用。如果您想查看哪些页面对象占用了最多的带宽、哪些页面对象在服务器上被压缩、意外的往返以及正在缓存的内容,这将是很好的选择。与服务器和客户端之间的时间相比,它可以让您大致了解客户端 Web 浏览器中的处理时间
Yslow 很好,IE 的 HttpWatch 也很棒。然而,两者都错过了对用户来说最重要的指标“页面(首屏)何时可供用户使用?”。我觉得还没有解决...
显然有几种方法可以确定响应时间,但挑战一直是如何衡量在浏览器中花费的渲染时间。
我们有一个受控的测试阶段,在这个阶段我们使用几个自动化工具来测试应用程序。我们从此测试生成的输出之一是每个事务的提琴手跟踪(单击)。然后,我们可以分析提琴手跟踪以了解最后一个字节的时间,并将其减去页面花费的总时间。
像这样 1. A= 由自动化工具测量的总响应时间(在我们的例子中,我们使用 QTPro) 2. B= 到最后一个字节的时间(服务器 + 网络时间,来自 fiddler 跟踪) 3. C= AB (大约渲染时间,或在浏览器中花费的时间)
以上我解释的所有内容都可以作为标准测试过程,测试结束后我们可以生成每一层花费的时间分解,例如渲染时间、网络时间、数据库调用等......