如何测量页面加载速度？
我正在尝试量化“网站缓慢”。 在过去，您只需确保 HTML 是轻量级的、图像经过优化并且服务器不会过载。 在建立在现代内容管理系统之上的高端网站中，存在更多的变量：第三方广告、跟踪器和各种其他标注、CDN 的性能（有趣的是，有时内容交付网络会让事情变得更糟）、JavaScript 执行、CSS 过载，以及各种服务器端问题，例如长查询。
显而易见的答案是每个开发人员都清除缓存并不断查看 Firebug 插件的“net”部分。 您还使用过哪些其他方法来衡量“网站拖屁股”？
I am trying to quantify "site slowness". In the olden days you just made sure that your HTML was lightweight, images optimized and servers not overloaded. In high end sites built on top of modern content management systems there are a lot more variables: third party advertising, trackers and various other callouts, the performance of CDN (interestingly enough sometimes content delivery networks make things worse), javascript execution, css overload, as well as all kinds of server side issues like long queries.
The obvious answer is for every developer to clear the cache and continuously look at the "net" section of the Firebug plugin. What other ways to measure "site dragging ass" have you used?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（14）
Yslow 是一个可以帮助您的工具（浏览器扩展）。
Yslow is a tool (browser extension) that should help you.
Firebug，Web开发者必备的Firefox扩展，可以测量加载情况网页上不同元素的时间。 至少您可以排除 CSS、JavaScript 和其他元素加载时间过长的情况。
如果您确实需要缩短 JavaScript 和 CSS 加载时间，网络上有各种 JavaScript 和 CSS 压缩器，它们可以简单地从中删除不必要的文本，例如换行符和注释。 当然，为了开发方便，保留一个普通版本。
如果您使用 PNG，我最近遇到了一个可以缩小 PNG 大小的 PNG 优化器，名为 OptiPNG。
Firebug, the must have for web developers Firefox extension, can measure the loading time of different elements on your webpage. At least you can rule out CSS, JavaScript, and other elements taking too much time to load.
If you do need to shrink JavaScript and CSS loading times, there are various JavaScript and CSS compressors out there on the web that simply take out unnecessary text out of them like newline characters and comments. Of course, keep an ordinary version on the side for development sake.
If you use PNGs, I recently came across a PNG optimizer that can shrink PNG sizes called OptiPNG.
一般来说，“页面加载时间”确实不容易定义。
这取决于您使用的浏览器，因为不同的浏览器可能会并行执行更多请求，因为javascript在不同的浏览器中具有不同的速度，并且渲染时间也不同。
因此，您只能使用您感兴趣的浏览器来真正测量真实的页面加载时间。
页面加载的结束也可能很难定义，因为在页面上的所有内容都可见之后可能会出现 Ajax 请求。 这是否计算页面加载？
最后但并非最不重要的一点是，实际页面加载时间可能并不那么重要，因为“感知性能”才是最重要的。 对于用户来说，重要的是她何时有足够的信息来继续
Markus
我不知道有什么办法（在至少我可以告诉你:])这会自动测量你的页面感知加载时间。
使用 AOL Pagetest for IE 和 YSlow for firefox（链接见上文）为您带来“感觉”加载时间。
"Page Load time" is really not easy to define in general.
It depends on the browser you use, because different browsers may do more requests in parallel, because javascript has differents speeds in different browsers and because rendering time is different.
Therefore you can only really measure your true page load time using the browser you are interested in.
The end of the page load can also be difficult to define because there might be an Ajax request after everything is visible on the page. Does that count the the page load or not?
And last but not least the real page load time might not matter that much because the "perceived performance" is what matters. For the user what matters is when sHe has enough information to proceed
Markus
I'm not aware of any way (at least no I could tell you :] ) that would automatically measure your pages perceived load time.
Use AOL Pagetest for IE and YSlow for firefox (link see above) to get a "feeling" for you load time.
为自己安装一个合适的调试代理（我强烈推荐Charles）
您不仅能够看到完整的故障响应时间/大小，您可以保存数据以供以后分析/比较，以及摆弄请求/响应等。
（编辑：Charles 对调试 SOAP 请求的支持值得其共享软件费用的微薄 - 它救了我仅这一周就掉了半天头发！）
Get yourself a proper debugging proxy installed (I thoroughly recommend Charles)
Not only will you be able to see a full breakdown of response times / sizes, you can save the data for later analysis / comparison, as well as fiddle with the requests / responses etc.
(Edit: Charles' support for debugging SOAP requests is worth the pittance of its shareware fee - it's saved me a good half a day of hair-loss this week alone!)
我经常使用 webpagetest.org，您可以使用它在不同位置、不同浏览器上执行性能测试（尽管只有 msie 7） -9)，具有不同的设置（迭代次数、连接速度、第一次运行与第二次访问、如果需要的话排除特定请求、如果需要的话提供凭据，...）。
结果是非常详细的页面加载时间报告，其中还提供了有关如何优化的建议。
它确实是一个很棒的（免费）工具！
I routinely use webpagetest.org, which you can use to perform performance tests from different locations, on different browsers (although only msie 7-9), with different settings (number of iterations, connection speed, first run vs 2nd visit, excluding specific requests if you want, credentials if needed, ...).
the result is a very detailed report of page loading time which also provides advise on how to optimize.
it really is a great (free) tool!
上次我在一个大容量网站上工作时，我们做了几件事，包括：
如果您想快速浏览，请先说近似值，我会选择 YSlow，看看影响应用程序页面加载时间的主要因素是什么。
Last time I worked on a high-volume website, we did several things, including:
If you want a quick look, say a first approximation, I'd go with YSlow and see what the major factors affecting page load time in your app are.
好吧，请叫我老式的，但是..
time curl -L http://www.example.com/path
在 Linux 中:) 除此之外，正如前面提到的，我是 YSlow 的忠实粉丝。
Well, call me old fashioned but..
time curl -L http://www.example.com/path
in linux :) Other than that, I'm a big fan of YSlow as previously mentioned.
PageSpeed是Google推出的在线检查工具，非常准确可靠：
https:// /developers.google.com/pagespeed/
PageSpeed is an online checking tool by Google, which is very accurate and reliable:
https://developers.google.com/pagespeed/
如果是asp.net，您可以使用Trace.axd。
雅虎提供了 yslow，它非常适合检查 javascript
If it's asp.net you can use Trace.axd.
Yahoo provide yslow which can be great for checking javascript
YSlow 如上所述。
并将其与 Fiddler 结合起来。 如果您想查看哪些页面对象占用了最多的带宽、哪些页面对象在服务器上被压缩、意外的往返以及正在缓存的内容，那么这是很好的选择。 它可以让您大致了解客户端 Web 浏览器中的处理时间与服务器和服务器之间所花费的时间相比。 客户
YSlow as mentioned above.
And combine this with Fiddler. It is good if you want to see which page objects are taking the most bandwidth, which are being compressed at the server, unexpected round-trips, and what is being cached. And it can give you a general idea about processing time in the client web browser as compared to time taken between server & client
Apache 基准。 使用
ab -c <服务器上的CPU数量> -n 1000 url可以很好地估计页面的速度。
Apache Benchmark. Use
ab -c <number of CPUs on server> -n 1000 urlto get good approximation of how fast your page is.
在 Safari 中，网络时间轴（在“开发”菜单下可用，您必须专门启用）提供有关各个页面组件加载时间的有用信息，并显示当每个组件开始加载时。
In Safari, the Network Timeline (available under the Develop menu, which you have to specifically enable) gives useful information about loading time of individual page components, as well as showing when each component started loading.
Yslow 很好，HttpWatch for IE 也很棒。 然而，两者都忽略了对用户最重要的指标“首屏页面何时可供用户使用？”。 我认为这个问题还没有解决...
Yslow is good, and HttpWatch for IE is great as well. However, both miss the most important metric to a user "When is the page -above the fold- ready for use to the user?". I don't think that one has been solved yet...
显然有多种方法可以确定响应时间，但挑战始终是如何测量浏览器中花费的渲染时间。
我们有一个受控的测试阶段，其中我们使用多个自动化工具来测试应用程序。 我们从这个测试中生成的输出之一是每个事务的 fiddler 跟踪（一次点击）。 然后，我们可以分析 fiddler 跟踪以了解最后一个字节的时间，并将其减去页面所花费的总时间。
像这样的东西
1. A= 由自动化工具测量的总响应时间（在我们的例子中，我们使用 QTPro）
2. B= 最后一个字节的时间（服务器 + 网络时间，来自 fiddler 跟踪）
3. C= AB（大约渲染时间，或在浏览器中花费的时间）
我解释的所有上述内容都可以作为标准测试过程，测试结束时我们可以生成每层花费的时间的细分，例如渲染时间、网络时间、数据库调用等...
There are obviously several ways to identify the response time, but the challenge has always been how to measure the rendering time that is spent in browser.
We have a controlled test phase in which we use several automated tools for testing the application. One of the output we generate from this test is a fiddler trace for each transaction (a click). We can then analyse the fiddler trace to understand the Time for last byte and subtract it with the overall time the page took.
Something like this
1. A= Total response time as measured by the an automated tool (in our case we use QTPro)
2. B= Time to last byte (Server + Network time, from the fiddler trace)
3. C= A-B (approx Rendering time, OR the time spent in browser)
All the above I explained can be made a standard test process and end of the test we could generate a break-up of time spent at each layer e.g. rendering time, network time, database calls etc...