使用chrome开发者工具中的network面板测量网站网络性能

前面的话

　　Chrome 开发者工具是一套内置于Google Chrome中的Web开发和调试工具，可用来对网站进行迭代、调试和分析。使用 Network 面板测量网站网络性能。本文将详细介绍chrome开发者工具中网络面板network的使用

 

概述

【打开方式】

　　打开方式有如下三种

　　一、在Chrome菜单中选择 更多工具 > 开发者工具

　　二、在页面元素上右键点击，选择 “检查”

　　三、使用 快捷键 Ctrl+Shift+I (Windows) 或 Cmd+Opt+I (Mac)

 【做用】

　　Network 面板记录页面上每一个网络操做的相关信息，包括详细的耗时数据、HTTP 请求与响应标头和 Cookie，等等

　　它有以下做用

　　一、使用 Network 面板记录和分析网络活动

　　二、总体或单独查看资源的加载信息

　　三、过滤和排序资源的显示方式

　　四、保存、复制和清除网络记录

　　五、根据需求自定义 Network 面板

【组成】

　　Network 面板由五个窗格组成：

　　一、Controls。使用这些选项能够控制 Network 面板的外观和功能

　　二、Filters。 使用这些选项能够控制在 Requests Table 中显示哪些资源。提示：按住 Cmd (Mac) 或 Ctrl(Windows/Linux) 并点击过滤器能够同时选择多个过滤器

　　三、Overview。 此图表显示了资源检索时间的时间线。若是看到多条竖线堆叠在一块儿，则说明这些资源被同时检索

　　四、Requests Table。 此表格列出了检索的每个资源。 默认状况下，此表格按时间顺序排序，最先的资源在顶部。点击资源的名称能够显示更多信息。 提示：右键点击 Timeline 之外的任何一个表格标题能够添加或移除信息列

　　五、Summary。 此窗格列出了请求总数、传输的数据量和加载时间

　　默认状况下，Requests Table 会显示如下列。能够在表头栏上点击右键来添加和移除列

Name。资源的名称。 Status。HTTP 状态代码。 Type。已请求资源的 MIME 类型。 Initiator。发起请求的对象或进程。值为如下选项之一： Parser。Chrome 的 HTML 解析器发起请求。 Redirect。HTTP 重定向发起请求。 Script。脚本发起请求。 Other。某些其余进程或操做发起请求，例如用户经过连接或者在地址栏中输入网址导航到页面。 Size。响应标头（一般为数百字节）加响应正文（由服务器提供）的组合大小。 Time。从请求开始至在响应中接收到最终字节的总持续时间。 Timeline。Timeline 列能够显示全部网络请求的可视瀑布。 点击此列的标题能够显示一个包含更多排序字段的菜单。

【记录】

　　在 Network 面板打开时，DevTools 在默认状况下会记录全部网络活动。 要记录活动，只需在面板打开时从新加载页面，或者等待当前加载页面上的网络活动

　　能够经过 record 按钮指示 DevTools 是否记录。 显示红色代表 DevTools 正在记录。 显示灰色 代表 DevTools 未在记录。 点击此按钮能够开始或中止记录，也能够按键盘快捷键 Cmd/Ctrl+e

【幻灯片】

　　Network 面板能够在页面加载期间捕捉屏幕截图。此功能称为幻灯片。点击摄影机图标能够启用幻灯片。图标为灰色时，幻灯片处于停用状态。若是图标为蓝色，则说明已启用。从新加载页面能够捕捉屏幕截图。屏幕截图显示在概览上方

　　将鼠标悬停在一个屏幕截图上时，Timeline 将显示一条黄色竖线，指示帧的捕捉时间

　　双击屏幕截图可查看放大版本。在屏幕截图处于放大状态时，使用键盘的向左和向右箭头能够在屏幕截图之间导航

 

事件

　　Network 面板突出显示两种事件：DOMContentLoaded 和 load。 解析页面的初始标记时会触发 DOMContentLoaded。 此事件将在 Network 面板上的两个地方显示：

　　一、Overview 窗格中的蓝色竖线表示事件；

　　二、在 Summary 窗格中，能够看到事件的确切时间

　　页面彻底加载时将触发 load。此事件显示在三个地方：

　　一、Overview 窗格中的红色竖线表示事件

　　二、Requests Table 中的红色竖线也表示事件

　　三、在 Summary 窗格中，能够看到事件的确切时间

 

详细信息

　　点击资源名称（位于 Requests Table 的 Name 列下）能够查看与该资源有关的更多信息

　　可用标签会因所选择资源类型的不一样而不一样，但下面四个标签最多见：

Headers。与资源关联的 HTTP 标头。 Preview。JSON、图像和文本资源的预览。 Response。HTTP 响应数据（若是存在）。 Timing。资源请求生命周期的精细分解。

【网络耗时】

　　点击 Timing 标签能够查看单个资源请求生命周期的精细分解。

　　生命周期按照如下类别显示花费的时间：

Queuing Stalled 若是适用：DNS lookup、initial connection、SSL handshake Request sent Waiting (TTFB) Content Download

　　将鼠标悬停到 Timeline 图表内的资源上时，您也能够看到相同的信息

【查看HTTP标头】

　　点击 Headers 能够显示该资源的标头。

　　Headers 标签能够显示资源的请求网址、HTTP 方法以及响应状态代码。 此外，该标签还会列出 HTTP 响应和请求标头、它们的值以及任何查询字符串参数

　　点击每一部分旁边的 view source 或 view parsed 连接，您可以以源格式或者解析格式查看响应标头、请求标头或者查询字符串参数

【预览资源】

　　点击 Preview 标签能够查看该资源的预览。Preview 标签可能显示一些有用的信息，也可能不显示，具体取决于所选择资源的类型

【查看 HTTP 响应内容】

　　点击 Response 标签能够查看资源未格式化的 HTTP 响应内容。 Preview 标签可能包含一些有用的信息，也可能不包含，具体取决于所选择资源的类型

 

生命周期

　　全部网络请求都被视为资源。经过网络对它们进行检索时，资源具备不一样生命周期，以 Resource Timing 表示。Resource Timing API 提供了与接收各个资源的时间有关的大量详细信息。请求生命周期的主要阶段包括：

一、重定向 　　当即开始 startTime。 　　若是正在发生重定向，redirectStart 也会开始。 　　若是重定向在本阶段末发生，将采集 redirectEnd。 二、应用缓存 　　若是是应用缓存在实现请求，将采集 fetchStart 时间。 三、DNS 　　domainLookupStart 时间在 DNS 请求开始时采集。 　　domainLookupEnd 时间在 DNS 请求结束时采集。 四、TCP 　　connectStart 在初始链接到服务器时采集。 　　若是正在使用 TLS 或 SSL，secureConnectionStart 将在握手（确保链接安全）开始时开始。 　　connectEnd 将在到服务器的链接完成时采集。 五、请求 　　requestStart 会在对某个资源的请求被发送到服务器后当即采集。 六、响应 　　responseStart 是服务器初始响应请求的时间。 　　responseEnd 是请求结束而且数据完成检索的时间。

　　Network 面板中有给定条目完整的耗时信息

【queueing】

　　若是某个请求正在排队，则指示：

　　一、请求已被渲染引擎推迟，由于该请求的优先级被视为低于关键资源（例如脚本/样式）的优先级。 图像常常发生这种状况

　　二、请求已被暂停，以等待将要释放的不可用 TCP 套接字

　　三、请求已被暂停，由于在 HTTP 1 上，浏览器仅容许每一个源拥有六个 TCP 链接

　　四、生成磁盘缓存条目所用的时间（一般很是迅速）

【stalled】

　　请求等待发送所用的时间。 能够是等待 Queueing 中介绍的任何一个缘由。 此外，此时间包含代理协商所用的任什么时候间

【proxy negotiaion】

　　与代理服务器链接协商所用的时间

【DNS lookup】

　　执行 DNS 查询所用的时间。 页面上的每个新域都须要完整的往返才能执行 DNS 查询

【Initial Connection】

　　创建链接所用的时间，包括 TCP 握手/重试和协商 SSL 的时间

【SSL】

　　完成 SSL 握手所用的时间

【Request sent】

　　发出网络请求所用的时间。 一般不到一毫秒

【TTFB】

　　等待初始响应所用的时间，也称为至第一字节的时间。 此时间将捕捉到服务器往返的延迟时间，以及等待服务器传送响应所用的时间

【content Download】

　　接收响应数据所用的时间

 

诊断问题

【queueing时间过长】

　　最多见问题是一系列已被加入队列或已被中止的条目。这代表正在从单个网域检索太多的资源。在 HTTP 1.0/1.1 链接上，Chrome 会将每一个主机强制设置为最多六个 TCP 链接。若是一次请求十二个条目，前六个将开始，然后六个将被加入队列。最初的一半完成后，队列中的第一个条目将开始其请求流程

　　要为传统的 HTTP 1 流量解决此问题，须要实现域分片。也就是在应用上设置多个子域，以便提供资源。而后，在子域之间平均分配正在提供的资源

　　HTTP 1 链接的修复结果不会应用到 HTTP 2 链接上。事实上，前者的结果会影响后者。 若是部署了 HTTP 2，不要对资源进行域分片，由于它与 HTTP 2 的操做方式相反。在 HTTP 2 中，到服务器的单个 TCP 链接做为多路复用链接。这消除了 HTTP 1 中的六个链接限制，而且能够经过单个链接同时传输多个资源

【TTFB时间过长】

　　等待时间长表示至第一字节的时间 (TTFB) 漫长。建议将此值控制在 200 毫秒如下

　　主要有如下两个缘由

　　一、客户端与服务器之间的网络条件较差

　　二、服务器应用的响应慢

【content Download时间过长】

　　若是Content Download 阶段花费了大量时间，则提升服务器响应或串联不会有任何帮助。首要的解决办法是减小发送的字节数