记chrome浏览器分析页面加载时间
项目背景：现项目主要是做关于机器人的调度系统，涉及到web端、移动端、小程序及服务端和实体机器人端；
迭代背景：web端设备演示界面优化
记录方向：web端优化
记录时间：20210119
==================================================================
因为项目有一个页面渲染效果不好，花费的时间很长，通过浏览器开发者工具检查了一下请求花费的时间。
在网上找到一篇好文，不容错过，特别是文章中连接的关于浏览器并发请求资源素数是什么这篇文章，指的收藏，虽然我并不做前段开发，只是一枚小测试而已。
对于测试岗位随着自己工作年限的增长，觉得测试岗位需要了解的东西要多要广，不需要多了解的多深，能够知道开发到底在聊些什么，这是我对测试岗位所需知识面的理解以及界定，也是要求
自己在测试岗位中需要时刻汲取新知识，增加知识面；
==============转载自：https://www.cnblogs.com/yangtoude/p/chrome-devtools-network-performance.html-=======
今天趁着下班的时间看了下chrome浏览器的网页加载时间分析工具和相关文档，简单写点儿东西记录一下。
以百度首页加载为例，分析下一张图片1.jgp（就是背景图）的加载时间
看右侧的Timing标签，从下往上看各个阶段：
最下面一行，Explanation是一个链接，它链接到了chrome对Timing解释的文档(从这里可以看出chrome对开发人员真的很友好)，这张图片加载总共花费的时间为：36.32ms。
Content Download，浏览器下载响应文件所花费的时间26.84ms，与本地网络有关系。
Waiting(TTFB)，从发起请求到接收到服务器响应的首个字节所花费的时间，它的主要组成部分：服务器响应和网络传输（往返）。
Request sent. The request is being sent. 表示请求正在发出，这个是不占用时间的。
Stalled。The request could be stalled for any of the reasons described in Queueing. 请求会因为各种原因的排队被拖延，与请求队列有关系。这张图片的请求被拖延了1.48ms。
Queueing(排队). The browser queues requests when: 浏览器会在以下情况下将某个请求排队：
- There are higher priority requests. 有更高优先级的请求
- There are already six TCP connections open for this origin, which is the limit. Applies to HTTP/1.0 and HTTP/1.1 only. 在http1.0/1.1协议下，chrome对于同一域名下的并发请求数（连接数）限制为6个。这么做的原因：（1）是基于端口数量和线程切换开销的考虑，浏览器不可能无限量的并发请求：由于 TCP 协议的限制，PC 端只有65536个端口可用以向外部发出连接，而操作系统对半开连接数也有限制以保护操作系统的 TCP\IP 协议栈资源不被迅速耗尽，因此浏览器不好发出太多的 TCP 连接，而是采取用完了之后再重复利用 TCP 连接或者干脆重新建立 TCP 连接的方法。如果采用阻塞的套接字模型来建立连接，同时发出多个连接会导致浏览器不得不多开几个线程，而线程有时候算不得是轻量级资源，毕竟做一次上下文切换开销不小。（2）为了防止过多的并发导致服务器崩溃，这是“有良知的tcp客户端”对于服务器的一种默契。详见：浏览器允许的并发请求资源数是什么意思？
- The browser is briefly allocating space in the disk cache 浏览器正在硬盘的缓存上分配空间。
对于某个请求我们能够优化的主要是TTFB，即，从发起请求到收到服务器响应的时间间隔。从图中也可以看出，它耗费的时间所占的比例也比较大。那么也就主要从服务器响应和网络传输这两方面来下手。如果只考虑网络传输这个因素，那么压缩传输数据，毕竟网络速度有限，减少传送的数据字节数可以加快传输速度。
=====================这是并发请求资源数是什么意思的原文==========================
浏览器允许的并发请求资源数是什么意思？
和
的答案分别从前后端答复了。我再补充和整理一下吧。
这个问题实际上涉及非常多的考虑和因此而发生的优化技术：
首先，是基于端口数量和线程切换开销的考虑，浏览器不可能无限量的并发请求，因此衍生出来了并发限制和HTTP/1.1的Keep alive。 所以，IE6/7在HTTP/1.1下的并发才2，但HTTP/1.0却是4。 而随着技术的发展，负载均衡和各类NoSQL的大量应用，基本已经足以应对C10K的问题。 但却并不是每个网站都懂得利用domain hash也就是多域名来加速访问。因此，新的浏览器加大了并发数的限制，但却仍控制在8以内。
后端的保护
已经说得很全面了，补充一小点就是浏览器即使放弃保护自己，将所有请求一起发给服务器，也很可能会引发服务器的并发阈值控制而被BAN，而另外一个控制在8以内的原因也是keep alive技术的存在使得浏览器复用现有连接和服务器通信比创建新连接的性能要更好一些。
所以，浏览器的并发数其实并不仅仅只是良知的要求，而是双方都需要保护自己的默契，并在可靠的情况下提供更好的性能。
稍微跑跑题据说有益身心健康。
=================== 我是健康的分割线 ========================
前端技术的逐渐成熟，还衍生了domain hash, cookie free, css sprites, js/css combine, max expires time, loading images on demand等等技术。这些技术的出现和大量使用都和并发资源数有关。
- 按照普通设计，当网站cookie信息有1 KB、网站首页共150个资源时，用户在请求过程中需要发送150 KB的cookie信息，在512 Kbps的常见上行带宽下，需要长达3秒左右才能全部发送完毕。 尽管这个过程可以和页面下载不同资源的时间并发，但毕竟对速度造成了影响。 而且这些信息在js/css/images/flash等静态资源上，几乎是没有任何必要的。 解决方案是启用和主站不同的域名来放置静态资源，也就是cookie free。
- 将css放置在页面最上方应该是很自然的习惯，但第一个css内引入的图片下载是有可能堵塞后续的其他js的下载的。而在目前普遍过百的整页请求数的前提下，浏览器提供的仅仅数个并发，对于进行了良好优化甚至是前面有CDN的系统而言，是极大的性能瓶颈。 这也就衍生了domain hash技术来使用多个域名加大并发量（因为浏览器是基于domain的并发控制，而不是page），不过过多的散布会导致DNS解析上付出额外的代价，所以一般也是控制在2-4之间。 这里常见的一个性能小坑是没有机制去确保URL的哈希一致性（即同一个静态资源应该被哈希到同一个域名下），而导致资源被多次下载。
- 再怎么提速，页面上过百的总资源数也仍然是很可观的，如果能将其中一些很多页面都用到的元素如常用元素如按钮、导航、Tab等的背景图，指示图标等等合并为一张大图，并利用css background的定位来使多个样式引用同一张图片，那也就可以大大的减少总请求数了，这就是css sprites的由来。
- 全站的js/css原本并不多，其合并技术的产生却是有着和图片不同的考虑。 由于cs/js通常可能对dom布局甚至是内容造成影响，在浏览器解析上，不连贯的载入是会造成多次重新渲染的。因此，在网站变大需要保持模块化来提高可维护性的前提下，js/css combine也就自然衍生了，同时也是minify、compress等对内容进行多余空格、空行、注释的整理和压缩的技术出现的原因。
- 随着cookie free和domain hash的引入，网站整体的打开速度将会大大的上一个台阶。 这时我们通常看到的问题是大量的请求由于全站公有header/footer/nav等关系，其对应文件早已在本地缓存里存在了，但为了确保这个内容没有发生修改，浏览器还是需要请求一次服务器，拿到一个304 Not Modified才能放心。 一些比较大型的网站在建立了比较规范的发布制度后，会将大部分静态资源的有效期设置为最长，也就是Cache-Control max-age为10年。 这样设置后，浏览器就再也不会在有缓存的前提下去确认文件是否有修改了。 超长的有效期可以让用户在访问曾访问过的网站或网页时，获得最佳的体验。 带来的复杂性则体现在每次对静态资源进行更新时，必须发布为不同的URL来确保用户重新加载变动的资源。
- 即使是这样做完，仍然还存在着一个很大的优化空间，那就是很多页面浏览量很大，但其实用户直接很大比例直接就跳走了，第一屏以下的内容用户根本就不感兴趣。 对于超大流量的网站如淘宝、新浪等，这个问题尤其重要。 这个时候一般是通过将图片的src标签设置为一个loading或空白的样式，在用户翻页将图片放入可见区或即将放入可见区时再去载入。 不过这个优化其实和并发资源数的关系就比较小了，只是对一些散布不合理，或第一页底部的资源会有一定的帮助。 主要意图还是降低带宽费用。
总的来说，各类技术都是为了能让用户更快的看到页面进行下一步操作，但却不必将宝贵的资源浪费在没有必要的重复请求、不看的内容上。
==============浏览器渲染的过程 转载自：https://blog.csdn.net/iamlujingtao/article/details/101295778=====================
前言
前端人员可能不太了解浏览器渲染Html的过程，或者了解相关知识，但是不能通过具体的方式来更深入认识。
本文通过Chrome的开发者工具来直观了解浏览器渲染html的过程，能对于页面性能优化有更好的帮助。
浏览器渲染过程
我们先看一张图解：
我们看到Html和Css先是分开解析，然后合在一起生成RenderTree，最后绘制，显示。
浏览器渲染步骤
浏览器渲染步骤大体可分为4步：
-
1、HTML被HTML解析器解析成DOM Tree, css则被css解析器解析成CSSOM Tree。
-
2、DOM Tree和CSSOM Tree解析完成后，被附加到一起，形成渲染树（Render Tree）。
-
3、节点信息计算(重排)，这个过程被叫做Layout(Webkit)或者Reflow(Mozilla)。即根据渲染树计算每个节点的几何信息。
-
4、渲染绘制(重绘)，这个过程被叫做(Painting 或者 Repaint)。即根据计算好的信息绘制整个页面。
以上4步简述浏览器的一次渲染过程，理论上，每一次的dom更改或者css几何属性更改，都会引起一次浏览器的重排/重绘过程，而如果是css的非几何属性更改，则只会引起重绘过程。所以说重排一定会引起重绘，而重绘不一定会引起重排。
重排重绘解析
简单来说：
-
重排（Layout）就是页面元素发生几何变更（例如位置变更），牵连其它元素发生几何变化，导致页面所有元素执行一次重新排版。
-
重绘（Paint）就是页面元素发生样色变更（例如颜色变更），但不影响其它元素发生几何变化，使页面执行一次重新绘图。
其中，重排会消耗更多性能，重绘则消耗小部分性能，所以我们优化页面，要尽量减少重排！
实例演示
现在我们做一个Demo，然后通过Chrome的Performance工具来直观了解浏览器渲染Html的过程：
页面有一个盒子和2个按钮，现在我们点击录制，然后刷新页面，看看过程是怎样的
只修改背景色
点击“改变背景色”看看过程是怎样的：
可以看到如果只是改变背景色，并没有触发重排（Layout），只触发了重绘（Paint）。
只修改宽度
点击“改变宽度”看看过程是怎样的：
可以看到如果只是改变宽度，则既触发重排（Layout）又触发重绘（Paint）
当然还有其它例如其它过程，例如合成图层（Composite Layers）,这又是一大学问，日后再探讨。
总结
我们通过上面简单的demo了解到浏览器渲染Html的过程，也了解到重排和重绘的知识，所以我们优化页面性能，要尽量减少重排（减少dom操作、减少几何属性操作）。
浙公网安备 33010602011771号