核心是语义清晰、层级扁平、资源可控：用准确语义标签替代div堆叠，嵌套控制在3–4层内，meta charset必须位于head前1024字节，script加defer/async或置底部，关键资源preload，DOM超50子元素需分块。
能显著提升网页性能的 HTML 结构，核心不是“写得多”，而是“写得准”：语义清晰、层级扁平、资源可控。很多性能问题在 <html> 文件被请求的那一刻就已埋下——比如 <script> 放在 <head> 里没加 defer，或 <meta charset="utf-8"> 被挤到第 1500 字节之后。
为什么 <meta charset> 必须在前 1024 字节内
浏览器解析 HTML 是流式进行的，一旦发现开头没声明编码，就会先按 latin1 解析一段，等真正读到 <meta charset="utf-8"> 再重载整个文档——这不是卡顿，是白屏+乱码+重绘。这不是兼容性问题，是 HTML 规范强制要求。
-
<meta charset="utf-8">必须是<head>中前几行之一，最好紧贴<title>前 - 不要把它和一堆
<meta name="description">或第三方 SDK 的<script>混在一起塞到底部 - 用开发者工具的 Network → Response 查看原始响应体，确认它出现在前 1024 字节内（Ctrl+F 搜
charset即可）
如何用语义化标签替代 <div> 堆叠而不踩坑
语义化不是为了好看，是为了让浏览器跳过“猜结构”环节。但错用 <article> 和 <section> 反而会增加解析负担，因为它们触发隐式 ARIA 角色和额外 DOM 层级。
-
<main>必须且只能出现一次，且不能嵌套在<article>或<section>内；它是页面唯一核心内容容器 -
<article>表示可独立分发、复用的内容单元（如一篇博客、一条新闻），不是“随便一个模块” -
<aside>不等于“右边栏”，而是与当前内容相关但可剥离的补充信息；纯广告位请用<div role="complementary"> - 避免
<div><div><div><p>这类无语义嵌套——先问自己：“删掉这个<div>，样式/功能是否还成立？”不成立就留，否则直接删
DOM 层级超过 4 层为什么真会影响渲染速度
浏览器构建 DOM 树是深度优先递归过程，每多一层嵌套，不仅解析时间线性增长，CSS 选择器匹配成本也指数上升（比如 .a .b .c .d p 要逐层回溯）。实测中，单个 <section> 下子元素超 50 个，滚动时重排明显卡顿。
立即学习“前端免费学习笔记（深入）”；
- 用 DevTools → Elements 面板按
Ctrl+Shift+C定位深层节点，重点查<div>套<div>的区域 - 用
display: grid或display: flex替代 2–3 层包裹容器（例如三栏布局无需<div class="row">+ 三个<div class="col">） - 动态列表插入时，用
DocumentFragment批量操作，避免每加一项都触发一次 DOM 重排 - 服务端渲染（SSR）时警惕空
<div class="">或仅用于 JS 操作的冗余容器——它们仍要进 DOM 树，且无法被 CSS 优化跳过
哪些 <link> 和 <script> 位置错误比代码逻辑错误更致命
一个没加 defer 的 <script src="app.js"> 放在 <head> 里，会立刻中断 HTML 解析，等 JS 下载执行完才继续——此时连 <body> 都没生成，用户看到白屏。这比 JS 里少个分号影响大得多。
-
<script>放</body>前是最简单兜底方案；对非关键脚本（如统计、埋点）必须加async；对依赖 DOM 的初始化脚本必须加defer -
<link rel="preload">只对明确知道首屏马上要用的资源有效（如首屏大图、关键字体），错用反而抢占带宽 -
<link rel="preconnect">对跨域 CDN 有用（如https://fonts.googleapis.com），但别对十几个域名都加——每个 preconnect 都要建立 TCP/TLS 连接 - 删掉没被任何工具读取的
<meta name="keywords">和过时的<meta http-equiv="X-UA-Compatible">，它们只是多几个字节
最常被忽略的不是怎么写新功能，而是检查已有结构：有没有 <div> 嵌套超过 6 层？<meta charset> 是否真的在开头？<script> 是不是还在 <head> 里裸奔？这些地方改一行，比优化 JS 算法更容易见效。
