商品详情页卡顿主因是HTML结构过深、CSS选择器冗余及图片加载策略不当：DOM嵌套超3层易致解析中断，CSS层级应≤3并禁用通配符，关键图禁用lazy，第三方脚本须异步沙盒化。
商品详情页卡顿，90% 以上不是 JS 写得烂，而是 HTML 结构、CSS 加载时机和图片加载策略在拖后腿——尤其当页面含 4800+ DOM 节点、15 张未压缩图、5 层嵌套结构时，浏览器解析阶段就已濒临熔断。
DOM 嵌套超 3 层直接触发解析中断
移动端 WebView 和低端安卓设备对嵌套深度极其敏感。Chrome 解析器在遇到 <div><div><div><div><div><table><tr><td> 这类结构时，会因内存压力主动截断后续标签，导致首屏内容缺失或白屏。<ul>
<li>用 DevTools → Elements 面板右键任意节点 → <code>Show DOM properties 查看 childNodes.length 和实际嵌套层级，超过 6 层必须重构
<td> 内嵌套 <code><div> 或 <code><section></section>，改用语义化平铺结构：<h2 class="product-title"></h2> 替代 <div class="info"><div class="title-wrapper">
<h1></h1>
<li>
<code><template></template> 包裹非首屏区块（如“用户评价”“相关推荐”），用 IntersectionObserver 动态克隆插入，避免初始解析负担CSS 选择器层级 >3 或含通配符引发强制同步布局
像 .product .detail .content .image .caption 这种 5 层选择器，每次滚动或样式变更都会触发全量重排；*[class^="product-"] 更是让浏览器遍历全部节点，主线程瞬间卡死。
- 所有 CSS 规则层级严格 ≤3，优先用 BEM 命名：
.product-image而非.product .image - 移除所有通配符选择器（
*、[attr]类模糊匹配），用显式类名替代 - 用 Chrome Performance 面板录制滚动过程，若看到大量
Layout任务且耗时 >16ms，大概率是选择器问题
图片懒加载写错反而放大 CLS 和卡顿
loading="lazy" 在 Safari 15.4 以下和旧版安卓 WebView 中完全无效；同时设 src 和 loading="lazy" 可能触发重复请求；没设 width/height 则加载时重排，CLS 直接爆表。
立即学习“前端免费学习笔记（深入）”；
- 首屏 Hero 图、轮播第一张、价格按钮图标等关键资源，必须禁用
loading="lazy"，用真实src - 非首屏图统一用
data-src+IntersectionObserver，并显式声明width和height（可用aspect-ratio配合） - WebP/AVIF 格式替换 JPEG：服务端按
Accept头返回对应格式，CDN 开启自动转换，单图体积可降 60%
第三方脚本未沙盒化抢占主线程
7 个同步加载的统计、AB 测试、客服 SDK，每个平均占用主线程 120ms，叠加后 TTI（可交互时间）直接飙到 5.6s。它们不是“等页面空闲再执行”，而是抢在 DOMContentLoaded 前就开干。
- 所有第三方脚本必须用
async，且通过fetch()+eval()动态注入，禁止硬编码在 HTML 中 - 对有依赖关系的 SDK（如 A/B 测试需先加载实验配置），用
requestIdleCallback(() => { /* load */ })延后至空闲帧执行 - 用
<iframe sandbox="allow-scripts"></iframe>封装高风险脚本，隔离其 DOM 访问和事件监听能力
真正卡住详情页的，从来不是“要不要加虚拟滚动”，而是 HTML 是否能在 1 秒内完成解析、CSS 是否在首屏渲染前就位、图片是否在进入视口前 200px 就已开始加载——这些细节不抠清楚，再 fancy 的 JS 框架也救不了卡顿。
