首屏文本不能等CSS加载完才显示，因为浏览器必须等关键CSSOM构建完成才能生成渲染树，而外部CSS在弱网下可能pending超2秒，导致白屏或骨架屏；此时DOM已有内容，但渲染被阻塞在CSSOM环节。
为什么首屏文本不能等CSS加载完才显示
浏览器必须等关键CSSOM构建完成才能生成渲染树，而外部CSS文件在弱网下可能卡在pending状态超2秒——此时DOM里已有
和
，但用户看到的仍是白屏或骨架屏。这不是“样式没出来”，是渲染流程被阻塞在CSSOM环节。
常见错误现象：LCP指标差、3G下首屏等待超3秒、用户反复刷新页面。根源不是JS慢，而是成了单点故障。
- 内联首屏必需的文本样式（font-family、line-height、color、font-size），体积控制在1KB以内
- 把非文本相关样式（如动画、悬停效果、栅格布局）全部剥离到外链CSS，用media属性隔离：
<link rel="stylesheet" href="layout.css" media="screen"> - 避免@import，它会串行阻塞，等价于把多个CSS请求压进一个长队列
如何用fetchpriority确保文本节点优先解析
fetchpriority不是锦上添花，而是告诉浏览器：“这个资源影响文字是否能立刻读到”。默认所有和都被标记为low，哪怕它是标题下的
<h1>父容器背景图，也会和文本争带宽。
使用场景很明确：只要DOM节点内容属于首屏可读信息（标题、摘要、操作说明），其关联资源就该提权。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 首屏
<h1>所在section的背景图，加fetchpriority="high"并配合loading="eager" - 字体文件（.woff2）必须加
fetchpriority="high"，否则fallback字体撑开布局引发CLS - 非可视资源如埋点脚本、广告SDK，统一设
fetchpriority="low"，不抢文本通道
DOM结构怎么写才能让文本最快“吐”出来
HTML解析是流式的，浏览器边下载边构建DOM树。如果首屏文本被包在五层嵌套
容易踩的坑：用data-lazy占位符包裹标题、把
- 首屏文本节点（
<h1>、<p>、<button>）必须写死在HTML最前面，不包裹无语义wrapper - 禁用
display: contents替代文本容器——Safari 15.4+才支持，老版本会丢失文本渲染上下文 - 所有文本级元素必须带明确
lang属性，避免弱网下字体回退时重排
弱网下文本渲染失败的兜底策略
光靠优化还不够。当fetch探测确认弱网（连续两次响应>800ms），必须主动降级：不是等CSS超时，而是立刻用内联style覆盖原有样式，确保文字至少能以系统字体、14px、黑灰配色呈现。
这个逻辑不能写在CSS里，必须由JS动态注入——否则SSR会把降级样式一并输出，污染SEO和爬虫。
- 预留空
<style id="text-fallback"></style>，弱网触发时用textContent写入最小可用样式 - 降级文案用
textContent插入，不用innerHTML，防XSS且避免HTML解析开销 - 禁用所有transition和@keyframes，改用
opacity: 1硬切，避免requestAnimationFrame在低端设备掉帧
文本优先不是“只做文字”，是把可读性作为渲染链路上不可妥协的基线——一旦网络不可靠，其他都可裁，唯独用户要读的那一行字，得先出来。
