必须将脚本移出head或添加async/defer属性，控制DOM嵌套深度不超过4层，图片需声明width/height属性，表格布局应避免或设table-layout:fixed。
避免 script 在
浏览器一遇到没加修饰的 <script src="xxx"></script>，立刻暂停 HTML 解析，等 JS 下载、编译、执行完才继续。哪怕只是 <script>console.log(1)</script> 放在 里，也会卡住整个 DOM 构建流程，首屏白屏时间直接拉长。
必须根据用途选对加载方式：
- 第三方统计、广告等独立脚本：加
async - 依赖 DOM 结构（比如操作
document.getElementById）或需按序执行的脚本：加defer - 现代模块化代码：用
type="module"，天然具备defer行为，且支持静态分析和预加载
内联脚本（<script>...</script>）永远阻塞，除非你确认它只做极轻量初始化（如设置 window.__INIT__）。
控制 DOM 嵌套深度，别让浏览器反复匹配标签闭合
嵌套超过 4 层（比如 <div><div><div><div>
<p>）会让解析器在内存中维持更长的打开标签栈，匹配结束标签的成本线性上升。深层嵌套还常伴随冗余定位（<code>position: relative 叠加）、强制重排（getBoundingClientRect() 触发同步布局）等问题。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 用语义标签替代无意义
<div> 堆叠：<code><main></main>、<section></section>、<article></article>浏览器能跳过部分继承链判断 - Flexbox/Grid 能单层搞定的布局，别用三层
<div class="wrapper"><div class="inner"><div class="content"> <li>Chrome DevTools 的 “Layers” 面板里如果看到大量小尺寸重叠合成层，大概率是嵌套+定位滥用导致</li> <h3>图片必须声明 <code>width和height，防布局抖动引发重排loading="lazy"只控制下载时机，不解决渲染时的空间预留问题。如果<img alt="HTML怎么配置核心渲染标签降低性能峰值" >没设尺寸，浏览器无法预估占位区域，图片加载完成瞬间会挤开下方内容，触发整块区域重排——文字上跳、按钮位移都是典型表现。正确做法：
- 显式写
width和height属性（注意：是 HTML 属性，不是 CSS） - 响应式场景可用 CSS
aspect-ratio替代，但得查兼容性（Safari 15.4+、Chrome 88+） - 服务端渲染或 SSR 场景下，务必在生成 HTML 时注入原始宽高，别留到 JS 运行时再补
禁用表格布局，
<table> 是隐式重排放大器 <p>表格渲染需要两遍计算：先确定列宽（依赖所有单元格内容），再布局行高。只要任一单元格内容变化（比如字体加载完成、动态插入文本），整个表格就可能触发强制重排。这不是“慢”，而是“不可预测的峰值”——尤其在移动端弱网或低端设备上，一次表格重排可能卡顿 200ms 以上。</p> <p>替代方案很明确：</p> <ul><li>纯展示型表格仍可用 <code><table>，但必须加 <code>border-collapse: collapse和固定列宽（table-layout: fixed） - 显式写
- 任何带交互、动态数据、响应式需求的“类表格”布局，一律用
display: grid或display: flex - 已有老项目表格难以替换？至少给
<table> 加 <code>style="table-layout: fixed; width: 100%"，并为第一行<th> 或 <code><col>显式设宽真正难优化的从来不是单个标签，而是它们组合后触发的隐式行为——比如一个没设宽高的图片 + 一个表格 + 一段放在
的同步脚本，三者叠加会让重排从偶发变成常态。盯住浏览器 DevTools 的 “Rendering” 面板，把 layout 强制触发次数压到最低，比堆技巧更管用。
