web页面响应慢的原因「如果用户觉得web应用反应卡顿主要从哪几个方面来排查」

时间:2023-07-08 03:08:41阅读:190
主要有以下几个方面排查应用反应慢问题加载慢资源下载慢首屏并发请求资源过多首屏接口慢首屏对应的 JS 执行慢首屏渲染慢首屏加载静态资源过大.......执行过程慢接口慢long tasks 太多, 阻塞 JS 执行内存泄漏重绘…

主要有以下几个方面排查应用反应慢问题加载慢资源下载慢首屏并发请求资源过多首屏接口慢首屏对应的 JS 执行慢首屏渲染慢首屏加载静态资源过大.......执行过程慢接口慢long tasks 太多, 阻塞 JS 执行内存泄漏重绘重排 过多关键节点没有加 节流防抖.......主要排查手段有哪些通过建立性能监控指标: 通过真实用户数据反馈, 来判断用户是否卡顿, 包含网络监控、运行时性能监控、Chrome devtools: NetWork 主要排查网络问题

Chrome devtools: Performance 主要细查性能运行时性能,包含了 long tasks、render 次数、重排重绘、执行时间线、阻塞场景

Chrome devtools: Performance monitor 主要监控用户运行时性能,看看是否有内存泄露

react Developer Tools: 可以用于追踪 react 应用性能、渲染次数、重排重绘

Lighthouse: 全面分析网页性能的一个工具、支持浏览器插件

webpack-bundle-analyzer: 进行产物依赖分析、包大小分析抓包: 通过抓包的方式, 看看线上请求分析、请求模拟、网络劫持之后仅仅看 JS 执行时间E2E测试: 通过 E2E 进行性能预检, 每次上线前进行一系列系统操作, 看看时间耗时和线上耗时波动主要解决办法和思路资源加载方向使用 tree shaking 减少包体积代码压缩和混淆对于高版本浏览器, 直接使用 es6 语法,低版本浏览器再使用 es5(es6 语法代码量会比编译成 es5 代码量小很多, 且执行速度也快)使用 split chunks 进行大包拆分、小包复用使用 gzip使用 图片压缩使用 雪碧图图标使用 iconfont 加载懒加载, 仅加载首屏必要资源使用 tailwindcss 等技术, 复用 css使用 微前端 技术,首屏仅加载当前子应用页面,可以做到只加载整站很少的一部分代码首屏非必要依赖尽量延后到 FMP 或者 TTI 之后再加载组件微前端化渲染方向尽量减少重排重绘减少重复渲染(useMemo、useCallback、memo 等)减少 setState 次数(多次 setState 可以合并为一次)尽量减少 dom 节点深度网络方向使用流式服务端渲染, 可以查看文档:juejin.cn/post/695381…使用服务端渲染, 减少首屏请求使用 SSG 静态站点生成首屏必要数据, 不作客户端请求, 用后端模板注入使用 BFF 进行请求聚合使用 CDN 进行网络请求分发DNS Prefetch资源预加载(在闲暇时间加载后续页面所需要的资源和接口,例如:link rel preload)启用 HTTP2 多路复用在业务逻辑上, 首屏必要接口提前(例如在 html 加载的那一瞬间,利用一个非常小的 js 文件将首屏需要的请求发送出去, 然后缓存下来, 到业务使用的时候直接就使用即可)使用缓存技术缓存资源与请求:强缓存、协商缓存、离线缓存、service Worker 缓存、后端业务缓存

运行时卡顿方向

查看是否存在有有 long tasks, 有计划的拆解 long tasks解决项目中复杂度问题: www.jianshu.com/p/ffbb25380…排查项目是否有内存泄露排查特定业务流程是否有慢接口高复杂计算逻辑放在 service worker 处理参考文档https://juejin.cn/post/7096144248713510943https://juejin.cn/post/6882936217609732110https://juejin.cn/post/7119074496610304031https://juejin.cn/post/7159807927908302884

评论

  • 评论加载中...