前端的面试笔记——HTML&JavaScript篇（二）前端页面性能检测

于 2025-05-19 16:38:01 发布
阅读量859 收藏 14
点赞数 23
分类专栏： 个人面试复习笔记 文章标签： 页面性能检测 LCP FID CLS 性能判定标准 性能优化策略
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/jason_renyu/article/details/148065146
版权

前端页面性能检测和判定是优化用户体验的核心环节，需要结合实验室数据（Lab Data）、现场数据（Field Data）和行业标准综合评估。以下是主流方法、工具及判定标准的详细解析：

一、性能检测的核心维度与指标

1. 加载性能

  • 核心指标：
    • LCP（最大内容绘制）：衡量首屏主要内容的加载速度，理想值 ≤ 2.5 秒，需优化图片 / 视频、关键资源加载顺序。
    • FCP（首次内容绘制）：首次渲染像素的时间，理想值 ≤ 1 秒，关注 HTML 解析与首屏渲染效率。
    • TTFB（首字节时间）：服务器响应速度，理想值 ≤ 200ms，优化后端性能或 CDN 配置。

2. 交互性能

  • 核心指标：
  • FID（首次输入延迟）：用户首次交互到响应的时间，理想值 ≤ 100ms，减少长任务（>50ms）和主线程阻塞。
  • TTI（可交互时间）：页面完全可交互的时间，通过 TTIAPI 测量，优化 JavaScript 执行效率。

3. 视觉稳定性

  • 核心指标：
    • CLS（累积布局偏移）：元素意外移动的程度，理想值 ≤ 0.1，避免动态内容导致的重排（如图片 / 广告未预留空间）。

4. 其他关键指标

  • FMP（首次有意义绘制）：用户感知到页面 “可用” 的时间，适合 SPA 应用评估。
  • TBT（总阻塞时间）：FCP 到 TTI 之间的主线程阻塞时间总和，反映交互准备度。
  • Bundle Size：JS/CSS 包体积，过大易导致加载和解析延迟，建议单页 JS ≤ 150KB（压缩后）。

二、性能检测工具与使用场景

1. 浏览器内置工具（实验室数据）

Chrome DevTools

  • 适用场景： 开发阶段实时调试，深度分析性能瓶颈。
  • 核心功能：
    • Performance 面板：录制页面加载过程，分析 LCP、FID、长任务、资源瀑布图。
    • Lighthouse：一键生成性能审计报告，提供优化建议（如图片压缩、移除阻塞脚本）。
    • Coverage：检测未使用的 JS/CSS 代码，辅助代码拆分。
  • 操作技巧： 模拟移动端设备、限速网络（如 Slow 3G），复现真实用户环境。

Firefox DevTools

  • 特色功能：
    • Performance Monitor：实时监控 CPU / 内存 / 网络占用，适合定位内存泄漏。
    • Netmonitor：可视化网络请求依赖关系，识别资源加载阻塞链。

2. 在线性能分析工具

Google PageSpeed Insights

  • 优势： 整合 Lighthouse 实验室数据与 CrUX（Chrome 用户体验报告）现场数据，提供移动端 / 桌面端双版本评分。
  • 输出内容：
    • 性能评分（1-100），红色项为严重问题（如 LCP 超时、未压缩图片）。
    • 优化清单：按优先级排列，如 “延迟非关键 JavaScript”“使用 WebP 格式图片”。

WebPageTest

  • 专业级功能：
    • 多地区节点测试（如纽约、东京），模拟真实地理位置延迟。
    • 视频录制与性能指标时间轴对比，直观展示渲染卡顿。
    • 支持自定义 HTTP 头、缓存策略，深度测试 CDN 或认证场景。

GTmetrix

  • 综合分析： 结合 Lighthouse 和 WebPageTest 数据，生成 “性能” 与 “结构” 双评分，提供 Waterfall 图和 YSlow 规则检查（如缓存策略、域名收敛）。

3. 真实用户监测（RUM）工具（现场数据）

Google Analytics 4 (GA4)

  • 集成指标： 自动收集 FCP、LCP、CLS 等 Core Web Vitals 数据，按国家 / 设备 / 浏览器维度细分。
  • 使用场景： 监控生产环境性能波动，定位特定用户群体的体验问题。

New Relic / Datadog

  • 高级功能：
    • 自定义性能指标（如 TTI、用户自定义交互延迟）。
    • 异常检测与警报：当 LCP 第 75 百分位超过阈值时触发通知。

Web Vitals 库（JavaScript SDK）

  • **轻量级方案：**通过 web-vitals npm 包手动上报 LCP/FID/CLS 数据到自有监控平台，适合隐私要求高的场景。

4. 自动化性能测试工具

Pa11y/Dalmatiner

  • 自动化审计： 集成 Lighthouse/axe 等工具到 CI/CD 流程，每次代码提交时自动检测性能与 accessibility 问题。
  • 配置示例：
    	# GitHub Actions 配置  
	 name: Run Lighthouse audit  
	 uses: foo-software/lighthouse-check-action@v3  
	 with:  
	   urls: "https://example.com"  
	   threshold: 70 # 性能评分低于70时失败

Calibre

  • 可视化对比： 录制不同版本页面的性能视频，逐帧对比渲染差异，适合 SPA 或动画优化。

三、性能判定标准与优化策略

1. 行业标准与评分阈值

指标良好（绿色）需要改进（黄色）较差(红色)
LCP≤ 2.5 秒2.5-4 秒> 4 秒
FID≤ 100ms100-300ms> 300ms
CLS≤ 0.10.1-0.25> 0.25
Lighthouse 性能评分≥ 9050-90< 50

2. 优化优先级策略

  1. 紧急修复（红色项）：
    • 阻塞渲染的资源（如未标记 async/defer 的 JS）。
    • 未优化的图片（格式非 WebP/AVIF、未设置宽高导致 CLS）。
  2. 中等优先级（黄色项）：
    • 长任务（通过 DevTools 火焰图定位耗时函数，拆分为微任务或使用 Web Workers）。
    • 过大的 JS bundle（启用 Tree Shaking、Code Splitting）。
  3. 长期优化（绿色项维护）：
    • 预加载关键路由资源（SPA 场景）。
    • 采用 HTTP/3 或 QUIC 协议减少延迟。

3. 性能预算设置

  • 定义规则： 例如 “单页 JS 体积增量 ≤ 5KB / 版本”“LCP 第 75 百分位 ≤ 3 秒”。
  • 工具落地： 使用 bundlesize 监控包体积变化，结合 RUM 工具设置警报阈值。

四、性能检测的最佳实践

  1. 分阶段测试：
    • 开发阶段： 侧重实验室数据（DevTools/Lighthouse），快速定位代码级问题。
    • 预发布阶段： 通过 WebPageTest 模拟多地区用户环境，验证 CDN 和缓存策略。
    • 生产阶段： 依赖 RUM 工具监控真实用户体验，重点关注长尾用户（如低端设备、弱网地区）。
  2. 对比分析：
    • A/B 测试不同优化方案的性能差异（如服务端渲染 vs 客户端渲染的 LCP 对比）。
    • 跟踪历史数据，分析性能趋势与代码变更的关联（如某次上线后 FID 突增）。
  3. 用户 - centric 优化：
    • 优先优化首屏可见区域内容，非关键资源采用懒加载（如 Intersection Observer）。
    • 针对高流量页面（如落地页、结算页）进行专项性能审计。

五、工具选型参考表

实时调试推荐工具核心优势
实时调试Chrome DevTools深度分析主线程、资源依赖
多地区性能测试WebPageTest真实节点模拟、视频对比
生产环境监控GA4 + Web Vitals SDK免费、集成用户行为数据
自动化 CI/CD 检测Pa11y + Lighthouse-check-action代码提交时自动阻断性能退化
性能对比与可视化Calibre视频逐帧对比、SPA 动画优化

通过组合使用上述工具，结合数据驱动和用户体验导向的优化策略，可系统性提升前端页面性能，并确保优化效果符合行业标准与业务目标。

Qwen-14B-Chat-Int4推理报错:ImportError: libcudart.so.12: cannot open shared object file
qq_42681787的博客
11-09 1750
按照提示，pip安装这两个包，结果报错： ImportError: libcudart.so.12: cannot open shared object file: No such file or directory。发现是由于安装的 auto-gptq版本与conda安装的CUDA版本冲突所导致。在 Qwen-14B-Chat-Int4推理时，发现报错，缺少 optimum 和 auto-gptq 两个pip包。安装了跟我conda环境与cuda版本相匹配的 AutoGPTQ，问题解决。
大模型LLM 在线量化；GPTQ\AWQ量化及推理
weixin_42357472的博客
11-19 2110
参考:https://github.com/casper-hansen/AutoAWQ/blob/87350fefb9081dadec111cea9b315d009d877a87/examples/quant_custom_data.py。参考：https://vllm.readthedocs.io/en/latest/quantization/auto_awq.html。参考：https://github.com/vllm-project/vllm/issues/1538。应该是vllm暂时还不支持。
llama2使用gptq量化踩坑记录
weixin_50845368的博客
11-07 7305
我刚开始直接pip install auto-gptq，产生了一系列的问题。本地是CUDA11.6，首先的问题是无法量化。gptq本身是一个github仓库，随后集成在了Transformers 库里，介绍如下：optimum🤗Transformers**已经整合了*，**用于对语言模型进行GPTQ量化。您可以以8、4、3甚至2位加载和量化您的模型，而不会对性能产生很大的影响，并且能够提高推理速度！这在大多数GPU硬件上都得到支持。optimum。
关于pycharm安装GDAL包失败的问题
永不言弃的博客
06-01 2837
4 找到自己项目所在路径下的Scripts文件夹 也就是pycharm 中解释器设置下的解释器路径 C:\Users\casia\OPT-server\Scripts\GDAL-3.3.3-cp39-cp39-win_amd64.whl。5 在终端下输入 pip insall C:\Users\casia\OPT-server\Scripts\GDAL-3.3.3-cp39-cp39-win_amd64.whl。代表自己电脑是win64位机。是自己python版本号。网页中找到对应的安装包。
AtomGPT
TH_NUM的博客
07-02 570
【转发】为了能够在中文上训练出一个能够和ChatGPT能力接近的中文大模型，我们开放了AtomGPT项目AtomGPT基于LLaMA的模型架构，从0开始训练，希望能在训练的过程中，将模型能力得到提升的进化过程展示出来，感受到模型学习的过程。(ps:各位大佬，如果本项目能给您带来一点点帮助，麻烦点个⭐️吧)
BaiChuan13B-GPTQ量化详解
Blue&boke
04-18 1462
1、按照网上搜索的一些代码，如使用auto_gptq原生库进行训练后量化，可能会正常量化，但是在线推理时会出现如找不到bin文件或者tf文件，即模型权重文件，所以和网上大部分代码不同的地方在于，需要提前保存对应模型的权重文件，如果是BaiChuan13B，那么在进行模型量化前，对其进行保存。按照上述步骤，此时模型量化文件保存成功，接下来就是模型在线推理。
源2.0-M32大模型适配AutoGPTQ工具及量化&推理教程
2401_82700030的博客
09-29 1727
AutoGPTQ‌是一个开源工具包，专注于简化大规模语言模型(LLMs)的量化过程。它基于高效的GPTQ算法开发，主要使用Python编程语言，并依托PyTorch框架来实现量化功能。AutoGPTQ的设计目标是为开发者和研究人员提供一个易于使用的API接口，即使对量化技术不太了解的用户也能轻松进行模型量化。通过采用仅量化权重的方式，该工具包在尽量减少性能损耗的情况下，缩减了模型体积，提升了部署的效率。
【AIGC】大模型面试高频考点-LLM量化方法对比：GPTQ、GGUF、AWQ
LeeZhao的博客
03-16 1267
LLM量化方法对比：GPTQ、GGUF、AWQ
欺诈文本分类检测（十四）：GPTQ量化模型
golfxiao的专栏
09-11 1888
本文通过gptq方法分别对微调后的模型进行了8位量化和4位量化，并对比了量化前后模型的性能指标差异，8位量化模型的性能指标变化小，而4位量化模型的性能指标变异较大。
【通义千问】大模型Qwen GitHub开源工程学习笔记（4）-- 模型的量化与离线部署
weixin_46481662的博客
10-13 2760
量化方案基于AutoGPTQ，提供了Int4量化模型，其中包括Qwen-7B-Chat和Qwen-14B-Chat。更新承诺在模型评估效果几乎没有损失的情况下，降低存储要求并提高推理速度。量化是指将模型权重和激活的精度降低以节省存储空间并提高推理速度的过程。AutoGPTQ是一种专有量化工具。Int4是指4位整数量化，与传统的8位量化相比，可以进一步减少存储要求。
pip install pytorch-quantization error
qq_43318374的博客
05-28 848
【代码】pip install pytorch-quantization error。
大模型量化AutoGPTQ代码配置
HuanB123的博客
11-04 436
针对大语言模型推理性能优化的研究取得了巨大的进展，如今我们不仅能够在高端显卡上完成大语言模型的推理，甚至在 CPU 和边缘设备上都可以轻松运行大语言模型。在此记录我配置大模型量化的代码AutoGPTQ的过程中出现的问题和解决方案。选择合适自己的python、系统、和cuda版本的wheel文件，在这里我选择的第三个，因为我的是cu117。大家也可以根据图示命令查看自己虚拟环境中的cuda版本，选择对应的文件。安装的话得到的很可能是不符合你的环境的包。其实最核心的在于安装auto-gptq这个包，但是直接。
使用autogpt来写一篇技术文章（如何部署autogpt+遇到的问题+如何使用）
王亮的博客
04-15 5573
autogpt如何部署，部署遇到问题，使用体验
Qwen大模型实践之量化
lldhsds的专栏
05-08 1648
当前该功能不支持与flash attention同时开启，如果你开了KV cache量化的同时又开了flash attention（use_flash_attn=True， use_cache_quantization=True, use_cache_kernel=True），程序默认将关闭use_flash_attn。开启了KV cache量化之后，模型在推理时可在生成更长的序列（sl，生成的token数）时，节约更多的显存。运行程序后，模型加载完毕，显存占用9G左右，有降低。
AutoGPTQ量化环境搭建与示例实现
qq_41878154的博客
09-10 992
运行上述代码后可以得到一个量化后的文件夹，这个量化后的模型是以.safetensor格式保存的。文件中具体内容如下所示。
使用GPTQ进行4位LLM量化
wangyifan123456zz的博客
02-26 3575
当一些权重被中间更新推到网格之外时，这种效果可能会恶化。一个简单的启发式应用来防止这种情况：异常值一出现就被量化。这个过程可能需要大量的计算，特别是对于LLMs。为了解决这个问题，OBQ方法使用了一种技巧，避免在每次简化权重时重新进行整个计算。量化权重后，它通过删除与该权重相关的行和列(使用高斯消去)来调整计算中使用的矩阵(Hessian矩阵)。该方法还采用向量化的方法，一次处理多行权矩阵。尽管OBQ的效率很高，但随着权值矩阵的增大，OBQ的计算时间也会显著增加。
在本地Windows机器加载大模型并生成内容
最新发布
oscar999的专栏
03-25 789
本篇演示在本地机器下载和加载大模型并获取AI产生的内容。简单起见，使用的大模型是Qwen2.5-0.5B-Instruct，整个模型的所有文件不到1G。Qwen2.5-0.5B-Instruct 是阿里巴巴云 QWen 团队基于Transformer 架构开发的轻量级指令调优语言模型，专为资源有限场景设计。环境准备。
【笔记】AutoModelForCausalLM
热门推荐
weixin_50862344的博客
06-05 2万+
初学者肯定有很多不对头的地方，麻烦大家多多指点！！！
autogptq
03-11
对于那些希望进一步优化其部署环境中的模型性能的人来说，`AutoGPTQ` 提供了多种配置选项来自定义量化参数，比如位宽(bit-width)，这有助于平衡精度损失与运行效率之间的关系。 #### 注意事项 当处理特定硬件平台...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值