放body底部并非更慢，而是执行时机仍会阻塞解析：未加defer/async的script无论位置如何，都会暂停HTML解析、下载并执行完才继续，若依赖DOM则报错；内联脚本永远阻塞，外部脚本加defer可保序且不阻塞，加async则不保序且可能早于DOM就绪。
为什么<script>放body底部反而更慢</script>
不是位置问题，是执行时机问题。浏览器遇到未加defer或async的<script>标签，会立刻暂停HTML解析、下载脚本、执行完才继续——哪怕它在</body>之前。如果这个脚本依赖DOM（比如调用document.getElementById），又没做延迟处理，就可能报NullReferenceError或静默失败。
- 内联脚本（
<script>xxx</script>）永远阻塞，无法绕过 - 外部脚本加
defer：下载不阻塞，执行在DOM构建完成后、DOMContentLoaded前，顺序保证 - 外部脚本加
async：下载不阻塞，但下载完立刻执行，不等DOM，也不保序，适合埋点、广告等无依赖逻辑 - 把
<script src="main.js"></script>硬塞进<body>底部，只是“看起来”不卡首屏，实际仍会中断解析流程
CSS加载卡住HTML解析的真实原因
很多人以为只影响渲染，其实它直接冻结HTML解析器。浏览器一看到<link rel="stylesheet" href="base.css">，就会暂停DOM构建，直到CSS下载完成、CSSOM生成完毕才继续——哪怕这个CSS只用于页脚的<footer>。
- 关键路径上不要放非关键CSS；非关键样式用
media="print"或media="(min-width: 1024px)"触发异步加载 - 避免在
<head>里混写<link>和<script>：JS可能等CSSOM，CSS又等JS下载（如果JS里动态注入CSS） -
<link rel="preload" as="style" href="critical.css">可提前发起请求，但不改变阻塞行为；真正解法是拆出关键CSS内联，其余异步加载
语义化结构如何影响首屏性能
<header>、<main>、<section>这些标签本身不提速，但它们让浏览器更快识别内容优先级。现代渲染引擎（如Chromium）会对<main>内的文本节点、图片做更高优先级的解析与布局计算；而<div class="main">会被当作普通容器，无特殊调度。
-
<main>必须且只能出现一次，且应包裹首屏核心内容；搜索引擎和屏幕阅读器也依赖它定位主体 -
<picture>+<source>比单个<img srcset>更可控：能配合media属性按视口条件加载不同资源，避免大图下载 - 避免嵌套过深的
<div>：每层嵌套都增加DOM节点数和样式计算复杂度；Chrome DevTools 的“Layers”面板能直观看到哪些元素触发了额外合成层
静态化与HTML结构的隐性耦合
大型系统做HTML静态化时，常忽略结构对缓存粒度的影响。比如把整个页面生成一个index.html，只要页脚版权年份更新，整页缓存失效；但如果用<include src="/footer.html">（服务端SSI）或模块化<template>，就能单独缓存头部、主体、侧栏。
立即学习“前端免费学习笔记（深入）”；
- 静态化前先评估结构可拆分性：
<header>、<nav>、<main>、<aside>、<footer>天然适合独立生成与缓存 - 避免在静态HTML里留
document.write或eval调用——它们会让CDN或边缘缓存拒绝缓存该响应 - 服务端渲染（SSR）输出的HTML，若含大量
data-*属性传递状态，需确认前端JS是否真需要；冗余属性会增大传输体积，且不参与渲染
defer漏加，一段media没设，就可能让首屏多等300ms——而这段时间，用户已经划走了。 
