江苏网站开发,网站开发毕业设计收获与体会,遵义网络公司,php值班系统 wordpress一、RAIL 性能模型
RAIL性能模型指出了用户对不同延迟时间的感知度#xff0c;以用户为中心的原则#xff0c;就是要让用户满意网站或应用的性能体验。
RAIL #xff1a;响应(Response)、动画(Animation)、空闲(Idle)、加载(Load) RAIL 性能模型 用户感知延迟的时间窗口 1…一、RAIL 性能模型
RAIL性能模型指出了用户对不同延迟时间的感知度以用户为中心的原则就是要让用户满意网站或应用的性能体验。
RAIL 响应(Response)、动画(Animation)、空闲(Idle)、加载(Load) RAIL 性能模型 用户感知延迟的时间窗口 1、响应
网站性能对于响应方面的要求是在用户感知延迟之前接收到操作的反馈。比如用户进行了文本输入、按钮单击、表单切换及启动动画等操作后必须在100ms内收到反馈如果超过100ms的时间窗口用户就会感知延迟。
看似很基本的用户操作背后可能会隐藏着复杂的业务逻辑处理及网络请求与数据计算。对此应当将较大开销的工作放在后台异步执行而即便后台处理要数百毫秒才能完成的操作也应当给用户提供及时的阶段性反馈。比如在单击按钮向后台发起某项业务处理请求时首先反馈给用户开始处理的提示然后在处理完成的回调后反馈完成的提示。
2、动画
前端所涉及的动画不仅有炫酷的UI特效还包括滚动和触摸拖动等交互效果而这一方面的性能要求就是流畅。
研究表明这是由于视神经存在反应速度造成的其值是1/24s即当我们所见的物体移除后该物体在我们眼中并不会立即消失而会延续存在1/24s的时间。对动画来说无论动画帧率有多高最后我们仅能分辨其中的30帧但越高的帧率会带来更好的流畅体验因此动画要尽力达到60fps的帧率。
每一帧画面的生成都需要经过若干步骤根据60fps帧率的计算一帧图像的生成预算为16ms(1000ms/60≈16.66ms)除去浏览器绘制新帧的时间留给执行代码的时间仅10ms左右。
3、空闲
完全可以利用浏览器的空闲时间处理可延迟的任务只要让用户感受不到延迟即可。
为了更加合理地利用浏览器的空闲时间最好将处理任务按50ms为单位分组。这么做就是保证用户在发生操作后的100ms内给出响应。
4、加载
用户感知要求我们尽量在1s内完成页面加载如果没有完成用户的注意力就会分散到其他事情上并对当前处理的任务产生中断感。需要注意的是这里在1s内完成加载并渲染出页面的要求并非要完成所有页面资源的加载从用户感知体验的角度来说只要关键渲染路径完成用户就会认为全部加载已完成。
对于其他非关键资源的加载延迟到浏览器空闲时段再进行是比较常见的渐进式优化策略。
二、性能优化的步骤
进行性能优化的步骤一般是
首先可量化地评估出网站或应用的性能表现
然后立足于网站页面响应的生命周期分析出造成较差性能表现的原因
最后进行技术改造、可行性分析等具体的优化实施。
1、性能测量
1、Chrome 浏览器的 Performance 功能
打开开发者工具的Performance选项卡单击左上角的“开始评估”按钮后刷新网站该工具便开始分析页面资源加载、渲染、请求响应等各环节耗费的时间线据此便可分析一定程度的性能问题比如JavaScript的执行是否会触发大量视觉变化的计算重绘和重排或回流是否会被多次触发等。 2、灯塔Lighthouse
Lighthouse是一个开源的自动化审查网站页面性能的工具可根据所提供的网站URL从性能、可访问性、渐进式Web应用、SEO搜索引擎优化等多个方面进行自动化分析最终给出一份具有指导意义的报告。它既可以当作Chrome的扩展插件来使用又可以在开发者工具中直接使用。 集成在 Chrome 开发者工具中的 Lighthouse 除此之外还会经常用到的性能测试工具有PageSpeed Insights、WEBPAGETEST、Pingdom等。
2、生命周期
网站页面的生命周期通俗地讲就是从我们在浏览器的地址栏中输入一个URL后到整个页面渲染出来的过程。
整个过程
域名解析建立TCP连接前后端通过HTTP进行会话压缩与解压缩前端的关键渲染路径等
把这些阶段拆解开来看不仅能容易地获得优化性能的启发而且也能为今后的前端工程师之路构建出完整的知识框架网站页面加载的生命周期如下图所示 3、优化方案
(1)传输资源的优化比如图像资源不同的格式类型会有不同的使用场景在使用的过程中是否恰当。
(2)加载过程的优化比如延迟加载是否有不需要在首屏展示的非关键信息占用了页面加载的时间。
(3)JavaScript是现代大型网站中相当“昂贵”的资源是否进行了压缩书写是否规范有无考虑内存泄漏等。
(4)关键渲染路径优化比如是否存在不必要的重绘和回流。
(5)本地存储和浏览器缓存。
三、网页访问原理
1、网络请求线程开启
浏览器接收到我们输入的URL到开启网络请求线程这个阶段是在浏览器内部完成的。
首先是对URL的解析。
URL结构Protocol//HostPort/PathQuery#Fragment 解析 URL 解析URL后如果是HTTP协议则浏览器会新建一个网络请求线程去下载所需的资源要明白这个过程需要先了解进程和线程之间的区别以及目前主流的多进程浏览器结构。
1、进程与线程
简单来说进程就是一个程序运行的实例操作系统会为进程创建独立的内存用来存放运行所需的代码和数据而线程是进程的组成部分每个进程至少有一个主线程及可能的若干子线程这些线程由所属的进程进行启动和管理。由于多个线程可以共享操作系统为其所属的同一个进程所分配的资源所以多线程的并行处理能有效提高程序的运行效率。 进程与线程 (1)只要某个线程执行出错将会导致整个进程崩溃。
(2)进程与进程之间相互隔离。这保证了当一个进程挂起或崩溃的情况发生时并不会影响其他进程的正常运行虽然每个进程只能访问系统分配给自己的资源但可以通过IPC机制进行进程间通信。
(3)进程所占用的资源会在其关闭后由操作系统回收。即使进程中存在某个线程产生的内存泄漏当进程退出时相关的内存资源也会被回收。
(4)线程之间可以共享所属进程的数据。
2、多进程浏览器 多进程浏览器 (1)浏览器主进程一个浏览器只有一个主进程负责如菜单栏、标题栏等界面显示文件访问前进后退以及子进程管理等。
(2)GPU进程GPU图形处理单元最初是为了实现3D的CSS效果而引入的后来随着网页及浏览器在界面中的使用需求越来越普遍Chrome便在架构中加入了GPU进程。
(3)插件进程主进程会为每个加入浏览器的插件开辟独立的子进程由于进程间所分配的运行资源相对独立所以即便某个插件进程意外崩溃也不至于对浏览器和页面造成影响。另外出于对安全因素的考虑这里采用了沙箱模式即上图中虚线所标出的进程在沙箱中运行的程序受到一些限制不能读取敏感位置的数据也不能在硬盘上写入数据。这样即使插件运行了恶意脚本也无法获取系统权限。
(4)网络进程负责页面的网络资源加载之前属于浏览器主进程中的一个模块最近才独立出来。
(5)渲染进程也称为浏览器内核其默认会为每个标签窗口页开辟一个独立的进程负责将HTML、CSS和JavaScript等资源转为可交互的页面其中包含多个子线程即JS引擎线程、GUI渲染线程、事件触发线程、定时触发器线程、异步HTTP请求线程等。当打开一个标签页输入URL后所发起的网络请求就是从这个进程开始的。另外出于对安全性的考虑渲染进程也被放入沙箱中。
打开Chrome任务管理器可以从中查看到当前浏览器都启动了哪些进程 Chrome 任务管理器 2、建立 HTTP 请求
这个阶段的主要工作分为两部分DNS解析和通信链路的建立。简单说就是首先发起请求的客户端浏览器要明确知道所要访问的服务器地址然后建立通往该服务器地址的路径。
1、DNS 解析
前面讲到的URL解析其实仅将URL拆分为代表具体含义的字段然后以参数的形式传入网络请求线程进行进一步处理
首先第一步便是这里讲到的DNS解析。
其主要目的便是通过查询将URL中的Host字段转化为网络中具体的IP地址因为域名只是为了方便帮助记忆的IP地址才是所访问服务器在网络中的“门牌号” DNS 解析过程 首先查询浏览器自身的DNS缓存如果查到IP地址就结束解析由于缓存时间限制比较大一般只有1分钟同时缓存容量也有限制所以在浏览器缓存中没找到IP地址时就会搜索系统自身的DNS缓存如果还未找到接着就会尝试从系统的hosts文件中查找。
在本地主机进行的查询若都没获取到接下来便会在本地域名服务器上查询。如果本地域名服务器没有直接的目标IP地址可供返回则本地域名服务器便会采取迭代的方式去依次查询根域名服务器、COM顶级域名服务器和权限域名服务器等最终将所要访问的目标服务器IP地址返回本地主机若查询不到则返回报错信息。
2、网络模型
在通过DNS解析获取到目标服务器IP地址后就可以建立网络连接进行资源的请求与响应了。
在互联网发展初期为了使网络通信能够更加灵活、稳定及可互操作国际标准化组织提出了一些网络架构模型OSI模型、TCP/IP模型。 网络模型 OSI 各层的具体作用 3、TCP 连接
根据对网络模型的介绍当使用本地主机连上网线接入互联网后数据链路层和网络层就已经打通了而要向目标主机发起HTTP请求就需要通过传输层建立端到端的连接。
传输层常见的协议有TCP协议和UDP协议。
由于TCP是面向有连接的通信协议所以在数据传输之前需要建立好客户端与服务器端之间的连接即通常所说的“三次握手”具体过程分为如下步骤
(1)客户端生成一个随机数seq假设其值为t并将标志位SYN设为1将这些数据打包发给服务器端后客户端进入等待服务器端确认的状态。
(2)服务器端收到客户端发来的SYN1的数据包后知道这是在请求建立连接于是服务器端将SYN与ACK均置为1并将请求包中客户端发来的随机数t加1后赋值给ack然后生成一个服务器端的随机数seqk完成这些操作后服务器端将这些数据打包再发回给客户端作为对客户端建立连接请求的确认应答。
(3)客户端收到服务器端的确认应答后检查数据包中ack的字段值是否为t1ACK是否等于1若都正确就将服务器端发来的随机数加1(ackk1)将ACK1的数据包再发送给服务器端以确认服务器端的应答服务器端收到应答包后通过检查ack是否等于k1来确认连接是否建立成功。 连接建立的关系图 当用户关闭标签页或请求完成后TCP连接会进行“四次挥手”
(1) 客户端发送指令告诉服务器端请求关闭
由客户端先向服务器端发送FINM的指令随后进入完成等待状态FIN_WAIT_1表明客户端已经没有再向服务器端发送的数据但若服务器端此时还有未完成的数据传递可继续传递数据。
(2)服务器端收到请求关闭确认数据是否完成传递未完成则告诉服务器请等待
当服务器端收到客户端的FIN报文后会先发送ackM1的确认告知客户端关闭请求已收到但可能由于服务器端还有未完成的数据传递所以请客户端继续等待。
(3)服务器端确认数据传递完成发送给客户端告诉准备关闭
当服务器端确认已完成所有数据传递后便发送带有FINN的报文给客户端准备关闭连接。
(4)客户端收到关闭操作为确保数据正确双方客户端再次确认后即断开连接
客户端收到FINN的报文后可进行关闭操作但为保证数据正确性会回传给服务器端一个确认报文ackN1同时服务器端也在等待客户端的最终确认如果服务器端没有收到报文则会进行重传只有收到报文后才会真正断开连接。而客户端在发送了确认报文一段时间后没有收到服务器端任何信息则认为服务器端连接已关闭也可关闭客户端信息。
连接关闭的关系图如下图所示 连接关闭的关系图 3、前后端的交互
当TCP连接建立好之后便可通过HTTP等协议进行前后端的通信但在实际的网络访问中并非浏览器与确定IP地址的服务器之间直接通信往往会在中间加入反向代理服务器。
1、反向代理服务器
对需要提供复杂功能的网站来说通常单一的服务器资源是很难满足期望的。一般采用的方式是将多个应用服务器组成的集群由反向代理服务器提供给客户端用户使用这些功能服务器可能具有不同类型比如文件服务器、邮件服务器及Web应用服务器同时也可能是相同的Web服务部署到多个服务器上以实现负载均衡的效果。 反向代理服务器的作用 反向代理服务器通常的作用如下
负载均衡、安全防火墙、加密及SSL加速、数据压缩、解决跨域、对静态资源缓存。
2、后端处理流程
经反向代理收到请求后具体的服务器后台处理流程大致如下
(1)首先会有一层统一的验证环节如跨域验证、安全校验拦截等。如果发现是不符合规则的请求则直接返回相应的拒绝报文。
(2)通过验证后才会进入具体的后台程序代码执行阶段如具体的计算、数据库查询等。
(3)完成计算后后台会以一个HTTP响应数据包的形式发送回请求的前端结束本次请求。
只要网站涉及数据交互这个请求和响应的过程就会频繁发生而后端处理程序的执行需要花费时间HTTP协议保证数据交互的同时也对传输细节有所限制。这其中就存在很大的性能优化空间比如HTTP协议版本的升级、缓存机制等。
3、HTTP 相关协议特性
HTTP是建立在传输层TCP协议之上的应用层协议在TCP层面上存在长连接和短连接的区别。所谓长连接就是在客户端与服务器端建立的TCP连接上可以连续发送多个数据包但需要双方发送心跳检查包来维持这个连接。
短连接就是当客户端需要向服务器端发送请求时会在网络层IP协议之上建立一个TCP连接当请求发送并收到响应后则断开此连接。根据前面关于TCP连接建立过程的描述我们知道如果这个过程频繁发生就是个很大的性能耗费所以从HTTP的1.0版本开始对于连接的优化一直在进行。
HTTP1.0
浏览器与服务器只保持短暂的连接浏览器每次请求都需要 与服务器建立一个TCP连接
HTTP1.1
引入了长连接TCP默认不关闭可以被多个请求复用 在同一个TCP连接里客户端可以发送多个请求 多个请求按次序在服务端被处理 新增了一些请求方法、请求头和响应头
HTTP2.0
采用二进制格式而非文本格式 完全多路复用而非有序并阻塞的、只需要建立一个连接即 可实现并行 使用报头压缩降低开销 服务器推送
HTTP3.0
QUIC 基于 UDP 实现是 HTTP/3 中的底层支撑协议该协 议基于 UDP又取了 TCP 中的精华实现了即快又可靠的 协议。
4、浏览器缓存
具体的缓存策略分为两种强缓存和协商缓存。
强缓存就是当浏览器判断出本地缓存未过期时直接读取本地缓存无须发起HTTP请求此时状态为200 from cache。在HTTP 1.1版本后通过头部的cache-control字段的max-age属性值规定的过期时长来判断缓存是否过期失效这比之前使用expires标识的服务器过期时间更准确而且安全。
协商缓存则需要浏览器向服务器发起HTTP请求来判断浏览器本地缓存的文件是否仍未修改若未修改则从缓存中读取此时的状态码为304。具体过程是判断浏览器头部if-none-match与服务器短的e-tag是否匹配来判断所访问的数据是否发生更改。这相比HTTP 1.0版本通过last-modified判断上次文件修改时间来说也更加准确。
具体的浏览器缓存触发逻辑如下图 浏览器缓存触发逻辑 在浏览器缓存中强缓存优于协商缓存若强缓存生效则直接使用强缓存若不生效则再进行协商缓存的请求由服务器来判断是否使用缓存如果都失效则重新向服务器发起请求获取资源。
4、关键渲染路径
当我们经历了网络请求过程从服务器获取到了所访问的页面文件后浏览器如何将这些HTML、CSS及JS文件组织在一起渲染出来呢
1、构建对象模型
首先浏览器会通过解析HTML和CSS文件来构建DOM文档对象模型和CSSOM层叠样式表对象模型为便于理解我们以如下HTML内容文件为例来观察文档对象模型的构建过程。 浏览器接收读取到的HTML文件其实是文件根据指定编码(UTF-8)的原始字节形如3C 62 6F 793E 65 6C 6F 2C 20 73 70…首先需要将字节转换成字符即原本的代码字符串接着再将字符串转化为W3C标准规定的令牌结构所谓令牌就是HTML中不同标签代表不同含义的一组规则结构。然后经过词法分析将令牌转化成定义了属性和规则值的对象最后将这些标签节点根据HTML表示的父子关系连接成树形结构 文档对象模型 DOM 树 DOM树表示文档标记的属性和关系但未包含其中各元素经过渲染后的外观呈现。
这便是接下来CSSOM的职责了。
与将HTML文件解析为文档对象模型的过程类似CSS文件也会首先经历从字节到字符串然后令牌化及词法分析后构建为层叠样式表对象模型。假设CSS文件内容如下 最后构建的CSSOM树如图: CSSOM 树 这两个对象模型的构建过程是会花费时间的可以通过打开Chrome浏览器的开发者工具的性能选项卡查看到对应过程的耗时情况 构建过程耗时监控 2、渲染绘制
当完成文档对象模型和层叠样式表对象模型的构建后所得到的其实是描述最终渲染页面两个不同方面信息的对象一个是展示的文档内容另一个是文档对象对应的样式规则接下来就需要将两个对象模型合并为渲染树渲染树中只包含渲染可见的节点该HTML文档最终生成的渲染树如图 渲染树 渲染绘制的步骤大致如下
(1)从所生成DOM树的根节点开始向下遍历每个子节点忽略所有不可见的节点脚本标记不可见、CSS隐藏不可见因为不可见的节点不会出现在渲染树中。
(2)在CSSOM中为每个可见的子节点找到对应的规则并应用。
(3)布局阶段根据所得到的渲染树计算它们在设备视图中的具体位置和大小这一步输出的是一个“盒模型”。
(4)绘制阶段将每个节点的具体绘制方式转化为屏幕上的实际像素。
关键渲染路径执行快慢将直接影响首屏加载时间的性能指标。
当首屏渲染完成后用户在和网站的交互过程中有可能通过JavaScript代码提供的用户操作接口更改渲染树的结构一旦DOM结构发生改变这个渲染过程就会重新执行一遍。可见对于关键渲染路径的优化影响的不仅是首屏性能还有交互性能。
以上内容是《Web前端性能优化》的书籍的读书笔记。
