视频打开慢时很容易先想到重新压小一点。这次我对同一段海浪做了三组读取测试，先保持画面不变。还是同一段视频。开始等待却从接近6秒降到了不到1秒。变化来自索引位置和读取方式。串联视频工具时值得先试这一步，再考虑调画质。
对照素材取自冰岛海浪，制成了1433114字节的普通MP4。视频长8秒、960×540、25帧每秒且无音轨。头尾两版通过复制重封装把moov放在媒体数据之前或之后。moov可以先理解成播放需要的一部分描述信息。两版mdat媒体数据的哈希一致，这次搬动没有改动编码内容。
我在同一轮也用图映 ImgIng的中文工作台试了完整WebM的体积优先MP4导出。那个结果带分片结构，和本篇普通头尾对照分开记录。本段使用固定的8秒静音文件来单独查看索引位置的影响。下面两图是本轮受控复现页面的截图，并非图映产品界面。
先保持索引在文件尾部，仅调整服务端的Range响应。Range是浏览器请求某一段字节的方式。服务端忽略它并顺序返回时，Firefox两次首帧分别用了5.785秒和5.786秒。允许按范围返回后就变成0.883秒和0.942秒。相同文件没有重新降低码率就出现了不同的等待。
两张图里都已经播放成功。截图时点得说清。两次实验都在到达第6秒画面后截图，不能凭海浪是否出现比较起播。应该看下方"首帧显示"：单次读数约0.94秒与5.79秒。两次结果的中位数则为0.913秒与5.786秒，和截图显示的单次读数分别记录。尾部信息需要读到，却未必需要顺着读完中间所有数据。本轮支持Range时的浏览器会先去尾部取所需字节再回到前方。服务端忽略范围请求就走不了这个近路，本次成功起播的尾部版只能等顺序读取到尾部。路径发生变化时，画面仍然保留着原来的清晰度。
第三组在服务端继续忽略Range的前提下把索引前移。Firefox两次首帧为0.599秒和0.608秒，中位数0.604秒。这组和尾部且忽略Range的5.786秒相比只改变了索引位置。前一组对照改的是读取响应。两步分别对照就能看出"搬到前面"和"能取文件后段"各自的作用。
图里还有一个容易看反的数字。较早显示首帧的那次随后跳到6秒用了约3.91秒，较晚起播的那次跳转却约0.03秒。后者已经顺序读到了文件尾。这个跳转数字不能倒推它起播更快。我把首帧等待和后续跳转分开记，没有只选较小的那个数宣布胜出。
测试采用Firefox151测试构建和本地HTTP服务。每秒256 KiB的写入额度由所有活动视频响应共享，各请求开始另等80毫秒。每种条件只跑两次，首帧计时终点为首次视频帧通知。这不是线上平台测速，也没有把网络往返完整模拟出来。结果能说明当前对照中的原因，不能给所有浏览器承诺相同的提升。
素材为Alexander Grebenkov的Ocean waves at Lækjavik beach, Iceland，采用CC BY 3.0许可。本次截取前8秒、缩放、移除音轨并转为MP4，再制作索引头尾两版。图片取自2026年9月30日核验的真实复现页面，海浪不是我拍摄的。
遇到类似等待时，我会保留一份画面不变的对照文件，再核对索引位置与服务端实际响应。把这两个条件分开改，每次先比较首帧等待。需要拖动时再记另一项结果。调低画质和换服务如果同时进行，就难以分清哪个动作起了作用。当前这段海浪不需要靠再次损失画质来证明差别。