视频懒加载通过延迟非视口内视频的加载，提升页面性能与用户体验，主要采用loading=”lazy”属性或IntersectionObserver API实现，结合poster图、明确尺寸设置及多格式支持可优化效果，但需注意CLS、SEO及兼容性问题，并在首屏关键视频等场景避免使用。
视频的懒加载，说白了，就是让那些不在用户当前视口范围内的视频先“歇着”，不急着下载和渲染。只有当用户滚动页面，视频即将进入视线时，我们才真正去加载它。这对于提升网页加载速度、节省用户流量，以及优化整体用户体验来说，简直是神来之笔。尤其是那些图片、视频内容丰富的网站，没有懒加载，用户打开页面时可能会等到花儿都谢了。
解决方案
实现HTML视频懒加载，其实有多种策略，从浏览器原生支持到自定义JavaScript，各有各的妙处。
最直接、最现代的方式是利用浏览器原生的loading="lazy"属性。这简直是前端工程师的福音，一行代码就能搞定：
这里我特意加了poster属性，它能在视频加载前显示一张预览图，提升用户体验。width和height也别忘了，这能帮助浏览器预留空间，避免视频加载后页面布局跳动（Cumulative Layout Shift, CLS）。不过，loading="lazy"目前主要针对视频本身的文件加载。对于source标签里的src，它可能不会直接处理，所以很多时候我们还需要结合JavaScript来更精细地控制。
立即学习“前端免费学习笔记（深入）”；
对于更精细的控制或者需要兼容旧版浏览器的情况，IntersectionObserver API是我的首选。它能高效地监测一个元素是否进入或离开了视口，性能比传统的滚动事件监听要好得多。
首先，HTML结构可以这样：
然后，JavaScript部分：
document.addEventListener("DOMContentLoaded", function() { const lazyVideos = [].slice.call(document.querySelectorAll("video[data-src]")); if ("IntersectionObserver" in window) { let lazyVideoObserver = new IntersectionObserver(function(entries, observer) { entries.forEach(function(video) { if (video.isIntersecting) { const lazyVideo = video.target; const source = document.createElement('source'); source.src = lazyVideo.dataset.src; source.type = lazyVideo.dataset.type; lazyVideo.appendChild(source); lazyVideo.load(); // 触发视频加载 lazyVideo.removeAttribute("data-src"); // 清除data-src，避免重复加载 lazyVideo.removeAttribute("data-type"); lazyVideoObserver.unobserve(lazyVideo); // 停止观察已加载的视频 } }); }); lazyVideos.forEach(function(lazyVideo) { lazyVideoObserver.observe(lazyVideo); }); } else { // Fallback for browsers that don't support IntersectionObserver // 这种情况下，可以考虑直接加载，或者使用传统的滚动事件监听，但性能会差一些 lazyVideos.forEach(function(video) { const source = document.createElement('source'); source.src = video.dataset.src; source.type = video.dataset.type; video.appendChild(source); video.load(); video.removeAttribute("data-src"); video.removeAttribute("data-type"); }); }});
这段JS代码的核心思路是：当视频元素进入视口时，我们动态地创建标签，将其data-src和data-type属性值赋给src和type，然后添加到元素中，并调用load()方法触发视频加载。一旦加载完成，就停止对该视频的观察。
除了懒加载，还有哪些视频带宽优化技巧？
说实话，仅仅实现懒加载只是优化视频体验的第一步。想要真正把带宽榨干，让用户流畅观看，还有很多“骚操作”可以尝试。我个人觉得，这些技巧结合起来，效果远比单一优化要显著得多。
视频格式和编码的选择： 这是最基础也最重要的。H.264（AVC）是目前兼容性最好的，但H.265（HEVC）和Google的WebM（VP9/AV1）在相同画质下能提供更高的压缩率，文件更小。特别是AV1，那是未来的趋势，虽然编码耗时，但播放效果和压缩比非常惊人。我的建议是，提供多格式视频源，让浏览器选择最优的，比如：
分辨率和码率自适应： 别指望所有用户都有5G或光纤。根据用户的设备和网络状况，提供不同分辨率和码率的视频版本，这是非常关键的。HLS (HTTP Live Streaming) 和 MPEG-DASH 是实现这种自适应流媒体播放的常用技术。虽然这通常需要专门的视频处理服务，但对于大型视频内容平台来说，这是标配。
视频压缩和转码： 即使是同一种格式，通过调整编码参数，比如降低码率、调整GOP（Group of Pictures）大小、使用Two-Pass编码等，也能在不明显牺牲画质的前提下，大幅减小文件体积。FFmpeg是这类操作的瑞士军刀，功能强大到令人发指。
CDN (Content Delivery Network) 分发： 这几乎是所有静态资源优化的黄金法则。将视频文件部署到CDN上，可以利用CDN在全球各地的节点，将内容分发到离用户最近的服务器，大大减少传输延迟和提高下载速度。
预加载和预连接： 虽然和懒加载有点“反向操作”，但对于那些确定会播放的视频（比如用户点击播放按钮后），可以提前做一些准备。 可以告诉浏览器“这个视频我很快就要用，你先去下载吧”。而 则可以提前建立与CDN服务器的连接，节省DNS解析和TCP握手的时间。但请注意，预加载要慎用，只针对那些用户极有可能互动的视频，否则可能适得其反，浪费带宽。
懒加载视频实现中常见的坑和解决方案是什么？
在实际操作懒加载视频的时候，我踩过不少坑，有些问题不注意真的会影响用户体验甚至网站性能。这里我总结几个比较常见的，希望能帮大家避开。
用户体验差：视频加载慢，Placeholder图不清晰或缺失。
问题： 懒加载虽然节省了带宽，但如果视频加载需要很长时间，或者加载前的占位图模糊不清、与视频内容不符，用户会觉得体验很糟糕。页面上出现一个大大的空白区域或者一个难看的默认图标，这可不是我们想要的。解决方案：高质量Poster图： 为每个视频准备一张高质量、能准确反映视频内容的poster图片。这张图应该足够吸引人，尺寸也应该和视频保持一致，避免加载后出现布局跳动。骨架屏或加载指示器： 在视频真正加载出来之前，用一个简单的骨架屏或者一个旋转的加载指示器来填充区域，告诉用户“这里有内容，正在加载中”，这比空白要好得多。预加载关键元数据： 虽然视频文件本身是懒加载的，但可以考虑预加载视频的元数据（比如时长、分辨率等），这样在加载指示器或骨架屏上可以显示更多信息。
SEO问题：搜索引擎抓取不到视频内容。
问题： 如果视频内容完全依赖JavaScript动态加载，搜索引擎的爬虫可能无法正确解析和索引这些视频，导致你的视频内容在搜索结果中表现不佳。解决方案：标签： 在标签内部使用标签，为不支持JavaScript的浏览器或爬虫提供一个静态的视频链接或描述。结构化数据（Schema.org VideoObject）： 使用Schema.org的VideoObject标记来描述你的视频内容，包括标题、描述、缩略图URL、上传日期等。这能帮助搜索引擎更好地理解和索引你的视频。Sitemap中的视频信息： 在你的网站Sitemap中包含视频相关的URL和元数据，直接告诉搜索引擎你的视频在哪里。
JavaScript禁用或失败：
问题： 少数用户可能禁用JavaScript，或者由于网络问题导致JS文件加载失败。这时候，依赖JS的懒加载就会失效，用户可能根本看不到视频内容。解决方案：优雅降级（Graceful Degradation）： 确保在JavaScript不可用时，用户仍然能够访问到视频内容。比如，可以在标签中直接使用src属性作为备用，但这样做就失去了懒加载的优势。更好的做法是结合，或者在没有JS的情况下，直接加载视频，尽管这会增加初始页面负担。
CLS (Cumulative Layout Shift) 问题：页面布局跳动。
问题： 如果视频元素在加载前没有明确的尺寸（width和height），当视频加载完成后，它会突然占据空间，导致页面其他元素向下或向上跳动，严重影响用户体验，也是Core Web Vitals中的一个重要指标。解决方案：明确设置width和height： 这是最直接有效的方法。在HTML中为标签明确指定width和height属性。CSS aspect-ratio： 如果视频是响应式的，可以使用CSS的aspect-ratio属性来保持视频的宽高比，例如aspect-ratio: 16 / 9;。这比传统的padding-bottom hack要优雅得多。
什么时候不应该使用视频懒加载？
虽然视频懒加载好处多多，但它并非万能药，也有些场景下，我个人觉得不使用懒加载反而会更好。过度优化有时反而是画蛇添足。
首屏关键视频（Hero Video）：
如果你的网站首页顶部有一个作为“门面”或品牌宣传的背景视频，或者是一个用户一进入页面就必须立即看到的教学视频，那么对其进行懒加载可能会适得其反。用户打开页面却看到一个空白或者一个占位符，会让他们觉得网站很慢，体验受损。这种情况下，视频的即时性比加载性能更重要。
视频是核心内容且数量极少：
设想一个页面，它所有的信息都通过一两个视频来传达，而且这些视频就位于页面的上半部分。如果页面上只有这么几个视频，并且它们很快就会进入用户的视口，那么懒加载带来的性能提升微乎其微，甚至可以忽略不计。反而，引入JavaScript来实现懒加载，增加了额外的复杂性和潜在的加载失败风险。这种情况下，直接加载可能更简单、更可靠。
内网应用或特定高性能环境：
在一些特定的内网应用场景，比如企业内部培训系统，或者已知用户网络环境极佳（例如，所有用户都在同一局域网内，带宽极其充裕），视频加载速度通常不是瓶颈。这时候，强行引入懒加载，可能只是增加了开发和维护的复杂度，而没有带来明显的性能收益。
视频需要立即播放或进行特定交互：
某些视频可能被设计成在页面加载完成后立即自动播放（尽管自动播放有其自身的UX争议），或者用户需要立即与视频进行互动（比如作为游戏的一部分）。如果对这些视频进行懒加载，可能会打断预期的用户流程，导致用户操作无效或体验不连贯。
浏览器原生支持不佳且无必要Fallback：
虽然现代浏览器对loading="lazy"的支持越来越好，但如果你的目标用户群中存在大量使用老旧浏览器的情况，而你又没有实现可靠的IntersectionObserver或滚动事件的Fallback机制，那么懒加载就可能完全失效。这种情况下，确保视频能被正常访问比追求极致性能更重要。
总而言之，懒加载是一种强大的优化手段，但它的应用需要结合具体场景和用户需求来判断。在追求性能的同时，我们也不能牺牲用户体验和内容的可用性。
以上就是HTML代码怎么实现懒加载视频_HTML代码视频懒加载实现与带宽优化技巧的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1580547.html
微信扫一扫 
支付宝扫一扫 
