浏览器解析html严格按源码顺序逐行进行，首屏内容须置于html顶部，用loading="eager"确保首图优先请求，js应绑定domcontentloaded事件；脚本未加async或defer会阻塞解析，css不阻塞html但可能阻塞js执行。
浏览器解析HTML是严格按源码顺序逐行进行的
不是“先head后body”这种粗略划分，而是真正从第一行开始，一个标签接一个标签往下走。遇到<script></script>就停，遇到<link rel="stylesheet">就发请求但不阻塞（除非CSS被JS同步读取），遇到<img>就按loading属性决定是否立刻发起HTTP请求。
常见错误现象：把大块<div class="sidebar">写在<code><main></main>前面，结果首屏DOM节点延迟生成，哪怕CSS用position: absolute把它视觉上“拽”到右边也没用——浏览器根本还没解析到<main></main>。
- 首屏必需内容（如
<header></header>、<h1></h1>、首张<img>）必须出现在最顶部 - 非关键资源（页脚、评论区、统计脚本）统一后置，或用
defer脚本动态插入 - 避免在首屏DOM前塞
<script></script>或未加media条件的<link rel="stylesheet">
script标签的位置直接决定DOM就绪时机
<script></script>无论内联还是外链，只要没加async或defer，就会阻塞HTML解析。它一出现，浏览器立刻暂停构建DOM树，转去下载（外链）、解析、执行JS，等它彻底跑完才继续往下扫。
使用场景：需要操作DOM的脚本，绝不能放在里裸写；但若只是定义工具函数，放反而更早可用。
- 操作DOM的代码，要么放
底部紧贴，要么包进DOMContentLoaded事件监听器 -
window.onload要等所有图片、iframe加载完才触发，比DOMContentLoaded晚得多，别误用 - 外链脚本加
defer可让其等DOM解析完再执行，且保持书写顺序；加async则谁先下载完谁先执行，顺序不保证
loading="eager"和loading="lazy"控制的是请求发起时机，不是渲染顺序
loading属性只对<img>和<iframe></iframe>生效，它不改变HTML解析顺序，只决定“浏览器解析到这一行时，要不要立刻发HTTP请求”。设为lazy的图，哪怕写在第一行，也不会触发网络请求；而eager（默认）则一解析到就发。
容易踩的坑：混用eager和lazy时，靠前的lazy图可能比靠后的eager图更晚开始加载——因为浏览器对lazy图的请求会推迟到滚动接近视口时才触发。
- 首屏大图、Banner必须显式加
loading="eager"，防止被浏览器启发式策略跳过 - 折叠区域、瀑布流卡片图用
loading="lazy"，且确保它们在HTML中物理位置靠后 -
loading对CSS背景图、srcset、<picture></picture>完全无效，别指望它起作用
CSS加载不影响HTML解析，但可能阻塞JS执行
<link rel="stylesheet">本身不阻塞HTML解析（现代浏览器会预加载），但它会影响后续<script></script>的执行：如果JS里调用了getComputedStyle()或读取了元素宽高，浏览器必须等对应CSSOM构建完成才能继续运行该脚本。
性能影响：多个阻塞渲染的CSS文件会拉长首次绘制（FCP）时间；而CSS文件过大或服务器响应慢，会导致JS执行卡住，间接拖慢整个页面交互就绪时间。
- 关键CSS内联到
里，非关键CSS用media属性做条件加载（如media="print"） - 避免在JS里同步读取布局信息（如
offsetHeight），这类操作会强制触发回流 - 用
rel="preload"提前拉取关键CSS，但注意它不改变解析顺序，只优化网络调度
