HTML标签本身不加载，所谓“标签加载延迟”实为浏览器解析DOM、触发资源请求或执行逻辑时被卡住，根源在script阻塞、CSS渲染阻塞、img尺寸未约束引发回流或自定义元素过早定义。
HTML 标签本身不“加载”，所谓“标签加载延迟”其实是浏览器在解析、构建 DOM、触发资源请求或执行关联逻辑时被卡住——根源在 script 阻塞、link[rel="stylesheet"] 渲染阻塞、img 未约束尺寸引发回流，或自定义元素过早定义。解决它不靠“加速标签”，而靠切断阻塞链、控制资源调度时机。
为什么 script 放
浏览器解析 HTML 遇到无修饰的 <script src="app.js"></script>，会立刻暂停 DOM 构建，下载、解析、执行完 JS 才继续——哪怕它只用来初始化轮播图，也会拖垮首屏渲染。
- 同步脚本必须移出
：最稳妥是塞到前；若必须在 head，加defer（保证顺序、DOM 解析完执行）或async（无依赖第三方脚本，如统计） - 绝对禁用
document.write()：现代浏览器中它直接清空文档流，本地双击打开 HTML 时尤其致命 - 内联脚本（
<script>...</script>）若超过 1KB，建议外提并压缩；否则会延长 HTML 下载和解析时间
link[rel="stylesheet"] 怎么避免阻塞首屏渲染
CSS 是 render-blocking 资源，浏览器必须等所有 link[rel="stylesheet"] 下载并解析完才开始绘制——哪怕样式表在 最末尾，也拦着整个页面。
- 内联首屏关键 CSS：
<style></style>块放，只含body、.hero、.nav等首屏可见规则，体积压到 10KB 内 - 异步加载剩余 CSS：
<link rel="stylesheet" href="app.css" media="print" onload="this.media='all'">，利用media="print"让浏览器不阻塞，加载完再切回all - 严禁在 CSS 文件里用
@import：它串行加载、无法预加载、实测拖慢 FCP 300ms+
img 和 iframe 的“延迟感”不是加载慢，是调度错
img 默认不阻塞解析，但没设 width/height 会触发布局偏移（CLS）；iframe 则一加载就拉起完整子页面环境，资源全量并发请求，极易卡主线程。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
-
img必须显式声明尺寸：用width/height或aspect-ratio预留空间，避免加载后重排 - 首屏图禁用
loading="lazy"：banner、logo、Hero 图写上就是错的，可能被延迟加载导致白块 -
iframe按需加载：首次只加载当前页，其他页用隐藏iframe预加载，切换时复用已缓存实例，而非反复src赋值 - 第三方
iframe（如地图、客服）加sandbox并限制权限，避免其脚本抢占主线程
Custom Elements 不是性能优化手段，而是风险点
自定义元素标签（如 <product-card></product-card>）在未定义时只是“未知元素”，但大量集中出现会加重样式计算与布局压力；若定义太早（如 里注册），升级过程会打乱渲染流水线。
- 所有
customElements.define()必须放在前，且加defer（外链）或包裹在DOMContentLoaded里（内联） - 非首屏区域的自定义元素（如分页后列表），用
IntersectionObserver监听进入视口后再定义/升级 - 内容简单（如图标、徽标）优先用纯 HTML + CSS，别为封装而封装——自定义元素的初始化成本远高于收益
真正卡顿往往藏在你看不见的地方：批量 DOM 操作未节流、getBoundingClientRect() 强制同步回流、DevTools 开着时 console.log(div) 深度遍历子树。优化前先录一段 Performance 面板，看主线程瓶颈在哪段代码，比盲目加 async 有用得多。
