图片与视频资源加载的性能控制

图片与视频资源加载的性能控制，本质上是在回答一个问题：一个页面里到底该放多少视觉资产，以及这些资产在什么时间点进入网络。个人网站尤其需要面对这个矛盾——想展示作品，又不想让服务器和带宽成为瓶颈。这里的控制手段并不复杂，核心是三个方向：压缩体积、延迟加载、按需提供不同规格。

先分清资源类型，再谈优化手段

图片和视频在网页中的加载行为有本质区别。图片是独立的请求，浏览器会根据 HTML 中的 src 或 CSS 中的 background-image 去获取文件；视频则更复杂，<video> 标签默认会加载元数据，而 preload 属性决定了浏览器是否提前下载视频内容。

处理资源前，先给文件分类。作品展示图、证书扫描件、背景视频、附件文档，它们的用途不同，加载策略也不同。作品图需要清晰度，但用户未必会全部看完；背景视频是装饰性的，即使加载失败也不该影响主体内容；证书和附件属于低频访问资源，不需要主动加载。

一个容易出错的地方是：把视频当作图片来优化。图片可以用 loading="lazy" 让浏览器延迟加载，但视频的懒加载需要手动控制 preload 属性，或者干脆不设置 src，等用户滚动到附近时才用 JavaScript 赋值。如果直接给视频加 loading="lazy"，浏览器会忽略这个属性，视频仍然会按默认策略加载。

首屏资源：降级方案是必须的

首屏是用户进入页面后第一眼看到的内容，这里的资源加载失败影响最大。假设页面顶部有一个背景视频，如果视频文件因为网络问题没有加载出来，页面应该呈现什么？如果只放一个 <video> 标签，空白背景会显得页面没有完成。

降级方案可以这样写：在视频容器下方放置一张压缩过的封面图，用 CSS 把图片设为背景，视频元素覆盖在图片上方。视频加载成功并开始播放后，图片自然被遮挡；视频加载失败时，图片仍然显示。这个方案不依赖 JavaScript，纯 HTML 和 CSS 就能实现。

```html
<div class="hero">
<img src="cover.jpg" alt="" class="hero-bg">
<video class="hero-video" muted autoplay loop preload="none">
<source src="intro.mp4" type="video/mp4">
</video>
</div>
```

这里的关键是 preload="none"，它告诉浏览器不要主动下载视频内容，只有用户点击播放或 JavaScript 触发播放时才加载。配合 CSS 让视频绝对定位覆盖在图片上，图片在视频未加载时自然可见。

需要检查的边界情况是窄屏设备。手机上视频播放可能受系统省电模式或自动播放策略限制，此时图片背景会一直显示，所以封面图本身要足够清晰，不能只是模糊的占位。另外，如果用户使用键盘操作，Tab 键会聚焦到视频元素上，需要确认聚焦状态有可见样式，否则键盘用户无法感知当前焦点位置。

列表页与详情页：封面图和懒加载的分工

作品列表页如果直接加载所有大图，页面体积会迅速膨胀。这里的控制手段是：列表页只显示压缩封面，点击进入详情页后再加载完整大图。

封面图的压缩程度可以比详情图更高，因为它在列表中的显示尺寸通常较小。但要注意，封面图不能只做尺寸缩小而不做文件压缩——一张 4000px 宽的原始照片缩放到 400px 显示，浏览器仍然要下载完整的原始文件。正确的做法是在导出时就把图片调整到实际需要的尺寸，再配合压缩工具降低文件体积。

懒加载适合列表页的图片。loading="lazy" 是浏览器原生支持的属性，不需要引入额外脚本。它的行为是：图片进入视口附近才开始加载，用户快速滚动时，未进入视口的图片不会被请求。检查懒加载是否生效，可以在浏览器开发者工具的 Network 面板里观察，滚动页面时应该看到图片请求是分批出现的，而不是页面加载时一次性全部发出。

一个容易忽略的问题是懒加载与布局偏移的关系。图片没有固定尺寸时，懒加载会导致页面在图片加载完成后突然跳动。给图片设置 width 和 height 属性，或者用 CSS 的 aspect-ratio 预留空间，可以避免这个问题。这在移动端尤其重要，因为手机屏幕高度有限，布局跳动会打断阅读。

大文件的存放位置：权限控制与服务器负载

私有文件，比如证书原件、PDF 文档，不适合放在公开目录里直接引用。即使文件名是随机字符串，只要链接被分享出去，任何人都能访问。这类文件应该放在需要登录或权限验证的目录下，由后端接口控制访问。

从服务器负载的角度看，大文件放在 Web 服务器的静态目录里，每次访问都会占用带宽。如果网站访问量不大，这个问题不突出；但一旦某个文件被分享到社交平台，短时间内的大量请求可能拖慢整个服务器。把大文件迁移到对象存储服务，可以减轻 Web 服务器的压力，但这属于架构调整，不是前端代码能解决的问题。

判断文件是否适合放在 Web 服务器上，可以看两个条件：文件是否经常被访问，以及文件体积是否超过几 MB。低频访问的小文件放在服务器上没有问题；高频访问的大文件应该考虑外部存储或 CDN。

检查与维护：记录修改原因比工具名称更重要

性能优化的效果需要验证，不能只看页面能不能显示。检查时至少要看三个层面：资源请求数量、单个文件体积、加载完成时间。浏览器开发者工具的 Network 面板可以查看每个请求的状态码和传输大小，如果发现某个图片返回了 200 但传输体积远大于预期，说明文件没有压缩到位。

另一个检查维度是不同网络环境下的表现。电脑上的宽带网络加载很快，不代表手机 4G 网络下体验一致。开发者工具里可以模拟较慢的网络速度，观察页面在弱网下的加载顺序是否合理——首屏内容是否优先出现，懒加载的图片是否在用户滚动时才请求。

维护层面容易出问题的地方是：修改了某个资源文件，但忘了更新引用它的代码。比如把视频文件从 MP4 换成了 WebM，但 HTML 里的 <source> 标签没有同步修改；或者压缩了图片，但 CSS 里引用的还是旧文件名。这些问题的排查成本很高，所以文件命名最好包含版本信息，修改时同步更新引用。

记录修改原因也很有价值。过几个月后回看代码，如果只看到 cover-v2.jpg 这个文件名，很难想起当时为什么压缩到 80% 质量。在代码注释或项目文档里写一句“原图 2.3MB，压缩后 180KB，质量损失在可接受范围”，后续维护时就能判断是否还有进一步优化的空间。

资源加载性能控制不是一个一次性的任务，而是随着内容增加不断需要调整的过程。每次新增图片或视频时，先问三个问题：这个文件必须在这个页面出现吗？它需要以原始质量加载吗？用户滚动到它之前，浏览器有必要下载它吗？带着这三个问题去处理资源，比套用任何固定规则都更可靠。