首屏加载慢的主因是HTML触发的渲染阻塞而非文件体积大；关键CSS需内联且≤10KB，script必须用defer/async，图片须设宽高防CLS，禁用@import和document.write。
首屏加载慢，八成不是 HTML 文件大，而是它触发的阻塞行为卡住了渲染起点——关键 CSS 没内联、@import还在用、script标签没加 defer，或者图片连 width 和 height 都没设。
怎么判断瓶颈真在 HTML 渲染路径上
别一上来就改代码。先打开 Chrome DevTools → Network 面板 → 勾选 “Disable cache” → 刷新页面，盯住三件事：
-
document请求的TTFB是否 > 200ms？如果是，问题在服务端（Nginx 配置、SSR 渲染逻辑、数据库查询） -
main.css或app.js的Initiator是否显示为parser？说明是 HTML 解析时同步加载，大概率是关键阻塞源 - Waterfall 中，
FCP（First Contentful Paint）前有没有长空白？如果有，且紧挨着某个<link rel="stylesheet">或<script>，那就是它
关键 CSS 必须内联，且位置和体积都得卡死
浏览器遇到外部 <link rel="stylesheet"> 就停住渲染，直到 CSSOM 构建完成。首屏按钮、Header、Hero 区样式绝不能走网络请求。
- 用
critters（Vite/webpack 插件）或criticalCLI 驱动 Puppeteer，在模拟 iPhone SE（{ width: 375, height: 667 }）下提取真实首屏用到的规则，不是截取main.css前几 KB -
<style>标签必须放在<head>最顶部，紧贴<meta charset>后面；后面不能紧跟任何<link rel="stylesheet"> - 内联内容控制在 ~10KB（gzip 后约 4–8KB），超了可能跨 TCP 包，反而拖慢
TTFB - 禁用
@import、剔除含url()的声明（如背景图、字体）、过滤掉@font-face和@keyframes
script 标签不加 defer 或 async 就等于白屏邀请函
<script src="app.js"></script> 是最危险的默认行为：HTML 解析停摆，用户看到白屏，且执行顺序不可控。
立即学习“前端免费学习笔记（深入）”；
- 业务主逻辑脚本一律用
defer：<script src="app.js" defer></script>—— 下载不阻塞，执行在 DOM 解析完后、DOMContentLoaded前，顺序保证 - 第三方统计、广告类脚本用
async：<script async src="analytics.js"></script>—— 下载不阻塞，但执行时机不确定，不依赖 DOM - 绝对禁用
document.write()：现代浏览器已废弃，执行即清空文档流，本地环境尤其敏感 - 不要把
script放在<body>底部当“兜底方案”——defer已足够，且语义更清晰、兼容性更好
非关键 CSS 和图片必须主动“让路”，不能靠浏览器猜
非首屏样式（如模态框、图表库、打印样式）如果还用普通 <link rel="stylesheet">，浏览器照样会阻塞渲染，直到它下载并解析完。
- 用
<link rel="stylesheet" media="print" onload="this.media='all'">实现异步加载；IE 不支持onload，需配<noscript>回退 - 暗色模式等条件样式，直接写
<link href="dark.css" rel="stylesheet" media="(prefers-color-scheme: dark)">，别包在@import里 - 首屏图片必须显式设置
width和height属性，否则加载时引发布局偏移（CLS），拉低 Core Web Vitals 分数 -
loading="lazy"只对<img>和<iframe>生效，且默认触发距离视口约 1250px —— Hero 图、轮播图第一张、关键按钮图标必须禁用
最容易被忽略的是：内联 CSS 体积超限、@import 藏在第三方样式表里、defer 脚本仍依赖未加载的 polyfill、以及图片尺寸缺失导致的 CLS —— 这些问题不会报错，但会让 FCP 稳稳卡在 1s 以上。
