背景视频播放优化实录：从mp4卡顿到HLS分片秒开

一、问题现象：三种设备三种病#

博客首页有一段 245 秒的樱花飘落背景视频（firefly.mp4，14.94MB）。上线后发现同一个视频在不同入口表现完全不同，没有一种让人满意：

需求非常明确：完整 245 秒不截取、双平台都能播、加载快。压缩治标不治本，截取视频被直接否决，最终落在 HLS 分片方案上。

二、根因定位：Range 请求与平台能力差异#

浏览器播放 mp4 时，“边下边播”依赖 HTTP 的 Range 请求：浏览器先请求文件开头一小段（Range: bytes=0-1048575），服务器返回 206 Partial Content 和这一段的字节，浏览器解码开头就能开始播放，播放的同时继续请求后续分段。这个机制不需要服务器支持，只需要它响应 Range 头。

对本站两个托管平台做了实测：

于是 mp4 单文件在两条路上都受限：

• dev 上：不支持 Range → 15MB 必须整体下载完 → 手机上就表现为”下载界面/放不了”，电脑上点播放后长时间无反应；
• io 上：支持 Range 但线路慢 → 下载跟不上播放速度 → 卡顿。

三、视频压缩的取舍：五个版本的迭代#

在动播放方案之前，先尝试把视频压小。245 秒的视频，Cloudflare Pages 单文件上限 25MB，可用码率预算约等于 25MB × 8 / 245s ≈ 816kbps，动画画面（樱花飘落 + 人物）对这个码率非常敏感：

压缩只能把体积从 30MB 压到 15MB，“服务器不支持 Range”这个硬伤不会因为文件变小而消失——问题不在文件大小，在下载方式。这条路走到头了，必须换播放架构。

四、HLS 分片：行业标准做法#

HLS（HTTP Live Streaming） 是 Apple 提出的流媒体协议，也是当前事实上的行业标准：把视频切成若干 6 秒左右的小分片（.ts 文件）+ 一个播放清单（playlist.m3u8），播放器按需逐片拉取。YouTube、B 站、Netflix 的网页播放都是 HLS / DASH（DASH 是另一套类似标准）的思路——“分片传输”本身就是行业标准做法，而不是什么 hack。

为什么分片能绕开”不支持 Range”？因为每个分片是完整的小文件（约 355KB），服务器直接返回整个文件即可，根本不需要 Range；播放器一次只拉几片，播到哪拉到哪，总下载量随播放进度增长，而不是一次性拉完 15MB。

1
ffmpeg -y -i firefly.mp4 \
2
  -c:v libx264 -preset medium -crf 30 -pix_fmt yuv420p \
3
  -c:a aac -b:a 96k \
4
  -force_key_frames expr:gte(t,n_forced*6) \
5
  -hls_time 6 -hls_playlist_type vod \
6
  -hls_segment_filename seg_%04d.ts \
7
  playlist.m3u8

3. 播放链路设计#

播放器逻辑（BackgroundPlayer.astro）：

1
function doPlay() {
2
  var url = getCurrentUrl();
3
  // 单视频 + 有 HLS 配置 + 未启用备用源时优先走 HLS
4
  if (hlsUrl && !isMultiple && !fallbackTried) {
5
    playHls(hlsUrl, function () { playMp4(url); });
6
  } else {
7
    playMp4(url);
8
  }
9
}

• playHls()：点击播放时才动态加载 hls.min.js（约 605KB，懒加载不拖慢首屏），初始化 Hls 实例，MANIFEST_PARSED 后 video.play()；
• HLS 致命错误（data.fatal）自动 destroyHls() 并回退 mp4；
• mp4 再失败进备用源，全部失败才显示图片壁纸。

1
import('/assets/js/hls.min.js')
2
  .then(function (mod) {
3
    var Hls = mod.default || window.Hls;
4
    if (!Hls) { onFail(); return; }
5
    startWith(Hls);
6
  })
7
  .catch(function () { onFail(); });

五、双域名分工与自定义域名的真相#

• io（GitHub Pages）：主站，用户访问和微信分享的域名；页面跨域拉取 dev 的分片；
• dev（Cloudflare Pages）：视频仓库，存放 m3u8 + 41 个分片；国内下载快；_headers 配置 Access-Control-Allow-Origin: * 允许跨域。

关于自定义域名，一个常见误区是”绑了自定义域名视频就不卡了”。实际上自定义域名只是换门牌号：把 lycaonide.github.io 绑成 lycaonide.com，访问时底层还是同一台 GitHub/Cloudflare 服务器，是否支持 Range、国内线路快慢完全不变。把”域名无关”这件事说透——视频卡顿/下载界面的根因是两个平台能力问题，跟域名无关：

真正能让 mp4 直接边下边播的条件是：同时满足”有自定义域名 + 视频托管到支持 Range 且国内快的平台”（如阿里云/腾讯云 OSS/COS + CDN，或支持 Range 的国内托管）。这种情况下浏览器直接拉 mp4 就能边下边播，不需要分片；光有域名、托管还在 GitHub/CF 上，等于白绑。HLS 分片方案则对”不支持 Range”天然免疫，与域名无关。

六、CF Pages 不支持 Range 的替代方案#

先交代为什么需要替代方案：CF Pages 对视频不支持 Range 请求（HTTP Range 是浏览器”边下边播”的基础，服务器按需返回字节区间）。浏览器拿不到 Range 响应，只能整包下载 15MB 视频——这就是”下载界面”和”加载慢”的直接根源。不想用 HLS 的话，还有几条路，按推荐度排序：

① Cloudflare R2（最推荐）

• 原理：CF 自家对象存储，原生支持 Range，mp4 单文件直接边下边播；
• 怎么用：CF 控制台开 R2 → 新建 bucket → 上传视频 → 开启公共访问（Public Access）拿到直链 → 播放器改回一行 video.src = mp4 链接；
• 成本：免费额度 10GB 存储 + 100 万次读/月，本项目 14.94MB 的视频随便用；
• 优点：和 CF 生态一体，以后有自定义域名直接绑；国内访问速度比 GitHub 好；播放器代码回到最简单的单 mp4；
• 缺点：需要去 CF 开 R2（新用户开 R2 可能要绑卡，超出免费额度才计费）；R2 国内速度不算顶级，但明显好于 GitHub。

② jsDelivr CDN（免费捷径）

• 原理：GitHub 仓库文件走 jsDelivr 免费 CDN，支持 Range、国内节点速度快；
• 怎么用：视频传到 GitHub release → 用 https://cdn.jsdelivr.net/gh/用户名/仓库名@版本号/路径/视频.mp4 格式的链接；
• 限制：单文件 20MB 上限（本项目 14.94MB 刚好卡线）；jsDelivr 国内稳定性一般（2022 年出过 DNS 故障，曾大面积失效）；
• 结论：作为免费捷径可以试，但不建议当主方案——稳定性和服务政策都是外部不可控因素。

③ Workers 代理模拟 Range（不推荐）

• 原理：写一个 Worker 拦截视频请求，手动解析 Range 请求头、按字节区间切片返回；
• 问题：每次请求都要回源拉全量视频再切片，带宽浪费严重、首次延迟高；代码和调试成本不小，效果还受 Worker 执行时间限制（免费档 10ms CPU）；
• 结论：只有”必须用 CF Pages 域名 + 必须保持单文件 mp4”这种极端约束下才值得考虑。

④ 保持 HLS（本项目现状）

• 原理：ffmpeg 把视频切成 41 个 .ts 分片 + 一个 playlist.m3u8 清单，播放器按清单逐片拉取；
• 优势：对”不支持 Range”天然免疫——每个分片都是完整小文件，服务器直接返回即可，Range 根本不在依赖链里；行业标准做法（YouTube、B 站、Netflix 都是分片流）；已双平台实测正常；
• 缺点：代码比单 mp4 复杂一点（多一个 hls.js 和一批分片文件），但对本项目来说这个复杂度完全可接受。

我的建议：

• 想彻底简化代码 → 方案①（R2）：视频传上去开公共访问，播放器改回一行 video.src = mp4，hls.js 和 41 个分片全删；R2 在 Cloudflare 生态内，以后自定义域名直接绑，国内速度比 GitHub 好；
• 不想动任何东西 → 维持 HLS 现状：已经解决你的问题，是行业标准做法，零成本；
• jsDelivr 当免费捷径可以试，但稳定性要打个问号，别当主方案；Workers 模拟 Range 复杂度高收益低，直接跳过。

七、总结#

1. 问题本质：mp4 单文件播放依赖服务器支持 Range；CF Pages 不支持、GitHub Pages 线路慢，两条路都受限；
2. 压缩解决不了播放架构问题，但压缩本身依然重要——480p / 14.94MB 是清晰度与体积的平衡点；
3. HLS 分片是行业标准做法：把视频切成小分片，播放器按需拉取，绕开 Range 限制，YouTube / B 站 / Netflix 都是这个思路；
4. 域名只管门面：自定义域名不改变底层服务器能力，除非同时换到支持 Range 且国内快的托管；
5. 兜底链路：HLS → mp4 → 备用源 → 图片壁纸，任何网络下都有内容可播。