HTML结构顺序决定首屏渲染速度，关键内容应前置；阻塞资源需defer/async；首屏CSS内联、非关键CSS用media隔离；fetchpriority和decoding可优化图片加载优先级与解码时机；JSON-LD不阻塞渲染但能辅助预加载。
HTML结构顺序直接影响首屏渲染速度
浏览器解析HTML是流式、自上而下的，DOM构建从<html>开始逐节点进行，中间遇到阻塞资源（如未加defer或async的<script>）就会暂停。这意味着：把关键内容（如首屏标题、主图、核心按钮）写在HTML靠前位置，比“先加载导航再加载正文”更有效。
常见错误现象包括：首屏白屏时间长、LCP（最大内容绘制）指标差、移动端3G网络下首屏延迟超3秒。
- 避免在
<head>里引入大量第三方JS，尤其未声明async的统计脚本 - 把非关键CSS（如打印样式、暗色模式后备样式）用
media属性隔离，例如<link rel="stylesheet" href="print.css" media="print"> - 语义化标签（如
<main>、<article>）本身不提速，但配合fetchpriority="high"可让浏览器更早识别并提升其子资源优先级
CSS选择器优先级不是性能瓶颈，但样式表加载时机才是
CSSOM构建必须等关键CSS下载并解析完成才能继续渲染，所以“选择器写得复杂”本身不拖慢渲染，但“CSS文件体积大+未内联+未预加载”会直接卡住首屏。浏览器对.header .nav ul li a这种深层嵌套选择器的匹配开销极小，真正影响的是你是否让style.css成了关键路径上的单点故障。
实际项目中，!important滥用、过度使用ID选择器、盲目拆分CSS文件反而更容易引发维护性问题和意外覆盖。
立即学习“前端免费学习笔记（深入）”；
- 将首屏必需的CSS内联到
<head>中，用工具如critters自动提取 - 对非首屏组件CSS，用
rel="preload"+as="style"提前拉取，再动态插入<link> - 避免在
@import中链式加载CSS，它会阻塞并串行下载，等价于把多个HTTP请求压成一个长队列
fetchpriority和decoding是被严重低估的HTML原生优化属性
这两个属性不改变布局逻辑，但能显著影响资源调度顺序和主线程占用——尤其是图片类资源。默认情况下，所有<img>都被浏览器标记为low优先级，哪怕它是LCP候选元素；解码过程也默认同步执行，大图一来就卡顿交互。
它们不是“锦上添花”，而是解决真实瓶颈的开关：首图加载慢、滚动卡顿、输入框响应延迟。
- 首屏关键图必须加
fetchpriority="high"，且配合loading="eager"（不要用lazy） - 大于100KB的图片建议加
decoding="async"，小图标或SVG保持默认即可 -
fetchpriority="low"适合埋点脚本、分析SDK、非可视占位图等，明确告诉浏览器“别抢带宽”
结构化数据（JSON-LD）不影响渲染性能，但会影响资源预判
放在<head>里的<script type="application/ld+json">不会阻塞DOM或CSSOM构建，浏览器会忽略其执行，仅用于SEO和富媒体展示。但它能间接提升性能：搜索引擎或浏览器预加载器可能根据其中的"@id"或"image"字段，提前发起对关键图片或视频的请求。
注意：它不参与样式计算、不触发重排重绘，但若误写成type="text/javascript"，就会变成阻塞脚本执行。
- 确保
type值严格为"application/ld+json"，大小写敏感 - 避免在JSON-LD里引用外部URL（如
"url": "https://.../image.jpg"），这不会触发预加载，只是纯文本 - 如果页面有多个关键图，且已用
fetchpriority="high"标注，JSON-LD里的image字段价值就大幅降低
fetchpriority当成装饰属性，而不是资源调度指令；以及把结构化数据当SEO附属品，而没意识到它可能是预加载线索的补充来源。 
