Optimizing websites for speed is a craft, and each craft requires tools. The most-used website optimization tools are GTmetrix, YSlow and Pingdom Tools.
优化网站的速度是一项技巧，每一项技巧都需要工具。 最常用的网站优化工具是GTmetrix ， YSlow和Pingdom Tools 。
GTmetrix is a rather advanced tool that offers a lot on its free tier, but it also offers premium tiers. If you sign up, you can compare multiple websites, multiple versions of the same website, tested under different conditions, and save tests for later viewing.
GTmetrix是一个相当高级的工具，在其免费套餐中提供了很多功能，但同时也提供了高级套餐 。 如果您注册，则可以比较多个网站，同一网站的多个版本，在不同条件下进行测试的情况，并保存测试以供以后查看。
YSlow is still relevant, although its best days were those when Firebug ruled supreme among the browser inspectors. It offers a Chrome app and other implementations — such as add-ons for Safari and Opera, a bookmarklet, an extension for PhantomJS, and so on.
YSlow仍然有意义，尽管它的最佳时期是Firebug在浏览器检查员中居于统治地位的日子。 它提供了一个Chrome应用程序和其他实现 -例如Safari和Opera的附件，一个书签，一个PhantomJS的扩展等等。
For advanced users, PhantomJS integration means that one could, for example, automate the testing of many websites — hundreds or thousands — and export the results into the database.
对于高级用户而言，PhantomJS集成意味着，例如，它可以自动化许多网站(数百或数千个)的测试，并将结果导出到数据库中。
YSlow’s Ruleset Matrix has for a number of years been a measuring stick for website performance.
YSlow的Ruleset矩阵多年来一直是衡量网站性能的标准。
Pingdom Tools is a SaaS service that offers monitoring and reporting of website performance, and it has strengthened its market position in recent years. It also offers a DNS health check and website speed testing on its free tier, which is comparable to GTMetrix and YSlow.
Pingdom Tools是一项SaaS服务，可提供网站性能的监视和报告，并且近年来已增强了其市场地位。 它还免费提供了DNS运行状况检查和网站速度测试，可与GTMetrix和YSlow媲美。
For the purposes of this article, we purchased a fitting domain name — ttfb.review — and installed Drupal with some demo content on it. We also installed WordPress on wp.ttfb.review, and demo installations of Yii and Symfony on their respective subdomains.
为了本文的目的，我们购买了一个合适的域名ttfb.review ，并安装了带有一些演示内容的Drupal。 我们还在wp.ttfb.review上安装了WordPress，并在各自的子域上演示了Yii和Symfony的演示安装。
We used the default WordPress starting installation. For Drupal, we used the Devel and Realistic Dummy Content extensions to generate demo content. For Symfony we used the Symfony demo application, and for Yii we used basic application template.
我们使用默认的WordPress开始安装。 对于Drupal，我们使用了Devel和realistic Dummy Content扩展来生成演示内容。 对于Symfony，我们使用了Symfony演示应用程序 ；对于Yii，我们使用了基本应用程序模板 。
This way, we’ll be able to compare these installations side-by-side, and point out the things that deserve attention.
这样，我们将能够并排比较这些安装，并指出需要注意的事项。
Please be aware that these are development-level installations, used only for demonstration purposes. They aren’t optimized for running in production, so our results are likely to be subpar.
请注意，这些是开发级安装，仅用于演示目的。 它们并未针对在生产中运行进行优化，因此我们的结果可能会低于标准。
After logging in (registration is free), we tested all four of our demo websites, and compared the results side-by-side:
登录后(免费注册)，我们测试了所有四个演示网站，并比较了结果：
We can see that our Drupal installation loaded the fastest, while Yii’s installation took a whopping ten seconds to load. However, it wouldn’t be smart to use this for any kind of technology comparison, as these are not production-ready websites, and those systems that require more knowledge and work to set up are expected to come in “debug” (or development) mode. The other thing to keep in mind is that to get any conclusive results, it’s advisable to repeat the tests a couple of times. Our testing server’s virtualization system is OpenVZ, for which resource allocation can be inconsistent.
我们可以看到我们的Drupal安装加载速度最快，而Yii的安装加载时间却高达10秒。 但是，将其用于任何类型的技术比较都不明智，因为它们不是可用于生产的网站，并且那些需要更多知识和工作才能建立的系统预计会“调试”(或开发) )模式。 要记住的另一件事是，要获得任何确凿的结果，建议重复测试两次。 我们测试服务器的虚拟化系统是OpenVZ，其资源分配可能不一致。
We can see the relevant metrics:
我们可以看到相关指标：
total number of requests 请求总数 total page size 总页面大小 total time of loading 总加载时间We could say that these are the primary metrics we ought to pay attention to, the most important of which is loading time. All the other metrics we see are useful guidelines that give us clues on how to improve our loading time.
我们可以说这些是我们应该注意的主要指标，其中最重要的是加载时间。 我们看到的所有其他指标都是有用的准则，这些准则为我们提供了有关如何缩短加载时间的线索。
Shaun Anderson of the Hobo SEO agency from UK published an article on the correlation between website speed and conversions/Google ranking — with some interesting results.
来自英国Hobo SEO机构的Shaun Anderson发表了一篇有关网站速度与转化次数/ Google排名之间的相关性的文章 ，并得出了一些有趣的结果。
The thing to keep in mind is that time matters most. All other metrics are mere guidelines.
要记住的是时间最重要。 所有其他指标仅是准则。
This comparison can be seen online on GTmetrix, so readers can analyze it item by item.
可以在GTmetrix上在线查看此比较，因此读者可以逐项进行分析。
The first set of results is in the PageSpeed tab, where we can see that the only thing that this algorithm complains about with our Yii installation (the slowest in our test) is JS minification (or, rather, the lack of it). Drupal is the best, although it has most of the red flags. If we take page size into consideration, Symfony fares the best, with a page weight of only 507KB.
第一组结果在PageSpeed选项卡中，我们可以看到该算法在我们的Yii安装中(我们测试中最慢的)抱怨的唯一事情是JS缩小(或者缺少它)。 Drupal是最好的，尽管它具有大多数危险信号。 如果考虑页面大小，Symfony的效果最好，页面重量仅为507KB。
We can see from this example that mere test grades don’t tell us everything.
从这个例子中我们可以看出，仅仅考试成绩并不能告诉我们一切。
If we switch to the YSlow tab, we see more realistic scores:
如果我们切换到“ YSlow”标签，我们会看到更现实的分数：
But it’s still hard to ascribe the loading time difference to any of these items. That’s why we have the Waterfall tab: it shows us where the delay is. Waterfall comparison, for lack of screen real-estate, can only compare two results side-by-side, so we’ll compare Drupal and Yii installations (best and worst loading time) on this results page:
但是，仍然很难将加载时间差归因于任何这些项目。 这就是为什么要使用“ 瀑布”选项卡的原因：它显示了延迟在哪里。 由于缺乏屏幕空间，瀑布比较只能并排比较两个结果，因此我们将在此结果页面上比较Drupal和Yii安装(最佳和最差的加载时间)：
This finally gives us some clue that none of the previous tools gave us. The whole nine seconds spent by Yii are spent on the first (main) request for the website’s HTML — not for the static resources. If we hover over the long, purple line on the Yii chart, we’ll have GTmetrix spell out for us the exact anatomy of that nine-second response:
最终，这为我们提供了一些以前的工具都没有给我们的线索。 Yii花费的整个九秒时间都花在了网站HTML的第一个(主要)请求上，而不是静态资源。 如果我们将鼠标悬停在Yii图表上的紫色长线上，我们将让GTmetrix为我们清楚地说明该9秒响应的解剖结构：
Here we can detect where the problem lies — in the “Waiting” phase, in the page generation phase, or to use a more familiar term, TTFB, Time To First Byte. This means that the problem lies purely on our Nginx or PHP side. The things we can do about this are manifold, and have a lot to do with the exact application we are dealing with. We would need to inspect where the issue lies on our backend.
在这里，我们可以检测出问题所在–在“等待”阶段，页面生成阶段，或者使用更熟悉的术语TTFB ，即第一个字节的时间 。 这意味着问题完全出在我们的Nginx或PHP方面。 我们可以做的事情是多方面的，并且与我们正在处理的确切应用程序有很大关系。 我们需要检查问题出在我们后端的什么地方。
It could be a resource-hungry application, inefficient database queries, server-software RAM constraints, etc. A tool that can come in handy here to monitor server processes is Monit, along with application-specific tools and procedures to diagnose and improve loading time. Two things that will almost always improve TTFB are: more server resources, and caching solutions like Varnish. If the static resources were the main culprit, we would need to pay more attention to warnings on the PageSpeed and YSlow tabs, gzipping, minification, and perhaps deploy our website on a CDN like Cloudflare.
这可能是一个消耗资源的应用，低效的数据库查询，服务器软件RAM限制等一个工具，可以在这里派上用场，以监视服务器进程是monit的 ，用专用工具和程序以及诊断和改善加载时间。 几乎总能改善TTFB的两件事是：更多的服务器资源，以及诸如Varnish之类的缓存解决方案。 如果静态资源是主要的罪魁祸首，我们将需要更加注意PageSpeed和YSlow选项卡上的警告，gzip压缩，缩小以及将我们的网站部署在Cloudflare之类的CDN上。
One of the reasons for the difference between Drupal and Yii might be the fact that Drupal comes with “batteries included”, more production-ready out of the box, while Yii comes ready for extensive development.
Drupal和Yii之所以不同的原因之一可能是因为Drupal附带了“包括电池”，开箱即用，而Yii可以进行广泛的开发。
We can see that the Drupal installation comes, by default, with some caching solutions turned on:
我们可以看到，默认情况下，Drupal安装附带了一些缓存解决方案：
After tinkering with Drupal for a bit, and toying with its built-in modules and configuration options like BigPipe and caching, we could reduce the load time by another half-second:
在对Drupal进行了一些修改之后，并使用了其内置模块和配置选项(例如BigPipe和缓存)，我们可以将加载时间再减少半秒：
We can see the comparison on GTmetrix.
我们可以在GTmetrix上看到比较 。
On GTmetrix, we can compare our tests from the home page:
在GTmetrix上，我们可以从主页比较测试：
We can also simply add different report URL suffixes to see them side-by-side:
我们还可以简单地添加不同的报告URL后缀并排查看：
For the Video tab, we must enable the video-recording option in our Advanced options:
对于“ 视频”选项卡，我们必须在“ 高级”选项中启用“视频录制”选项：
(By the way, we can see that in subsequent tests, Drupal’s cache warm-up reduced our website’s load time by a further 200 miliseconds.)
(顺便说一下，我们可以看到，在随后的测试中，Drupal的缓存预热使我们的网站的加载时间又减少了200毫秒。)
Now we have video available in the Video tab of the results:
现在，结果的“视频”选项卡中提供了视频：
This way, we can sometimes visually get clues about the loading issues or bottlenecks. The system also offers to generate a filmstrip of the page load.
这样，有时我们可以从视觉上获得有关加载问题或瓶颈的线索。 该系统还提供生成页面加载的幻灯片的功能。
In single tests, there’s also a Timings tab which separates the loading phases and gives us the time and explanation of each phase, like the Time To First Byte that we mentioned earlier:
在单项测试中，还有一个Timings选项卡，它分隔了加载阶段，并为我们提供了每个阶段的时间和说明，例如我们前面提到的Time To First Byte：
(This is the ttfb.review of Drupal’s one-second load.)
(这是Drupal的一秒钟负载的ttfb.review。)
The History tab on the single page reports is for the monitored pages, or multiple tests over time, where we can see our progress:
单页报告上的“ 历史记录”选项卡适用于受监控的页面，或者用于一段时间内的多个测试，我们可以在其中查看进度：
For comparisons, we have the Graphs tab:
为了进行比较，我们有“ 图形”选项卡：
There are more settings that can be found in the off-canvas sidebar:
在画布的侧边栏中可以找到更多设置：
By repeating the tests, in the course of writing this article, we saw the load time for the Yii app drop to 1.2 seconds, and Symfony to 1.6 seconds.
通过重复测试，在撰写本文的过程中，我们看到Yii应用程序的加载时间降至1.2秒，而Symfony的加载时间降至1.6秒。
With Symfony, a look at the History tab shows that TTFB remained the same, and the 400 millisecond improvement is most likely due to the difference in loading of static resources:
使用Symfony，在“ 历史记录”选项卡上可以看到TTFB保持不变，并且400毫秒的改进很可能是由于静态资源加载的不同而造成的：
But the next two charts show that there was nothing to claim credit for the speed improvement except the accidentally better network throughput:
但是接下来的两个图表显示，除了意外的更好的网络吞吐量外，没有什么值得称赞的速度改进：
With Yii, the improvement is more radical across all three metrics, TTFB, onload and fully loaded time:
使用Yii，在TTFB，onload和完全加载时间这三个指标上的改进都更加彻底：
Here, the improvements are accidental and due to either the server overload or the network throughput changes, but as we make changes on our website, and improve across these different metrics, we will be able to monitor our progress in the History tab.
在这里，这些改进是偶然的，并且是由于服务器过载或网络吞吐量的变化而引起的，但是当我们在网站上进行更改并在这些不同指标上进行改进时，我们将能够在“ 历史记录”选项卡中监视我们的进度。
GTmetrix has many more options, and it goes beyond the scope of one article. For example, even on the free plan, we can test with mobile or desktop browsers, and we can simulate the speed of the visitor’s network — ADSL, 3G, etc.
GTmetrix还有更多选择，它超出了一篇文章的范围。 例如，即使是免费计划，我们也可以使用移动或桌面浏览器进行测试，并且可以模拟访问者网络(ADSL，3G等)的速度。
We can also test the website from different locations on the globe:
我们还可以从全球不同位置测试该网站：
This can come in handy when we’re expecting visitors from more than one region, or when we’re measuring the impact of implementing a CDN into our stack. Network latency can make a couple of seconds of difference in the load time from one location on the globe to another.
当我们期望来自多个地区的访问者，或者正在评估将CDN实施到堆栈中的影响时，这可能会派上用场。 网络延迟可能会使从地球上一个位置到另一位置的加载时间相差几秒钟。
YSlow, with its ruleset, came from the work of the Yahoo developers Exceptional Performance team. It became a prominent web performance tool primarily as a Firebug add-on, but this has been rendered obsolete with Firefox Quantum.
YSlow及其规则集来自Yahoo开发人员Exceptional Performance团队的工作 。 它主要作为Firebug插件而成为著名的Web性能工具，但是Firefox Quantum使其已过时。
It’s still available as a bookmarklet, a Safari extension, a command-line tool, or as a Chrome app:
它仍然可以作为书签 ， Safari扩展程序 ， 命令行工具或Chrome应用程序使用 ：
We can select a ruleset to apply, set the strictness of the criteria, and then get results under Grade, with grades by items, from A to F, with explanations and links for each item/dimension.
我们可以选择一个要应用的规则集，设置条件的严格性，然后在“ 等级”下获取结果，并按从A到F的项目等级进行评分 ，并提供每个项目/维度的说明和链接。
In the Grade tab, we can filter our results. For example, with our Yii app, filtering the results to just those pertaining to the Server, we see this:
在“ 成绩”选项卡中，我们可以过滤结果。 例如，使用我们的Yii应用程序，将结果过滤到与服务器有关的结果中，我们将看到：
This gives us a quick overview of the things we can improve by adjusting our server settings — gzipping the content, setting the Expires headers, deploying the website on a CDN, etc.
这使我们可以快速了解可以通过调整服务器设置来改进的功能-gzip压缩内容，设置Expires标头，在CDN上部署网站等。
Each of the YSlow recommendations/grades gives us a brief explanation, and a link to read more about the topic.
每个YSlow建议/等级都会给我们简要说明，并提供一个链接以阅读更多有关该主题的内容。
The Components tab gives us an overview of all the resources or URLs loaded during the page load time, including the page itself, JS, CSS, images, their sizes, compressed sizes, cookies, headers sent.
“ 组件”选项卡为我们提供了页面加载期间加载的所有资源或URL的概述，包括页面本身，JS，CSS，图像，其大小，压缩大小，cookie，已发送的标头。
In the case of our Yii demo app, for example, we can see in our Components tab that we aren’t compressing our JS properly (the size is the same as uncompressed), nor setting any Expires headers — which should be done in a production app:
例如，在我们的Yii演示应用程序中，我们可以在“ 组件”标签中看到我们没有正确压缩JS(大小与未压缩的大小相同)，也没有设置任何Expires标头-应该在生产应用：
More about the criteria and rules can be found here.
有关标准和规则的更多信息，请参见此处 。
The Statistics tab has a great overview of all of the elements that make up the page, percentage in the total weight of the page, and overview of the same with a primed browser cache. This is something we can manipulate with the Expires header. GTmetrix has an article about the Expires header. This performance dimension affects repeated visitors — those who, due to our Expires instruction being sent to our visitor’s browser, have the static resources kept in the browser’s cache for repeat visits for a certain, specified amount of time.
“ 统计信息”选项卡很好地概述了构成页面的所有元素，页面总重量的百分比以及带有已填充浏览器缓存的页面的总览。 这是我们可以使用Expires标头处理的东西。 GTmetrix上有一篇有关Expires标头的文章 。 这种性能维度会影响重复访问者-由于将Expires指令发送到访问者的浏览器，这些访问者将静态资源保存在浏览器的缓存中，以便在指定的特定时间内重复访问。
On the YSlow website, there’s a more in-depth guide about each of the 23 criteria it uses for grading the tested websites, with further tips for optimization.
在YSlow网站上，针对其用于对测试网站进行评分的23条标准中的每条标准，都有更深入的指南 ，以及进一步的优化技巧。
Pingdom offers an extensive set of tools, both for DNS health check and for full-page testing.
Pingdom提供了广泛的工具集，可用于DNS运行状况检查和整页测试。
After doing the test and getting a brief overview, as shown above, further down on the report page we have itemized recommendations about improving our load time:
如上所示，在完成测试并获得简要概述之后，在报告页面的下方，我们逐项列出了有关改善加载时间的建议：
We can see here the recommendations regarding the Expires headers that we mentioned above, among other things.
我们可以在这里看到有关上文提到的Expires标头的建议。
Below that, we can inspect our HTTP responses, and whether we have problematic redirections, or invalid responses (in the case that some of the resources didn’t load):
在此之下，我们可以检查我们的HTTP响应，以及是否有问题的重定向或无效的响应(在某些资源未加载的情况下)：
In the case of another production website we had tested — a really resource-heavy website with a lot of static resources — the results looked like this:
对于另一个生产网站，我们已经测试过-一个真正的资源丰富的网站，其中包含大量静态资源-结果看起来像这样：
Back to our test Drupal installation on http://ttfb.review, Pingdom gives us — further down the result page — a breakdown of the content by type, weight and percentage:
回到我们在http://ttfb.review上测试的Drupal安装中，Pingdom为我们提供了-在结果页面的下方-按类型，重量和百分比细分了内容：
In the case of the mentioned resource-heavy website we tested (we didn’t leave the URL visible, because it is a rather bad example of a website, which is running in production), we can see the problematic parts: a massive video, Google maps, a chat widget by an external provider:
对于我们测试过的提到的资源密集型网站(我们没有使URL可见，因为它是正在生产中的网站的相当差的示例)，我们可以看到有问题的部分：大量视频，Google地图，外部提供商的聊天窗口小部件：
Back with our Drupal site, Pingdom allows us to dissect the whole page load, request by request, allowing us to see which requests/responses make up the most of our load time:
回到我们的Drupal网站，Pingdom允许我们按请求剖析整个页面负载，从而使我们能够查看哪些请求/响应构成了我们最多的负载时间：
Then, by colors, we can further break down the phases of every single request/response, and locate the bottlenecks, either by getting rid of the most expensive resources, or gzipping them, minifying the JS and CSS, or deploying them on a CDN.
然后，通过颜色，我们可以进一步摆脱每个请求/响应的阶段，找到瓶颈，方法是摆脱最昂贵的资源，或者压缩它们，缩小JS和CSS，或者将它们部署在CDN上。
We can also combine them where possible to reduce the number of requests, or implement the HTTP/2 protocol, which allows for more asynchronous, non-blocking loading of resources.
我们还可以在可能的情况下组合它们以减少请求的数量，或实现HTTP / 2协议 ，该协议允许更多的异步，非阻塞资源加载。
Bellow this waterfall chart, Pingdom has a color legend, explaining each.
在这张瀑布图的贝娄下面，Pingdom有一个颜色说明，每个说明都有。
In the case of our Drupal website, since we set up the domain DNS settings from scratch, when we started writing this article, we set our domain’s A record TTL — Time To Live, or domain record caching time — to 1 minute, trying to speed up the deployment of our domain. To reduce the ping, the DNS part of the first request, we would increase TTL time once the domain is set up to a maximum. This way, the domain setting would be cached, and there would be no need for thorough domain DNS lookup.
对于我们的Drupal网站，由于我们是从头开始设置域DNS设置的，因此当我们开始撰写本文时，我们将域的A记录TTL ( 生存时间)或域记录缓存时间设置为1分钟，试图加快我们域的部署。 为了减少ping(第一个请求的DNS部分)，一旦将域设置为最大，我们将增加TTL时间。 这样，将缓存域设置，并且不需要彻底的域DNS查找。
Each of these requests has a dropdown button on the right, and clicking it, we get insight into each request’s and response’s headers:
这些请求中的每一个在右侧都有一个下拉按钮，然后单击它，我们可以深入了解每个请求和响应的标题：
Here we can debug whether a request is cached on the server, whether the content is cached, and so on.
在这里，我们可以调试请求是否在服务器上缓存，内容是否在缓存等。
With a website deployed on Cloudflare, for example, we can see from a resource’s headers that cf-cache was HIT — meaning the resource is cached, we can see it is gzipped, the expires headers are set, as well as cache-control headers:
例如，在将一个网站部署在Cloudflare上的情况下，我们可以从资源的标头中看到cf-cache是HIT ，这意味着该资源已被缓存，我们可以看到它被压缩，设置了expires标头以及缓存控制标头。 ：
On a Cloudflare-deployed website, we can see on our Pingdom waterfall chart, downloads of resources are more parallel, asynchronous and non-blocking. This can also be achieved by setting up our server to use the HTTP/2 protocol:
在Cloudflare部署的网站上，我们可以在Pingdom瀑布图上看到，资源的下载更加并行，异步且无阻塞。 这也可以通过将服务器设置为使用HTTP / 2协议来实现：
(There’s no waiting for one request/response cycle to finish for the next one to begin.)
(无需等待一个请求/响应周期完成，即可开始下一个请求/响应周期。)
Some improvement here can be achieved by preloading resources.
通过预加载资源可以在此处实现一些改进。
With Pingdom, like with GTmetrix, we can choose the location from which to test. We tried to test our Yii demo installation, http://yii.ttfb.review, from Sweden (previous GTmetrix tests were done from Vancouver, Canada), and the difference is obvious. Our website now took 445 milliseconds to load:
与Pingdom一样，与GTmetrix一样，我们可以选择进行测试的位置。 我们尝试从瑞典测试我们的Yii演示安装http://yii.ttfb.review(以前的GTmetrix测试是从加拿大温哥华进行的)，两者之间的区别是显而易见的。 我们的网站现在花费445毫秒来加载：
In this case, we also see the DNS latency is taking maybe more than it should. We should reduce the TTL DNS setting, and the blue parts on static resources are the “Connect” phase, so we can assume that HTTP/2 with its keepalive improvements would be able to leverage a single connection to push all of these resources, without the overhead of establishing a new TCP connection for every resource:
在这种情况下，我们还看到DNS延迟所花费的时间可能超过了应有的时间。 我们应该减少TTL DNS设置，并且静态资源上的蓝色部分处于“连接”阶段，因此我们可以假设HTTP / 2及其keepalive改进将能够利用单个连接来推送所有这些资源， 而无需为每个资源建立新的TCP连接的开销 ：
The simplest path here would probably, again, be a CDN.
同样，这里最简单的路径可能是CDN。
The DNS latency is even more visible when we test from California:
当我们从加利福尼亚测试时，DNS延迟更加明显：
We can safely assume that solving the DNS issue and serving static resources more efficiently would slash the load time by one third.
我们可以安全地假设解决DNS问题并更有效地提供静态资源将使加载时间减少三分之一。
Pingdom offers premium monitoring solutions similar to GTmetrix. It can monitor uptime, send alerts, monitor average load times, etc.
Pingdom提供类似于GTmetrix的高级监控解决方案。 它可以监视正常运行时间，发送警报，监视平均加载时间等。
Both GTmetrix and Pingdom give us an option to export HAR files. HAR — or HTTP Archive format files — are JSON-formatted archive files for logging of a web browser’s interaction with a site. We are attaching a HAR file from our GTmetrix test of the WordPress test installation (which has a lot of problems to debug, by the way).
GTmetrix和Pingdom都提供了导出HAR文件的选项。 HAR(或HTTP存档格式文件)是JSON格式的存档文件， 用于记录Web浏览器与网站的交互 。 我们正在从WordPress测试安装的 GTmetrix测试中附加一个HAR文件 (顺便说一下，这有很多问题需要调试)。
This file is a standard format for debugging website responsiveness.
此文件是用于调试网站响应能力的标准格式。
This file can then be imported into Google’s Har Analyzer:
然后可以将该文件导入Google的Har Analyzer ：
This can then be further analyzed, shared, etc.
然后可以进一步分析，共享等。
Other tools that deserve to be mentioned are Page Load Time for Chrome, which works as a neat browser widget with brief loading stats:
其他值得一提的工具是Chrome的Page Load Time ，它可以作为一个简洁的浏览器窗口小部件，具有简短的加载状态：
Then, there’s the Dotcom Tools web speed test:
然后，进行Dotcom Tools网络速度测试 ：
It offers 24 testing locations, and then detailed waterfall charts for each one.
它提供24个测试位置，然后为每个位置提供详细的瀑布图。
There’s also PageSpeedGrader:
还有PageSpeedGrader ：
Google’s PageSpeed Insights is another tool we can use to get insights and recommendations for possible improvements and best practices, both for mobile and desktop visitors:
Google的PageSpeed Insights是我们可以用来获取针对移动和桌面访问者的见解和建议的另一种工具，以提出可能的改进和最佳做法：
In this article, we’ve set up some demo web installations and tried to show how we can debug the various elements that make up the page load time. There are other tools that can discover bottlenecks, that give us insights into the server processes, like New Relic, DataDog, and other server-involved tools like Monit — advanced tools, but a bit more invasive regarding server infrastructure.
在本文中，我们已经设置了一些演示Web安装，并试图说明如何调试组成页面加载时间的各种元素。 还有其他一些工具可以发现瓶颈，使我们可以深入了解服务器进程，例如New Relic ， DataDog以及其他与服务器有关的工具(如Monit) (高级工具)，但是对服务器基础结构的侵入性更大。
翻译自: https://www.sitepoint.com/improving-page-load-performance-pingdom-yslow-gtmetrix/
相关资源：jdk-8u281-windows-x64.exe