chrome开发者工具_如何使用Chrome开发者工具查找性能瓶颈

chrome开发者工具

介绍 (Introduction)

As one advances through a software development career, concerns beyond writing code that works may arise. In the world of web development, it becomes pertinent to not only build functional software, but to also make it highly performant so that it can seamlessly deliver the desired experience while also using minimal resources.

随着软件开发事业的发展，可能会出现超出编写有效代码的担忧。 在Web开发的世界中，不仅要构建功能软件，还要使其具有高性能，以便它可以无缝地提供所需的体验，同时又使用最少的资源，这才是有意义的。

Ordinarily, this would be quite a large task as one can’t make projections about the resource consumption properties of an application without tools to simulate and measure various parameters.

通常，这将是一项巨大的任务，因为如果没有用于模拟和测量各种参数的工具，就无法对应用程序的资源消耗属性进行预测。

In this article, you will explore one of these tools: The Chrome Developer Tools. Specifically, you will examine the handiness of the Audits and Performance tab in evaluating web applications and discovering performance problems.

在本文中，您将探索以下工具之一：Chrome开发者工具。 具体来说，您将在评估Web应用程序和发现性能问题时检查“ 审核和性能”选项卡的便利性。

In order to make this a practical examination, you will be testing various techniques to seek out performance issues on a website and resolve them. This tutorial explores the Scotch.io website, but these steps can be applied to any website.

为了使这成为一个实际的检查，您将测试各种技术以找出网站上的性能问题并解决它们。 本教程探讨了Scotch.io网站，但是这些步骤可以应用于任何网站。

先决条件 (Prerequisites)

To follow along with this tutorial, the Google Chrome browser installed on your computer.

要继续本教程，请在您的计算机上安装Google Chrome浏览器 。

第1步-准备浏览器 (Step 1 — Preparing the Browser)

When improving the performance of a website or web application, there are two main aspects to consider:

在提高网站或Web应用程序的性能时，需要考虑两个主要方面：

• Load Performance
  负载表现
• Run-time Performance
  运行时性能

This tutorial will focus more on Load Performance. Load Performance refers to the performance of the page when it is loading. The major objective is to identify performance issues that affect application speed and the overall user experience.

本教程将重点关注负载性能。 加载性能是指页面加载时的性能。 主要目的是确定影响应用程序速度和整体用户体验的性能问题。

To begin testing Load Performance, you will start by setting up the audit.

要开始测试负载性能，您将从设置审核开始。

Launch your Chrome browser and open a tab in Incognito mode by pressing COMMAND + SHIFT + N on macOS or CTRL + SHIFT + N on Windows or Linux. Once the Incognito browser is open, navigate to a website that you’d like to test.

启动Chrome浏览器并在隐身模式下通过在MacOS上按COMMAND + SHIFT + N或在Windows或Linux上按CTRL + SHIFT + N来打开选项卡。 打开隐身浏览器后，导航至您要测试的网站。

Next, open the DevTools by pressing COMMAND + OPTION + I on macOS, or CTRL + SHIFT + I on Windows or Linux. If you’d like to change the location of the DevTools console, click on the three vertical dots on the tool bar and make a selection from the Dock Side option.

接下来，在macOS上按COMMAND + OPTION + I ，或者在Windows或Linux上按CTRL + SHIFT + I ，打开DevTools。 如果要更改DevTools控制台的位置，请单击工具栏上的三个垂直点，然后从Dock Side选项中进行选择。

Once you’re happy with the console placement, switch over to the Audits tab. With the help of this tool, you will create a baseline to measure subsequent application changes, as well as receive insights on what changes will improve the application.

对控制台放置感到满意后，请切换到“ 审核”选项卡。 在此工具的帮助下，您将创建一个基线来衡量后续的应用程序更改，并获得有关哪些更改将改善应用程序的见解。

Note: The Audits tab may be hidden behind the More Panels arrow button.

注意： “审核”选项卡可能隐藏在“ 更多面板”箭头按钮后面。

Your primary objective here is to identify performance bottlenecks on Scotch and optimize for better performance. A bottleneck, in software engineering, describes a situation where the capacity of an application is limited by a single component.

您的主要目标是确定Scotch上的性能瓶颈 ，并进行优化以获得更好的性能。 软件工程中的瓶颈描述了一个应用程序的容量受单个组件限制的情况。

In the next step, you will perform an audit to look for performance bottlenecks.

在下一步中，您将执行审核以查找性能瓶颈。

第2步-执行审核 (Step 2 — Performing the Audit)

When performing the audit, you will use a tool called Lighthouse. Lighthouse is an open-source automated tool for improving the quality of any web page in the areas of performance, accessibility, progressive web features, and more.

执行审核时，将使用名为Lighthouse的工具。 Lighthouse是一个开放源代码的自动化工具，用于在性能，可访问性，渐进式Web功能等方面提高任何网页的质量。

In the Audits tab of the Chrome DevTools, let’s configure the auditing tool. We have the following settings presented before us:

在Chrome DevTools的“ 审核”标签中，让我们配置审核工具。 我们面前有以下设置：

设备 (Device)

This gives us the option of toggling the user agent between Mobile and Desktop options. More than half of web traffic as of the third quarter of 2018 is generated by Mobile devices, so we will be auditing Scotch.io on Mobile.

这使我们可以在移动和桌面选项之间切换用户代理。 截至2018年第三季度， 超过一半的网络流量是由移动设备产生的，因此我们将在Mobile上审核Scotch.io。

审核 (Audits)

This setting allows us to select what quality of the application we are interested in evaluating and improving. In this case, performance is the main concern, so you can uncheck every other option.

此设置使我们可以选择对评估和改进感兴趣的应用程序质量。 在这种情况下，性能是主要考虑因素，因此您可以取消选中所有其他选项。

节流 (Throttling)

This option enables you to simulate the conditions of browsing on a mobile device. You will use the Simulated Fast 3G, 4x CPU Slowdown option. This will actually not throttle during the audit, but it will help calculate how long the page will take to load under mobile conditions.

此选项使您可以模拟在移动设备上浏览的条件。 您将使用Simulated Fast 3G，4x CPU Slowdown选项。 这实际上不会在审核过程中节流，但有助于计算在移动条件下加载页面所需的时间。

清除存储 (Clear Storage)

This enables you to clear all cached data and resources for the tested page in order to audit how first-time visitors experience the site, so check this option if it isn’t already checked.

这使您可以清除测试页面的所有缓存数据和资源，以审核首次访问者如何体验该网站，因此如果尚未选中此选项，请选中此选项。

After configuring the audit as specified above, click on Generate report and wait while it prepares a detailed report of the site’s performance.

在按上述指定配置审核后，单击“ 生成报告”，然后等待它准备有关站点性能的详细报告。

步骤3 —分析审核报告 (Step 3 — Analyzing the Audit Report)

On completion of the audit, the report should look like this:

审核完成后，报告应如下所示：

The number in a circle at the top right indicates the overall performance score of the site on a scale of 1–100. We currently have a 55, which indicates that there is a chance for improvement along with the suggestions provided to increase the score and performance. Let’s break the report into sections and analyze them individually.

右上角的圆圈中的数字表示该站点的整体绩效得分，范围为1-100。 目前，我们有55分 ，这表示有改进的机会，并提供了提高分数和提高表现的建议。 让我们将报告分为几个部分，并分别进行分析。

In the Metrics section, you will find quantitative insight into various aspects of the site’s performance:

在“ 指标”部分，您将发现有关网站性能各个方面的定量见解：

Directly below the Metrics section is a group of screenshots that show the various UI states of the page from the point of the initial query until when it loads completely:

“ 指标”部分的正下方是一组屏幕快照，显示了从初始查询到完全加载时页面的各种UI状态：

The Diagnostics section gives you additional performance information usually indicating the factors that determine a web page’s load time:

“ 诊断”部分为您提供了其他性能信息，这些信息通常指示确定网页加载时间的因素：

Finally, the Passed audits section highlights the performance checks that were passed by the web page:

最后，“ 通过的审核”部分突出显示了网页通过的性能检查：

Now that you’ve analyzed the audit, you know what issues may need to be addressed.

现在，您已经分析了审计，您知道可能需要解决哪些问题了。

第4步-解决“指标”部分中的问题 (Step 4 — Addressing Issues in the Metrics Section)

In this example, five performance issues were highlighted. In this step we will explore possible fixes:

在此示例中，突出显示了五个性能问题。 在这一步中，我们将探讨可能的修复：

第一有意义的油漆 (First Meaningful Paint)

The First Meaningful Paint tells you when the primary content of the page becomes visually available. According to the audit, it takes about 3.4 seconds before you see the main content. This can be confirmed by clicking on the View Trace button. This will take you to the Performance tab where you can go through the various UI states during the load period to confirm what happens at each specific time.

当页面的主要内容在视觉上可用时， First Meanfulful Paint会告诉您。 根据审核，大约需要3.4秒才能看到主要内容。 可以通过单击“ 查看跟踪”按钮来确认。 这将带您进入“ 性能”选项卡，您可以在该选项卡中查看加载期间的各种UI状态，以确认在每个特定时间发生的情况。

Notice that it is at this time that the page content becomes visible.

请注意，此时页面内容才可见。

In order to improve this, we must optimize the critical rendering path of the page/overall application. This means that we prioritize the display of content as desired by the user in order to create a better experience and improve performance. This can be done by reducing the number of critical resources, the critical path length, and the number of critical bytes.

为了改善这一点，我们必须优化页面/整体应用程序的关键渲染路径。 这意味着我们会根据用户的需求优先显示内容，以创造更好的体验并提高性能。 这可以通过减少关键资源的数量，关键路径长度和关键字节的数量来完成。

速度指数 (Speed Index)

The Speed Index shows how quickly page content is visibly populated. This takes about 7.2 seconds as shown on the performance tab:

速度索引显示页面内容的可见填充速度。 如“效果”标签上所示，这大约需要7.2秒 ：

One way to fix this, like in the previously examined metric, is to optimize the critical rendering path. A second way is to optimize content efficiency. This involves manually getting rid of unnecessary downloads, optimizing transfer encoding through compression, and caching whenever possible to prevent re-downloads of unchanging resources.

解决此问题的一种方法(如先前检查的指标一样)是优化关键渲染路径。 第二种方法是优化内容效率。 这涉及手动消除不必要的下载，通过压缩优化传输编码以及在可能的情况下进行缓存以防止重新下载不变的资源。

第一个CPU空闲 (First CPU Idle)

Also known as First Interactive, the First CPU Idle tells you when the page becomes minimally interactive (the CPU is idle enough to handle user input, like clicks, swipe, and so on). From the audit, this takes approximately 6.5 seconds. It is always a win to reduce this value to the minimum:

第一个CPU空闲状态也称为First Interactive ，它告诉您页面的交互程度最低(CPU空闲到足以处理用户输入(例如单击，滑动等))。 从审核开始，这大约需要6.5秒 。 将此值减小到最小总是一个胜利：

To solve this, you need to take the same steps as with the Speed Index.

要解决此问题，您需要采取与Speed Index相同的步骤。

互动时间 (Time to Interactive)

Time to Interactive shows the time it takes for the page to become fully interactive. The audit in this example reveals 6.9 seconds for this metric. Interactivity in this context describes the point where:

互动时间显示页面完全互动所需的时间。 此示例中的审核显示该指标的时间为6.9秒 。 在这种情况下，交互性描述了以下几点：

• The page has displayed useful content.
  该页面显示了有用的内容。
• Event handlers are registered for most visible elements on the page.
  在页面上为大多数可见元素注册了事件处理程序。
• The page responds to user interactions within 50 milliseconds.
  该页面在50毫秒内响应用户交互。

To fix this, you need to defer or remove unnecessary JavaScript work that occurs during page load. This can typically be achieved by sending only the code that a user needs through code splitting and lazy loading, compression, minification, and by removing unused code and caching. You can learn more about optimizing the code here.

要解决此问题，您需要推迟或删除页面加载期间发生的不必要JavaScript工作。 通常可以通过以下方式实现此目的：通过代码拆分和延迟加载，压缩，压缩以及删除未使用的代码和缓存，仅发送用户所需的代码。 您可以在此处了解有关优化代码的更多信息。

估计输入延迟 (Estimated Input Latency)

Estimated Input Latency describes the responsiveness of an application to user input. The audit records approximately 170 milliseconds on this metric. Applications generally have 100 milliseconds to respond to a user input, however, the target for Lighthouse is 50 milliseconds. The reason for this disparity is that Lighthouse uses a proxy metric, which is the availability of the main thread to evaluate this metric rather than measuring it directly.

估计的输入延迟描述了应用程序对用户输入的响应。 审核记录此度量标准大约170毫秒 。 应用程序通常需要100毫秒来响应用户输入，但是Lighthouse的目标是50毫秒。 造成这种差异的原因是Lighthouse使用了代理指标 ，该指标是主线程评估该指标(而不是直接测量)的可用性。

Once it takes longer than the specified time, the app may be perceived as laggy. You can learn more about estimated input latency here.

一旦花费的时间超过指定的时间，则该应用可能会被认为是落后的。 您可以在此处了解有关估计输入延迟的更多信息。

In order to improve this metric, you could use service workers to perform some computations, thus freeing up the main thread. Another helpful measure is to refactor CSS selectors to ensure they perform fewer calculations.

为了改善该指标，您可以使用服务工作者来执行一些计算，从而释放主线程。 另一个有用的措施是重构CSS选择器，以确保它们执行较少的计算。

步骤5 –在“商机”部分中解决问题 (Step 5 — Addressing Issues in the Opportunities Section)

The Opportunities section lists out optimizations that can improve the performance:

商机部分列出了可以提高性能的优化：

Usually, when web pages load, they connect to other origins in order to receive or send data. To improve performance as in this case, it is best to inform the browser to establish a connection to such origins earlier on in the rendering process, thus cutting down on the amount of time spent waiting to resolve DNS lookups, redirects, and several trips back and forth until the client receives a response.

通常，在加载网页时，它们会连接到其他来源以接收或发送数据。 在这种情况下，为了提高性能，最好在渲染过程中尽早通知浏览器建立与此类源的连接，从而减少等待解析DNS查找，重定向和回程所花费的时间。直到客户收到答复为止。

To fix this, you can inform the browser of your intentions to use such resources by adding a rel attribute to link tags as shown below:

要解决此问题，您可以通过将rel属性添加到链接标签来通知浏览器您打算使用这些资源，如下所示：

<link rel="preconnect" href="https://scotchresources.com">

On secure connections, this could still take some time, so it must be used within 10 seconds or else the browser will automatically close the connection and all the early connection work goes to waste.

在安全连接上，这可能仍需要花费一些时间，因此必须在10秒内使用它，否则浏览器将自动关闭连接，并且所有早期的连接工作都将浪费掉。

结论 (Conclusion)

We have now successfully received a performance report on Scotch.io using the Audit tool, as well as examined prospective solutions to the identified bottlenecks.

现在，我们已经使用审核工具在Scotch.io上成功收到了一份性能报告，并检查了已发现瓶颈的预期解决方案。

Load is not a single moment in time — it is an experience that no one metric can fully capture. There are multiple moments during the load experience that can affect whether a user perceives it as “fast” or “slow.”

负载不是时间紧迫的时刻，而是一种度量标准无法完全捕获的经验。 负载体验中有很多时刻会影响用户将其感知为“快速”还是“缓慢”。

Performance is like a long train, with multiple separate coaches yet similar and united in purpose. In testing, one must pay attention to the little wins that cumulatively increase application speed and result in a better experience for the end user.

表现就像是一列漫长的火车，有多个独立的教练却又相似且目的一致。 在测试中，必须注意一点点收获，这些收获会逐渐提高应用程序速度并为最终用户带来更好的体验。

For even further reading, the Web Fundamentals section of the Google Developers site is a great resource.

为了进一步阅读， Google Developers网站的Web基础知识部分是一个不错的资源。

翻译自: https://www.digitalocean.com/community/tutorials/how-to-use-chrome-dev-tools-to-find-performance-bottlenecks

chrome开发者工具