html 嵌套过深、script 位置不当、内联资源过大、缺少 resource hint 是首屏渲染卡顿的四大主因，需分别通过简化结构、调整脚本加载策略、外链资源、预加载关键资产来优化。
HTML 标签嵌套过深会拖慢渲染速度
浏览器解析 HTML 是自上而下流式进行的，每多一层嵌套，就多一次 DOM 树节点创建和样式计算。尤其在移动端或低端设备上，<div><div><div><div> <p> 这种结构会让首次内容绘制（FCP）明显延迟。</p> <p> 实操建议：</p> <p><span> 立即学习 </span>“<a href="https://pan.quark.cn/s/cb6835dc7db1" style="text-decoration: underline !important; color: blue; font-weight: bolder;" rel="nofollow" target="_blank"> 前端免费学习笔记（深入）</a>”；</p> <ul> <li> 用 <code>devtools → Elements → 右键节点 →“Show DOM properties”查深度，超过 6 层就要警惕
<section></section>、<article></article> 语义化标签替代<div> 堆叠的，优先替换——它们本身不增加渲染开销，还利于 CSS 选择器简化 <li> 避免在 <code><table> 里套 <code><div> 再套 <code><span></span>：表格单元格内样式计算成本高，嵌套后易触发重排script 标签位置不当导致阻塞关键渲染路径
<script></script>默认同步加载执行，放在 或顶部时，浏览器必须暂停 HTML 解析、下载并执行完脚本，才能继续构建 DOM 树。这是首屏白屏最常见的原因。
实操建议：
立即学习 “ 前端免费学习笔记（深入）”；
- 非必要逻辑（如统计、埋点、第三方 SDK）一律加
defer属性，确保按顺序执行但不阻塞解析 - 纯交互逻辑（如按钮点击事件绑定）用
async，但注意它不保证执行顺序，且可能在 DOM 未就绪时运行 - 真需要操作 DOM 的脚本，放
前——别信“DOMContentLoaded 比 load 快”的模糊说法，实测中晚 100ms 加载，首屏渲染就晚 100ms
内联 CSS 和 JS 体积过大影响 TTFB 和解析耗时
服务器返回的 HTML 文件本身如果含大段 <style></style> 或<script></script>，不仅拉长传输时间（TTFB 变高），还会让浏览器解析器卡在文本扫描阶段，延迟 DOM 构建起点。
实操建议：
立即学习 “ 前端免费学习笔记（深入）”；
- 单个
<style></style>块超过 1KB，就该拆成外部<link rel="stylesheet">；CSS-in-JS 生成的内联样式同理 -
<script></script>内联代码超 50 行，基本可判定为维护风险 + 性能隐患，应提取为模块文件 - 用
curl -I看响应头Content-Length，HTML 体大于 15KB 时，要重点检查内联资源占比
缺少 resource hint 导致关键资源加载滞后
浏览器默认只对 HTML 中直接出现的链接做预加载，像字体、关键 CSS、首屏图片这些依赖关系隐含的资源，不加提示就只能等 HTML 解析到对应标签才发起请求，白白浪费空闲带宽。
实操建议：
立即学习 “ 前端免费学习笔记（深入）”；
- 首屏必用的字体，加
<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin> - 关键 CSS 文件（如
base.css）在里用<link rel="preload" as="style">，再用<link rel="stylesheet">正常引入 - 避免滥用
prefetch：它适用于用户下一步大概率访问的资源（如分页第二页的 JS），不是首屏内容，否则会挤占关键资源带宽
真正卡顿的地方，往往不在你写的 JavaScript 里，而在 HTML 被浏览器读到第一行开始的那几百毫秒——结构松散、加载顺序错位、资源提示缺失，这些细节一旦固化进模板，后续优化成本远高于初期约束。
