关键渲染路径本质是资源阻塞位置不当：link[rel="stylesheet"]和同步script会中断HTML解析与绘制，导致首屏白屏，即使DOMContentLoaded很快，因CSSOM未就绪无法生成渲染树，真正影响可视内容的是FCP。
关键渲染路径不是“慢”，而是“卡在错的位置”——link[rel="stylesheet"] 和同步 script 标签会直接中断 HTML 解析和页面绘制，哪怕 DOM 已就绪，用户仍看到白屏。
为什么首屏白屏久但 DOMContentLoaded 很快？
因为浏览器必须等 CSSOM 构建完成，才能和 DOM 合成渲染树；而一个未加修饰的 <link rel="stylesheet"> 会阻塞后续所有渲染步骤。即使 Network 面板显示 CSS 已加载完毕，若它没被标记为“非关键”，解析器仍会等待其 CSSOM 就绪才继续。
-
DOMContentLoaded只表示 DOM 树构建完成，不保证样式或脚本已就绪 - 真正影响“肉眼可见内容”的是
First Contentful Paint (FCP)，它依赖渲染树生成 - 用 Chrome DevTools 的 Performance 面板录制，重点关注
Parse HTML → Recalculate Style是否出现长空白段
如何识别哪些 CSS/JS 属于“关键”资源？
关键资源 = 首屏渲染必需的最小 CSS + 初始化首屏交互必需的 JS。不能靠猜测，得看实际加载链路：
- 打开 Network 面板，筛选
css和js，看 Initiator 列：若显示parser，说明是 HTML 解析时同步拉取，大概率是关键资源 - 检查 CSS 文件是否包含
body、header、.hero、.card等首屏元素的选择器；含@import或大量media="(min-width: 1024px)"的通常不是 - JS 若只用于轮播图初始化、表单校验或埋点，且不参与首屏结构生成，就不是关键 JS
内联关键 CSS 与异步加载非关键 CSS 的实操要点
内联不是把整个 main.css 塞进 <head>，而是提取出真正影响首屏的规则（通常 2–5 KB）；非关键部分要拆离并异步注入，否则仍会阻塞。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
- 用工具如
PurgeCSS或手动生成 critical CSS，输出为<style>...</style>直接插入<head> - 非关键 CSS 推荐用
<link rel="preload" as="style" onload="this.rel='stylesheet'">，配合<noscript><link rel="stylesheet"></noscript>保底 - 避免在内联
<style>中写@import—— 它会触发同步网络请求，立刻退化为外部阻塞加载 - 如果用了 Webpack/Vite，可通过插件（如
critical或vite-plugin-critical-css）自动提取，但需验证输出是否真覆盖首屏
JS 加载策略选 defer 还是 async？
二者都解除对 HTML 解析的阻塞，但执行时机不同，选错会导致 JS 找不到 DOM 节点或样式未就绪。
-
defer：脚本按顺序下载，等 DOM 解析完、DOMContentLoaded前执行 —— 适合依赖 DOM 结构或需顺序执行的 JS（如初始化 Vue 实例、处理导航栏） -
async：脚本一下载完立刻执行，不保证顺序 —— 适合完全独立、无依赖的 JS（如统计脚本、客服浮窗） - 绝对不要在
<head>放同步<script src="..."></script>，尤其当它位于<link rel="stylesheet">之前时，会强制暂停 CSS 加载 - 现代项目中，
type="module"脚本默认行为类似defer，但注意旧浏览器兼容性
最易被忽略的一点：优化后必须验证 FCP 和 LCP 数值，而不是只看 DOMContentLoaded。很多项目把 JS 改成 defer 就以为万事大吉，却没动 CSS 加载逻辑——结果白屏时间毫无改善，因为瓶颈仍在 CSSOM 构建阶段。
