首屏稳定性取决于HTML质量而非JS框架；结构错误、阻塞脚本、未优化资源导致白屏或闪动；需确保HTML语义正确、关键CSS内联≤14KB、首屏图片禁用lazy、脚本优先使用defer。
首屏呈现是否稳定、快速，不取决于JS框架多炫酷，而取决于HTML是否经得起真实网络和设备的考验——结构松散、语义错乱、资源加载失控的HTML，再好的CSS和JS也救不回来。
为什么首屏白屏或闪动，常是HTML结构问题
浏览器解析HTML是流式、自上而下的过程。一旦遇到未闭合标签、嵌套错乱（比如 <div><p></div></p>）、或过早引入阻塞脚本，渲染就会中断或重排。这种错误不会报JS错误，但会导致首屏内容延迟数秒甚至完全不显示。
- 常见现象：页面“卡住”1–2秒后突然全部出现；滚动时顶部内容跳动；SEO抓取不到
<main>内文字 - 根本原因：DOM树构建异常 → 渲染树生成延迟 → 首屏像素迟迟不出
- 检查方式：打开开发者工具 → Elements 面板看DOM是否被自动修正（如出现灰色
<body>外标签），或 Network → HTML响应体中是否有大量空格/注释/无意义<div>嵌套
关键CSS内联但别超14KB，否则反而拖慢
把首屏必需的样式直接写进<head>里的<style>，能绕过外部CSS请求的RTT延迟。但体积失控会反向阻塞HTML parser，得不偿失。
- 提取范围仅限：字体大小/颜色/间距、首屏容器宽高、按钮基础状态、加载骨架动画所需的最小规则
- 不要包含：主题色切换逻辑、暗色模式完整规则、非首屏组件样式（如
.modal、.sidebar） - 验证方法：复制
<style>内容粘贴到编辑器，用字符统计工具确认是否≤14KB（约1.5万字节） - 构建时建议：用
critters或rollup-plugin-critical-css自动化提取，避免人工漏判
图片懒加载用loading="lazy"，但首屏图必须显式排除
loading="lazy"是浏览器原生支持的懒加载方案，但它对所有<img>一视同仁。首屏图片若也被懒加载，就违背了“优先保障核心内容”的原则。
立即学习“前端免费学习笔记（深入）”；
- 必须排除的情形：
<img src="hero-banner.jpg" loading="lazy">→ 改为移除loading属性，或显式设为loading="eager" - 注意兼容性：Safari 15.4+、Chrome 76+、Firefox 75+支持；旧版需回退至IntersectionObserver方案
- 不要滥用：装饰性图片（如背景花纹）可设
alt=""并加loading="lazy"；含关键信息的图片（如商品主图、表单验证码）必须同步加载 - 额外提醒：
<picture>内部的每个<source>无需单独加loading，只在最外层<img>上设置即可
script标签放body底部？现在更推荐defer
把<script>扔到</body>前曾是标准做法，但现代浏览器已支持更精准的控制——defer让脚本并行下载、按顺序执行，且不阻塞HTML parser，比“放底部”更可靠。
- 适用场景：所有不依赖DOM操作的初始化脚本（如埋点SDK、配置加载、工具函数库）
- 慎用
async：它不保证执行顺序，适合完全独立的资源（如广告脚本），但会破坏依赖链 - 必须同步执行的脚本（如内联初始化代码）：保留在
<head>，但要极简，且确保不调用document.querySelector等API - 验证效果：Network面板查看脚本是否标记为“Finished”早于
DOMContentLoaded事件触发
真正影响高可用的，从来不是某一行炫技的JS，而是HTML里一个没闭合的<div>、一张忘设alt的图标、或一段本该defer却硬塞进<head>的脚本——这些细节不声不响，却决定用户第一眼看到的是内容，还是空白或错误。
