如何用工具定位性能瓶颈

凉拌西红柿
0 阅读11分钟

1. 性能优化工具

性能优化不是盲目的去修改代码,优化的核心是用工具量化问题,从而定位性能瓶颈.
对于检测工具,其实Chrome浏览器自带的基本工具就能实现检测的需求.
(以下工具内容可能受浏览器版本影响有部分差异,但大致区别不大)

1.1 Lighthouse(整体性能评分+问题定位)

  • 使用场景: 用于快速评估页面的整体性能,SEO,易用性,并生成可视化报告,标注核心问题和优化建议,适合先用来进行全局排查.

  • 操作步骤: Chrome浏览器内F12打开开发者工具->Lighthouse标签->勾选Performance->生成报告.

  • 核心关注指标:(指标具体定义可参考前端性能核心标准含义)

    • LCP(最大内容绘制):优秀标注<2.5s.>4s为差.反映首屏的加载速度.对应常见的首屏优化场景.
    • FID/INP(交互响应):优秀标准<200ms,反映页面的交互流畅度.对应渲染,运行时优化场景
    • CLS(布局偏移): 优秀标准<0.1,反映了页面的稳定性.多由图片未设尺寸,动态插入DOM导致

  • 作用:报告直接标注未压缩的资源,未懒加载的图片,阻塞渲染资源等问题.

1.2 Performance面板(运行时性能+卡顿排查)

  • 使用场景: 可以用来分析页面加载,运行,交互全流程性能,定位长任务,重排重绘,页面卡顿掉帧等问题.主要解决的是感觉页面卡但是又不知是那里卡的问题.

  • 操作步骤: Chrome浏览器内F12打开开发者工具->Performance->点击录制按钮->刷新页面/操作页面->停止录制并生成火焰图.

  • 核心关注点:

    • 主线程任务:找红色长条长任务(>50ms) ,长任务会阻塞渲染.常对应的是JS执行,DOM操作优化等场景
    • 帧数率(FPS):正常60fps,低于30fps表明卡顿,看是否频繁触发内容的重排重绘.
    • 网络瀑布图:看资源的加载顺序,加载时长,判断是否有阻塞资源.

1.3 Network面板(网络请求+资源加载排查)

  • 使用场景: 分析接口请求,静态资源加载问题,定位请求太多,资源文件较大,缓存失效,慢请求等问题.

  • 操作步骤: Chrome浏览器内F12打开开发者工具->Network->录制网络日志或刷新

  • 核心关注点:

    • 资源大小: 看JS,图片,CSS体积,判断是否需要压缩,拆包.
    • 请求数量: 接口/静态资源请求过多,对应接口合并,资源合并优化.
    • 缓存状态: Size列显示from disk cache未强缓存生效,否则缓存配置失效.
    • 加载时序: 是否有阻塞渲染的JS/CSS(排在首屏资源前加载)

1.4 Memory面板(内存泄漏+内存占用排查)

  • 使用场景: 解决页面越用越卡,内存持续上涨问题,定位内存泄漏.
  • 操作步骤: Chrome浏览器内F12打开开发者工具->Memory->堆快照->多次录制快照,对比内存占用变化.
  • 泄漏判断: 多次操作后内存占用不下降,反而持续升高,说明存在内存泄漏,重点检查定时器,事件监听,闭包,第三方实例未销毁等问题.

2. 标准化定位步骤

当面对一个慢项目时,按照先全局后局部,先网络后渲染,先前端后后端的这个顺序进行定位.

2.1 全局检查,判断问题的类型

先用Lighthouse跑分,看核心Web指标,快速判断是加载慢问题还是交互卡顿问题:

  • LCP不达标->首屏加载,资源体积,网络请求问题
  • INP/CLS不达标->渲染,JS执行,内存问题

2.2 分模块定位问题

2.2.1 加载类问题

打开Network面板,看首屏加载的资源体积和请求数,单包>1MB,请求数>50个,基本是资源过大,请求过多导致;然后看缓存列,无缓冲标识说明缓存配置错误.

2.2.2 渲染类问题

打开Performance,看主线程长任务和FPS,长任务多,FPS低,是DOM操作频繁,重排重绘过多,长列表未优化导致.

2.2.3 运行时问题

多次切换页面/操作组件,看Memory面板内存占用,持续上涨则是内存泄漏;操作时无响应,则是JS长任务阻塞主线程.

2.2.4 构建类问题

查看打包后的dist文件夹体积,verdor.js > 2MB,则说明第三方依赖未优化,未拆包.

2.3 区分问题优先级

定位到问题后,按"低成本高收益"的优先级排序优化,避免一上来就做SSR或者重构代码这种高成本操作:

  • 高优先级: 开启Gzip,图片压缩,配置强缓存,添加防抖节流,图片懒加载等.
  • 中优先级: 代码分割,路由懒加载,清除无用代码,接口合并
  • 低优先级: SSR/SSG,虚拟滚动,Web Workder,切换构建工具.

3. 常见问题

  • 优化过度: 不要盲目进行拆包,拆包过多会导致请求数量增加,HTTP1.1下反而更慢;图片懒加载不要滥用,首屏图片禁止懒加载,否则会拖慢LCP.
  • 重绘重排: 不要在循环里读取offsetTop,clientWidth等样式属性,会触发浏览器强制同步布局,批量DOM操作前先隐藏元素.
  • 缓存策略要精准: 强缓存适合长期不变的静态资源(图片,第三方库),协商缓存适合频繁更新的资源;文件名必须加hash,避免缓存覆盖.
  • 内存泄漏必查项: Vue/React组件销毁时,必须清除addEventListener监听,setInterval定时器,echarts/map实例,闭包不要持有DOM引用.

4. 举例说明

image.png

这个是找到的一个项目,使用Lighthouse后生成的测试报告,也能看出来一些东西.

image.png 就是这个按钮,点击后等待报告生成就行.
现在分析一下上面的报告内容.

4.1 总体概览(顶部三个圆形分数)

这个是当前报告最重要的地方,直观展示网站在三大核心维度的表现:

模块得分颜色含义
Performance(性能)34🔴 红色极差,页面加载慢,交互卡顿,用户体验严重受损.需优先优化
Best Practices(最佳实践)96🟢 绿色优秀!基本遵循现代Web开发规范,安全性和代码质量良好
SEO(搜索引擎优化)83🟠 橙色良好但有改进空间,主要问题集中在元数据和robots.txt配置上

注意:在三个圆形分数下面,有个告警信息,这个提示是说浏览器可能安装了扩展程序(比如广告拦截器,脚本管理等).这些扩展可能会影响测试结果,希望下次测试时使用"无痕模式"或关闭这些扩展在进行测试.

4.2 Performance(性能)模块 - 得分 34

核心指标(Metrics) - 决定性能分数的关键.这些是Google Core Web Vitals的核心指标,直接影响用户感知和搜索排名:

image.png

指标数值状态含义与建议
First Contentful Paint(FCP)5.6s差用户看到第一个内容(文字/图片)花了5.6秒->太慢.目标应为<1.8秒.应该优化首屏资源加载顺序,压缩CSS/JS,启用缓存
Largest Contentful Paint(LCP)10.7s极差最大可见元素(通常是主图或主题)渲染完成耗时10.7秒->严重影响体验!,目标应为<2.5秒.检查大图未压缩,服务器响应慢,阻塞资源过多
Total Blocking Time(TBT)500ms差主线程被阻塞时长500ms->用户点击无反应.目标应<200ms.减少JS执行时间,拆分长任务,使用Web Workers.
Speed Index(SI)7.5s差页面视觉填充速度指数为7.5->越高越差,目标应为<3.4s.优化关键渲染路径,延迟非关键资源.
Cumulative Layout Shift(CLS)0完美布局完全稳定,无意外移动

注:性能分数是基于以上指标加权计算出来的,其中LCP,TBT,CLS权重最高.

image.png

Diagnostics(诊断项) - 具体问题清单
这部分列出了影响性能的具体原因,并按严重程度排序(🔴严重/🟠中等/⚪轻微),以下是问题解析
严重问题(必须优先解决)

  • Largest Contentful Paint element - 10,720ms

    • 说明: 导致LCP过慢的元素(可能是大图或长文本)花了10.7秒才渲染.
    • 建议: 压缩该图片,预加载,使用懒加载,或者换用更小格式(WebP),确保服务器快速响应.

  • Mainimize main-thread work - 3.1s

    • 说明: 主线程处理任务耗时3.1s ->导致TBT高
    • 建议: 减少同步JS执行,避免复杂计算,使用requestIdleCallback或阻塞方式.

  • Reduce JavaScript execution time - 1.5s

    • 说明: JS执行本身耗时1.5秒->可能是框架初始化,第三方库过大.
    • 建议: 代码分割,Tree Shaking,移除未使用依赖,异步加载非必要脚本.

  • Enable text compression - Est savings of 7,862 kib

    • 说明: 文本资源(HTML/CSS/JS)未启用Gzip/Brotli压缩->浪费大量带宽.
    • 建议: 在服务端开启gzip或brotli压缩(Nginx/Apache/Cloudflare都支持)

image.png 点开查看,都是第三方库

  • Avoid an excessive DOM size - 938 elements

    • 说明: DOM节点数达938个->影响渲染性能和内存占用.
    • 建议: 简化结构,虚拟列表,避免嵌套过深,删除隐藏无用节点.

  • Reduce unused JavaScript — Est savings of 6,228 KiB

    • 说明：加载了大量未使用的JS 代码 → 增加下载和执行开销。
    • 建议：使用 webpack/vite 等工具做 Tree Shaking，按需加载组件

image.png 恩,还是这几个没做处理

  • Minify JavaScript — Est savings of 3,259 KiB

    • 说明：JS 文件未压缩（含空格注释）→ 体积臃肿
    • 建议：构建时启用 Uglify/Terser 压缩
      估计都猜到了,还是那几个

  • Page prevented back/forward cache restoration — 1 failure reason

    • 说明：页面阻止了 bfcache（前进/后退缓存恢复）→ 用户返回时需重新加载
    • 常见原因：使用了 unload 事件监听器、设置了 Cache-Control: no-store
    • 建议：移除 unload 监听器，改用 pagehide；检查 HTTP 头设置

中等问题(建议优化)**

  • Image elements do not have explicit width and height
    → 缺少宽高属性可能导致布局偏移（虽然 CLS=0，但仍建议加上以防未来变动）。
  • Serve images in next-gen formats — Est savings of 19 KiB
    → 推荐使用 WebP/AVIF 替代 PNG/JPG，节省流量。
  • Properly size images — Est savings of 13 KiB
    → 图片尺寸大于显示区域 → 应裁剪或缩放至实际所需大小。
  • Avoid serving legacy JavaScript to modern browsers — Est savings of 43 KiB
    → 给现代浏览器发送了兼容旧版的 polyfill → 可通过 <script type="module"> + dynamic import 优化。
  • Reduce unused CSS — Est savings of 83 KiB
    → 加载了未使用的 CSS → 使用 PurgeCSS 或构建工具清理。
  • Avoid enormous network payloads — Total size was 10,249 KiB
    → 整个页面资源总量超 10MB → 极度不合理！必须大幅压缩图片、精简 JS/CSS、启用 CDN

轻微问题(可惜优化)

  • Avoid long main-thread tasks
  • User Timing marks and measures
  • Avoid large layout shifts
  • Avoid chaining critical requests
  • Minimize third-party usage

这些属于进阶优化项，可在基础问题解决后再考虑。

4.3 Best Practices(最佳实践)模块 - 得分96

唯一的失败项:

image.png

  • Browser errors were logged to the console
    → 浏览器控制台存在错误日志（如 JS 报错、404 资源缺失等）。

    • 建议：打开开发者工具 Console 标签页，查看具体错误并修复（例如引用不存在的文件、语法错误等）。

其他项目均通过或不适用，说明网站在安全策略（CSP、HSTS）、防点击劫持、隔离等方面做得很好。

4.4 SEO(搜索引擎优化)模块 - 得分 83

image.png

  1. Document does not have a meta description
    → 缺少 <meta name="description" content="..."> 标签。

    • 影响：搜索引擎无法生成摘要 snippet，降低点击率。
    • 建议：为每个页面添加简洁有力的描述（约 150–160 字符）。

  2. robots.txt is not valid — 107 errors found
    → robots.txt 文件格式错误或包含无效指令。

    • 影响：搜索引擎爬虫可能误判哪些页面可以抓取，导致收录异常。
    • 建议：访问 https://yourdomain.com/robots.txt，用 Google Robots Testing Tool 验证并修正语法错误。

4.5 如何基于报告优化

4.5.1 第一步：立即修复 Performance 中的严重问题

  1. 启用文本压缩（Gzip/Brotli）→ 最快见效，节省近 8MB！
  2. 压缩和优化图片 → 特别是 LCP 元素，转为 WebP 并调整尺寸。
  3. 减少 JS 体积和执行时间 → Tree Shaking + Code Splitting + 异步加载。
  4. 缩小 DOM 规模 → 重构模板，避免冗余嵌套。
  5. 最小化 JS/CSS → 构建流程中加入压缩步骤。
  6. 解决 bfcache 阻止问题 → 移除 unload 监听器。

4.5.2 第二步：修复 SEO 问题

  1. 添加 <meta name="description"> 到所有重要页面。
  2. 修正 robots.txt 文件，确保语法正确且允许主流爬虫访问。

4.5.3 第三步：复查 Best Practices

  1. 打开 Chrome DevTools → Console，找出并修复所有 JS 错误。

4.5.4 第四步：重新测试

  • 使用 无痕模式 或 新建干净 Chrome Profile 再次运行 Lighthouse。
  • 对比前后得分变化，确认优化效果。
avatar
文章
阅读
粉丝