<details>标签不能优化首屏加载速度，因其仅控制视觉折叠，不干预资源加载时机；浏览器解析到img标签即发起请求，与是否在<details>内无关。
标签本身**不能优化首屏加载速度**。它只是视觉折叠控件，对资源加载时机零干预。
浏览器解析到
<img src="a.jpg"> 就会发起请求，不管它是否在 <details> 里、是否折叠、是否加了 style="display:none" —— 这是 DOM 解析阶段的默认行为，无法绕过。
真正影响首屏性能的是：DOM 体积、JS 执行阻塞、图片/脚本等资源是否被提前拉取。而 <details> 包裹大段 HTML 或图片，反而可能让问题更隐蔽。
为什么 details 不减少首屏资源请求？
常见错误现象：<details><summary>点我展开</summary><img src="big-banner.jpg"></details> 页面一打开，big-banner.jpg 就已发出请求，LCP 被拖慢，但开发者误以为“折叠了就等于没加载”。
根本原因：
-
<details>不改变资源加载优先级，也不阻止浏览器预加载器（preload scanner）扫描并抓取src、href等属性 - 折叠状态由
open属性和 CSS 控制，与资源调度无关 - 内部的
<script>仍会同步执行（除非加defer或async），可能卡住主线程
想让 details 里的图片真懒加载，必须手动接管
核心思路：用 data-src 替代 src，监听 toggle 事件，在用户点击展开时才赋值。
实操要点：
立即学习“前端免费学习笔记（深入）”；
- 把
<img src="a.jpg">改成<img alt="...">，初始不设src - 给
<details>加 class，如<details class="lazy-details"> - 监听
toggle事件：details.addEventListener('toggle', () => { if (details.open) { img.src = img.dataset.src; } }); - 若
<details open>默认展开，需在页面加载后立即执行一次赋值逻辑 - 避免重复触发：赋值前加
if (!img.src)判断
比 toggle 更顺滑的方案：用 IntersectionObserver 预加载
用户还没点开，但 <details> 已滚动进视口附近时就预加载内容，体验更自然。适合 FAQ、长文档折叠章节等场景。
关键配置：
- 用
rootMargin: '100px'提前触发，避免用户点开瞬间白屏或等待 - 观察目标是
<details>元素本身，不是里面的<img> - 首次进入视口后调用一次加载函数，然后
unobserve()防止重复执行 - Safari 12.1 之前不支持
toggle事件，但 IntersectionObserver 支持从 Safari 12.2 开始，兼容性略好
真正提升首屏速度，得换思路
单纯依赖 <details> 是错把“视觉隐藏”当成“资源隔离”。更有效的做法是：
- 非首屏区块改用
fetch()动态加载 HTML 片段，再注入到<details>内部 —— 这样初始 HTML 体积小，且资源完全按需拉取 - 服务端返回的片段必须纯净：不含
<html>、<body>，只返回<div>...</div>类结构 - 注入后若含
<script>，需手动创建并执行，innerHTML不会自动运行脚本 - 首屏关键图坚决不用
loading="lazy"，且必须带width和height，否则 CLS 和 LCP 都会恶化
toggle 兼容性处理不到位、默认展开逻辑遗漏，任何一个点出问题，都会导致图片不加载、重复加载或首屏变慢。不如一开始就明确：折叠归折叠，加载归加载，两者必须解耦控制。
