本文介绍的 Chrome 开发者工具基于 Chrome 65版本,如果你的 Chrome 开发者工具没有下文提到的那些内容,请检查下 Chrome 的版本
本文是 前端开发必备之Chrome开发者工具(上篇) 的下篇,废话不多说,直接开始介绍。
网络面板记录页面上每个网络操作的相关信息,包括详细的耗时数据、HTTP 请求与响应标头和 Cookie等等。
Network 面板可以在页面加载期间捕捉屏幕截图。此功能称为幻灯片。
点击 摄影机 图标可以启用幻灯片。图标为灰色时,幻灯片处于停用状态 (
)。如果图标为蓝色,则说明已启用 (
)。
重新加载页面可以捕捉屏幕截图。屏幕截图显示在概览上方。
将鼠标悬停在一个屏幕截图上时,Timeline将显示一条黄色竖线,指示帧的捕捉时间。
双击屏幕截图可查看放大版本。在屏幕截图处于放大状态时,使用键盘的向左和向右箭头可以在屏幕截图之间导航。
Network 面板突出显示两种事件:DOMContentLoaded
和 load
。
解析页面的初始标记时会触发 DOMContentLoaded
。 此事件将在 Network 面板上的两个地方显示:
页面完全加载时将触发 load
。此事件显示在三个地方:
默认情况下,每当您重新加载当前页面或者加载不同的页面时,网络活动记录会被丢弃。启用 Preserve log 复选框可以在这些情况下保存网络日志。 新记录将附加到 Requests Table 的底部。
要查看 Network 面板中给定条目完整的耗时信息,您有三种选择。
下面的代码可以在 DevTools 的 Console 中运行。 它将使用 Network Timing API 检索所有资源。 然后,它将通过查找是否存在名称中包含“style.css”的条目对条目进行过滤。 如果找到,将返回相应条目。
performance.getEntriesByType('resource').filter(item => item.name.includes("style.css"))
如果某个请求正在排队,则指示:
请求等待发送所用的时间。 可以是等待 Queueing 中介绍的任何一个原因。 此外,此时间包含代理协商所用的任何时间。
与代理服务器连接协商所用的时间。
执行 DNS 查询所用的时间。 页面上的每一个新域都需要完整的往返才能执行 DNS 查询。
建立连接所用的时间,包括 TCP 握手/重试和协商 SSL 的时间。
完成 SSL 握手所用的时间。
发出网络请求所用的时间。 通常不到一毫秒。
等待初始响应所用的时间,也称为至第一字节的时间。 此时间将捕捉到服务器往返的延迟时间,以及等待服务器传送响应所用的时间。
接收响应数据所用的时间。
通过 Network 面板可以发现大量可能的问题。查找这些问题需要很好地了解客户端与服务器如何通信,以及协议施加的限制。
最常见问题是一系列已被加入队列或已被停止的条目。这表明正在从单个网域检索太多的资源。在 HTTP 1.0/1.1 连接上,Chrome 会将每个主机强制设置为最多六个 TCP 连接。如果您一次请求十二个条目,前六个将开始,而后六个将被加入队列。最初的一半完成后,队列中的第一个条目将开始其请求流程。
要为传统的 HTTP 1 流量解决此问题,您需要实现域分片。也就是在您的应用上设置多个子域,以便提供资源。然后,在子域之间平均分配正在提供的资源。
HTTP 1 连接的修复结果不会应用到 HTTP 2 连接上。事实上,前者的结果会影响后者。 如果您部署了 HTTP 2,请不要对您的资源进行域分片,因为它与 HTTP 2 的操作方式相反。在 HTTP 2 中,到服务器的单个 TCP 连接作为多路复用连接。这消除了 HTTP 1 中的六个连接限制,并且可以通过单个连接同时传输多个资源。
又称:大片绿色
等待时间长表示至第一字节的时间 (TTFB) 漫长。建议将此值控制在 200 毫秒以下。长 TTFB 会揭示两个主要问题之一。
要解决长 TTFB,首先请尽可能缩减网络。理想的情况是将应用托管在本地,然后查看 TTFB 是否仍然很长。如果仍然很长,则需要优化应用的响应速度。可以是优化数据库查询、为特定部分的内容实现缓存,或者修改您的网络服务器配置。很多原因都可能导致后端缓慢。您需要调查您的软件并找出未满足您的性能预算的内容。
如果本地托管后 TTFB 仍然漫长,那么问题出在您的客户端与服务器之间的网络上。很多事情都可以阻止网络遍历。客户端与服务器之间有许多点,每个点都有其自己的连接限制并可能引发问题。测试时间是否缩短的最简单方法是将您的应用置于其他主机上,并查看 TTFB 是否有所改善。
又称:大片蓝色
如果您看到 Content Download 阶段花费了大量时间,则提高服务器响应或串联不会有任何帮助。首要的解决办法是减少发送的字节数。
利用网络调节,您可以在不同的网络连接(包括 Edge、3G,甚至离线)下测试网站。这样可以限制出现最大的下载和上传吞吐量(数据传输速率)。延迟时间操控会强制连接往返时间 (RTT) 出现最小延迟。
可以通过 Network 面板开启网络调节。从下拉菜单中选择要应用网络节流和延迟时间操控的连接。
使用 Chrome DevTools 的 Timeline 面板可以记录和分析您的应用在运行时的所有活动。 这里是开始调查应用中可觉察性能问题的最佳位置。
Timeline 面板包含以下四个窗格:
Overview 窗格包含以下三个图表:
深色部分表示传输时间(下载第一个和最后一个字节之间的时间)。
横杠按照以下方式进行彩色编码:
该面板主要能做:
该面板主要能做:
该面板主要能做:
使用左侧面板可以检查各个安全或非安全源。
点击安全源查看该源的连接和证书详情。
如果您点击非安全源,Security 面板会提供 Network 面板过滤视图的链接。
点击链接可以查看具体是源的哪些请求通过 HTTP 提供。
由于大多数桌面设备都没有 GPS 芯片和加速度计,所以测试它们比较困难。Chrome DevTools 的 Sensors 模拟窗格可以通过模拟常见的移动设备传感器来降低测试的开销。
要访问 Chrome DevTools 传感器控件,请执行以下操作:
注:如果您的应用检测到使用 JavaScript(如 Modernizr)的传感器加载,请确保在启用传感器模拟器之后重新加载页面。
与桌面设备不同,移动设备通常使用 GPS 硬件检测位置。在 Sensors 窗格中,您可以模拟地理定位坐标,以便与 Geolocation API 结合使用。
在模拟抽屉式导航栏的 Sensors 窗格中选中 Emulate geolocation coordinates 复选框,启用地理定位模拟。
您可以使用此模拟器替换 navigator.geolocation 的位置值,并在地理定位数据不可用时模拟用例。
要测试来自 Orientation API 的加速度计数据,请在 Sensors 窗格中选中 Accelerometer 复选框,启用加速度计模拟器。
您可以操作下列方向参数:
您也可以点击模型加速度计并将其拖动到所需方向。
Chrome开发者工具是一个非常强大的工具,灵活使用将让你在前端调试中事半功倍。
这两篇文章只是整理的一些我平时常用的功能,还有很多的功能等着我们去挖掘。
https://developers.google.com/web/tools/chrome-devtools/