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:
块放,只含body、.hero、.nav等首屏可见规则,体积压到 10KB 内 - 异步加载剩余 CSS:
,利用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 不是性能优化手段,而是风险点
自定义元素标签(如 )在未定义时只是“未知元素”,但大量集中出现会加重样式计算与布局压力;若定义太早(如 里注册),升级过程会打乱渲染流水线。
- 所有
customElements.define()必须放在前,且加defer(外链)或包裹在DOMContentLoaded里(内联) - 非首屏区域的自定义元素(如分页后列表),用
IntersectionObserver监听进入视口后再定义/升级 - 内容简单(如图标、徽标)优先用纯 HTML + CSS,别为封装而封装——自定义元素的初始化成本远高于收益
真正卡顿往往藏在你看不见的地方:批量 DOM 操作未节流、getBoundingClientRect() 强制同步回流、DevTools 开着时 console.log(div) 深度遍历子树。优化前先录一段 Performance 面板,看主线程瓶颈在哪段代码,比盲目加 async 有用得多。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!










