Chrome浏览器移除功能集
2011-01-12 09:09:17 
阿炯
本文记录了Chrome/Chromium浏览器的重大移除功能的记录。不再支持H.264视频解码器
移除了 JPEG-XL 支持
放弃SPDY拥抱 HTTP/2
移除 Theora 支持
终止 “隐私沙盒” 项目
重新引入对 JPEG XL 格式的原生支持
不再支持H.264视频解码器
Google 在2011年1月中旬的 Chromium 官方博客宣布由于 H.264 编解码器并非开放标准，Chrome 将在几个月后正式停止对 H.264 视频解码的支持，全面采用开放的 WebM 和 Theora 格式。
在其博客上表示，自从 WebM 视频编解码器推出以后，在性能、厂商支持以及独立性方面已经取得了很大的进步，为了与 Chromium 现有支持的編解码器保持一致，Chrome 最终将改变 HTML 标签的视频支持格式，放弃 H.264 视频格式的支持，大力发展开放的 WebM 技术。该变化将会在接下来的几个月内生效，现在宣布这一消息主要是为了提醒内容发布商做好准备，别到时候因为 Chrome 的“突然袭击”而导致网站上的视频无法在 Chrome 中播放，说白了就是提醒内容发布商也赶紧放弃 H.264 标准。
看起来这件事情并没有这么简单，估计是 Google 想让 H.264 也开源，但没有谈妥，出的故意打压 H.264 标准的招数，当然也有可能是因为 Apple 大力支持 H.264，Google 故意与之唱反调。但有意思的是，Google 还是承认了 H.264 标准在视频领域扮演的重要角色。
移除了 JPEG-XL 支持
2022年12月中旬消息，谷歌方面已经按照原定的计划，实现了在 Chrome/Chromium 110 中取消对 JPEG-XL 支持的决定。目前相关代码已经完成合并，从 Chromium/Chrome 网络浏览器代码库中删除了 JPEG-XL 支持。在相关消息于2022年 10 月份刚被曝出时，就有一些用户和开发者表达了对 JPEG-XL 的支持；并试图促使谷歌改变他们对取消 JPEG-XL 支持的立场，但事实证明他们并没有成功。谷歌方面曾解释称其作出这一决定的原因在于：
1.处于实验性阶段的 flag 和代码不应无限期地保留
2.整体生态对 JPEG-XL 格式缺乏兴趣，难以继续推动试验
3.与现有的格式相比，新的图像格式并没有带来足够的增量收益，因此没有理由默认启用它
4.通过移除相关代码可以减轻维护负担，帮助开发者专注于改进 Chrome 中的现有格式。
且谷歌也对 WebP 和 AVIF 等替代格式更感兴趣。 谷歌/AVIF团队近日还分享一份基准测试结果，将 AVIF 图像格式与 WebP、JPEG 和 JPEG XL 图像格式进行了比较。
JPEG XL 基于 Google 的 PIK 格式和 Cloudinary 的 FUIF 格式（该格式基于 FLIF），它的默认设置能在实现接近无损的视觉效果的同时，提供良好的压缩效果，这一项目希望成为其他光栅有损和无损图像格式的通用替代品。
JPEG 是指联合影像专家小组，它是设计该格式的委员会。
X 是指自 2000 年以来的几个 JPEG 标准的名称的一部分：JPEG XT 、JPEG XR、JPEG XS。
L 代表长期，因为创建这种格式的意图是替换旧的 JPEG 文件格式并能被使用同样长的时间。
JPEG-XL 比特流格式于 2021 年底完成，并开始被各种开源和闭源应用程序采用。JPEG-XL 的目标是免版税，不过今年早些时候微软获得了有关 JPEG-XL 使用的 “rANS”（范围非对称数字系统）数据压缩的专利，这引起了一些担忧。
FSF 抨击谷歌弃用 JPEG-XL：强调了浏览器选择和自由格式的必要性
2023年4月中旬消息，谷歌在 Chrome 91 版本中引入了 JPEG-XL 图像格式支持；但在2022年 11 月，谷歌工程师提交补丁称决定在 Chrome 110 中移除对 JPEG-XL 图像格式的实验性支持。2023 年 2 月份，该公司已经正式废除了 JPEG-XL 图像格式，转而使用其自己的专利 AVIF 格式。针对谷歌此举，自由软件基金会 (FSF) 近期发文表达了对谷歌所拥有的强大市场控制力的担忧。
“无论是通过谷歌在开发和广告方面投入的数百万美元，还是通过它为用户提供的 '便利' 来换取自由；事实是，Google Chrome 是网络标准的仲裁者。Firefox 浏览器可以削弱这种扼制。但谷歌在 2 月份废除了 JPEG-X L 图像格式，转而使用其自己的专利 AVIF 格式...... 确实再次强调了它对平台的控制力之大，令人不安。”
当初，谷歌方面解释其弃用 JPEG-XL 的一大理由是： 整个生态系统没有足够的兴趣继续试验 JPEG-XL。FSF 反驳称，就算抛开 “生态系统” 这一用词不谈，谷歌自己就是这个 “生态系统” 中迄今为止最大和最危险的掠夺者时，轻易就可以改变 "整个生态系统" 的状态。而相较谷歌，普通网络用户可能只是一个 “微生物”。因此谷歌所谓的衡量 “生态系统” 想要什么，其实事实上是看他们自己想要什么。
“如果我们认真看待他们在将网络变成 'WWorst App Store' 方面的贡献，那么我们就会明白谷歌真正想要什么。谷歌想做对自己的掠夺性利益最有利的事情，而不是对整个网络最有利的事情。”
对于 Chromium 用户提出的不要弃用 JPEG-XL 的恳求，谷歌选择视而不见，也没有对用户的担忧做出回应。因此FSF也呼吁大家团结起来向谷歌展示自己不可被改变的坚定决心。“它可以继续想它想要的东西：控制；我们将继续想我们想要的东西：自由。”
FSF也指出，目前的情况并非毫无希望；因为即使是谷歌也无法阻止我们创建我们想要的网络社区：不在我们的计算机上运行大量恶意、非自由代码的页面。我们有权选择在浏览器中运行或不运行的内容...... 我们的社区可以做的是团结起来支持那些选择支持 JPEG-XL 和类似格式的免费浏览器，让大 G 知道即使我们比它渺小，我们也不会任人摆布。
更多详情可查看官方公告。
放弃SPDY拥抱 HTTP/2
互联网竞争环境相当的复杂，这个也体现在 Web 浏览器对不同技术和标准的支持，这些技术和标准都直接导致了性能和兼容性的表现差异很大。可能很多人天真的认为应该有一些真正开放的标准，但是静下来想想，是谁在制定标准呢？如果互联网真的开放，那为什么看起来是几个巨头公司在掌舵呢？所以...没有真正开放的标准。
而 Google 就是这样一个在做决策的公司，决策着 Web 的未来，当然这不一定是坏事。它会从自身利益角度来决定一些技术的走向，例如 Google 宣布其 Chrome 浏览器将跟 SPDY 说再见，开始实现 HTTP/2 协议。来自 Google 的 Chris Bentzel 在2015年2月说：HTTP 是 Web 万维网的基础网络信息，目前广泛使用的是 HTTP/1.1 标准，该标准是 1999 年在 RFC2616 中定义的。但是到了今天 Web 的发展日新月异，同时一个新版本 HTTP/2 也在标准路上不断前行，计划在未来数周内发布的 Chrome 40 中支持 HTTP/2 标准。
Bentzel 进一步解释：一些关键的特性如连接复用、Header 压缩、优先级和协议握手改进等等已经完成。Chrome 从 6 开始就支持 SPDY，但其大多数优点都已经在 HTTP/2 中出现，因此是到了跟 SPDY 说再见的时候了。我们计划在 2016 年移除对 SPDY 的支持，同时也将移除名为 NPN 的 TLS 扩展，服务器开发人员强烈鼓励迁移到 HTTP/2 和 ALPN。从这点来看，将 SPDY 换成 HTTP/2 是正确的选择，虽然二者都是”开放“的，但是 HTTP/2 更能代表未来，而且用户也不会感觉到太大的变化。
移除 Theora 支持
谷歌高级软件工程师、Chrome 开发者 Dale Curtis 于2023年10月下旬在 Google Groups 发帖称，考虑到一些新的安全风险，桌面版 Chrome 浏览器中计划淘汰并移除对 Theora 视频编解码器的支持。称Theora的使用率很低（现在还经常出现错误），对大多数用户来说已不再需要支持。
针对媒体编解码器的零日攻击激增。
UKM 的使用率已降至可测量水平以下。
在使用率下降之前，Chrome 团队手动检查了一些站点，发现其都错误地选择了 Theora，而不是 VP9 等更现代的编解码器。
Safari 或 Chrome on Android 从未支持过 Theora。
他们将为仍然需要 Theora 支持的网站提供 ogv.js polyfill，且不会删除对 ogg 容器的支持。计划是逐步开始升级实验，先在 M120 取消对 Theora 的支持。在此期间，有需要的用户可以通过 chrome://flags/#theora-video-codec 重新激活 Theora 支持。暂定时间表为：
2023 年 10 月 23 开始 50/50 canary 开发实验。
2023 年 11 月 1 日至 6 日：开始 50/50 beta 实验。
2024 年 1 月 16 日：以 100% 启动。
2024 年 2 月：删除 M123 中的代码和 chrome://flag。
2024 年 3 月：Chrome 123 将升级到稳定版。
Theora 是 Xiph.Org 基金会开发的一种免费、开放的有损视频压缩格式。可用于在线和光盘上分发电影和视频，而无需支付许可费和版税费用，也无需与其他格式相关的供应商锁定。其于 2008 年 11 月 3 日全面公开发布，比特流格式于 2004 年 7 月 1 日冻结。Theora 前身是由 On2 Technologies 公司开发的专利视频编解码器 On2 TrueMotion VP3。
终止 “隐私沙盒” 项目
谷歌宣布于2025年10月将关闭其自 2019 年启动、用于取代第三方 cookie 的隐私广告平台项目 “隐私沙盒（Privacy Sandbox）”，旗下多个 API 技术将被淘汰，包括 Attribution Reporting API、Topics API、Protected Audience API 等。该项目由谷歌副总裁 Anthony Chavez 主导，他在官方博客中表示：“在评估整个生态系统的反馈以及观察到的采用率极低情况后，我们决定终止剩余 Sandbox 技术。”
Privacy Sandbox 最初提出是为网络广告行业提供一种替代传统第三方 cookie 的方法，从而在保护用户隐私的同时，继续支持广告定向和效果测量。谷歌曾计划通过其浏览器 Chrome 进行大规模推广 Privacy Sandbox，不过该项目在推进过程中遇到了多个挑战：包括广告生态系统的采纳缓慢、浏览器其他厂商的抵制、监管层面的担忧。虽然项目终止并放弃 “Privacy Sandbox” 这一品牌。，但谷歌表示依然致力 “在 Chrome、Android 及整个 Web 上改进隐私”。
重新引入对 JPEG XL 图片格式的原生支持
Google 于2026年1月中旬在 Chromium 浏览器引擎中重新加入对 JPEG XL 图片格式的原生支持，并采用全新的 Rust 实现解码器 jxl-rs，以满足长期存在的内存安全和安全合规要求。目前该功能已集成进代码，但用户仍需在 chrome://flags 中手动打开 #enable-jxl-image-format 开关，这也是自 2022 年 Chrome 110 版本之后，该格式首次重回 Chrome 正式渠道。 与此同时，其他主流浏览器对 JPEG XL 的支持依然不算完善：Firefox 需要在设置中手动启用，而 Safari 只有部分支持。
JPEG XL 被视为替代老旧 JPEG 标准的下一代图片格式，相比传统 JPEG，在画质相当的条件下可将文件体积极大缩减，压缩后体积最多可缩小约 60%，同时仍具备极快的解码速度，有利于网页加载性能的整体提升。 过去二十多年大规模普及的 JPEG，在现代标准下压缩效率已相对落后，因此业界一直在寻找新的开放格式，用以支撑更高分辨率和 HDR 等新一代影像需求。
Google 曾在 2022 年主动移除 Chrome 中对 JPEG XL 的实验性支持，当时给出的理由包括：网站端采用率偏低、生态需求不足，继续投入维护成本意义有限。 此外，Google 自身也在积极推动另一种由其参与制定的图片格式 AVIF，希望推动 Web 端更多采用该格式，从而在标准话语权上占据优势。两年之后，多个因素共同推动 Google 改变立场，促成 JPEG XL 的 “回归”。
一方面，苹果与 Mozilla 近年先后在各自浏览器中提供了该格式支持，使得 Chrome 一度成为主流浏览器中唯一缺席 JPEG XL 的 “例外”。 另一方面，2025 年底，PDF 协会将 JPEG XL 选为 PDF 规范中嵌入高动态范围（HDR）内容的首选解决方案，这意味着如果 Google 希望其内置 PDF 查看器完整呈现新一代 PDF 文档中的 HDR 图像，就不得不重新支持该格式。
此外在开发者调研与问卷中，JPEG XL 被开发者列为浏览器端图片支持方面的首要痛点，进阶特性如渐进式解码和动画能力吸引了大量内容提供方和工具开发者。这一次重新接纳 JPEG XL，Google 采用了用 Rust 语言编写的新解码实现 jxl-rs，通过内存安全特性降低安全漏洞和维护负担的风险。
在 Google 看来，Rust 这种内存安全语言有助于降低长期维护成本，避免传统 C/C++ 实现中频繁出现的内存错误，为在大规模用户群体中开启新格式支持扫清了重要障碍。对开发者和网站运营方而言，随着 Chrome 重新加入这一拼图，JPEG XL 在桌面和移动端浏览器上的完整链路正在形成，未来在网页、PDF 乃至更多多媒体内容场景中的落地有望进一步提速。