HTML渲染慢主因是结构冗余和CSS加载顺序不当，关键渲染路径卡在DOM构建与CSSOM合成；<link>放<head>会因CSS阻塞渲染致白屏，内联关键CSS并延迟非关键样式可显著提速。
HTML 渲染慢，八成不是 JS 写得差，而是结构写得“太老实”、CSS 加得太“太晚”。关键渲染路径（CRP）卡在 DOM 构建和 CSSOM 合成上，改结构和调顺序比压代码体积见效更快。
为什么 <link rel="stylesheet"> 放 <head> 里会白屏
CSS 是渲染阻塞资源：浏览器必须等所有已声明的 CSSOM 构建完成，才能生成渲染树并绘制首屏。哪怕只有一行 <link href="main.css" rel="stylesheet"> 在 <head>，而该 CSS 文件加载慢或服务器响应延迟，整个页面就停在白屏——DOM 可能已解析完，但浏览器死等 CSSOM。
- 同步
<script>会阻塞 HTML 解析，但 CSS 阻塞的是渲染（paint），更隐蔽也更致命 -
<link>不加media属性时，默认为all，即无论屏幕尺寸都参与当前渲染树构建 - 用
@import在 CSS 文件中引入其他样式表，等于嵌套同步请求，会额外增加网络往返，务必替换为<link>
如何内联关键 CSS 而不破坏可维护性
内联（inline）关键 CSS 是缩短 CRP 最直接的手段，但不能把整个 main.css 塞进 <style> 标签——那会让 HTML 体积暴涨、无法缓存、难以调试。
- 只提取“首屏可见区域”所需的最小样式集，例如 header、hero、首屏按钮、字体定义等，通常控制在 10–15KB 内
- 用工具自动化提取：Webpack 的
critters插件、Vite 的vite-plugin-critical，或 CLI 工具penthouse+ Puppeteer 截图分析 - 保留外部 CSS 文件用于非关键样式，并用
media属性延迟加载：<link href="non-critical.css" rel="stylesheet" media="print" onload="this.media='all'">
DOM 结构扁平化对布局性能的真实影响
深层嵌套本身不直接拖慢解析，但它放大了 CSS 选择器匹配开销、增加了重排计算复杂度，尤其当父元素尺寸变化时，子树重排成本呈指数上升。
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
- 避免无意义包裹：比如
<div><div><div><p>Text</p></div></div></div>，语义化标签如<article>或<section>更轻量且自带隐式样式边界 - Flexbox/Grid 布局替代浮动+绝对定位组合，减少对
position: relative和z-index的依赖，降低层叠上下文创建频次 - DOM 节点数超 1500 时，
getComputedStyle()或offsetHeight等读操作延迟明显上升；虚拟滚动不是“锦上添花”，而是列表页的底线要求
为什么 defer 脚本仍可能拖慢首屏渲染
defer 确保脚本不阻塞 HTML 解析，但它仍需等待 DOM 解析完成才执行——如果脚本里有 document.querySelector('.hero') 并立即修改其 style.width，就会触发强制同步布局（Forced Synchronous Layout），打断渲染流水线。
- 真正安全的脚本应避开所有布局读取操作，或把读/写分离：先批量读取（
el.getBoundingClientRect()），再统一写入（el.style.transform = 'translateX(10px)'） - 动画逻辑优先用 CSS
@keyframes+transform/opacity，JS 只负责开关类名，不触发布局属性 - 第三方 SDK（如埋点、广告）默认使用
async，并确保其初始化逻辑不依赖首屏 DOM 尺寸计算
最容易被忽略的点是：CSS 关键路径优化不是“加个 preload 就完事”，而是要确认内联部分是否真被浏览器当作“关键”处理——DevTools 的 Performance 面板里看 Parse HTML 和 Recalculate Style 是否仍有长任务，以及 Rendering 面板是否开启 Paint flashing 来验证首屏区域是否真的在第一时间绘制出来。
