HTML5 性能监控实战：利用 API 发现并优化渲染瓶颈-H5教程-PHP中文网

关键是要在内联脚本中用performanceobserver监听first-contentful-paint，结合resource timing定位阻塞资源，并用longtask捕获主线程卡顿，通过fcp/lcp交叉验证优化效果。

html5 性能监控实战：利用 api 发现并优化渲染瓶颈

要发现并优化渲染瓶颈，关键不是等页面跑起来再看，而是从加载初期就捕获真实绘制行为，并把时间点和主线程活动关联起来。PaintTiming 和 PerformanceObserver 是最直接的抓手，配合 Resource Timing 和 longtask 监听，能准确定位“为什么用户看到内容慢”。

用 PaintTiming 精确捕获首次有效渲染（FCP）

FCP 是用户感知“内容出现”的第一个信号，单位是毫秒，起点为 navigationStart。它不等于 DOM 加载完成，也不依赖图片是否加载完，只要浏览器画出第一个文本、图标或非空白 SVG 就触发。

必须在 内联脚本中注册 PerformanceObserver，监听 first-contentful-paint 类型，避免因延迟执行而漏掉条目；
不要用 window.addEventListener('load') 或 DOMContentLoaded 来读取，这些事件发生时 Paint 条目可能已被清理；
示例代码应放在 HTML 最开头：
<script><br>if ('PerformanceObserver' in window) {<br> new PerformanceObserver(l => {<br> l.getEntries().forEach(e => e.name === 'first-contentful-paint' && console.log('FCP:', e.startTime));<br> }).observe({ entryTypes: ['first-contentful-paint'] });<br>}<br></script>

结合 Resource Timing 找出拖慢 FCP 的资源

FCP 被推迟，往往不是因为 JS 写得慢，而是某个 CSS、字体或关键 JS 还没下载完或解析完。Resource Timing 能暴露每个资源的真实耗时和传输细节。

HTML Extract

使用 MinerU 从 HTML 页面和文件中提取内容，将 HTML 转换为保持标题、列表、表格及文本层次结构的干净、结构化 Markdown。F...

下载

调用 performance.getEntriesByType('resource')，筛选出 initiatorType 为 link（CSS）、script 或 font 的条目；
重点关注 duration > 400ms 的字体（.woff2）或 CSS 文件，它们常阻塞渲染；
检查 transferSize 是否远大于 decodedBodySize，若差异大，说明压缩未生效或 CDN 未开启 Brotli；
对 name 指向第三方域名的资源，对比 connectStart 与 secureConnectionStart 差值，超 150ms 表明 TLS 握手慢，需加 <link rel="preconnect">。

用 PerformanceObserver 捕获长任务，定位主线程卡顿

用户觉得“卡”，常常不是加载慢，而是某段 JS 占用主线程太久，导致绘制被推迟。这类问题不会报错，也难靠肉眼识别，必须靠 longtask 类型监听。

注册 observer 时明确指定 entryTypes: ['longtask', 'largest-contentful-paint']，一次拿到卡顿与首屏大图数据；
单个任务 duration > 50ms 就构成风险，> 100ms 很可能已影响 FCP；
常见诱因包括：未节流的 resize 监听器、React 大量同步更新、复杂 CSS 选择器引发样式重计算；
验证方式：在 Chrome DevTools Performance 面板录制，打开 “Main” 线程轨道，找红色长条——那就是阻塞绘制的长任务。