删 div 比加 loading 更关键,因为冗余 dom 节点增加解析开销和传输字节,应优先用语义标签替代无意义 div、确保唯一 main、正确使用 alt 和 svg 优化。

loading="lazy" 不是语义标签,但它是当前减少网络传输损耗最直接有效的 HTML 属性之一——前提是语义结构本身已足够轻量、无冗余。
为什么删 div 比加 loading 更关键
很多团队一上来就给图片加 loading="lazy"、用 html-minifier 压缩空格,却忽略一个事实:浏览器下载的是字节,解析的是 DOM 节点。一个嵌套 5 层的 div 块,哪怕只包一行文字,也会生成 5 个 DOM 节点 + 对应的样式计算开销 + 更长的 HTML 字符串。
常见错误现象:
- CMS 输出的正文里,每段
<p></p>外套三层<div class="content-wrapper"><div class="inner"><div class="text"> <li>用 <code><section></section>包裹单个按钮或图标,而它本该属于<aside></aside>或直接 inline - 服务端模板中硬编码
<div id="js-header-placeholder">,但实际 JS 并未接管,纯属占位 <p>实操建议:</p> <ul> <li>用浏览器 DevTools 的「Elements」面板展开 DOM 树,观察是否有连续 3 个以上无 class/id/role 的 <code>div;有则必须重构 - 把 CMS 模板中所有
<div> 替换为语义等价标签:纯文本容器 → <code><article></article>或<section></section>;导航区 →<nav></nav>;侧边功能块 →<aside></aside> - 禁用「自动包裹」类插件(如某些富文本编辑器的“响应式容器”开关),改由 CSS Grid / Flex 控制布局,而非靠多层
div撑结构 - 单页应用(SPA)中,路由切换后未移除旧
<main></main>,新内容又套了一层 - SSR 渲染时,模板 layout 文件含
<main></main>,子组件也自带<main></main> - 第三方 SDK 注入的弹窗或浮层,内部擅自使用
<main></main>(典型如某些客服 widget) - 上线前跑一次
document.querySelectorAll('main').length,值必须为 1;否则构建阶段报错中断 - 在 Webpack/Vite 插件中加入 HTML AST 扫描逻辑,拦截重复
<main></main>标签(可用parse5+ 自定义 rule) - 动态插入内容时,统一用
aria-live+role="region"替代<main></main>,避免语义冲突 - SVG 图标内联时,没删掉编辑器自动生成的
<title></title>和<desc></desc>,导致 HTML 体积极增且无实际用途 - 用
<img src="spacer.gif" alt="">做占位,现代布局下完全可由 CSSaspect-ratio或min-height替代 - CDN 返回的图片 URL 含 query 参数(如
?v=20260630),但 HTML 中写死未压缩路径,导致缓存失效+重复下载 - 所有
<img>必须有alt;信息图/图表类图片,alt内容应复述图中关键数据,而非“图表一张” - SVG 内联前用
svgo清理元数据,删掉id、style、data-等非必要属性 - 图片路径统一走构建时变量注入,确保开发/生产环境都使用带哈希或版本号的 CDN 地址
<main></main> 只能出现一次,但很多人写了两次
这不是校验警告,是硬性规范。重复的 <main></main> 会让爬虫和屏幕阅读器无法判断哪一块才是页面核心内容,间接导致首屏关键资源被降权加载——哪怕你用了 preload,也可能因语义混乱被浏览器忽略优先级。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML,替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度,HTML 能同时承载排版、表格、SVG 等。
使用场景:
实操建议:
alt="" 是合法的,但用错地方就是传输浪费
一张装饰性图标设 alt="" 可减少字符串长度,但若把带操作语义的图标(比如 PDF 下载按钮里的文件图标)也设为空,浏览器仍会下载该图,却失去语义提示——用户靠屏幕阅读器无法得知“这是下载入口”,只能靠猜;开发者则可能额外加 aria-label 补救,反而增加 JS 体积和执行负担。
容易踩的坑:
实操建议:
真正影响传输损耗的,从来不是多几个空格或少一个换行,而是 DOM 结构是否真实反映内容意图。语义越准,浏览器越少猜测,JS 越少补救,最终 HTML 文件自然变小、解析更快、首屏更稳。










