语义化标签本身不提升渲染速度，但通过降低 DOM 结构噪声、加速 CSS 选择器匹配和 JS 查询，间接缩短关键渲染路径；错误嵌套（如 <nav> 塞进 <footer>）会触发渲染树重建，比多几个 <div> 更伤性能。
语义化标签本身不触发硬件加速，但能减少不必要的重排重绘，为 GPU 分层提供更干净的渲染树；盲目加 transform: translateZ(0) 或 will-change 反而可能拖慢首屏。
为什么 <main> 和 <section> 会影响渲染性能？
浏览器在构建渲染树时，会跳过 display: none 或不可见节点，但不会因语义标签自动“优化”布局。真正起作用的是：语义标签降低了 DOM 结构噪声，让 CSS 选择器匹配更快、JS 查询更精准，间接缩短关键渲染路径。
-
<main>必须唯一且直接子元素不能是<section>或<article>—— 否则部分 Chromium 版本会忽略其语义，导致渲染树中该节点被降级为普通<div> -
<section>不自带样式，但若嵌套过深（如<section><section><section>），会增加 layout 阶段的遍历成本，尤其当父级有flex或grid时 - 用
<div role="main">替代原生<main>：无障碍可用，但 SEO 权重和渲染树结构识别全失效
transform 硬件加速在哪些 HTML 结构里才真正生效？
硬件加速不是“加了就快”，它依赖图层（layer）分离。只有满足以下条件的元素，浏览器才会为其创建独立合成层：
- 元素有
transform（非translateX/Y的 2D 位移，需含Z轴或 3D 变换）、opacity < 1、will-change: transform等触发属性 - 该元素不在一个已存在合成层的父容器内（否则会被合并，不新增层）
- 父级没有
overflow: hidden或clip-path等剪裁限制（会阻止层提升）
常见翻车点：<header> 里加 transform: translateZ(0)，但外层 <body> 有 overflow-x: hidden —— 加了等于没加，图层根本提不上去。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
移动端 <picture> + <source> 怎么避免布局抖动？
图片加载前高度塌陷 → 加载后重排 → 视觉跳动，这是首屏 LCP 延迟主因之一。语义化本身不解决，但 <picture> 提供了可控入口：
-
<source>必须带media或type，否则浏览器当摆设，仍走<img>fallback 流程 - 必须显式设置
<img>的width和height属性（非 CSS），否则 Safari 不会预留空间 - 搭配
loading="eager"（而非lazy）用于首屏图片，否则 Chrome 会延迟加载，加剧抖动 - 慎用
<picture>包裹 SVG：多数 SVG 本身无尺寸，<img>无法推断宽高，仍会抖动
最易被忽略的一点：语义标签的层级关系一旦写错（比如把 <nav> 塞进 <footer> 内部），不仅 SEO 权重归零，某些 WebView 还会强制重建渲染树——比多几个 div 更伤性能。
