首屏加载慢主因是HTML解析阻塞和关键资源加载顺序不当；应内联首屏CSS、用defer加载JS、精准preload关键资源，并禁用@import和document.write。
首屏加载慢，八成卡在 HTML 解析和关键资源加载顺序上。不是 JS 太多，而是浏览器被你写的 <link rel="stylesheet"> 和 <script> 拖住了——它得等 CSSOM 构建完才能开始渲染，得等 JS 执行完才能继续解析 HTML。
怎么让关键 CSS 不阻塞首屏渲染
外部 CSS 默认是渲染阻塞的：浏览器必须下载、解析、构建 CSSOM 后，才肯画第一帧。首屏样式若全靠 main.css，FCP 就注定延迟。
- 把首屏用到的 CSS 提取出来，内联进
<head>的<style>标签里，不发请求、不等待 - 非首屏 CSS 用
<link rel="stylesheet" media="print" onload="this.media='all'">延迟加载，或配合media属性做条件加载（如media="(min-width: 768px)"） - 绝对别在
@import里引入关键 CSS —— 它会串行阻塞，比<link>多一次网络往返，实测拖慢 FCP 300ms+ - 用 Chrome DevTools 的 “Coverage” 面板检查哪些 CSS 规则压根没用到，删掉它们比压缩更有效
script 标签放哪儿、加什么属性才不白屏
默认 <script src="app.js"> 是同步阻塞的：HTML 解析停住 → 下载 JS → 执行 JS → 继续解析。用户看到的就是白屏。
- 业务逻辑 JS 优先用
defer：下载异步，执行时机在 DOM 解析完成后、DOMContentLoaded前，且按顺序执行 - 统计类、无依赖脚本（如
analytics.js）可用async：下载完立刻执行，时机不可控，可能早于 DOM 就绪 - 兜底方案是把
<script>放在</body>前——至少保证 DOM 已构建完毕，但不如defer可控 - 禁用
document.write()：现代浏览器已废弃，执行即清空文档流，必然阻塞且不可恢复
preload 该加在哪、怎么写才真正加速
preload 不是“越多越好”，它是高优先级资源提示，写错反而抢带宽、挤掉 HTML 或关键 CSS。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
- 只对「确定马上要用」的资源生效：比如首屏字体（
as="font"+ 必须加crossorigin）、首屏 Hero 图的src、或异步 JS 中立刻要import()的模块（as="script"） -
preload和prefetch别混：前者是当前导航用，后者是下一页可能用；Network 面板里前者标Priority: high，后者是low - 别
preload图片：多数图片由 CSS 或 JS 控制展示时机，提前加载反而挤占带宽 - 移动端尤其注意：首屏图必须设
loading="eager"，否则可能触发两次加载
图片懒加载要不要写 loading="lazy"
原生 loading="lazy" 对 <img> 和 <iframe> 有效，但有明确边界。
- 只对离视口较远（默认约 1250px）的元素生效，滚动中会自动触发加载
- 不支持背景图、
image-set()等，这些还得靠IntersectionObserver手动实现 - 必须显式设置
width和height属性，否则懒加载会引发布局偏移（CLS）——这是 Core Web Vitals 扣分重灾区 - 首屏大图千万别加
loading="lazy"，它可能被当成“非关键资源”延迟加载，导致首屏空白或重复请求 - Safari 15.4+ 才支持
loading="lazy"对<iframe>的支持，旧版需回退到data-src+ JS 方案
最容易被忽略的是：内联 CSS 的体积控制（建议 2–3KB 内）、preload 的 as 和 crossorigin 缺一不可、以及首屏图片的 loading 属性必须显式为 eager。这些细节不处理，其他优化效果会打折扣。
