<details>不会加速首屏渲染，反而可能拖慢FCP 60–110ms；因其默认仍完整解析、样式计算与布局，仅视觉折叠，须配合content-visibility: auto与contain-intrinsic-size才可能优化，且仅限Chrome 108+/Edge 109+。
<details> 不会加速首屏渲染，反而可能拖慢——除非你用对了触发时机和配套策略。
为什么直接加 <details> 反而让 FCP 变慢
浏览器解析到 <details> 时，仍会完整构建其内部 DOM 节点、计算样式、生成布局树。它只是默认折叠（open 属性未设），但内容并未跳过解析或渲染流程。实测显示，在含 50+ 行代码块的 <details> 中，FCP 延迟可达 60–110ms（低端安卓 WebView）。
常见错误现象：
- 把整段 Markdown 预览或 API 文档塞进
<details>，以为“不展开就不渲染” - 嵌套在
<section>或<article>内部多层使用，叠加 DOM 深度 - 子元素含
position: absolute或transform，导致浏览器为每个<details>生成独立包含块
<details> 真正起效的两个前提
它只在「内容可延迟呈现 + 浏览器能跳过绘制」时才优化首屏。必须同时满足：
立即学习“前端免费学习笔记（深入）”；
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 内部内容不参与首屏 LCP 计算：比如不是 Hero 图、主标题、核心按钮等关键元素
- 配合
content-visibility: auto+ 动态contain-intrinsic-size（仅限 Chrome 108+、Edge 109+）
示例写法：
<details>
<summary>点击查看技术细节</summary>
<div class="details-content" style="content-visibility: auto; contain-intrinsic-size: 200px;">
<pre><code>...大段代码...</code></pre>
</div>
</details>
注意：contain-intrinsic-size 必须是预估高度，不能写 auto 或留空；否则 content-visibility 静默失效。
比 <details> 更适合首屏优化的替代方案
如果你的目标是降低首屏 DOM 节点数和样式计算量，以下方式更可控：
- 非首屏内容改用
<template>+ JS 懒实例化：DOM 完全不创建，直到用户交互 - 长文本区块用
display: none+ IntersectionObserver 触发渲染：兼容性更好，且可精确控制加载时机 - 服务端做条件渲染：SSR 阶段直接不输出折叠区 HTML，比任何客户端方案都快
尤其注意：<details> 在 SSR 渲染中若未加 open，服务端仍会吐出全部子节点 HTML——这和你想“省流量”的直觉相反。
真正容易被忽略的点：光有 <details> 标签毫无性能价值；它的优化潜力完全取决于是否切断了「解析→样式→布局→绘制」链条中的后半段，而这需要你手动补上 content-visibility 和尺寸契约，且接受 Safari 等浏览器不支持该组合的事实。
