html性能优化核心是避免解析阻塞和优化加载顺序：script应放body底部或用async/defer属性；关键css需内联，非关键css延迟加载；preload仅用于立即需要的资源；图片懒加载必须设width/height防布局偏移。
HTML 本身不慢，慢的是它触发的阻塞和加载顺序。优化不是压缩几个空格，而是让浏览器在解析 HTML 的每一毫秒都干对的事。
script 标签放哪儿、加什么属性才不白屏
浏览器遇到 <script src="app.js"></script> 会立刻暂停 HTML 解析，等 JS 下载并执行完才继续——首屏白屏就从这儿开始。
-
async：适合无依赖脚本（如analytics.js），下载不阻塞，但执行时机不可控，可能早于 DOM 就绪 -
defer：更适合业务逻辑 JS，下载不阻塞，执行在 DOM 解析完成后、DOMContentLoaded前，且严格按书写顺序 - 别把
<script></script>放在里又不加属性——这是最常见白屏原因 - 禁用
document.write()：现代浏览器已废弃，执行即清空文档流，本地测试尤其敏感
关键 CSS 怎么内联、非关键 CSS 怎么延迟
外部 <link rel="stylesheet"> 默认渲染阻塞：浏览器必须构建完 CSSOM 才能画第一帧。首屏样式若全靠 main.css，FCP 必然延迟。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 把首屏必需的 CSS 提取出来，内联进
<style></style>，控制在 2–3KB 内；别塞 base64 大图 - 非首屏 CSS 用
<link rel="stylesheet" media="print" onload="this.media='all'">延迟加载 - 或直接用
media属性做条件加载，比如media="(min-width: 768px)" - 绝对别在 CSS 文件里写
@import引入关键样式——它串行加载，实测拖慢 FCP 300ms+
preload 该加在哪、怎么写才真正加速
<link rel="preload"> 不是“越多越好”，它是高优先级提示，写错反而抢带宽、挤掉 HTML 或关键 CSS。
- 只对当前导航「立刻要用」的资源用：
<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>（crossorigin必加，否则字体不生效） - 首屏 Hero 图可 preload，但别对所有
<img loading="lazy">都加——浏览器可能先加载src，再触发懒加载，造成重复请求 - 别用 preload 加 JS 入口文件（如
main.js）——它本身已被defer覆盖，再 preload 属于冗余调度 - 验证是否生效：Chrome DevTools → Network 面板，看预加载资源的
Priority是否为high
loading="lazy" 对图片和 iframe 的兼容性陷阱
原生 loading="lazy" 看似简单，但只对 <img> 和 <iframe></iframe> 生效，且有明确限制。
- 必须显式设置
width和height属性，否则懒加载会引发布局偏移（CLS），Core Web Vitals 直接扣分 - Safari 15.4+ 才支持
loading="lazy"对<iframe></iframe>的支持，旧版需回退到data-src+ JS 方案 - 不支持背景图、
image-set()、CSS@font-face中的字体——这些还得靠IntersectionObserver手动实现 - 首屏大图千万别加
loading="lazy"，它可能被当成“非关键资源”延迟加载，导致首屏空白
最容易被忽略的点：HTML 解析本身是单线程的，任何同步行为（比如没加 defer 的脚本、含复杂选择器的内联 <style></style>、甚至一个错位的 @import）都会卡住整个流程。别只盯着体积，先看 Network 面板的 waterfall 时间线——哪里停住了，那里就是瓶颈。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
