问题八成出在HTML骨架上：嵌套超三层、语义错配、script阻塞解析等结构缺陷直接拖垮性能与可访问性，而非CSS或JS问题。
高负载下网页卡顿、首屏延迟、辅助设备读不出内容，问题八成出在 HTML 骨架上，而不是 CSS 写得不够炫或 JS 逻辑不够巧。结构松散、嵌套失控、资源加载顺序反直觉，会直接拖垮解析、渲染和可访问性。
语义化标签不是“加分项”，是浏览器和爬虫的导航图
把 <div class="main-content"> 换成 <main>，不是为了代码看起来更现代，而是让浏览器立刻知道“这是页面唯一核心内容区”——<main> 必须且只能出现一次，不能嵌套在 <article> 或 <section> 里。同理：<nav> 表示主导航（非面包屑或页脚链接），<aside> 是与当前内容相关但可剥离的补充（如侧边引用），纯广告位该用 <div role="complementary"> 而非硬套 <aside>。
-
<section>要能独立成文（比如一篇新闻、一个工具介绍），而<div>套<div>套<p>这类纯样式驱动结构，先问一句：“这个容器有没有独立语义？”没有就删 - 多个相邻
<div class="card">并列？优先考虑用<section>包一层，再用<article>包每个卡片 - 用开发者工具 Elements 面板按
Ctrl+Shift+C点击任意元素，看它的父链是否超过三层；超过就查是不是<div>堆出来的“假结构”
DOM 嵌套超三层，CSS 和 JS 就开始“猜谜”
浏览器构建 DOM 树是深度优先遍历，每多一层嵌套，解析耗时增加，CSS 选择器匹配成本也指数上升。比如 .a .b .c .d p 这种写法，浏览器要逐层回溯父节点，实际性能损耗远高于表面看上去的“多写几个点”。实测中，单个 <section> 下子元素超 50 个，滚动时重排明显卡顿。
- 用 Flex 或 Grid 替代 2–3 层包裹容器：三栏布局不用
<div class="row"><div class="col">…</div></div>，直接display: grid+grid-template-columns - 动态列表插入别用
el.innerHTML += <li>...</li>，改用DocumentFragment批量插入，避免每加一项都触发一次 DOM 重排 - 检查老项目里是否存在
<div><div><div><p>这类无语义嵌套——它们通常来自复制粘贴或过时的 UI 框架模板
资源加载顺序错一位，首屏就白屏两秒
一个没加 defer 的 <script src="app.js"> 放在 <head> 里，会立刻中断 HTML 解析，等 JS 下载执行完才继续——此时连 <body> 都没生成，用户看到白屏。更隐蔽的问题是：它还会卡住 CSSOM 构建，尤其当这个 script 放在 <link rel="stylesheet"> 前面时。
立即学习“前端免费学习笔记（深入）”；
- CSS 必须放
<head>，但禁止在 CSS 文件里写@import：它强制串行加载，main.css里的@import "theme.css"会让浏览器等 main 下完再发 theme 请求 - 关键 JS（如首屏交互）用
<script defer>；非关键（统计、埋点）用<script async>；内联脚本（<script>init();</script>）默认阻塞，务必加defer - 字体、首屏图片用
<link rel="preload" as="font">提前拉取，但别对所有 JSpreload——它不控制执行时机，反而可能挤占带宽
HTML 不该“动态拼接”，服务端能定死的尽量定死
所谓“高负载优化”，很多败在 HTML 生成阶段：模板引擎边渲染边请求数据、服务端拼接大量内联 JSON、甚至前端用 JS 动态生成整个 <main> 区域。这些做法让首屏完全依赖 JS 执行，失去 SSR 优势，也放大 TTFB 影响。
真正关键的是：哪些结构必须由服务端输出？<title>、<meta name="description">、首屏可见的 <article>、关键导航链接——这些应尽可能在初始 HTML 中存在。JS 只负责增强，而非构造骨架。
容易被忽略的一点是：HTML 压缩不能只删空格换行。如果用了构建工具，确认它是否移除了未使用的 <script> 或冗余 data-* 属性；手写项目则建议用 html-minifier-terser 做 CI 检查，避免上线后还带着开发期的 <!-- TODO: remove this --> 注释。
