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