根本原因是自动播放策略和加载时机不匹配；iOS禁自动播放且低电量跳过preload，安卓WebView对playsinline支持不一导致渲染中断。
video标签做全屏背景时，为什么iOS黑屏、安卓卡顿
根本原因是自动播放策略和加载时机不匹配。iOS Safari 默认禁止所有自动播放（包括muted），且低电量模式下直接跳过preload；安卓部分WebView对playsinline支持不一致，导致视频被强求全屏后中断渲染。
实操建议：
-
必须加muted、autoplay、playsinline三个属性，缺一不可；loop可选但建议加上，避免末帧闪白 - 不要依赖
preload="auto"——它在移动端常被忽略；改用preload="metadata"，只加载头信息，首帧渲染更快 - 视频源优先提供
mp4（H.264+AAC），别用webm作fallback——Safari不支持VP9硬件解码，软解卡顿明显 - 加
poster属性指向一张轻量级占位图（≤10KB），防止加载空白期布局塌陷
background-image不能用loading="lazy"，那首屏大图怎么防CLS
background-image确实不支持loading属性，强行套用无效；更麻烦的是，CSS背景图无法声明width/height，浏览器无法预留空间，滚动中突然加载会触发布局偏移（CLS）。
实操建议：
- 首屏Hero区域一律改用
object-fit: cover+loading="eager"，显式设置width和height属性（哪怕只是占位数值） - 如果必须用CSS背景（如伪元素装饰），用
aspect-ratio固定容器比例，并配合min-height兜底，避免内容挤占 - 慎用
background-size: cover搭配background-position: center——在小屏设备上可能裁掉关键视觉元素，建议用background-position: top保主体
内联Critical CSS超2KB后，TTFB反而变慢
内联CSS不是“越多越好”，体积过大时，HTML响应体变大，首字节时间（TTFB）直接受影响。实测超过2KB后，CDN边缘节点压缩/传输开销上升，低端网络下TTFB增加150ms+。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
实操建议：
- 用Chrome DevTools的Coverage面板定位真正首屏用到的样式，删掉所有
@media (min-width: 768px)以外的媒体查询块 - 避免在内联
里写@import——它会发起额外HTTP请求，彻底破坏内联意义 - 字体图标（如iconfont）的
@font-face规则别塞进内联CSS，改用单独预加载 - 移除对应外链
，否则样式重复应用，可能引发hover态错乱等意外交互
preload加错资源，比不加还拖慢首屏
是高优先级提示，不是万能加速器。加在非当前导航必需的资源上，会抢占带宽，把HTML、关键CSS甚至DNS查询挤到后面。
实操建议：
- 只对「当前页面立刻要渲染」的资源用：
font.woff2、首屏hero.jpg、关键CSS文件（注意：不是全部CSS） -
as属性必须准确：字体必须写as="font"，图片写as="image"，否则浏览器按as="fetch"降级处理，失去预加载意义 - 字体资源必须加
crossorigin属性，否则即使preload了也不生效——这是Safari和Firefox的硬性要求 - 绝对别对
main.js或vendor.js做preload：它们本身已用defer控制执行时机，再preload只会让JS下载提前，却卡住DOM构建
关键点在于：所有优化动作都得锚定「当前导航」这个上下文。视频是否播、图片是否载、CSS是否内联、资源是否preload，答案都不是静态的，而是由用户此刻看到哪一块内容决定的。漏掉这个前提，配置再全也救不了首屏。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
