论坛风格切换
 
  • 帖子
  • 日志
  • 用户
  • 版块
  • 群组
帖子
购买邀请后未收到邀请联系sdbeta@qq.com
  • 7阅读
  • 0回复

[业界新闻]Google为Chrome引入原生音视频懒加载 有望进一步加快网页速度 [复制链接]

上一主题 下一主题
 

发帖
11275
今日发帖
最后登录
2026-04-02
只看楼主 倒序阅读 使用道具 楼主  发表于: 2026-04-02 15:20:41
         Google Chrome以及包括微软Edge、Vivaldi在内的其他基于Chromium的浏览器,预计将很快支持原生的视频和音频懒加载功能。这一改动由独立开发者Helmut Januschka提出,他此前已多次为Chromium项目做出贡献。 abM84EU  
<A#5v\{.;~  
 M*d-z  
  懒加载(Lazy Loading)并不是新概念,Chrome多年前就已为图片和iframe等元素提供原生懒加载支持,但一直未覆盖视频和音频标签。此次改进意味着,今后Chromium系浏览器将在底层直接支持对多媒体内容的懒加载,有望在包含大量音视频内容的网页上显著缩短初始加载时间、提升页面响应速度。 u$W Bc\ j  
sW;7m[o  
  对于不熟悉这一机制的用户而言,懒加载指的是:当你打开一个网页时,浏览器不会在页面渲染的第一时间就完整下载和初始化所有图片、视频等资源,而是只在这些元素即将进入可视区域(例如你向下滚动到视频所在位置附近)时才触发加载。在没有懒加载的情况下,Chrome可能会在页面加载初期就同时请求所有媒体文件,导致首屏内容出现延迟、整体加载时间拉长。而在采用loading="lazy"的策略后,如果用户始终没有滚动到某段视频或音频所在区域,那么相关媒体甚至可能永远不会被下载,从而节省带宽和计算资源。 'n~fR]h}  
V3## B}2[Y  
  目前,大多数网站若想实现视频或音频的懒加载,通常要依赖JavaScript来完成,即通过Intersection Observer等API检测媒体元素何时进入视口,再动态设置src属性以触发加载。Helmut Januschka在提交给Chrome Status与Chromium开发者邮件列表的说明中指出,这种JavaScript方案存在实现复杂、容易出错的问题,而且无法与浏览器自身的预加载扫描器(preload scanner)以及内置的加载启发式策略充分协同。换言之,当前做法在性能和稳定性方面都不是最佳实践。  %)pP[[h  
KuA>"X  
  根据目前公开的信息,Januschka提出的方案,是将完整的原生视频和音频懒加载能力直接整合进Chromium,就像现有对图片和iframe的原生支持一样。一旦该功能进入Chrome正式版渠道,开发者便可以在或标签上直接添加loading="lazy"属性,而无需再依赖额外的JavaScript逻辑。这样,媒体资源的延迟加载将由浏览器原生引擎接管,更好地与预加载扫描流程和网络状态感知策略协同工作。 fk+1#7{  
F vj{@B!  
  Januschka强调,原生懒加载的优势在于,它允许浏览器基于网络状况设定更合理的加载阈值,更好地处理与autoplay、preload等HTML属性之间的交互关系,并避免将屏幕外媒体的加载计入window.onload事件,从而减少对页面初始加载完成事件的阻塞。这将使得网页在用户感知层面“更快可用”,同时保留对富媒体内容的支持能力。 ^rL ,&rk  
TW>?h=.z  
  目前,这一改动已被相关社区“率先发现”,但尚处于推进过程中。随着原生视频和音频懒加载在Chromium稳定版中落地,前端开发者现有基于脚本的懒加载实现,预计将逐步过渡到更简洁、性能更优的原生属性写法,从而为用户带来更流畅的浏览体验。 <lFdexH"T