首屏白屏久但 DOMContentLoaded 很快触发，是因为浏览器渲染需等待关键 CSSOM 构建、渲染树合成、布局和绘制完成，而 DOM 解析不受阻塞；典型表现为 Performance 面板中 Parse HTML 后卡在 Recalculate Style，Network 面板里 main.css 的 Initiator 为 parser 且耗时 >200ms。
为什么首屏白屏久但 DOMContentLoaded 很快就触发了
因为浏览器渲染不只等 DOM 构建完成——它还得等关键 CSSOM 构建、渲染树合成、布局和绘制。DOM 就绪 ≠ 页面可见。典型表现是 Performance 面板里 Parse HTML 后卡在 Recalculate Style，Network 面板中 main.css 的 Initiator 显示为 parser，且耗时 >200ms。
根本原因不是“慢”，而是“卡在错的位置”：<link rel="stylesheet"> 和同步 <script></script> 会中断 HTML 解析与绘制，哪怕 DOM 已生成，用户仍看到白屏。
- 即使 CSS 文件本地缓存命中，仍会触发一次微小但确定的阻塞（需验证响应头、解析内容）
- 多个
<link>串行加载时，第二份 CSS 的下载要等第一份 CSSOM 构建完才开始 -
@import强制串行加载，实测拖慢 FCP 300ms+，绝对不能用于关键样式
怎么内联首屏关键 CSS 才不翻车
内联不是把整站 CSS 塞进 <style></style>，而是只提取真正用于首屏像素生成的最小规则集，比如 .hero-title、.cta-button、导航栏固定高度等。手写极易漏掉伪类（.btn:hover）、媒体查询断点（@media (max-width: 768px)）或动态 class（is-loading）。
- 体积建议控制在 14KB 内（HTTP/2 单个 TCP 包的理想大小），超了反而增加 HTML 主文档解析开销
- Vite 用户配
vite-plugin-critical，build 时自动生成并注入；Webpack 项目用mini-css-extract-plugin分离出critical.css，再通过html-webpack-plugin注入 - 避免在
中写<link rel="stylesheet">，这会导致解析器反复回退重排
非关键 CSS 和 JS 怎么延迟加载又不破坏功能
非首屏 CSS 不能删，否则响应式断点、暗色模式等逻辑失效；JS 也不能简单移走，否则交互异常。关键是让浏览器先跳过加载，等首屏稳定后再触发。
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
立即学习“前端免费学习笔记（深入）”；
- CSS 推荐用
<link rel="stylesheet" href="non-critical.css" media="print" onload="this.media='all'">：浏览器默认不加载 print 样式，onload 触发后才切换 media，避免 FOUC - 更稳妥的做法是
DOMContentLoaded后动态插入：link.rel = 'stylesheet'，确保 DOM 就绪后再加载 - JS 必须放
的，加defer（保持顺序，不阻塞解析）；独立统计脚本如tracker.js用async（无序执行，适合上报） - 别对
logo.svg用prefetch——它是首屏关键图像，应内联或<link rel="preload" as="image">
怎么验证你的优化真起作用了
别只看 Lighthouse 分数或 DOMContentLoaded 时间戳——它只代表 DOM 就绪，不代表页面可交互或已绘制。真正要盯的是 Performance 面板里的 First Paint 和 First Contentful Paint 是否被脚本执行或 CSS 加载卡住。
- 打开 Chrome DevTools → Performance 面板 → 录制一次页面加载，重点看 Parse HTML 后是否被 Recalculate Style 或 Layout 长时间挂起
- 切到 Network 面板，筛选
css和js，看 Initiator 列：如果是parser，说明该资源是在 HTML 解析中途被同步拉取的，就是关键阻塞点 - Coverage 面板能真实反映 CSS 实际使用率，但注意它只抓当前视口，需结合移动端模拟和滚动行为多次采样
复杂点在于：内联 CSS 控制不好体积会拖慢 TTFB，异步加载时机不对会引发 FOUC 或布局抖动，而 parser 触发的请求一旦存在，就无法靠 CDN 或压缩绕过——它卡的是浏览器解析行为本身，不是网络速度。
