浏览器输入URL 回车后的执行机制

第一步 影响性能的关键:域名解析

将域名解析为IP;
由近到远查询;
默认使用缓存;
优化方向:使用dns-prefetch,减少域名数量,使用第三方知名域名

第二步:建立连接

浏览器会尝试连接对方服务器;
因为彼此存在不同的网络环境,连接过程会比较复杂;
这个阶段优化空间不大,一般跟服务器部署有关;
后端可以使用CDN加速;

第三步:发起请求(优化方向:减少请求数量,利用cookie传递初始化所需的数据)

浏览器构建请求:(请求方法,请求路径,请求头,请求体) GET /sockjs-node/info?t=1671439075238
HTTP/1.1 Accept: / Accept-Encoding: gzip, deflate Accept-Language:
zh-CN,zh;q=0.9 Connection: keep-alive Host: 192.168.2.16:13002 Origin:
http://localhost:13002 Referer: http://localhost:13002/ User-Agent:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/108.0.0.0 Safari/537.36

第四步:下载网页

检查请求头,是否使用缓存,是就启用缓存进入渲染阶段,否就下载网页(注意:尽量不要给HTML加缓存,避免更新问题);就像我们使用webpack打包后的dist文件通常会在html文件中以标签的形式引入一些文件,文件后缀名会加上hash值,如果我们进行了缓存有可能会导致我们获取不到最新的文件

第五步:边解析边渲染

边下载边解析边渲染,‘<link>’不会阻塞渲染,‘<script>’可能会阻塞渲染
图片视频等资源一般不会阻塞渲染,因为嵌套关系,渲染一般发生在闭合标签时,加载完成分别触发‘load’,‘DOMContentLoaded’事件
影响性能优化的下的因素:‘<script>’阻塞渲染
1.‘<script>’包含影响dom的方法,所以会阻塞渲染
2.‘<script defer>’不阻塞渲染,脚本会按顺序执行
3.‘<script async>’不阻塞渲染,脚本加载完就会执行
4.‘<script type=“module”>’会按需加载,按需执行
5.‘<script>’会影响到’DOMContentLoader’事件
优化方向:
尽量将‘<script>’放在’<body>'末尾
添加’defer’或者’async’属性
业务无关的代码(比如统计脚本),建议最后手动加载

影响性能优化因素:首屏渲染 FCP

第一次渲染的时间点发生在<head>加载完成之后
FCP一般不会影响渲染 的总时长,但是对用户体验帮助巨大
通常来说我们希望FCP<1s
优化方向:
将关键样式放在’<head>'中
'<head>'里不要放会阻塞脚本
首屏HTMl要放到一个闭合标签里
使用骨架屏

影响性能优化因素:并行加载

http/1.1 可以同时从一个域名下载6个资源(如果实在没http2,可以用多个域名指向同一个服务器来加载)
http/2可以通过复用连接,可以同时下载更多资源
优化方向
服务器使用http/2
如果使用http/1.1,可以使用多个域名;否则,少使用一些域名
压缩请求数
减少首次加载内容,使用lazy-load加载图片资源
非核心内容人工延迟加载

影响性能优化因素:CLS

CLS(Cumulative Layout Shift)是页面布局的稳定性
如果是渲染过程中,页面出现大量布局变化会影响用户体验(eg:本来在左边加载完后跑到右边)
所以Google Web Vitals中,将CLS纳入考量
优化方向:
使用骨架屏
减少使用web fonts
给图片添加起始尺寸
避免后期加载的内容导致页面变化

影响性能优化因素:LCP

LCP(Largest Contentful Paint)是页面最大内容的渲染时间
面积最大的内容通常也是最重要的内容,所以Google Vitals 用这个指标衡量用户体验
优化方向
将关键内容放在网页文件的前面
通过样式调整,满足产品的需要的同时,让关键内容尽可能早地渲染

第六步:加载资源

同样的效果,体积可能大不一样
优化资源,不仅提升用户体验还能给自己省钱
优化方向
减少请求的数量
压缩图片:位图webp,矢量svg
压缩视频MP4
使用视频MP4替代gif
增加缓存时间(30天,存在用户的盘中)

第七步:执行JS

spa关键步骤:所有Js都要先执行,SPA里,js负责渲染页面,所以JS执行时间里,直接影响到用户体验

影响性能优化的因素:执行效率

原生API,性能更好
新特性通常由更好的优化效率
静态代码更容易优化
优化方向:
在开发中多使用新特性,然后通过构建工具保证兼容性(webpack的corejs包)
通过统计工具,照顾尽可能多的用户,但要适当提高目标平台要求
配置编译工具,尽可能使用原生API
不要使用’eval’,'new Function()'等方法

影响性能优化的因素:代码量

代码量越少,下载时间越短
代码量越少,执行时间越短
用户通常只需要20%的功能,不要让他们下载100%的代码
优化方向
代码分模块,按需加载
使用ES Module,配合http/2
使用tree-shaking
使用高版本的第三方库

优化方向:复用缓存
代码分模块的时候尽量根据场景分组
升级依赖的时候,尽量集中更新某个模块
尽量让生成的代码具备一样的hash
如果有多个项目则尽量使用同样的分包

第八步:浏览器渲染完成

现代化前端SPA的渲染通常是分阶段的:
得到服务器响应后,快速渲染出骨架屏
加载必要的资源后,渲染出首屏
渲染出大部分页面骨架,等待静态资源慢慢加载

影响性能优化的因素:SSR

SSR(Server Side Rendering)服务端渲染,即在服务器上渲染出页面内容,再返回给客户端
通常SPA需要等待JS执行完毕再请求数据再去渲染页面
SSR可以让用户更早看到内容,提升用户体验

优化方向:
使用SSR框架,比如Nuxt.js(Vue),Next.js(React)
支持使用边缘计算和Serverless的服务,如Vercel
使用预渲染提前渲染页面

第九步:为用户回访、站内跳转做准备

静态资源保存较长时间的缓存
加强资源复用,减少请求
提前预缓存,预加载,本地化所需资源
不常变的数据,缓存在用户本地(甚至可以使用PWA技术缓存下载,下次加载直接读取)

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值