html嵌套超6层会显著拖慢lcp并恶化fid，因浏览器引擎有硬性开销：深度4→8时getcomputedstyle()耗时翻倍，深度12时低端安卓机单次计算卡顿超80ms；深层dom加剧dom查询延迟，使fid易超100ms阈值。
HTML嵌套深度超6层会拖慢LCP，且直接恶化FID
DOM树深度不是“看起来乱不乱”的问题，而是浏览器引擎的硬性开销。实测显示：深度从4升到8，getComputedStyle()耗时翻倍；深度达12时，低端安卓机单次计算卡顿超80ms——这直接推迟LCP渲染起点，也放大JS执行时的DOM查询延迟，让FID更容易突破100ms阈值。
常见错误现象：body > div > div > div > .item这类选择器在深度10的DOM里查100个节点，总耗时比深度3高3.7倍；更隐蔽的是，for循环中反复读取element.offsetWidth会强制触发同步布局，每一帧都可能掉帧。
- 用Chrome DevTools右键任意节点 → “Show DOM properties”，看
node.depth值，≥6就要重构 - 别靠肉眼数缩进，粘贴这段脚本到控制台快速定位深层节点：
(function walk(node, level = 0) { if(level >= 6) console.log(`深度 ${level}:`, node); for(let child of node.children) walk(child, level + 1); })(document.body); - 用
<section></section>、<article></article>替代无意义<div>嵌套，选择器可从<code>div > div > div p降为article p，匹配路径缩短50%以上里资源顺序错位，LCP会多等300–600ms
浏览器线性解析HTML，
里的标签顺序决定关键资源何时被发现、何时发起请求。一个没as属性的<link rel="preload">，Chrome 101+会直接忽略fetchpriority="high"；而<link rel="stylesheet">写在<link rel="preload" as="image">前面，LCP图片请求就被卡住800ms+常见错误写法：
<link rel="preload" href="font.woff2">缺as="font"+crossorigin→字体加载失败，文本类LCP延迟至fallback渲染；<script></script>动态插入preload→比HTML解析晚至少一个事件循环，错过预扫描器窗口。- 必须第一行：
<meta charset="utf-8"> - 字体预加载必须带
crossorigin：<link rel="preload" as="font" href="font.woff2" type="font/woff2" crossorigin> - LCP图片只preload 1–2个，且
href路径要和最终<img src>完全一致（大小写、斜杠、查询参数都不能差） - 内联
<style></style>必须放在所有外部<link rel="stylesheet">之前，否则即使写了也不会提前生效
首屏
<img>没写width/height，LCP判定会被延迟浏览器预扫描器能在HTML解析第一毫秒发现
src，但若没显式width和height，布局引擎就不知道尺寸，只能预留空白→图片加载完成再重排→触发CLS→LCP必须等布局稳定后才计时，实际延迟常达200–400ms。
anything-to-html下载将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
常见错误现象：
<img>没填src；Vue用v-if条件渲染首屏大图；<picture></picture>里<source></source>的media全不匹配，又没给<img>兜底src。- LCP图片的
<img>标签必须含真实、可访问的src（不能是空字符串或about:blank） - 避免包裹在
<template></template>、<slot></slot>或自定义元素里——预扫描器不深入这些节点 - 如果用
<picture></picture>，至少保证一个<source></source>无media属性，或<img>自身有src作为兜底 -
fetchpriority="high"只对Chrome有效，必须配合<link rel="preload">使用，不能单独依赖
FID恶化常源于深层DOM+同步脚本组合
FID不是JS执行慢的问题，而是主线程被占满后，用户点击事件排队等待的时间。DOM越深，
querySelector、getBoundingClientRect等API调用成本越高；若此时还有未加defer的脚本同步执行，FID就极易突破100ms。常见错误场景：SSR输出的HTML里，
<script src="vendor.js"></script>仍放在里，默认同步加载，浏览器停住HTML解析→DOM构建延后→首屏按钮绑定延迟→用户点下时主线程还在下载JS。- 非关键脚本（统计、监控、第三方SDK）必须加
defer：保序且不阻塞解析 - 纯交互逻辑（如按钮绑定）可用
async，但注意它不保序，且可能在DOMContentLoaded前运行；若操作DOM，大概率报Cannot read property 'addEventListener' of null - 真要操作首屏DOM的脚本（比如初始化轮播），放
末尾或开头，别信“DOMContentLoaded比load快”的模糊说法 - SSR/SSG生成的HTML若含
data-reactroot或_next标记，需确认其父容器是否无意中加深了嵌套层级
最易被忽略的点：LCP和FID恶化往往不是单一原因，而是结构深度+资源顺序+脚本加载三者叠加。比如一个深度8的DOM，配上没
as的preload和同步执行的统计脚本，LCP可能多等1.2秒，FID轻松破200ms——这种组合问题在DevTools里不会直接标红，得靠node.depth、Network面板请求时序、Performance录制三者交叉验证。 - 必须第一行：
