首页视频实测：同一个站跑两遍，一次90MB一次0

摘要：131个海外品牌电商站的首页，能打开的118个里有57个放了视频。把这些地址逐条问过去，166个文件合计1569098851字节，单个文件的中位数4861895字节，最大的一个162197189字节。可这张表撑不住：用真浏览器打开页面停60秒，18个站实际下载的视频字节中位数只有2628848，占它们首页挂着的文件总量中位3.25%，5个站一个字节都没下。更麻烦的是同一个站跑两遍答案也未必一样——graza.co两次分别是88924728和0，anker.com是2608264和51910，而casper.com两次差不到千分之一。

先说一个让我自己有点尴尬的过程。这轮实测本来是奔着一句话去的：首页上那些自动播放的背景视频，到底有多贵。第一遍量完，我手里有一张很唬人的表——44个站、166个视频文件、合计15亿多字节，最大的单个文件162197189字节。按站算，随便挑一个首页，视频体积是它HTML的16倍。

然后我打开真浏览器又跑了一遍，那张表基本作废了。再跑第三遍，第二张表也不太站得住。

这篇写的就是这三张表之间的落差：页面上挂着多大的文件、用户真正下了多少、以及下次再来还是不是这个数，是三个不同的问题，而多数性能报告只回答了第一个。

首页上到底有多少站在放视频？

样本沿用这一系列一直在用的那131个海外品牌电商域名，覆盖服饰、家居、3C、户外、美妆几大类。这一轮首页返回200的118个，剩下13个是403或者超时，直接出局。同一批域名此前量过样式表里用不上的规则与前端库停在哪一年，这次换到视频这一层。

118个里，首页HTML中能找到视频痕迹的有57个，占48.3%。这57个又分成两拨：47个站老老实实写了<video>标签，一共273个；另外10个站HTML里一个<video>都没有，视频地址藏在脚本或者内嵌的JSON数据里，要等脚本跑起来才会变成真正的元素。

每个站放几个视频，分布很偏。中位数是2个，四分位落在1个和6个，而最多的那个站misen.com在首页写了83个<video>标签。83这个数字第一次跑出来的时候我以为是正则写错了，翻了原始HTML才确认——它的商品列表里每一张卡片都配了一段悬停播放的短片。

这些视频是怎么被安排的？

273个标签的属性统计如下。这张表比后面所有的字节数都更能说明问题，因为它描述的是这些视频被设计成什么样。

静音、不全屏、循环、自动播放，这四件事凑在一起是一个很明确的用途声明：它不是给人点开看的内容，是当动态背景用的装饰。只有14个标签给了播放控件，也就是说273段视频里有259段，用户连暂停都做不到。

真正扎眼的是最后两行的落差。166个自动播放的视频里，有132个没写poster，涉及20个站。poster是视频加载出来之前显示的那张静态图。没有它，视频还没解码完的那几百毫秒里，那块区域就是一片空白或者纯色。

preload这个属性上，有5个标签写坏了

preload告诉浏览器要不要提前抓视频数据。273个标签的取值分布是：none128个、干脆没写84个、metadata44个、auto12个。加起来268个。

剩下5个的取值是”none”——注意那两个引号，它们不是ASCII的直引号，是排版用的中文弯引号。写模板的人本意是preload="none"，结果多套了一层排版引号，浏览器读到的属性值是一个带引号的四字符串，不在规范列出的任何一档里。按MDN对video元素各属性的说明，取值不合法时浏览器按自己的默认策略处理，而各家的默认策略并不是none。这个站本来想省的那份流量，一分都没省下来。

这类错误的特征是不报错、不显红、任何构建工具都不会拦。要发现它只能去读渲染出来的HTML原文。同类静默失效在资源提示那一轮里也出现过，写法合法、指向作废。

还有75个标签，压根没带地址

273个<video>里，有75个既没有src也没有子级的<source>，占27.5%。它们是留给脚本填的空壳，滚到视口里再由懒加载脚本把地址塞进去。这意味着任何只读HTML的工具——包括我自己第一轮那个脚本——都会低估这个站的视频规模。这跟空壳首页那一轮遇到的是同一件事的两面：HTML里看得见的，不等于页面上会发生的。后面会看到，这个低估有多大。

HTML上挂着的这些文件，到底有多大？

把能取到的地址逐条发HEAD请求，拿不到Content-Length的用Range: bytes=0-1读Content-Range的分母。每个站最多量6条不同地址，避免把请求压力堆到同一家CDN上。

44个站量到了体积，166个文件，合计1569098851字节。分布如下：

166个文件里有132个超过1兆字节，29个站的合计超过10兆字节。视频合计除以同站首页HTML的字节数，中位是16.3倍，最大的dji.com是377倍。

还有一个细节顺手记下来：这些文件的Cache-Control非常慷慨，116个是max-age=31557600，也就是整整一年。视频这类内容一旦生成就不会再改，给一年完全合理，跟带哈希的静态资源是同一套思路。记住这个数字——同一批站的HTML文档，中位缓存寿命是0秒，而Cache-Control这条指令写给谁这件事本身就常被搞错。

文件名里就写着码率

Shopify托管的视频有个方便的地方：文件名里带着转码档位。166个文件里有60个能读出这两项，分布是HD-1080p38个、SD-480p12个、HD-720p10个；码率中位3.0Mbps，最大7.2Mbps，其中12个文件是7Mbps以上。

7.2Mbps的1080p片段，用途是首页顶部那块横幅的动态背景。它会被缩到几百像素宽显示，也可能被手机用户在移动网络上打开——这跟srcset写着1920w却发140宽的图正好是反向的错配。转码档位这件事没人替站主做决定，上传什么，平台就存什么。

换成真浏览器停60秒，实际下了多少？

到这一步为止，所有数字都来自“文件有多大”。这把尺子有一个致命的假设：视频会被完整下载。为了检验它，我用无头Chromium把18个站的首页各打开一次，1440×900的视口，全程记录每个请求的响应体字节数，在第10秒、第25秒、第40秒、第60秒各拍一次累计值，第25秒开始缓慢滚到页面底部。

18个站的真实下载中位数是2628848字节，最大88924728，5个站是0；占各自文件总量的比例，中位3.25%，最大231.8%。这张表和上一张表用的是同一批站、同一天的数据，唯一的差别是量法。

为什么有5个站一个字节都没下

decathlon.com、liquiddeath.com、nomadgoods.com、oclean.com、quince.com这五个站，HTML里明明能读出视频地址，60秒里视频请求数为零。原因不止一种：有的视频元素在首屏之外很深的位置，滚动没滚到；有的靠交互触发；quince.com那批放在Contentful上的短片是商品卡片的悬停效果，鼠标不移上去就不会加载。判断一个资源到底会不会被请求，光看标记是不够的，这一点跟条件请求那一轮的教训一致。

这几个站不是“做得好”，只能说这些字节的账单还没到期。换一个真人来用，比如把某个品类逛完，账单随时会出现。

为什么有两个站反过来超过100%

graza.co是最极端的一个：我从它HTML里只解析出4条视频地址，合计38359108字节；真浏览器跑完60秒，下了88924728字节。多出来的那些是脚本注入的，只读HTML永远看不到。

顺带说一句它的档位：它的视频清一色HD-1080p-7.2Mbps，一档没降。一个卖橄榄油的独立站，首页停一分钟能走掉将近90兆流量。misen.com超过100%的原因相同——83个卡片视频里被真正播起来的那些，也没有全部进过我第一轮的清单。

滚动这个动作值多少字节

anker.com、chubbiesshorts.com、dji.com、eufy.com、ikea.com、graza.co这几个站，在第25秒之前视频字节几乎没有增长，滚动开始之后才动。chubbiesshorts从38742跳到14073828，ikea从93276跳到6856025。懒加载没有让这些字节消失，只是把账单推迟到用户往下滚的那一刻。

顺便记一次判据失效

这张表的第一版数字比现在大一截，因为我最初判断“哪些请求算视频”时把content-type为application/octet-stream的响应也算了进去。这一档里混着字体文件：dollarshaveclub那个数原本是371779，其中149549字节是三个woff2；hellotushy多算了10969字节的另一个字体。判据放宽一格，结论就多出六成。改成只认video/开头、含mpegurl、或者路径后缀是视频与分片后缀这三条，数字才干净。

同一个站再跑一次，答案还一样吗？

这是本轮最该做、也最容易被跳过的一步。上面那张表是每个站跑一次得到的。同一台机器、同一套动作、同一个窗口，隔一段时间再跑一遍，结果如下。

12个站里有7个两次几乎分毫不差，5个跨了一个数量级以上。graza.co第一次下了88924728字节，第二次60秒里一个字节都没有——同一个页面、同样的滚动动作。anker.com两次差了50倍。

这条分界线不在文件大小上，在视频被挂在哪儿。两次一致的那七个站，视频要么是首屏一条无条件自动播放的（casper），要么是固定位置滚到就播的一条（eufy、chubbiesshorts），要么根本不播（quince、oclean）。两次差一个数量级的那五个，无一例外是把视频铺在商品卡片或者轮播里的：graza九条、misen八十多条、insta360两条横幅轮播、ikea八条、anker多条——播到哪一条、播多久，取决于滚动停在哪、轮播转到第几张、脚本那一刻决定加载谁。

那这三个数字里，哪一个能当结论用？

一个都不能单独用，但它们合起来能说清一件事。

文件大小是个上界，而且非常松。casper.com首页挂着147277439字节，浏览器只取了7010224，占4.8%；graza.co首页“只”挂着38359108，浏览器一次取了88924728，超出231.8%。两个方向都能错，而且错得都不小。

单次实测是个样本，不是常数。3.25%这个中位数写进报告很好看，可它背后是从0到231.8%的分布，而同一个站重跑一次还能再摆动50倍。拿它去承诺“视频只会下3%”，第一个较真的人就能把你推翻。

真正立得住的说法只有一句：这笔流量对一部分站是确定的，对另一部分站是一个宽到没法做预算的区间，而决定属于哪一类的是版面结构，不是文件本身。首屏一条无条件自动播的视频，代价可以精确到字节；铺在卡片和轮播里的几十条，代价在零和几千万之间摆动——它既不能被算作“已经省下了”，也不能被算作“反正会下”。

保哥前阵子帮一个做户外装备的独立站看首屏，团队拿着一张资源清单说视频占了首页体积的九成，准备整段砍掉。真跑一遍才发现那段视频在移动端根本不触发自动播放，占的是清单上的九成，不是账单上的九成——该砍的是另外几个一直在下的第三方脚本。这类误判的代价不在于改错了什么，在于把真正的问题放过了。顺着这条思路，一个404页面要多少字节也是同一类被清单遮住的开销。

那到底是什么在决定这笔账单？

把18个站的差异摊开，决定权落在四件事上，一件都不在文件大小里。

第一件：这段视频会不会真的播起来

不播就不下。五个零字节的站是这一条的极端形态。判断依据不是autoplay写没写，而是这个元素有没有进入触发条件——视口位置、交互、脚本延迟启动，任何一环没满足，账单就不出现。而这一环恰恰是最不稳定的，上面那张两次对照表说的就是它。

第二件：播的时候用的是哪一条

casper.com是最清楚的例子。它首页HTML里挂着三条HD-1080p-7.2Mbps的片段，单条三千多万字节；真浏览器实际取的却是另一条HD-1080p-2.5Mbps的，7010224字节，两次实测都是这一条。同一个平台生成的多档转码，播放器按自己的判断挑了一档，而挑的不是HTML里最显眼的那条。

第三件：分不分片

hellotushy.com首页那个162197189字节的1080p文件，是这轮样本里最大的单个视频。真浏览器一次都没碰它——它取的是同一段素材的另一套地址：SD-480p.1.0Mbps.hls的分片流，四个分片加两份索引，合计2339746字节。

这就是HTTP实时流分片的价值。按RFC 8216对分片流的定义，播放器只取当前需要的那一段，随时可以切档，也随时可以停。而一个渐进式下载的mp4一旦开始播，浏览器就会一路把它拉完。样本里529条地址是mp4，96条是m3u8——用了分片的还是少数。选哪种传输方式跟服务器只压哪几种类型一样，是个出厂默认值决定的问题。

第四件：什么时候触发

就是上面滚动那一段。这一条决定的不是总额，是账单出现的时刻，而这个时刻恰好决定它压不压首屏。

手机用户拿到的是同一个文件吗？

source元素的media属性可以按屏幕宽度给不同的文件。273个视频标签下面的所有<source>里，写了media条件的只有22条。

正面例子是ikea.com。它同一块位置准备了两份：MS_Germany_Desktop为285580字节，MS_Germany_Mobile只有16121字节。差了17倍。这两个文件名摆在一起，说明这件事完全做得到，只是做的人少。

misen.com走的是另一条路——它把所有视频地址转到了一家图像与视频优化服务上，实测每条压到200万字节上下，那83个卡片视频两次跑下来也就一千多万。把档位交给一个会按设备判断的中间层，比在模板里手写media条件更容易做对，这是两个正面例子的共同点。

剩下那些站，手机用户和桌面用户拿的是同一个1080p文件。这件事在数据上表现得很沉默——不会报错，也不会掉排名，只会体现在某些地区的跳出率上。想把它变成可以监控的数字，得先把多层缓存与Core Web Vitals的关系理清楚。

poster这一张图，为什么比想的重要？

132个自动播放的视频没写poster。这不只是空白几百毫秒的问题。

按web.dev对最大内容绘制的说明，视频元素参与LCP的候选判定，用的是它的封面图或者第一帧。没有poster，这块区域在视频解出画面之前不构成有效的内容绘制，LCP的计时点就会往后推——推到视频真的解出第一帧为止。而自动播放的背景视频通常正好占着首屏最大的那块面积。

说白了，省掉一张几十KB的poster，可能让LCP多等上几百毫秒，而这几百毫秒是Core Web Vitals实打实要算的。这笔账在任何“视频文件多大”的表格里都看不到，跟关键渲染路径上那些阻塞项属于同一个预算池子。

顺带一提，Chrome的自动播放策略要求视频静音或者用户有过交互才允许自动播放。样本里89.4%的标签写了muted，说明这条规则大家都知道；但知道要静音和知道要配poster显然不是同一批知识。

视频这件事，对搜索到底有多大影响？

得分两层说，别混在一起。

第一层是性能。视频影响LCP和交互延迟，这一层是实打实的，也是本文全部数据落脚的地方。它跟页面体积对抓取的影响不是一件事——抓取看的是HTML本身，视频是HTML之外的资源，Googlebot抓页面时并不会去下你的mp4。

第二层是视频本身能不能被收录。Google的视频索引文档写得很清楚：要被当成视频内容处理，需要有专门的落地页、可抓取的视频文件或者播放页、以及配套的结构化数据。首页那段循环播放的背景片段，一条都不满足——它没有独立页面，没有标题，没有缩略图，本来也不是给人看的内容。

所以别指望背景视频带来视频搜索流量。真要做视频SEO，那是自托管与嵌入视频的收录机制那一套，跟首页装饰是两条完全不同的路。这一点在AI搜索时代的视频SEO里变化更大，但方向没变：得先有一个真正以视频为主体的页面。

自己站上怎么量一遍，按什么顺序改？

整套动作大概二十分钟，不需要任何付费工具。

第一步：先数标签，再数字节

打开首页，在开发者工具的元素面板里搜<video>，记下三个数：总数、带autoplay的数量、带poster的数量。第三个数除以第二个数如果不到一半，先去补poster，这是投入产出比最高的一步。

第二步：拉一条时间曲线，而且要跑两遍

网络面板清空，硬刷新，什么都别动等30秒，记下传输总量；再慢慢滚到底，再等30秒，记第二个数。然后整套重来一遍。两遍的差就是你这个页面的不确定区间，它比任何单次数字都重要——差得越多，说明你的视频越依赖时机，越没法给它做预算。如果你的站前面挂着CDN，记得按边缘缓存的分层规则确认量到的是回源还是命中。

第三步：确认播放器挑的是哪一条

在网络面板里按媒体类型筛选，看实际请求的URL。如果它跟你在HTML里写的那条不一样，说明中间有一层在替你选档——这是好事，但你得知道它在。如果一样，而且那条是1080p高码率的，那就是你自己在付这笔钱。

第四步：给移动端单独准备一份

要么用<source media="(max-width: 768px)">手写两份，要么把视频托管交给一个会按设备判断的服务。ikea和misen各自代表了这两条路，都跑得通。

第五步，也是最容易被跳过的：问一句这段视频要不要

273个标签里259个连播放控件都没有。一段用户既不能暂停、也不能全屏、还听不见声音的循环片段，它在页面上承担的功能，很多时候一张静态图加一点CSS动效就能替代。静态图那条路也不是没有代价，图片压缩工具的实测里就有把135字节的图标压成560字节的例子。但这个问题该在做设计稿的时候问，不该等到优化性能的时候才问。

这一轮的口径限制，一次说清

• 每站最多量6条地址。视频地址多的站（govee.com在HTML里出现了219条）只抽了前6条，所以“每站合计”是个下界，不是全量。
• 60秒窗口是人为的。真实用户停留时间从三秒到十分钟都有，窗口拉长，几个还在下的站数字会继续涨。
• 只测了桌面视口。1440×900、有线网络、没有省流量模式。移动端的自动播放行为、数据保护模式、以及运营商网络下的表现都不在这批数据里。
• 重复测量只做了12个站两次。上面那张对照表足够说明不稳定这件事，但两次样本算不出置信区间，只能读方向。页面本身也会自己抖动，做两次对比之前先量一条基线这条规矩在这里同样适用。
• 无头浏览器不等于真人。它不会把鼠标移到商品卡片上，所以所有靠悬停触发的视频都被系统性低估了——quince.com那两个零，多半就是这么来的。

另外一句方法上的提醒：只读HTML统计资源，在这个题目上是系统性低估的。graza.co的HTML里只有4条地址，实际跑起来远不止。这和第三方脚本会拉进HTML里看不到的域名是同一类现象，只是这次涨的是流量不是域名。想量准，就得让页面真的跑起来，这一点JS渲染那一轮已经验证过一次了。

常见问题解答

首页放自动播放视频，会不会直接拖低Core Web Vitals？

不是必然，取决于它占不占首屏最大那块面积、有没有poster、什么时候触发。数据里有站在60秒内一个视频字节都没下，那对LCP就没有影响；也有站首屏顶部就是一段高码率1080p片段，那影响会很直接。判据是打开网络面板看它是不是在首屏渲染完成之前就开始传输。

把视频改成懒加载，是不是就安全了？

懒加载改变的是账单出现的时间，不是金额。实测里好几个站在滚动之后才开始下载，chubbiesshorts一次就下了14073828字节。用户往下逛的时候网络照样被占满，只是不影响首屏那个指标而已。如果目标是省流量，得从档位和文件本身入手。

为什么同一个页面跑两次，视频字节差那么多？

因为视频加不加载取决于一串时机：脚本什么时候注入地址、元素什么时候进视口、轮播那一刻转到第几张。这些都不是确定的。实测12个站跑两遍，7个几乎分毫不差，5个差一个数量级以上，graza.co甚至一次88924728、一次0。视频铺得越散、越依赖轮播和滚动，这个摆动越大。

我怎么知道自己站上那段视频到底多大？

别看后台上传时显示的大小，那通常是原片。去网络面板里按媒体筛选，看实际请求的URL和响应体大小。Shopify托管的视频文件名里直接带着分辨率和码率，比如HD-1080p-7.2Mbps，一眼就能读出来是哪一档。

HLS分片流是不是一定比mp4好？

对长片和需要切档的场景是的，播放器只取当前段。但分片流要多一次索引请求，还要播放器支持，短到几秒的循环背景片段用它反而麻烦。样本里529条地址是mp4、96条是m3u8，这个比例大致反映了实际取舍。

把preload写成none，到底能省多少？

能省的是页面加载阶段的预取，不能省播放本身。真要它生效，得确认属性值写对了——这轮实测里就有5个标签把值写成了带排版引号的形式，浏览器不认，等于没写。

没有poster会怎样，真的有那么严重吗？

视觉上是首屏空一块，指标上是LCP的计时点被推到视频解出第一帧。166个自动播放的视频里132个没写，这是这轮实测中覆盖面最广的一个可修项，而且改起来最便宜——一张几十KB的静态图。

这批数据能不能代表我的站？

只能当参照。样本是131个国际品牌电商域名，规模、预算、技术栈都偏上，Shopify托管占了很大比例。中小独立站的视频通常更少但更没优化，方向一致而绝对数值不一样。真要下结论，还是得按上面那五步在自己站上跑一遍，而且第二步一定要跑两遍。

权威参考资料