Lighthouse评分未变是因为它只检测实际加载行为而非资源来源；若CDN地址错误、资源404、JS同步阻塞解析、DNS查询过慢或未正确使用async/defer，仍会触发“Render-blocking resources”警告。
CDN引入组件库时，为什么Lighthouse评分没变？
因为Lighthouse只测当前页面快照，不关心你用的是CDN还是本地文件——它测的是实际加载行为。如果你CDN地址写错、资源404、或JS执行阻塞了HTML解析，Lighthouse照样报“Render-blocking resources”。
- 检查
network面板：确认bootstrap.bundle.min.js和font-awesome.css状态码是200，且没有被浏览器拦截（比如混合内容警告） - 验证是否真用了
async或defer：如果<script>没加这两个属性，哪怕走CDN也会同步阻塞解析</script> - 注意CDN域名DNS查询耗时：某些地区访问jsdelivr可能比本地静态资源还慢，可改用
https://unpkg.com/或自建镜像
HTML模板里埋PerformanceObserver，为什么domInteractive时间不准？
因为PerformanceObserver监听navigation类型时，必须在<head>最开头就注册，晚于第一个<script>就可能漏掉navigationStart前的事件（如DNS查询、TCP连接）。
- 把监控脚本放在
<head>第一行，且用<script async defer>，避免打断HTML parser - 不要依赖
window.performance.timing——它已被标记为deprecated，优先用performance.getEntriesByType('navigation')[0] - 若服务端启用了HTTP/2 Server Push，
responseEnd可能早于fetchStart，此时需用connectStart到requestStart差值估算网络开销
集成第三方监控SDK后，FCP/LCP数据和真实用户对不上
常见原因是SDK注入时机太晚，或未适配服务端渲染（SSR）场景。比如用Express的res.render()返回HTML，但SDK脚本放在</body>底部，此时首屏元素已渲染完毕，指标采集失效。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 确保SDK脚本在
<head>内以<script async>方式加载，并支持immediate: true配置（如Sentry的tracingOrigins） - SSR环境下，前端SDK需识别
window.__INITIAL_PERF__等服务端注入的初始性能快照，否则会丢掉TTFB前的数据 - 避开
document.write()调用——它会清空DOM并重置所有PerformanceEntry，导致LCP计算中断
用sendBeacon上报performance数据，为什么服务端收不到？
sendBeacon()要求目标URL必须是同源或已配置CORS，且请求体只能是ArrayBuffer、Blob、FormData或URLSearchParams。直接传JSON对象会静默失败。
立即学习“前端免费学习笔记（深入）”；
- 上报前必须序列化：
navigator.sendBeacon('/log', new URLSearchParams(performance.getEntriesByType('navigation')[0])) - 避免在
beforeunload里调用——Chrome 80+已限制该事件中大部分API，应改用visibilitychange+document.hidden判断页面是否即将卸载 - 服务端Nginx需配置
client_max_body_size 1m，否则大体积Beacon请求会被截断，日志里只看到413 Request Entity Too Large
bootstrap.bundle.min.js里包含DOMContentLoaded监听器，而你的监控脚本又依赖这个事件触发，这时domInteractive和LCP的因果链就不是线性的了。 
