嵌套过深、script位置不当、首屏内容靠后、内联资源过大是拖慢fcp/lcp的四大主因：dom深度超6层须重构；非关键脚本加defer，操作dom脚本放前；首屏元素前置；内联css/js≤14kb并配resource hint。
嵌套过深直接拖慢首次内容绘制（FCP）
浏览器解析 HTML 是流式、自上而下进行的，每多一层嵌套，就多一次 DOM 节点创建 + 样式匹配 + 布局计算。实测中，<div>
<div><div><div><p></p></div></div></div> 这类结构在低端安卓机上可使 FCP 延迟超 200ms。
<ul>
<li>用 Chrome DevTools → Elements 面板右键任意节点 → <code>Show DOM properties 查看 depth 值，超过 6 层必须重构
<section></section>、<main></main>、<header></header> 替代三层以上 <div> 堆叠的，优先替换——语义标签本身不增加解析开销，还能减少 DOM 节点总数
<li>特别警惕 <code><table> 内嵌套 <code><div>：表格单元格样式计算成本高，嵌套后极易触发同步 Layout，尤其在 flex 容器里混用时
<h3>script 标签位置不当会卡住整个关键渲染路径（CRP）</h3>
<p><code><script></script> 默认同步执行，放在 
- 非关键逻辑（统计、埋点、第三方 SDK）一律加
defer：保证按顺序执行，又不阻塞 HTML 解析 - 纯交互脚本（如按钮绑定）可用
async，但注意它不保序，且可能在DOMContentLoaded前运行；若操作 DOM，大概率报Cannot read property 'addEventListener' of null - 真要操作 DOM 的脚本，必须放
前；别信“DOMContentLoaded比load快”的模糊说法——实测晚 100ms 加载，首屏就晚 100ms
首屏内容位置靠后导致 LCP 指标差
浏览器不会“跳着解析”。关键内容（如主标题、首图、核心表单）如果写在 HTML 底部，哪怕体积再小，也得等前面所有标签解析完才进入 DOM 树，LCP 自然被拉长。
- 把
<h1></h1>、<img fetchpriority="high">、<form></form>等首屏元素尽量前置，哪怕要牺牲一点模板复用性 - 导航栏、广告位这类非首屏内容，可考虑用
loading="lazy"+fetchpriority="low"降权，或拆成<template></template>+ JS 异步插入 - 避免在
里用<script></script>动态插入首屏 DOM——这等于把 CRP 从“HTML 流式解析”退化为“JS 执行后重建”，完全绕开浏览器原生优化
内联资源过大或缺失 resource hint 加剧阻塞
服务器返回的 HTML 如果含大段 <style></style> 或 <script></script>，不仅拉长传输时间（TTFB 变高），还会让浏览器解析器卡在文本扫描阶段，延迟 DOM 构建起点；而关键资源（如字体、首屏图片）没加提示，就只能等 HTML 解析到对应标签才发起请求，白白浪费空闲带宽。
-
<style></style>和<script></script>内联体积建议控制在 14KB 内（HTTP/2 下单个 TCP 包的理想大小），超了反而增加解析开销 - 首屏必用的字体，加
<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin> - 关键 CSS 文件（如 base.css）在
里用<link rel="preload" as="style">，再用<link rel="stylesheet">正常引入 - 绝对不要用
<meta http-equiv="Cache-Control" content="">——Chrome/Firefox/Edge 全忽略它，属于伪配置
defer 却把依赖 DOM 的初始化逻辑留在了 DOMContentLoaded 之后，问题照样会冒出来。
