section 必须包含直接子元素或紧邻兄弟的 heading(h2–h6)才能触发语义调度、content-visibility 裁剪、无障碍导航等优化;无标题的 section 等同于 div,且嵌套过深或误用 article 会显著降低性能。

section 必须配 heading 才触发语义调度
单独写 说明文字 常见错误:CMS 模板批量生成 支持离线使用 浏览器对 真正卡住的不是标签名,而是结构模糊后引发的连锁反应:样式计算链变长、JS 查询(如 错误混用后果严重:把商品卡片全塞进 很多人给 现代 SSR 页面中,JS 动态插入的 最常被忽略的点:section 不是性能开关,它是浏览器调度信号的“接收器”。没标题、没层级控制、没区分 article,再标准的写法也只是一堆语法正确的 div。真正在意速度的人,不会盯着标签名改,而是看 DevTools 的 Layers 面板有没有意外合成层、查 document.querySelectorAll('section h2').length 是否匹配业务语义、再跑一遍 Lighthouse 看“语义冗余”报错有没有消失。,浏览器完全当它是 紧邻 – 时,才会把它识别为“可折叠区块”“可跳转单元”,进而影响 content-visibility 裁剪粒度、无障碍导航树和滚动锚点行为。 却漏掉标题;用 JS 动态插入 后没补 ;或把 放在 外面——heading 必须是它的直接子元素或紧邻兄弟(按 HTML5 规范,允许 前有 ,但不能跨层)。
会使 DOM 节点数增加 15%,V8 编译耗时上升 8ms产品特性
section 嵌套过深会放大重排开销
的解析本身不慢,但开发者常把它当“高级 这种三层嵌套,实际 DOM 树已达 6–7 层,Chrome 实测 getComputedStyle() 耗时从 12ms 涨到 80ms。document.querySelector('section section p'))匹配成本飙升、content-visibility 自动裁剪失效。
下子元素建议 ≤ 50 个;超限后样式计算呈非线性增长 套 :三层语义区块已接近人类认知与渲染效率的临界点section 和 article 的性能分界点在哪
是“主题明确的区块”, 是“可独立分发的内容单元”。浏览器对后者启用独立渲染上下文:每个 的样式计算、重排开销被隔离,适合卡片流、博客列表等场景;而 主要影响资源调度与导航逻辑,不隔离渲染。,浏览器无法触发重排隔离,100 张卡片滚动时 layout 计算量翻倍;反过来,把 FAQ 条目硬拆成 ,反而因过度创建渲染上下文拖慢首屏。
:博客目录页的“热门文章”“最新评论”区块(每块含统一 ):单篇博客正文、新闻卡片、用户评论(每项可独立 RSS 分发),LCP 快 120–180ms;但改成 无显著变化
section 里图片 loading="lazy" 的坑
内所有 加 loading="lazy",结果首屏关键图延迟加载、LCP 暴涨。问题不在 ,而在它内部的图片是否属于首屏。 默认 loading="eager",和预期不符;而首屏图片若加了 loading="lazy",浏览器直接跳过加载,直到滚动才触发——这和“首屏优先”原则背道而驰。
loading 属性(等价于 eager),非首屏统一加 loading="lazy"
width 和 height:否则触发布局重排(CLS), 内部的重排会波及整个区块loading="lazy",否则默认 eager
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!











