移动端HTML卡顿主因是语义误用、嵌套过深（超6层拖慢FCP 200ms+）及冗余解析；应精简DOM节点（≤800）、用语义化标签替代div、首屏图设loading="eager"、正确配置viewport与preload。

移动端HTML标签本身不慢，慢的是你用错了语义、嵌套太深、或让浏览器多干了不该干的活。 优化不是加功能，而是砍掉解析、构建、重排过程中的冗余动作。

为什么

嵌套太多会导致卡顿

每个

都要经历 tokenization → parsing → DOM tree construction → render tree 构建。移动端 CPU 弱，800 个节点以上就明显拖慢首屏可交互时间；更麻烦的是，无意义嵌套会让 CSS 选择器（如 .header .nav .item .link）被迫走深度匹配，样式计算开销翻倍。

• 用
  、
  、
  、
  替代纯
  ，浏览器能跳过 class 解析直接定位语义区块
• Chrome DevTools → Elements → 右键「Copy」→「Copy outerHTML」粘贴后数一下标签总数，超 800 就该删
• 避免「div 套 div 套 div」只为了 margin/padding，改用 :where() 或 margin-block 等逻辑属性控制间距

img loading="lazy" 在 iOS 上为啥不加载

不是你写错了，是 Safari 的兼容性断层：iOS 15.4 之前完全忽略 loading="lazy"，且不 fallback 到默认行为——图片留空、布局塌陷、FCP 崩溃。这不是 bug，是规范落地延迟。

• 首屏图片必须显式写 loading="eager"，哪怕只有一张
• 非首屏图用 loading="lazy"，但得确认构建流程里没把 或 srcset 和它混用，否则某些安卓 WebView 会触发两次请求
• background-image 根本不支持该属性，得换 + object-fit，或退回到 IntersectionObserver 手动控制

meta viewport 设置错会放大所有性能问题

一个错配的 viewport 会让浏览器反复缩放、重绘、甚至强制触发 layout thrashing。比如 user-scalable=no 虽防双击缩放，但会让 iOS Safari 放弃 pinch-zoom 优化路径，渲染帧率直降。


DeepBI DHTML 页面生成器
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
下载
• 基础必写：
• 禁用 maximum-scale 和 user-scalable，除非有强业务约束（如金融类输入框防误触）
• 别信「device-width 是物理像素」——它是 CSS 像素，和 DPR 无关；真要适配高清屏，靠 srcset + image-set()，不是 viewport

preconnect 和 preload 混用反而拖慢首屏

preconnect 是建立 TCP/TLS 连接，preload 是提前拉资源，两者粒度不同。对非关键域名（如统计、广告）盲目 preconnect，会抢占 DNS 查询和连接池，反而挤占首屏 CSS/JS 的通道。

• 只对主域和字体 CDN 做
• preload 只用于首屏必需资源：关键 CSS、LCP 图片、WebFont，且必须带 as 属性，否则浏览器当普通 fetch 处理
• 别给 preload 加 onload 回调去切换 rel="stylesheet"，Safari 16+ 已原生支持 rel="preload" as="style" 自动升级，手动写反而出错

最常被忽略的点：HTML 压缩不是“锦上添花”，是硬门槛。未压缩的 HTML 多出 20% 字节，在 3G 下可能多耗 400ms TTFB —— 这段时间浏览器连 DOM 树都没开始建。别只压 JS/CSS，text/html 同样要 Gzip 或 Brotli。