首屏文本不能等CSS加载完才显示，因为浏览器需先构建关键CSSOM才能生成渲染树，而弱网下外部CSS可能pending超2秒，导致DOM已就绪但页面仍白屏或仅显骨架屏。
首屏文本为什么不能等CSS加载完才显示
因为浏览器必须等关键CSSOM构建完成才能生成渲染树，而外部CSS在弱网下可能pending超2秒——此时DOM里已有<h1>和<p>，但用户看到的仍是白屏或骨架屏。这不是“样式没出来”，是渲染流程卡死在CSSOM环节。
实操建议：
- 把首屏文本节点（如
<h1>、<p class="lead">）直接写在HTML靠前位置，不包裹在JS动态容器里 - 关键CSS必须内联进
<head>的<style>中，禁止用@import或外部main.css承载首屏文字样式 - 非首屏CSS改用
<link rel="stylesheet" media="print" onload="this.media='all'">延迟加载 - 验证方式：Chrome DevTools → Network → 看
document请求后是否紧跟着FCP时间点，若中间有长空白且后面跟着main.css，就是它在阻塞
DOM结构怎么安排才能让文本最快渲染出来
浏览器逐行解析HTML，<body>内元素的物理顺序，直接决定首屏文本DOM节点的创建时机。把<main>放在最前不是为了视觉，而是为了让文本内容最早进入构建队列。
常见错误现象：
立即学习“前端免费学习笔记（深入）”；
-
<aside>或广告<div>写在<main>前面，导致<h1>延后数百毫秒才被解析 - 用
flex-order或position: absolute强行视觉上提文本，但HTML源码里它还在页脚附近 - 服务端返回的HTML包含大量占位
<div data-skeleton>，却没删掉真实文本节点，造成双重DOM开销
正确做法：
-
<main>必须是<body>第一个子元素，里面只放首屏必需文本+<img loading="eager"> - 非首屏区域统一用语义化占位符，例如
<div data-lazy="comments"></div>，不挂载任何真实<p>或<span> - 禁用所有
data-init类自动执行逻辑，文本渲染完成≠可交互，交互初始化需显式判断networkStatus === 'good'
loading="eager"对首屏文本关联图片有多关键
loading="eager"不是锦上添花的配置，而是防止浏览器启发式策略误判首图优先级的保险栓。现代浏览器对<img>的加载决策基于位置+尺寸+解析时机，不加这个属性，哪怕<img>紧跟在<h1>后面，也可能被推迟到DOMContentLoaded之后才发请求。
使用场景与陷阱：
- 首屏Hero图、Banner、带文字叠加的主图，必须显式写
<img src="hero.jpg" loading="eager"> - 同一页面混用
eager和lazy时，靠前的loading="lazy"图会比靠后的eager图更晚开始加载——顺序优先级高于属性值 -
loading只对<img>和<iframe>生效，CSS背景图、<picture>里的<source>不受影响，别指望它控制那些资源 - 必须配
width和height属性，否则即使eager也会触发layout thrashing，拖慢文本流式渲染
内联CSS和结构占位怎么配合才不互相干扰
内联CSS解决的是“有字无样”，结构占位解决的是“有样无字”——二者必须协同，不能只做一半。比如内联了标题字体大小，但<main>里还塞着未裁剪的评论区DOM，主线程仍在解析无用节点，文本照样出不来。
关键控制点：
- 内联CSS只含首屏文本直接用到的规则：字体、行高、颜色、最大宽度，不含动画、媒体查询、伪类
- 结构占位不是简单删DOM，而是用
data-lazy标记+服务端按UA/NetworkInformation API动态输出不同HTML版本 - 禁止在内联
<style>里写@import，实测多一次HTTP往返，拖慢FCP平均300ms+ - 验证是否真生效：断网刷新页面，看纯文本能否在1s内完整呈现；若有缺失，说明CSS没内联全，或DOM仍含非首屏节点
最易被忽略的一点：结构裁剪必须发生在服务端，而不是靠JS在DOMContentLoaded后removeChild——后者已错过首屏渲染窗口，用户早关掉了页面。
