网页浏览器 · aiwiki.page

网页浏览器是一种应用软件，它从服务器请求由统一资源定位符（URL）标识的资源，解释返回的文档，并将其以可交互页面的形式呈现给用户。其核心任务包括：通过网络协议获取数据，解析超文本标记语言、层叠样式表和JavaScript，对内容进行布局与绘制，以及处理用户输入。浏览器是大多数人使用万维网和更广泛的互联网的主要界面，因此它塑造了信息的获取方式、网站的构建方式，以及人们对隐私和安全的体验。

浏览器源于超文本的理念，以及20世纪90年代围绕万维网展开的工作。当时，蒂姆·伯纳斯-李编写了第一个浏览器兼编辑器，随后第一批图形化浏览器迅速普及。此后，该领域的发展一直受到几个渲染引擎家族之间的竞争、开放的网络标准，以及关于安全、追踪、可扩展性和市场集中的持续争论的影响。现代浏览器是复杂的多进程系统，它集用户界面、用于网页应用的计算运行时、网络协议栈和存储于一体，如今它们本身已发展成为一个平台。

本词条大体分为三个部分：浏览器的起源、架构与技术运作；浏览器的安全、隐私、可扩展性与标准化；以及浏览器在市场、监管、无障碍访问和新兴技术中的更广泛作用。本词条面向希望获得全面了解的普通读者，技术细节足以说明浏览器的工作原理及其重要性。

定义与范围

网页浏览器是一种客户端软件，用于请求由 URL 标识的资源，通过网络获取这些资源，并将其呈现给用户。参考资料通常将其描述为一种在万维网上获取、呈现和浏览信息资源的软件应用，而资源的另一端通常是网页、图像、视频或其他内容。从网络角度看，浏览器是客户端–服务器交换中的客户端：它发送 HTTP 请求，服务器则返回文件。因此它也被称为 HTTP 客户端或用户代理。浏览器还可以显示存储在用户设备本地的内容，并访问私有网络或文件系统中的资源，因此其范围比公共网络更广。

这一定义将浏览器与相邻系统区分开来。Web 服务器存储资源并响应请求，但不负责显示资源。搜索引擎对网页进行索引并返回链接，但网页本身仍由浏览器获取并显示。操作系统负责管理硬件并启动程序，而浏览器就是其中一种程序。术语Web 客户端的含义更宽泛：Web 客户端既包括网页浏览器，也包括 Web 应用，而许多 Web 应用运行于浏览器之中，而非作为单独安装的程序存在。

大多数浏览器都包含一组共同的功能组件。用户界面提供地址栏、标签页、书签和设置选项。网络层负责解析域名、建立连接并使用 HTTP 协议通信。渲染引擎解析 HTML 和 CSS，并将其转换为可视化的页面布局；脚本引擎则执行 JavaScript，使页面在加载后能够发生变化。本地存储保存 Cookie、缓存文件、历史记录和会话数据。每个组件在本词条中都有专门的小节介绍；这里要强调的是，浏览器是由这些部分组合而成的，而不是单一的查看器。

浏览器的形态十分多样。桌面浏览器运行于 Windows、macOS 和 Linux 系统；移动浏览器运行于智能手机和平板电脑，其设计受触控输入、小屏幕和电池续航等因素制约。浏览器引擎也出现在电视、游戏机和汽车中。Lynx 等基于文本的浏览器不显示图像，这使其在网络连接缓慢时十分实用，至今在某些无障碍访问和脚本任务中仍有用处。无头浏览器则在没有可见窗口的情况下运行，由程序驱动，用于测试和数据采集。其中一些形态刻意保持极简，因此如果将浏览器定义为带有图形窗口的应用，就会把它们排除在外。

这一术语的使用较为随意。在日常用语中，“浏览器”与“网页浏览器”可以互换使用，“互联网浏览器”则是常见的非正式说法。从技术上讲，浏览器引擎或渲染引擎是将下载的资源转换为可交互页面的组件，它与外层的产品有所区别。多款浏览器可以共用同一个引擎，因此讨论兼容性问题时，通常指的是引擎系列而非品牌。网页视图是一种可嵌入的组件，它允许原生应用使用渲染引擎显示网页内容，而无需完整的浏览器界面。在实践中，应用内标注为“浏览器”的界面很可能是网页视图，而两者在安全性和兼容性方面的表现可能有所不同。

起源：从超文本到图形化网络

链接式文档的构想早于网络计算。1945年7月，万尼瓦尔·布什（Vannevar Bush）在《大西洋月刊》发表的文章《诚如所思》（As We May Think）中，描绘了一种设想中的桌面式装置，个人可以借助它保存书籍、记录和通信，并以极快的速度查阅。他将这一装置称为 memex。布什的核心主张是关联索引和基于路径的链接，这一构想后来成为超文本的概念蓝图，也成为万维网互联文档模型的概念基础。道格拉斯·恩格尔巴特（Douglas Engelbart）、泰德·尼尔森（Ted Nelson）和J. C. R. 利克莱德（J. C. R. Licklider）等先驱引用并发展了他的设想。在20世纪60和70年代，他们的超文本系统将这些构想变成了可以运行的软件，但都未能触及大众用户。

作为一类软件的浏览器，诞生于日内瓦附近的粒子物理实验室CERN。1989年3月，蒂姆·伯纳斯-李（Tim Berners-Lee）在CERN工作期间撰写了一份关于开发分布式信息系统的提案。1990年11月，他与罗伯特·卡约（Robert Cailliau）共同提交了正式的项目提案。到1990年圣诞节前后，伯纳斯-李已确定了万维网的基本概念，即HTML、HTTP和URL，并编写出第一个浏览器兼编辑器以及服务器软件。客户端运行在NeXT工作站上，这使得第一款浏览器兼编辑器只能在这些稀少的机器上使用。它同时也是一款编辑器，用户选中文本并点击"Link to Marked"（链接到标记处）即可创建链接页面。该程序最初名为WorldWideWeb，后改名为Nexus，以避免软件与万维网（World Wide Web）之间的混淆。第一台服务器info.cern.ch运行在CERN的一台NeXT计算机上。CERN以外的访问起步缓慢，万维网直到1991年夏天才在互联网上开放。

早期浏览器大多以文本为主。用户可以添加指向图像文件的文本链接，但图像会在单独的窗口中打开。图形化的转折点来自伊利诺伊大学开发的 NCSA Mosaic。美国国家超级计算应用中心（National Center for Supercomputing Applications）的一个团队于1993年4月22日发布了Mosaic 1.0，由此推动了网页浏览器的大众普及。它是第一款能够跨平台显示文本以及行内图像（GIF格式）的网页浏览器。正是"image"标签使Mosaic能够在浏览器中显示图像。马克·安德森（Marc Andreessen）曾在1993年2月的一则邮件列表消息中提议了IMG标签，但直到1995年11月，它才被纳入W3C的HTML规范。Mosaic并不是第一款浏览器，在它之前已有WorldWideWeb、Erwise和ViolaWWW。它的意义在于易用性。其界面、可靠性、对个人电脑的支持以及简便的安装方式，促成了Mosaic最初的流行。其普及速度很快，到1993年12月，该中心报告每月有超过5000份副本被下载。

安德森随后共同创办了网景公司（Netscape），其浏览器带来了进一步的易用性提升。网景加入了渐进式图像加载等功能。与Mosaic不同，用户不必再等待所有内容下载完毕才能看到页面。1994年发布的Netscape Navigator吸引了迅速扩大的用户群中的大部分份额。浏览器由此在20世纪90年代中期成为一个商业化的产品类别，而它与微软之间产生的竞争，是下一节的主题。

浏览器大战与标准的兴起

第一次浏览器大战

历史学家通常将第一次浏览器大战的时间定为1995年至2001年，这一时期Internet Explorer与Netscape Navigator争夺主导地位。网景一开始遥遥领先。微软进入市场时，网景已成为许多用户的默认选择，在1996年的鼎盛时期，网景的浏览器市场占有率达到86%。

微软最初的尝试较为保守。Internet Explorer的第一个版本是仓促移植自Mosaic的代码，于1995年8月作为Windows 95 Plus!附加包的一部分推出。转折点出现在1996年的第3版，该版本引入了让网景占据优势的功能，使微软团队有了缩小差距的动力。两者的收费方式也不同：与Netscape Navigator不同，Internet Explorer 1.0对所有Windows用户免费开放，包括商业公司在内。相比之下，网景则向原始设备制造商收取使用Netscape Navigator的许可费。

微软最具影响力的优势在于分销渠道。它并不只依靠浏览器本身的质量，而是免费提供给PC制造商和互联网服务提供商，让他们将其捆绑到硬件中，并与电脑制造商达成协议，将IE设为默认浏览器，往往完全排除了网景。由于两家公司各自推行不同的专有扩展，而且没有共同的标准来规范新功能，许多开发者别无选择，只能为其中一款浏览器量身定制网站。

反垄断诉讼

这场竞争引发了一起重大法律案件。美国司法部于1998年5月对微软提起反垄断诉讼，原告的主要论点很大程度上基于微软针对网景的种种行为。他们提出了违反《谢尔曼法》的四项不同指控，其中包括将IE与Windows捆绑销售。1999年11月，托马斯·彭菲尔德·杰克逊法官认定微软违反了1890年的《谢尔曼反托拉斯法》，并于2000年4月发布法律结论，确认了这一违法行为。

上诉后，哥伦比亚特区巡回上诉法院对原判作出部分维持、部分撤销的裁决。法院维持了微软非法维持其操作系统垄断地位的认定，撤销了微软试图垄断浏览器市场的认定，并将捆绑销售的指控发回重审。2001年9月，政府宣布不再寻求拆分微软。随后达成的和解并未要求微软将IE与Windows分离，法院批准了和解，其中哥伦比亚特区巡回上诉法院于2004年6月作出批准，尽管多个州持续反对。

实际效果是，IE仍然与Windows深度整合，其默认地位得以保留。开发者和竞争对手仍需与一款操作系统持续推广的产品竞争。因此，许多历史学家认为，这场诉讼的作用在于限制未来的捆绑销售行为，而并非一项重新开放浏览器市场的补救措施。

停滞与新的挑战者

凭借依然稳固的分销优势，Internet Explorer的市场份额迅速增长。在法院作出裁决时，IE的使用份额已超过50%，有一项回顾性研究指出，到2002年其浏览器市场份额已超过95%。1999年3月，网景被美国在线（AOL）收购，其独立产品逐渐淡出。和解之后的几年里，IE的开发明显放缓，2000年代成为浏览器功能相对停滞的时期。

竞争从多个方向重新出现。Mozilla社区开发出了Firefox。它最初并非作为Mozilla应用套件的一部分，而是以独立浏览器的形式，于2002年以代号Phoenix发布。苹果于2003年推出Safari，谷歌于2008年推出Chrome。如今，历史学家通常将2004年至2017年间Internet Explorer、Firefox与Google Chrome之间的竞争称为“第二次浏览器大战”。

开源与整合

网景最持久的回应是开放其源代码。1998年1月，网景宣布将发布Netscape Navigator 5.0的源代码，到1998年3月31日，最早的Mozilla代码以正式的开源许可证向公众开放。Mozilla项目旨在汇聚互联网上成千上万程序员的创造力。其排版引擎Gecko是重新编写的，因为旧的网景引擎速度慢，对W3C标准的支持不佳，并且缺少增量重排等功能。

在随后的十年里，引擎格局逐渐收窄。苹果的WebKit源自KDE项目的KHTML，于2005年开源；谷歌的Chromium项目于2008年启动，其中的Blink于2013年从WebKit分支出来。Opera于2013年、Microsoft Edge于2019年先后转向基于Chromium的引擎。到2010年代末，大多数主流浏览器都基于Blink或WebKit构建，Gecko则成为主要的独立引擎。这种整合降低了维护浏览器的成本，但也引发了关于引擎多样性的问题，相关讨论见“未解决的问题”一节。

内部架构

三层结构：界面、引擎与渲染器

浏览器通常可以被描述为三个相互协作的部分。用户界面（常被称为"外壳"，即 chrome）包含地址栏、标签页、书签和菜单，负责应用程序中"外壳"的部分，包括地址栏、书签、前进和后退按钮，同时也处理网络请求和文件访问等不可见的特权部分。浏览器引擎位于界面与渲染引擎之间，负责协调导航、加载以及两者之间的数据流动。渲染引擎（如 Blink、WebKit 或 Gecko）负责把 HTML、CSS 和 JavaScript 转换为像素。在 Chromium 中，运行用户界面并管理渲染器及其他进程的主进程被称为"浏览器进程"（browser process）或"浏览器"，而处理网页内容的进程被称为"渲染器进程"（renderer processes）或"渲染器"。渲染器使用开源的 Blink 布局引擎来解析和排版 HTML。这些层次之间的边界并不总是清晰的，不同项目对它们的称呼也各不相同。

多进程模型

基于 Chromium 的浏览器会把工作分配给多个操作系统进程，而不是全部运行在同一个进程中。Chromium 现在还拥有独立的 GPU 进程、网络服务和存储服务。渲染器进程会分配给各个标签页，Chrome 会尽量为每个站点（包括 iframe）分配独立的进程。GPU 之所以被放入独立进程，是因为 GPU 要处理来自多个应用的请求，并把它们绘制到同一个画面上。

这一设计主要有三个动机。第一是稳定性：它允许无关标签页中的网页并行运行，并且当某个渲染器进程崩溃时，用户仍可继续使用浏览器和其他标签页。第二是对图形栈故障的容错能力：有缺陷的驱动程序即使崩溃，也不一定会导致整个浏览器崩溃，因为 GPU 进程可以被重新启动。第三是网络安全方面的考虑，见下文。独立进程还让操作系统能够在多个处理器内核上调度任务，这使该模型与并行计算产生了联系。

站点隔离（site isolation）扩展了这一模型。在第 67 版之前，Chrome 会尽可能把来自不同网站的页面放入不同的渲染器进程，但由于兼容性限制，许多情况下不同站点的页面仍会共享同一进程，例如跨站点的 iframe。后续工作旨在确保一个渲染器进程最多只包含来自同一个网站的页面。

沙箱与进程间通信

渲染器是暴露面最大的组件，因为它要执行不受信任的页面代码。因此，渲染器运行在沙箱中，沙箱会移除其对系统资源的大部分直接访问权限。渲染器进程在沙箱中运行，其磁盘和网络 I/O 访问受到限制。渲染器不能直接执行底层网络操作，而是依赖网络服务，网络服务可以实施额外的安全检查和控制。因此，需要读取文件或建立网络连接的渲染器必须请求权限更高的进程，这类请求会通过进程间通信（IPC）传递。浏览器与渲染器使用 Mojo 或 Chromium 的旧版 IPC 系统进行通信。

这些设计选择也有代价。每个进程都会占用内存，进程越多，性能也可能受到影响。站点级隔离同样会增加 Chrome 的进程数量，并可能影响性能。浏览器进程是沙箱机制的例外：它是唯一的中心进程，完全不受沙箱限制。因此，该进程中的缺陷比渲染器中的缺陷更为严重。一位安全研究人员记录了浏览器进程中的一个释放后使用漏洞，该漏洞导致了沙箱逃逸，这说明了特权代码与非特权代码之间边界的重要性。一篇对比 Firefox 与 Chromium 的文章认为，Firefox 的模型粒度较粗，沙箱较弱，不过此类评估多来自倡导性来源，阅读时应考虑到这一点。

数据持久化层

浏览器会保存多种超出单次页面访问生命周期的持久数据，包括书签、浏览历史、用于恢复已打开标签页的会话状态、Cookie 以及网络资源缓存。在基于 Chromium 的浏览器中，这些数据通常存储在每个用户的配置文件目录中：历史记录和 Cookie 一般保存在 SQLite 数据库中，书签保存在 JSON 文件中，缓存的响应则存储在磁盘上。对其中部分数据的访问由浏览器进程中介：浏览器进程可以根据哪些网站需要专用进程，向渲染器进程授予对 Cookie 及其他资源的有限访问权限。由于渲染器无法直接读取其他站点的存储状态，持久化层也就成为进程模型安全设计的一部分。

渲染与脚本流水线

从网络字节到两棵树

浏览器不会等待完整响应全部到达后才开始构建页面。第一块数据一到达，解析器便开始工作：把标记转换为文档对象模型（DOM），并把样式规则转换为CSS对象模型（CSSOM），渲染器随后会用CSSOM把画面绘制到屏幕上。DOM是浏览器对标记的内部表示，脚本可以通过JavaScript API访问并修改它。CSSOM的构建方式有所不同。引擎把CSS规则转换为样式映射，并依据选择器生成一棵树，其中的父子与兄弟关系由选择器决定。两种结构在样式阶段之前彼此独立，这也是页面在CSS被理解之前无法被正确绘制的原因。

样式、布局、绘制与合成

样式计算将DOM节点与其匹配的规则配对。引擎解析层叠、优先级和继承，使每个元素最终得到计算样式。结果输入渲染树，渲染树只包含可见元素及其计算样式。

布局随后为每个节点分配尺寸和位置，绘制则把这些盒模型转换为绘制指令。绘制输出会被光栅化为小块图块，这样之后只需重绘受损区域。绘制生成绘制命令列表，光栅化则把页面切分为支持局部重绘的图块。合成是最后一个阶段。部分元素会被提升为由GPU支持的图层，合成线程将图块和图层组合成一帧。引擎通常根据 will-change、3D变换或不透明度等信号来提升元素。在这一环节，图形处理器承担了大部分视觉工作，让中央处理器得以腾出精力处理其他任务。这一优势在动画中最为明显。修改不透明度或变换可以避免触发布局或绘制，因此速度更快。由于合成器运行在独立线程上，即使主线程忙碌，它也能保持此类动画流畅。相反，修改几何形状或颜色则必须回到主线程处理。时间预算十分严格：浏览器的目标是每秒60帧，即每帧约16毫秒。

JavaScript引擎与即时编译

脚本执行在与布局代码分离的引擎中进行。SpiderMonkey（Firefox）、V8（Chromium）和JavaScriptCore（WebKit）为JavaScript生成原生机器码。V8是这一常见设计的典型例子：它先在名为Ignition的解释器中启动代码，再借助TurboFan优化编译器，将频繁执行的路径升级。SpiderMonkey和JavaScriptCore采用类似的多层方案。SpiderMonkey拥有多个JIT层级，JavaScriptCore则遵循类似的四层架构。

即时编译之所以有效，是因为引擎在程序运行时对其进行观察。它只为实际出现的情况生成代码，并根据运行时的观察结果进行特化。内联缓存记录操作所遇到的类型，因此总是看到相同形状的属性访问可以被简化为一条简短的机器指令。内存管理是另一个并行的问题：V8使用分代式、增量式、并发的垃圾回收器来回收内存，避免长时间停顿。由于JavaScript运行于约98.9%的网站上，这些引擎在很大程度上决定了交互式页面的响应速度。

事件循环与调度

脚本与渲染共用同一个主线程，因此二者的执行顺序十分重要。浏览器循环的每一轮先运行一个宏任务（例如定时器或输入事件），然后清空微任务队列，之后可能渲染一帧。微任务包括Promise回调、queueMicrotask调用以及MutationObserver回调。由于微任务在浏览器绘制之前完成，一长串微任务会推迟下一帧。当没有任何变化或标签页处于隐藏状态时，浏览器可能会完全跳过渲染。

事件循环也决定了视觉更新何时发生。requestAnimationFrame回调在渲染阶段中，于微任务之后、布局和绘制之前运行。这就是动画代码和DOM写入通常放在这些回调中的原因。在写入样式后立即读取布局属性则是另一个问题。以这种方式强制同步布局，可能会反复打断帧预算。开发者被建议避免“读-写-读”的操作序列，并将繁重的计算转移到Web Worker中。综合来看，事件循环、帧预算和合成器共同决定了页面的使用体验：一个快速结束并将控制权交还给浏览器的脚本能让界面保持响应，而独占主线程的脚本则会造成明显的卡顿。

网络、协议与缓存

从URL到连接

在任何页面内容到达之前，浏览器会先将URL拆分为协议方案、主机名、端口和路径，然后通过域名系统将主机名解析为IP地址。与服务器建立新连接需要进行TCP握手；若使用HTTPS，则还需在TCP之上完成TLS握手。TCP加TLS 1.3需要2个RTT（TCP占1个RTT，TLS占1个RTT），而QUIC通过将传输参数和密码学密钥共享一同发送，只需1个RTT即可完成连接。每一次往返都会增加延迟，因此减少往返次数是新一代协议设计的主要目标之一。

HTTP/1.1、HTTP/2与HTTP/3

在HTTP/1.1中，一个连接实际上一次只承载一组请求与响应，并且在流水线传输中，响应不能越过较早的响应提前返回。为了获得并发性，浏览器历来采用并行建立多个TCP连接的方式加以弥补。

HTTP/2在单个连接上复用多条流，并使用HPACK压缩头部。其弱点位于应用层之下：所有复用的流共享同一个TCP连接，而TCP要求严格按序交付，因此一个数据包丢失就会阻塞所有流的交付，直到重传完成。

HTTP/3通过将多路复用功能迁移到基于UDP构建的传输协议QUIC中来解决这一问题。由于QUIC原生支持多路复用，丢包只会影响到发生数据丢失的那些流。不过，QUIC并未消除所有等待：如果某个QUIC流内部的数据缺失，该流中后续的数据仍可能需要等待。部署情况也参差不齐：一些企业防火墙、移动运营商网络以及限制较严的NAT配置会阻断或限速UDP流量。因此，浏览器通常会先尝试QUIC，若尝试在短时间内未能成功，则回退到HTTP/2或HTTP/1.1。生产环境的部署必须采用机会性HTTP/3，并配合快速回退机制。

缓存、Cookie与会话状态

缓存是浏览器避免重复传输的主要手段。缓存的新鲜度由响应头控制：Expires响应头给出文档过期的日期，Cache-Control的max-age指令则告诉缓存该响应可在多少秒内视为新鲜。当存储的副本已过期时，浏览器可以询问服务器内容是否已发生变化。浏览器使用带有ETag值的If-None-Match请求头来重新验证内容，若ETag匹配，服务器即可返回304 Not Modified响应。带有no-store指令的响应根本不会被保存。若要完全避免任何形式的缓存，则可以改用no-store。

Cookie及其他会话数据的工作方式与缓存不同。浏览器按域名存储它们，并将匹配的Cookie附加到外发的请求中，服务器借此在多次独立的HTTP交互之间识别已登录的用户。

预连接、预取与连接池

资源提示允许页面提前告知浏览器其将需要哪些连接或资源。这些原语使开发者以及生成或交付资源的服务器能够协助用户代理决定连接哪些源、获取和预处理哪些资源。各类提示的开销各不相同：DNS预解析是开销最小的提示，它仅将域名解析为IP地址，而不建立TCP连接，也不进行TLS握手。预连接（preconnect）提示则更进一步，它包含DNS查询、TCP握手以及可选的TLS协商，使用户代理能够掩盖建立连接时的高延迟开销。预取（prefetch）的推测性最强，它为一次未必会发生的后续导航提前获取资源。

连接池则从相反的方向发挥作用，即复用浏览器已持有的连接。空闲的keep-alive连接会被保持打开，供同一源的后续请求使用，并受每个主机连接数上限的约束，因此只有在没有可复用连接时才需要进行新的握手。提示必须谨慎使用，因为每一次预连接都会消耗CPU和网络资源，过多的预连接反而可能损害性能。

安全架构

同源策略

同源策略（SOP）是 Web 应用安全模型中的一个概念。根据该策略，浏览器只允许第一个网页中的脚本访问第二个网页中的数据，且前提是两个网页具有相同的源。源由协议（scheme）、主机名和端口组成，即由 URI 协议、域名和端口号构成。该规则对于持有已登录会话的页面最为重要。它可以防止互联网上的恶意网站在浏览器中运行 JavaScript，读取用户已登录的第三方网页邮件服务中的数据，并将这些数据转发给攻击者。因此，即使两者运行在同一个浏览器中，显示银行页面的标签页与恶意页面的标签页也是相互隔离的。即使攻击者能够制作一个在嵌入式 iframe 中加载 bank.com 的网站，同源策略也会阻止这两个框架相互读取或交互。

该策略并非绝对。许多资源仍然允许嵌入：来自其他源的图片、样式表和 JavaScript 文件等静态资源仍可被嵌入，而读取其他源的 DOM 则被禁止。其适用范围也比一些人想象的要窄。它对跨站脚本攻击（XSS）完全无效，因为注入到受信任页面中的脚本本身就运行在该页面的源之下。各浏览器的实现也有差异，因为同源策略从未被定义为永久性的互联网规范，因此每个浏览器的实现都略有不同。已弃用的 <code>document.domain</code> 设置器体现了其中的权衡：它会削弱同源策略提供的安全保护，因此更推荐使用 CORS 响应头等受控的放宽机制。

进程隔离与站点隔离

现代浏览器通过将工作分散到多个进程中，来遏制已被攻破的页面所造成的损害。在 Chromium 中，存在一个中央进程，称为浏览器进程，它完全不受沙箱限制。网页内容则在其他进程中处理。渲染进程的攻击面最大，因为它们执行的大部分是不受信任的代码。因此其沙箱限制也最为严格：渲染进程不需要直接访问磁盘、网络或设备，所以 Chrome 可以将它们运行在受限沙箱之中。Firefox 采用了类似的设计，如今所有主流浏览器都包含沙箱并采用多进程架构。

仅靠沙箱无法阻止一个网站攻击与其共享进程的另一个网站。站点隔离弥补了这一缺口。站点隔离是一种浏览器安全功能，它根据网站所关联的源，将网站分组到各个沙箱进程中。Chromium 于 2018 年引入了该功能，每个网站被分离到各自独立的沙箱渲染进程中。其理由是：来自某一网站的渲染器漏洞利用，仍然无法访问另一网站的数据。该功能的推出是分阶段进行的。Chrome 67 在 Windows、Mac、Linux 和 Chrome OS 上为所有网站默认启用了站点隔离；此后，自 Chrome 77 起，站点隔离还能在桌面平台上防御被完全攻陷的渲染进程以及 UXSS 漏洞。Firefox 对应的项目 Fission 于 Firefox 95 中全面推出。

隔离还能限制侧信道攻击。诸如 Spectre 之类的预测执行攻击可以读取进程内的内存，因此操作系统的进程边界变得至关重要。有一项分析指出，操作系统针对此类攻击的缓解措施只能保证进程边界处的隔离；因此，将网站划分到不同进程中，是充分发挥这些缓解措施作用的唯一途径。崩溃的渲染进程也不会导致整个浏览器崩溃，这既是安全上的好处，也是稳定性上的好处。

证书校验与 HTTPS

安全连接依赖于在 TLS 握手过程中校验的密码学证书。浏览器会验证证书能否链接到受信任的根证书、是否与所请求的主机名匹配，以及是否已过期。校验失败时，浏览器会显示中间警告页面。错误处理是一种艰难的平衡。谷歌对 Chrome 错误报告的一项研究发现，超过一半的错误是由客户端或网络问题造成的，而非服务器配置错误。这些错误往往是误报，因为各种与攻击无关的情况每月会触发数以亿计的虚假浏览器警告。此类误报会降低用户对真实警告的信任。处理过于宽松同样存在风险。在一项自动化测试中，最新的移动端浏览器平均接受多达 33.2% 的无效证书，仅拒绝 5.4% 的无效证书，其余大部分则交由用户自行判断。

HTTPS 的采用率稳步增长。谷歌透明度报告追踪了 Chrome 导航中使用 HTTPS 的比例，数字大幅攀升：2015 年约为 30%–45%，到 2020 年前后达到约 95%–99%。到 2022 年，除 Linux 外的所有平台采用率均超过 90%，并于 2025 年接近 100%。Mozilla 的研究以网页数量而非浏览时长来衡量，给出了不同的数字：到 2024 年底，超过 80% 的网页通过 https 加载。明文流量仍然相当可观，这也是浏览器尝试采用更严格默认设置的原因。在 Chrome 141 中，谷歌对一小部分用户试验性地默认对公共网站启用"始终使用安全连接"。

安全浏览、更新与零日漏洞响应

浏览器还通过信誉服务来防范钓鱼和恶意软件网站。谷歌的安全浏览（Safe Browsing）服务维护着已知危险网址和软件的列表，浏览器会查询这些列表，在用户加载被标记的页面之前显示中间警告。由于这些防御依赖于最新数据，浏览器会频繁更新其黑名单及自身代码，且通常是自动完成的。

软件更新是应对漏洞的主要手段。零日漏洞利用是指在厂商发布修复程序之前就已被使用的攻击，是一个长期存在的隐患。浏览器厂商通常会发布紧急补丁，沙箱逃逸一经披露便会迅速修补。进程隔离在这里起到关键作用：一个逃离了某个渲染进程的漏洞利用，仍须突破沙箱和浏览器进程，这为补丁的部署争取了时间。安全研究人员已证明此类攻击链仍可能成功，因此沙箱隔离、站点隔离和频繁更新等多层防御需要共同使用，而不是相互替代。

隐私与追踪

Cookie 与跨站追踪

浏览器决定网站之后可以读取哪些已存数据，因此它处于网络追踪的核心位置。Cookie 是网站保存在浏览器中、并在之后的请求中再次发送的一小段记录。第三方 Cookie 属于地址栏所示域名之外的其他域名，曾是跟踪用户在各网站之间行为的主要手段。截至 2025 年底，Safari 和 Firefox 默认阻止跨站追踪。规模最大的浏览器 Chrome 则走了另一条路。2024 年 7 月，谷歌彻底放弃了逐步淘汰第三方 Cookie 的计划；2025 年 4 月，它又确认 Chrome 也不会引入替代性的同意提示。Chrome 转而在用户控制下保留第三方 Cookie。其"追踪保护"功能于 2024 年首次测试，旨在默认限制网站对第三方 Cookie 的访问，从而约束跨站追踪。无论浏览器默认如何设置，《通用数据保护条例》（GDPR）等数据保护法律下的同意义务对 Cookie 依然适用。

浏览器指纹识别

Cookie 可以被删除，但指纹是由浏览器自身的属性拼凑而成的。早期研究揭示了这一问题的规模：Mayer 于 2009 年首次研究浏览器指纹识别，并表明通过 navigator 和 screen 生成的指纹可以唯一识别 96.23% 的浏览器。应对措施大致分为两类。内容屏蔽根据指纹脚本的网络位置阻止其请求；API 限制则限制对已知用于指纹识别的某些 JavaScript API 的访问。Tor 浏览器倾向于全面限制 API，因为这样无需解决检测指纹脚本这一难题。其代价是功能失效：一些网站出于正当目的使用这些受限 API，也会因此无法正常运行。内容屏蔽也有自身风险，因为某个脚本可能具有双重用途，或者属于误判。另一些浏览器则选择随机化或标准化其对外暴露的数值。例如，Brave 默认随机化指纹数据，而 Tor 则通过标准化属性使不同用户看起来更加相似。两种方法都无法彻底消除指纹识别，而且保护效果取决于浏览器最新版本的更新情况。

隐私浏览

隐私浏览或无痕模式是针对本地设备的会话边界，而非针对网络的屏障。其核心作用是：关闭隐私浏览窗口后，该隐私会话中的浏览历史和 Cookie 会被删除。书签和已下载的文件则会保留，并且会话与主配置文件相互隔离，这对于同时登录多个账户或进行测试很有用。但其局限相当明显。网站、雇主、学校和互联网服务提供商仍可看到所访问的地址以及 IP 地址。它也无法防止病毒或恶意软件下载到设备上。安全研究人员还指出，隐私浏览会话中可识别的活动痕迹仍可能通过操作系统、浏览器安全漏洞或恶意浏览器扩展而泄露，并且某些 HTML5 API 可以暴露隐私模式已开启的事实。

加密 DNS 与内置保护

域名查询长期以明文方式传输，这使网络运营商即使在页面内容通过 HTTPS 加密的情况下，仍能看到用户解析过的每一个网站。浏览器为此开始支持加密的域名解析，通常是基于 HTTPS 的 DNS（DoH）或基于 TLS 的 DNS（DoT），将查询发送至指定的解析器。这把可见性从本地网络转移到了解析器那里，因此解析器的选择本身就成为一项隐私决策。加密客户端问候（ECH）是一项相关努力，旨在在 TLS 握手期间隐藏服务器名称。内置追踪保护则结合了这些措施、拦截列表以及按站点划分存储空间，它被广泛视为用户应在设置中检查的基础保护，不过各浏览器的具体默认值有所不同。

扩展与自定义

扩展，也称附加组件（add-ons），是安装到浏览器中的程序，用于改变浏览器的行为，或改变其所加载网页的外观和功能。Firefox 的文档将其扩展平台描述为由用户控制、以网页为核心，其实现在很大程度上与 Chromium 的扩展接口保持一致。正因为这种重叠，为基于 Chromium 的浏览器编写的扩展只需少量修改即可在 Firefox 中运行。

WebExtensions 模型

当前大多数扩展都基于 WebExtensions API，这是一套跨浏览器的系统，开发者可以在 Firefox、Chrome 和 Edge 上使用。其既定目标包括：便于在不同浏览器之间移植，便于审核 Mozilla 商店中的附加组件，以及在浏览器内部实现变化时减少功能失效。每个扩展都由一个清单文件描述，记录其名称、版本以及所请求的权限。代码主要使用 JavaScript 编写，并在几种不同的上下文中运行：保存长期逻辑的后台脚本、注入到符合 URL 模式页面中的内容脚本，以及工具栏弹窗、侧边栏和选项页面等扩展页面。扩展可用的具体 API 取决于其执行上下文、清单中声明的键，以及其声明的权限，例如 tabs、webNavigation 或 webRequest。功能更强的 API 需要扩展在清单中申请相应权限。

这些权限规则是对扩展的主要限制。浏览器在安装时向用户展示扩展能够访问的内容，因此用户接受权限请求的那一刻，就是其授予更大权力的时刻。这使扩展与网络安全和数据隐私联系在一起：一个拥有广泛权限的扩展，可以读取或修改用户在浏览器中的几乎所有操作。

常见类别

扩展大致可分为几类。广告和追踪器拦截工具会过滤网络请求或页面元素。密码管理器负责填写凭据和生成密码。开发者工具添加了检查器、性能分析器和框架调试器。其他常见类型还包括翻译工具、标签页和会话管理器、笔记与剪藏工具、阅读模式以及无障碍辅助工具。许多扩展由小型开发者或非营利项目构建，其中相当一部分是开源软件。

Manifest V3 与广告拦截之争

扩展设计中争议最大的变化，是谷歌的 Manifest V3（MV3）规范，该规范于 2019 年首次公布。其核心技术变化是：用 declarativeNetRequest（DNR）取代了 webRequest API 的阻塞式形式。后者允许扩展在每个网络请求发生时检查并修改它；前者则接受一组由浏览器自行应用的静态规则。谷歌将这一变化描述为在安全、隐私和性能方面的进步，认为限制扩展代码可以减少其能看到的用户流量。电子前沿基金会（EFF）则认为，新 API 削弱了用户控制权，并对隐私工具造成了不成比例的削弱；该组织还指出，谷歌作为大型广告网络的运营者，其身份构成了利益冲突。

规则数量上限成为一个现实问题。关于这一过渡的报道指出，uBlock Origin 需要约 30 万条规则才能正常工作，而 V3 的硬性上限仅为 3 万条。由于 DNR 过滤器必须预先声明，此前未知的追踪域名可能会绕过拦截。时间表也多次调整。早期公告将 Manifest V2 的支持终止时间定在 2024 年年中，但后来的报道则称 2025 年 6 月为最终期限，而且这一过渡普遍被描述为历经数年才推进。

Mozilla 采取了不同的路线。它表示将继续在 MV3 中支持阻塞式 WebRequest。"为了最大限度地与其他浏览器兼容，我们也将同时支持 declarativeNetRequest。"它给出的理由是，若缺乏足够的替代方案，这一替代方案将限制某些类型隐私扩展的能力。Brave 和 Opera 也宣布计划保留部分经典扩展的可用性，不过据报道其承诺力度各不相同。这一事件使浏览器之间出现了明显分野，并为开发者和用户提出了一个更广泛的问题：浏览器厂商是否应当决定哪些扩展功能继续可用。

主题、用户脚本与其他自定义

除扩展之外，用户还可以通过多种方式调整浏览器。主题可以改变界面的颜色和背景图像。Greasemonkey、Tampermonkey 和 Violentmonkey 等用户脚本管理器，允许用户在匹配的网站上运行自己的 JavaScript。自定义样式表提供了另一条途径，Firefox 通过配置文件支持这一功能，但相比官方扩展，它更加脆弱。主页、默认搜索引擎、键盘快捷键、工具栏布局和独立配置文件等设置，构成了常见的调整项。这些方法使用户无需等待厂商即可定制浏览器，但它们依赖与扩展相同的 API 和政策，因此这些规则的任何变化都会同时影响两类功能。

网页标准与治理

浏览器实现的许多技术是在别处定义的。HTML、CSS、JavaScript、HTTP 和 TLS 各自由不同机构维护的规范描述，浏览器厂商同意依据这些文本进行开发。治理问题，即谁来编写规范、分歧如何解决，几乎从万维网诞生之初就一直存在争议。

标准化组织及其职责

万维网标准最初由万维网联盟（W3C）协调，该组织于 1994 年在蒂姆·伯纳斯-李的主持下成立。W3C 负责制定 CSS、无障碍访问和图形等领域的规范，并且多年来还主导了 HTML 的开发。网络超文本应用技术工作组（WHATWG）于 2004 年由苹果、Mozilla 和 Opera 等浏览器厂商的工程师组建，他们希望继续推进 HTML 以及网络应用相关技术的工作。WHATWG 将 HTML 和 DOM 作为"生活标准"（living standards）持续维护，这些标准不断修订，而不是以编号版本发布。

互联网工程任务组（IETF）负责制定网络底层协议，包括 HTTP、TLS 和 QUIC，通常通过工作组完成，其成果以 RFC 形式发布。Ecma 国际通过第 39 技术委员会（TC39）标准化 ECMAScript，即 JavaScript 所基于的语言。由于这些机构各自负责不同的层次，一项浏览器功能可能同时依赖多个机构的成果。

开发、实现与测试

TC39 以协商一致的方式运作。提案需经过五个编号阶段，从初始想法（阶段 0）推进到最终成型的功能（阶段 4），每次晋级都必须得到委员会批准。一项提案通常需要完整的语义和语法描述、验收测试，并且在至少两个引擎中实现后才算完成。自 2015 年起，TC39 每年发布一版新的语言规范，取代了此前版本之间漫长的间隔。

浏览器通过共享测试检验其一致性。网络平台测试套件包含超过 180 万项独立检查，各个引擎运行相同的测试。互操作性项目是各引擎团队每年开展的合作项目，它挑选开发者提出的重点领域，并公布各引擎通过测试数量的得分。据一份摘要称，2024 年重点领域的跨浏览器得分从当年年初的 48% 上升至年底的 95% 以上，而 2026 年互操作性项目涵盖二十个重点领域。这些数字来自项目自身的仪表板，应理解为测试覆盖率的衡量指标，而非行为完全一致的完整证明。

测试也会暴露规范本身的问题。当不同引擎对同一测试给出不同结果时，差异往往指向文本中的歧义，可以在不一致的行为固化到已发布产品之前加以修正。

特性检测、渐进增强与兼容性

由于各项实现推出的时间不一，开发者依赖特性检测，即在运行时检查浏览器是否支持某个 API，然后再调用它。渐进增强是一种相关做法：页面先以最基本的 HTML 和样式构建，确保核心内容可用，再为支持更高级功能的浏览器叠加这些功能。HTML 规范定义了如何解析格式错误的标记，从而使较旧或有缺陷的页面仍能以可预测的方式呈现。

向后兼容是其背后隐含的承诺。厂商通常避免会破坏现有网站的改动，而已被广泛部署的标准也很少被移除。结果是新旧功能可以并存数十年，这提高了每一项新增功能的成本，也是规范工作进展缓慢、较为审慎的原因之一。

关于主导权的争议

最为显眼的治理争议涉及 HTML。在长期平行推进之后，WHATWG 于 2017 年通过了包含专利条款的知识产权政策，W3C 与 WHATWG 随之开始探索合作方式。2019 年 5 月 28 日，两个机构签署了一份谅解备忘录：HTML 和 DOM 的开发主要由 WHATWG 负责，W3C 则协助社区工作、编写测试，并将 WHATWG 的草案纳入其推荐标准（Recommendation）流程，同时停止自行独立发布这些规范。支持者认为，两个相互竞争的"规范性"版本一直有害。批评者则指出，这一安排实际上将控制权交给了浏览器厂商，因为 WHATWG 的编辑与一个由引擎开发者组成的指导小组合作。WHATWG 的编辑过程也曾在社区内引发分歧：在一个案例中，一项对 HTML 规范的拟议修改在社区提出反对后被撤回。

更广泛的争论在于，标准应由多方利益相关者协商一致来主导，还是由少数实现者主导，抑或是由二者结合、实现者掌握最终决定权的模式来主导。每种模式都是在包容性与速度之间，以及在实现者所提供的实践经验之间做出取舍。

浏览器的类型与变体

"浏览器"一词涵盖范围很广。桌面和移动端浏览器最为常见，但请求和显示网络资源这一基本工作，也可以由纯文本程序、自动化的"无头"工具，以及嵌入其他应用中的组件来完成。每种变体在界面、渲染引擎以及浏览器由谁控制等方面各有取舍。

桌面与移动浏览器

桌面浏览器假定使用者拥有大屏幕、键盘和鼠标，并且可用内存和电力充足，能够同时运行大量标签页、扩展程序和开发者工具。移动浏览器则必须适应触控输入、较小的屏幕，以及对内存、电池和网络流量更严格的限制。因此，移动浏览器通常会增加一些功能，例如积极丢弃标签页、减少后台活动、支持手势导航，并且常借助响应式布局和降低分辨率的图片来适配页面。两类设备使用的渲染引擎相同，但外围的界面和资源管理差异很大。两者的区别与其说在于页面引擎本身，不如说在于浏览器外壳在各种限制条件下的表现。

文本浏览器

文本浏览器只显示字符，不显示图片、大部分版式，通常也不运行脚本。最著名的例子是 Lynx，由堪萨斯大学的一个团队于 1992 年首次发布。它的前身 CERN Line Mode 浏览器每次只显示一行，而 Lynx 同年即改为全屏显示。Lynx 用图片的替代文本代替图片，因此适合在不借助图形的情况下测试网站的表现。它也被盲人和低视力用户广泛使用，因为其输出与语音合成及可刷新盲文显示器配合良好。它的局限也是实实在在的：处理复杂表格和框架的能力较差，也无法运行大多数 JavaScript。w3m 和 Links 等现代文本工具延续了同样的传统，但如今它们的用途主要局限于小众需求、无障碍访问，或远程终端环境。

无头浏览器

无头浏览器运行真实的浏览器引擎，但不显示可见窗口。它的渲染引擎和 JavaScript 引擎照常工作，只是由命令行工具或编程接口来控制，而不是由人点击操作。Google 的 Puppeteer 于 2017 年首次发布，通过 JavaScript 接口驱动 Chrome 和 Chromium；微软的 Playwright 支持 Chromium、Firefox 和 WebKit。Selenium 仍被广泛使用，尤其适用于跨多个版本和平台的浏览器兼容性测试。典型用途包括在持续集成流水线中进行软件测试、对单页应用进行回归测试、生成截图和 PDF，以及网页抓取。无头自动化也带来一些实际问题：越来越多的网站使用验证码和机器人检测技术；另外，某些功能（例如部分扩展程序的行为）过去在没有图形显示的情况下较难测试。

嵌入式网页视图

许多应用无需启动完整的浏览器即可显示网页内容，它们使用一种通常称为网页视图（web view）的嵌入式组件。在安卓系统上，Android System WebView 是基于 Chromium 的系统组件，应用通过调用它来渲染页面，并且它可以通过应用商店更新，而不仅随操作系统版本更新。由于大量应用依赖它，版本过旧会带来安全隐患。Meta 曾描述过这样一种情形：用户更新了应用，却没有更新其 WebView 或 Chrome，因此可能仍暴露于上游已修复的漏洞之中。2026 年，Google 发布了一个紧急 Chrome 更新，以修复 WebView 组件中一个可能让攻击者绕过策略控制的缺陷。网页视图还会引发兼容性问题：其中的内容未必与独立浏览器中的表现完全一致，而且宿主应用决定了嵌入页面能够访问哪些内容。因此，开发者必须谨慎处理导航、Cookie 和权限问题。

主要浏览器与引擎家族

目前广泛使用的大多数浏览器都基于三种渲染引擎之一：Blink、WebKit 和 Gecko。每种引擎都配有各自的 JavaScript 引擎，三者都以各自的节奏实现同一套已发布的标准，这也是同一网页在不同浏览器中表现可能略有差异的原因之一。Blink 搭配 V8，WebKit 搭配 JavaScriptCore，Gecko 搭配 SpiderMonkey。尽管它们遵循相同的规范，但实现的速度各不相同。

引擎家族

Blink 是 Chromium 项目的引擎，该项目主要由 Google 与其他贡献者共同开发。Chrome、Microsoft Edge、Opera、Vivaldi、Arc、Brave 以及其他基于 Chromium 的浏览器都使用 Blink。Blink 还是一些嵌入式网页视图的底层引擎，包括 Android WebView、Windows WebView2，以及用于渲染应用界面的 Electron。Blink 的渊源可追溯到 WebKit。WebKit 始于 2001 年，当时 Apple 分叉了 KDE 项目的 KHTML 引擎，用以开发 Safari。2013 年，Google 分叉 WebKit 创建了 Blink，以便独立演进该引擎。之后，微软也采用了同一基础：自 2020 年 1 月起，Microsoft Edge 基于 Chromium 构建，使用 Blink 渲染引擎和 V8 JavaScript 引擎。

WebKit 驱动 Safari，并且在历史上是 iOS 上所有浏览器所使用的引擎。Gecko 则不属于 WebKit 的谱系：它驱动 Mozilla Firefox，是唯一不源自 WebKit 的主流引擎。其历史相对独立，始终由 Mozilla（及早期的 Netscape）单独开发。

浏览器及其设计目标

各浏览器都在共享引擎之上添加自己的界面、服务和默认设置，因此引擎的选择更多地解释了兼容性，而非产品的特性。基于 Chromium 的浏览器可能会添加自己的用户界面、账户系统、隐私功能、同步、企业管理控制或其他服务，但这些附加内容并不会自动使其成为另一种引擎。其独特的目标通常是在产品层面提出的。据一份引擎对比表所述，Safari 通常与电池效率和稳定性相关联，Firefox 与标准合规性、隐私和引擎独立性相关联，Chrome 则与速度和广泛的兼容性相关联。Opera 内置了侧边栏和内置 VPN 等额外功能，三星互联网预装在三星 Galaxy 设备上，Brave 则默认屏蔽广告和跟踪器。

使用率的衡量

市场份额数据在很大程度上取决于统计方式。StatCounter 在全球超过 100 万个网站上安装了其跟踪代码。由于它以页面浏览量计算浏览器的市场份额，因此当用户访问受该公司监测的网站时，可能会被多次计算。其数据也属于“原始”数据，未经加权处理，也未采取其他手段来修正数据收集中的异常情况。NetMarketShare 则统计约 4 万个网站的独立访问量，无论用户一天内访问其中某个网站多少次，该公司都只计为一次访问。Cloudflare 统计其自有网络上的 HTTP 请求，得出的结果又有所不同，并且其 Radar 服务会从测量数据中过滤机器人流量，因此其结果更接近纯人类访问流量。

引擎层面的数据同样因来源而异。一项估计认为，若将 Chrome、Edge、Opera 及 Chromium 系列的其他浏览器合并计算，Blink 约占全球浏览量的 70%；而另一项数据显示，在 2026 年某一个月内，基于 Blink 的浏览器占所有已统计会话的 77.53%。这类差异在各类样本调查中属正常现象，只有当统计方法、时间段和设备范围一致时，比较才有意义。

平台规则与引擎要求

在 iOS 上，引擎的选择受到平台政策的制约，而不仅仅取决于市场力量。在大多数国家，iOS 上的 Chrome、Edge、Firefox 以及其他热门网页浏览器都被要求使用 WebKit，即驱动 Safari 的网页引擎。Apple 表示，WebKit 要求出于安全与隐私方面的考虑，但批评者认为该政策具有反竞争性。

欧盟已就其市场改变了这一做法。《数字市场法》迫使 Apple 从 iOS 17.4 开始，在欧盟为替代浏览器引擎提供新的选择。但这种开放是有条件的：Apple 要求获得相应授权，并满足功能标准、安全承诺、漏洞披露政策、及时更新以及按地区分发的相关条件。采用进展缓慢，有评论者指出，截至 2025 年底，iOS 上使用替代渲染引擎的浏览器数量为零。日本也采取了类似的做法。其《移动软件竞争法》原定于 2025 年 12 月 18 日全面实施，该法禁止任何阻止或妨碍采用替代浏览器引擎的措施。观察人士预计英国也会出现类似的义务。

性能与优化

加载速度与响应性的测量

网页性能通常不是用单一的速度数值来描述，而是用一组较小的时间与稳定性指标。最广为人知的一组是核心网页指标，谷歌将其定义为：衡量加载的最大内容绘制（LCP）、衡量响应性的下一次绘制交互时间（INP），以及衡量视觉稳定性的累积布局偏移（CLS）。其中"良好"的阈值分别为：LCP 不超过 2.5 秒，INP 不超过 200 毫秒，CLS 不超过 0.1。这些数值以真实页面访问的第 75 百分位数进行评估，因此页面必须在大多数访问中表现良好，而不能只在某次最理想的测试中达标。2024 年 3 月，INP 取代首次输入延迟（FID）成为响应性指标。与其前身不同，INP 考虑的是交互的整个生命周期，而不仅仅是第一个事件处理程序运行前的等待时间。

因此，开发者会区分实验室测量与现场测量。实验室测试在受控的设备和网络环境下进行，结果可重复，便于诊断问题。现场数据则来自真实用户，通常由浏览器收集并汇总到公开数据集中，反映访问者在各种硬件和网络条件下的实际体验。浏览器通过性能 API 及相关观察者接口提供底层的计时事件，因此网站也可以自行记录这些数值。

缓存、优先级与延迟加载

加载页面的大部分时间都花在获取资源上，因此浏览器和网站都会尝试减少请求数量，并对请求的先后顺序加以安排。阻塞渲染的样式表会被尽早获取，而脚本则可以标记为不阻塞 HTML 解析地加载。开发者还可以提示即将需要的资源，并为图片或其他请求设置优先级。为图片和嵌入框架声明宽度与高度，可以让浏览器在内容到达前预留空间，从而有助于控制 CLS。

延迟加载是指推迟获取尚未接近视口可见区域的资源，例如长文章下方的图片。现代浏览器通过图片和 iframe 上的原生属性支持这一功能，因此在常见场景下页面无需再编写自定义脚本。缓存在多个层面发挥作用：HTTP 缓存在响应仍然新鲜时直接复用；条件请求让服务器确认已存储的副本是否仍然有效；服务工作线程则可以为离线访问或重复访问保留自己的存储。另一项优化是往返缓存，它将整个页面保留在内存中，使后退导航几乎可以瞬间恢复页面。

内存与能耗管理

现代浏览器同时运行多个标签页，而每个标签页都可能占用大量内存。为了对此加以控制，Chrome 引入了一种名为"内存节省程序"的自动机制，约在 2023 年的 110 版本前后首次出现。启用后，Chrome 会主动丢弃在后台闲置一段时间的标签页，从而为活动标签页和其他应用释放内存。该标签页仍保留在标签栏中，用户切换回来时会重新加载。因此，Chrome 的开发者指南建议网页应用在状态变化时以及标签页被隐藏时保存其状态，以免因丢弃而丢失工作内容。用户可以将特定网站排除在外，但开发者无法在页面中控制这一设置。

后台节流是与之相关的机制，用于减少不可见页面所执行的工作。隐藏标签页中的定时器会被限制在最小间隔之内，由于没有内容需要绘制，动画帧回调会被暂停，而长时间隐藏的页面可能还会受到更严格的限制。Chrome 在笔记本电脑上的省电行为，也会对处于其他状态的页面施加类似的限制。这些措施可以减少 CPU 唤醒次数并降低电池消耗，但也可能干扰依赖精确计时的后台应用。出于这一原因，浏览器通常会豁免正在播放音频或视频的标签页，网站也可以为某些活动申请例外。

功能、兼容性与性能之间的权衡

每项优化都有其代价。预加载只有在资源确实被使用时才有帮助，而浪费的请求会占用移动网络的带宽。若过期规则配置不当，激进的缓存可能会提供过时的内容。对页面顶部附近的内容应用延迟加载，可能会推迟最大元素的绘制，从而使 LCP 变差。丢弃标签页可以节省内存，但会丢失未保存的表单输入和滚动位置，并迫使页面重新加载。节流可以节省能耗，但可能破坏依赖时序的功能。

功能的增长也会带来类似的矛盾。大型 JavaScript 包、为旧版引擎转译的代码，以及广告和分析等第三方脚本，往往是页面变得可响应所需时间的主要来源，在低端智能手机上尤为明显。依赖 GPU 和编译代码的丰富图形与计算密集型功能，可能会超出较弱硬件的承受范围。因此，浏览器开发者和网站作者必须在新能力与速度、内存占用及对旧设备的兼容性之间取得平衡，而这种平衡很少能一劳永逸地确定。

无障碍与国际化

浏览器通过无障碍树向辅助技术呈现页面。无障碍树是从 DOM 派生出的一个并行结构。对于每个与辅助技术相关的元素，浏览器会计算其角色、名称、状态和关系，然后交给平台接口，例如 Windows 上的 UI Automation、macOS 上的 NSAccessibility 以及 Linux 上的 AT-SPI。NVDA、JAWS 和 VoiceOver 等屏幕阅读器读取的是这棵树，而不是视觉布局。按钮、标题和表单标签等语义化 HTML 元素进入树时保留了其含义。由通用 div 和 span 元素构建的自定义控件通常不具备这些含义，因此 WAI-ARIA 规范允许作者添加角色、状态和属性（如 "expanded" 或 "checked"）来弥补这一缺口。ARIA 只是一种补充：它描述元素，但不赋予元素行为，脚本必须使这些属性与界面保持同步。通用的做法是：在原生 HTML 控件足够满足需求时优先使用它们。各浏览器将 ARIA 映射到平台 API 的完整程度有所不同，这种差异至今仍是开发者结果不一致的一个实际来源。

有若干浏览器功能无需针对特定页面做任何工作，就能为残障用户提供服务。键盘导航允许用户使用 Tab 键、方向键和 Enter 键操作页面，而不必依赖指针，这需要合理的焦点顺序和可见的焦点指示。浏览器提供页面缩放（会按比例放大包括布局在内的所有内容）以及仅文本缩放（只放大文字，不改变页面其余部分）。使用相对单位和可重排布局的网站对这两种缩放的适应性更好。用户还可以设置最小字号、自定义颜色以及高对比度模式，操作系统的"减少动态效果"偏好也可以通过媒体查询提供给页面。浏览器有自己的快捷键和菜单，但必须避免占用辅助技术所需的按键；浏览器快捷键与屏幕阅读器命令之间的冲突是一个反复出现的问题。

无障碍指南有着悠久的历史。第一份网络无障碍指南由 Gregg Vanderheiden 编写，于 1995 年 1 月发布。W3C 的《Web 内容无障碍指南》（WCAG）先后发布了 1.0 版（1999 年）和 2.0 版（2008 年）。WCAG 2.2 于 2023 年 10 月 5 日成为 W3C 推荐标准，之后又被批准为 ISO/IEC 40500:2025。该指南围绕四项原则组织：可感知、可操作、可理解和健壮（简称 POUR）。符合性依据成功准则进行衡量，这些准则大多与技术无关，但许多准则取决于浏览器的行为。W3C 的《用户代理无障碍指南》（UAAG）直接面向浏览器，而 WCAG 主要面向内容。因此，责任是共同承担的：浏览器必须暴露语义、支持输入与缩放并尊重用户设置；网站作者则必须提供文字替代、足够的对比度、带标签的控件以及可通过键盘操作的组件。实测结果表明，这种共同责任往往未能落实。据一家无障碍出版机构报道，2026 年 WebAIM 对前一百万个网站首页的分析发现，其中 95.9% 存在可检测到的 WCAG 2 失败项。

国际化以 Unicode 为基础，它为浏览器提供了统一的字符集和编码模型。UTF-8 是网页的主流编码，lang 属性则告诉浏览器应采用哪种语言规则来处理断字、引号、字体选择和语音合成。阿拉伯文和希伯来文等从右至左书写的文字要求浏览器应用 Unicode 双向算法，以确保混合方向的文本排序正确；dir 属性以及 inline-start、inline-end 等逻辑 CSS 属性，使页面布局能够适应两种书写方向。天城文和阿拉伯文等需要复杂字形处理的文字依赖文字整形引擎，中日韩文字的断行规则也不同于拼音文字。许多语言通过输入法编辑器输入，它们在多次击键中逐步组合字符。浏览器必须通过组合事件把这种组合状态告知脚本，否则文本框会出现错误行为。日期、数字和货币的格式化则可通过 ECMAScript Intl API 供脚本调用，该 API 依赖引擎内置的区域数据。

无障碍与国际化在多个方面相互影响。屏幕阅读器依赖 lang 属性来切换语音和发音规则，双向文本则可能同时干扰视觉焦点顺序和语音输出。翻译后的界面往往会变长，这可能破坏为某种语言设计的布局，并引发缩放和重排故障。由于这些问题横跨浏览器与页面两方，浏览器厂商、标准化组织和网站开发者会从不同角度测试同一功能，而二者之间的责任划分在实践中仍是一个悬而未决的问题。

作为应用平台的浏览器

大约二十年间，浏览器从文档阅读器发展成了完整应用的运行环境。现代网页即使在没有网络连接时也能继续工作，可以在设备上存储数据，执行大量计算，并调用图形处理器进行绘制，而且无需单独安装。其主要机制包括渐进式 Web 应用、一组底层的二进制与图形技术、基于浏览器引擎构建的桌面封装，以及与在线服务的集成。

渐进式 Web 应用（PWA）是这一转变最直接的形式。PWA 是一个普通网站，额外添加了描述安装后外观的 Web 应用清单，以及一个服务工作线程。服务工作线程是一个独立于页面运行的 JavaScript 文件，位于页面与网络之间，能够用本地缓存响应请求。开发者会为每类资源选择缓存策略：静态资源适合“缓存优先”，经常变化的数据适合“网络优先”，而“过期后重新验证”则先返回缓存副本，同时在后台获取新版本。响应内容保存在 Cache Storage API 中，结构化记录通常存入 IndexedDB。服务工作线程还支持推送通知和后台同步，使排队中的操作能在网络恢复后发送。实际上，PWA 的大部分离线行为都来自这几个组件，而不是浏览器默认提供的功能。

WebAssembly 是一种紧凑的二进制指令格式，使用 C、C++、Rust 等语言编写的代码能够在浏览器中以接近原生机器码的速度运行。W3C 于 2019 年将其发布为推荐标准，到 2020 年所有主流浏览器都已支持。后续修订增加了垃圾回收支持、64 位内存寻址、异常处理和尾调用。Unity 等游戏引擎借助它发布无需插件即可运行的 3D 游戏。WebAssembly 在 CPU 上执行，因此在图形方面，它通常承担承载程序逻辑的角色，而渲染工作则交由其他部分处理。

渲染大量 3D 内容需要访问 GPU。源自 OpenGL ES 的 WebGL 从 2010 年代初起提供了这一能力，但它不支持通用计算。WebGPU 是其继任者，参照 Vulkan、Metal 和 Direct3D 12 等现代原生 API 设计，并提供计算着色器，用于物理模拟和机器学习等任务。Chrome 和 Edge 于 2023 年 4 月首次推出 WebGPU，Safari 在 2025 年 6 月随 Safari 26 跟进，Firefox 则在 2025 年 7 月随 Firefox 141 发布。Transformers.js 和 ONNX Runtime Web 等库结合了 WebAssembly 与 WebGPU，使机器学习模型能够在用户自己的硬件上运行，模型文件在首次下载后会被缓存。性能在很大程度上取决于模型大小和设备，而且 WebGPU 在着色器编译阶段仍有一定的启动开销。

桌面应用同样建立在浏览器技术之上。Electron 将 Chromium 渲染引擎与 Node.js 运行时结合在一起，使开发者能够用 JavaScript、HTML 和 CSS 编写桌面软件。它最初在 GitHub 以 Atom Shell 之名诞生，现由 OpenJS 基金会维护。Visual Studio Code、Slack 和 Discord 是最知名的 Electron 应用之一。每个 Electron 应用都运行一个主进程，该进程可通过 Node.js 访问操作系统功能；每个窗口则在一个渲染进程中运行，其行为与网页非常相似。这种方式缩短了网页开发团队的开发周期，但每个应用都要附带一份浏览器引擎，从而增加了内存占用和磁盘体积。由于渲染进程要显示网页内容，这些应用也继承了浏览器的威胁模型，因此需要依赖沙箱机制，并保持所捆绑的引擎处于最新版本。

浏览器还与在线服务相连。基于账户的同步功能可以在设备之间传递书签、历史记录和已保存的密码，平台也提供用于登录、支付和云存储的 API。WebAuthn 等认证标准让浏览器能够使用通行密钥或硬件安全密钥，这些方式依赖公钥密码学，从不向网站发送共享密钥。Payment Request API 允许网站将支付信息交给浏览器自身的弹出界面，以便使用已保存的银行卡和电子钱包。基于重定向的 OAuth 与 OpenID Connect 登录将 Web 应用与身份提供商联系起来，许多应用还将数据存放在云计算后端。这些集成让浏览器的功能更加强大，但也使认证和支付流程集中于少数浏览器厂商和身份平台手中，由此引发了关于控制权和可移植性的问题。

市场结构与监管

浏览器市场往往趋于集中，其原因不仅限于工程质量。网络效应是一个原因：网页开发者会用大多数访问者已在使用的引擎进行测试，因此一款略胜一筹的竞争浏览器也难以获得多少优势。默认设置的影响则更为强大。大多数人会保留设备预装的浏览器或搜索框，因此控制预装选项的一方无需在功能上取胜，就能获得大量流量。研究者探讨了主动选择能否抵消预设默认值的拉力，这一问题构成了近期许多监管工作的框架。

浏览器厂商的大部分收入通常来自搜索服务提供商，这使得分发决策变成了收入问题。Mozilla 自身的数据便能说明这种依赖：2020 年，Mozilla 收入的 86% 来自其与谷歌的搜索合作协议；另一份后来的财务报告显示，其 5.93 亿美元收入中，有 5.1 亿美元来自谷歌搜索的付款。向苹果支付的款项规模则大得多。据报道，谷歌在 2021 年为 Safari 默认搜索位置支付了约 180 亿美元。美国案件的法院认定，此类安排实际上起到了事实上的排他性交易作用，使竞争对手无法获得改进自身搜索产品所需的查询量。正如一项针对该案的分析所指出的，更换默认搜索引擎几乎没有成本，用户可以零成本、以极小的努力改变默认引擎，真正的障碍在于默认设置本身，而非用户的努力程度。

美国的诉讼是对这些观点的最大检验。2024 年 8 月，阿米特·梅塔法官认定谷歌违反了《谢尔曼法》第 2 条，在搜索及相关广告领域构成非法垄断。他于 2025 年 9 月作出的补救裁决驳回了强制出售 Chrome 的请求，但禁止了涵盖谷歌搜索、Chrome、谷歌助手和 Gemini 应用的排他性分发合同。谷歌仍可向分销商支付默认位置费用，前提是付款不以排他性为条件，且协议期限不超过一年。法院拒绝了全面禁止付款的提议，理由是此类禁令将对设备制造商、无线运营商和浏览器开发者造成“重大损害风险”。批评者则认为，允许继续付款使排除竞争的主要机制依然存在。据报道，这些补救措施已于 2026 年 6 月生效，美国司法部和一个州联盟表示计划提起上诉，焦点集中在 Chrome 和与苹果的合作安排上。

欧盟则通过选择界面采取了不同的路径。2023 年 9 月，欧盟委员会根据《数字市场法》将谷歌认定为守门人，该法规于 2024 年 3 月在欧盟生效。依据该法，在特定条件下，iOS 和安卓系统必须向用户展示浏览器选择界面。在欧盟，用户首次在支持的 iOS 或 iPadOS 版本上打开 Safari 时，会出现苹果的选择界面；只有在欧盟 App Store 中达到下载量门槛后，浏览器才会被列入选项。谷歌在安卓设备的初始设置过程中加入了浏览器选择界面，并在其他平台的 Chrome 中加入了搜索选择界面。

这些影响是可以衡量的。一项对该政策推行情况的双重差分研究发现，与无此类强制要求的反事实情景相比，自政策实施 15 个月起，iOS 上 Firefox 的使用率高出 113%，安卓上高出 12%。作者认为，这一差距主要源于推行时间的差异：安卓的选择界面主要出现在新设备上，而 iOS 也在现有设备上显示了选择界面。据倡导组织“开放网络倡导”（Open Web Advocacy）称，2026 年 3 月，谷歌同意将欧盟选择界面中被选中的浏览器直接放在 Pixel 主屏幕的快捷栏中，取代 Chrome。Mozilla 也在向英国竞争与市场管理局提交的意见中主张，推迟实施浏览器选择要求将巩固现有企业的地位，并引用欧盟和日本的制度作为可借鉴的范例。

非营利和开源的浏览器项目是对这种集中化的制衡力量，但它们的独立性取决于资金来源。Mozilla 公司通过基金会结构将利润投入开源项目，但其大部分收入依赖搜索分成，因此它已拓展到 VPN 和 Relay 等付费服务订阅业务。Chromium 同样是开源的，但其开发在很大程度上依赖谷歌的支持。因此，源代码的可获取性本身并不能保证竞争，分发与资金安排的重要性至少不亚于此。

未解决的问题与争议

引擎多样性

目前，大多数浏览器依赖少数几款渲染引擎，其中 Blink（Chromium 所采用的引擎）使用最为广泛。批评者认为，这种集中化使某一家机构对网络的构建方式拥有过大的影响力。一份 2026 年的比较报告指出，包括 Chrome、Edge、Brave、Opera、Vivaldi 和三星互联网在内的绝大多数浏览器，现在都运行在同一个 Chromium/Blink 引擎上，这使网络标准倡导者对"Blink 单一化"表示担忧。目前，只有 Firefox（Gecko）和 Safari（WebKit）仍是主要的非 Chromium 阵营浏览器。

实际风险在于，开发者会针对市场份额最大的引擎进行测试，于是该引擎的特殊行为便事实上成为标准。一位评论者这样概括这一担忧：一款占主导地位的浏览器会让开发者只针对它进行开发，而忽视与小型浏览器的兼容性。引擎市场份额的数据并不稳定。一篇 2026 年的行业文章估计 Chromium 的份额约为 79%，而其他分析采用的浏览器与引擎统计口径不同，因此具体数字取决于统计方法。

反垄断行动迄今尚未直接改变这一格局。2025 年 9 月，美国联邦法院拒绝下令拆分 Chrome 或安卓操作系统，认为此类措施过于严厉，且与责任认定裁决中指出的排他性协议并无直接关联。不过，法院确实禁止谷歌订立或维持与 Chrome、搜索、谷歌助手及其 Gemini 应用等服务分发相关的排他性合同。

隐私与广告驱动的商业模式之争

浏览器在多个方面与广告存在商业关联。例如，谷歌的 Chrome 处于一项业务的核心位置。正如一份法庭文件摘要所描述的，浏览器提供的数据有助于其广告业务投放定向广告。因此，限制跨站追踪的厂商可能与自身的收入模式，或依赖追踪的合作伙伴形成竞争关系。Brave 和 Firefox 等以隐私为核心的产品，尝试把隐私作为差异化卖点。一份 2026 年的报告称，Brave 和 Firefox 正在成为注重隐私的用户首选的替代方案，其可信度正在提升。更广泛的担忧在于：某一款浏览器的用户越多，其所属公司能够获取的用户数据和使用习惯就越多，这引发了隐私方面的问题。

在增加平台功能的同时保持兼容性

每一项新能力，例如后台同步、设备访问或新的布局模型，都必须经过实现和测试，并在多年内持续可用。因此，浏览器面临一种两难：增加功能会加重维护负担，而删除旧有行为又可能导致现有网站失效。即使未来所有浏览器都选用同一款引擎，我们仍需多年支持现有的引擎，这是一位开发者在讨论中提出的看法。同样的张力也体现在关于弃用的争论中：由于一些网站和企业系统仍依赖旧功能，移除遗留功能常常引发争议。

AI 辅助浏览与自动化代理

变化最快的争论围绕代替用户浏览网页的 AI 代理展开。流量数据显示这一转变幅度很大，不过这些数字来自采用不同统计方法的公司。Cloudflare 首席执行官在 2026 年 6 月宣布，自动化流量已超过人类流量；一项 2026 年的分析称，全球所有 HTTP 网络流量中，自动化流量占 57.4%，人类用户则降至 42.6%。另一来源给出的数字是，在 HTML 网络流量中，机器人占 57.5%，人类占 42.5%。两者的差异说明，这些数字对统计范围非常敏感。

面向代理的浏览器也在扩大份额。一家机器人检测公司报告称，6 月份 Comet Browser 仍是最大的代理流量来源，占总量的 47.6%，接近全部流量的一半。该公司的测量只覆盖其网络所观察到的流量，因此描述的是样本，而非整个网络。

这些代理改变了用户、浏览器与网站之间的关系。出版商指出，代理式 AI 浏览器扮演了一种新型中间人的角色：它们不再把读者引向网站，而是可以直接在浏览器内部阅读、概括信息并采取行动。围绕页面浏览量构建的广告系统面临难题，因为它们需要区分真人浏览与机器访问，并据此调整变现逻辑。出版商的应对并不统一：一项 2026 年的调查发现，79% 的新闻出版商至少屏蔽了一个 AI 训练机器人，而屏蔽 Google-Extended 的仅有 46%。

对用户而言，核心问题在于控制权。谷歌已宣布 Chrome 可以作为自主代理运行，代表用户浏览网页、点击、填写表单并完成多步骤任务。一些设计提出为代理的操作设定明确的权限边界，但目前仍不清楚：用户如何审计代理的行为，网站如何对代理进行身份验证，以及 WebMCP 等拟议标准能否让网站以结构化的方式向代理提供工具，而不必迫使代理去解析页面。

参考来源

Reading: Web Browsercourses.lumenlearning.com
Web browseren.wikipedia.org
Web client definitionnordvpn.com
Vannevar Bush, Memex, As We May Think, The Atlantic, 1945livinginternet.com
As We May Thinkmuseum.parallel.ai
The birth of the World Wide Webtimeline.web.cern.ch
The world's first browser/editor, website and server go live at CERNtimeline.web.cern.ch
Inventing the Web - CHM Revolutioncomputerhistory.org
WorldWideWeben.wikipedia.org
Tim Berners-Leelemelson.mit.edu
1993: Mosaic Launches and the Web Becomes Open Sourcecybercultural.com
Mosaic 1.0 released on 22 April 1993 - WiredPenwiredpen.com
NCSA Mosaicen.wikipedia.org
NCSA Mosaic - The Code Librarydevthrottle.com
April 22, 1993 - A Day The Internet Fundamentally Changedcircleid.com
As We May Think by Vannevar Bush on Manhattan Rare Book Companymanhattanrarebooks.com
Browser warsen.wikipedia.org
Netscape Navigator and the First Browser Warinternet-history.info
Browser Warsthehistoryoftheweb.com
Global Information Assurance Certification Paper Copyright SANS Institutegiac.org
The History of the Browser Wars: When Netscape Met Microsoft - The History of the Webthehistoryoftheweb.com
The Browser Wars: Netscape Navigator vs Internet Explorerslicker.me
29 years ago, Microsoft thought of bundling Internet Explorer with Windowsxda-developers.com
D.C. Circuit Opinion -- U.S. v. Microsoftcyber.harvard.edu
U.S. v. Microsoft Corp., 253 F.3d 34 (D.C. Cir. 2001) :: Justialaw.justia.com
United States v. Microsoft Corp., 87 F. Supp. 2d 30 (D.D.C. 2000) :: Justialaw.justia.com
Firefoxen.wikipedia.org
The Story of Firefox: from Underdog to Superherolinuxjournal.com
History of the Mozilla Project — Mozillamozilla.org
Gecko (software)en.wikipedia.org
Netscape vs. Internet Explorermediag.com
Browser History: Epic power struggles that brought us modern browsers — Firefox.comfirefox.com
U.S. v. Microsoft, The Fight Continues - FindLawcorporate.findlaw.com
Mozillaen.wikipedia.org
Netscape (web browser)en.wikipedia.org
Mozilla Application Suiteen.wikipedia.org
Firefoxbritannica.com
Inside look at modern web browser (part 1)developer.chrome.com
Multi-process Architecturechromium.org
Site Isolation Design Documentchromium.org
How modern browsers work. A very deep-dive into how modern web…medium.com
Why Chrome Browser adopted Multi-process architecture?reeshabh-choudhary.medium.com
Site Isolationchromium.org
Cleanly Escaping the Chrome Sandbox - Theori BLOGtheori.io
Firefox and Chromiummadaidans-insecurities.github.io
Chromium - Site Isolationchromium.googlesource.com
Chromium Docs - Process Model and Site Isolationchromium.googlesource.com
Sprocket - Chromium architecture overviewszeged.github.io
Populating the page: how browsers work - Performancedeveloper.mozilla.org
How the Browser Rendering Pipeline Actually Works - DEV Communitydev.to
Inside the Browser Rendering Pipeline - Aleksandar Gjoreskialeksandargjoreski.dev
Browser Rendering Pipelinetheclientside.net
Compilation of JavaScript to Wasm, Part 2: Ahead-of-Time vs. JITcfallin.org
JavaScript Engines Explained—Comparing V8, SpiderMonkey, JavaScriptCore, and More · Frontend Dogmafrontenddogma.com
A deep dive into the inner workings of JavaScript engines: writing code that makes V8 happyaudreydoyen.com
The JavaScript Event Loop — macro/microtasks, rendering, and avoiding jankcaduh.com
When Does requestAnimationFrame Execute? Understanding Its Timing in the JavaScript Event Loop — w3tutorials.netw3tutorials.net
The Event Loop: Microtasks, Macrotasks & Output Prediction - DEV Communitydev.to
The Browser Render Pipeline Every Frontend Engineer Should Knowisraynotarray.com
How Browsers Read HTML, Render, and Apply Styles, The Sequence and Developer Best Practicesspaceout.pl
HTTP/3 and QUIC: Solving Transport Head of Line Blocking and Connection Migrationsystemoverflow.com
Why HTTP/3 Exists: The Limits of HTTP/2 and the Rise of QUIC - DEV Communitydev.to
Emulating web browser in a dedicated intermediary boximage-ppubs.uspto.gov
Web cacheen.wikipedia.org
ETags: What they are, and how to use themfastly.com
Cache control in HTTP. Optimize bandwith usage using cache…medium.com
Resource Hintsw3.org
Resource Hints explainedhttp.dev
Assist the browser with resource hintsweb.dev
Resource Hints Explained: Prefetch, Preload, Preconnect, DNS-Prefetch — Enterno.ioenterno.io
Telemetry over quicimage-ppubs.uspto.gov
HTTP caching - MDN Web Docs - Mozilladeveloper.mozilla.org
Same-origin policyen.wikipedia.org
Same-origin policy (SOP)portswigger.net
Same-origin policy - Security - MDN Web Docs - Mozilladeveloper.mozilla.org
Agentic Browsers and the Same-Origin Policyagent-security.cs.washington.edu
What Is Same-Origin Policy? The Key to Web Securityhuntress.com
Same-Origin Policy (SOP)invicti.com
Chromium Docs - What’s Up With Site Isolationchromium.googlesource.com
Site isolationen.wikipedia.org
Where the Wild Warnings Are: Root Causes of Chrome Certificate Errorsresearch.google
Where the Wild Warnings Are: Root Causes of Chrome HTTPS Certificate Errorsacmccs.github.io
Where the Wild Warnings Are: Root Causes of Chrome HTTPS Certificate Errorsresearchgate.net
HTTPS by defaultblog.google
The State of https Adoption on the Webresearch.mozilla.org
Third-Party Cookies in 2026studiostray.com
No More Cookies? Google Third-Party Cookies Ending in Chromecookiebot.com
Google Privacy Sandbox officially shuts down: What it means and what’s nextusercentrics.com
FP-Radar: Longitudinal Measurement and Early Detection of Browser Fingerprintingarxiv.org
Fingerprinting the Fingerprinters: Learning to Detect Browser Fingerprinting Behaviorsarxiv.org
Private browsing: What it doestheconversation.com
Private browsingen.wikipedia.org
Browse in Incognito mode - Computer - Google Chrome Helpsupport.google.com
How to Protect Your Privacy From Browser Fingerprinting (2026)privacyon.com
Google shares update on next step toward phasing out third-party cookies in Chromeblog.google
About the WebExtensions APIextensionworkshop.com
Browser extensions - Mozilla - MDN Web Docsdeveloper.mozilla.org
Browser Extensionsbrowserext.github.io
JavaScript APIs - Mozilla - MDN Web Docsdeveloper.mozilla.org
googles manifest v3 will make the fight against third party adblockers even worsetechradar.com
Mozilla opens testing for Manifest v3 extensions in Firefoxtheregister.com
Firefox Hits Out At Google Chrome’s Manifest V3forbes.com
WebExtensions - MozillaWikiwiki.mozilla.org
Chrome pushes forward with plans to limit ad blockers in the futuremalwarebytes.com
Chrome Manifest V3 Deadline: Ad Blocker Impact 2025byteiota.com
Google's Controversial Manifest V3 Changes - The End of Ad Blocking?franklinetech.com
Firefox confirms support for Manifest V2 & V3 extensions, contrasting Google's phase-outalternativeto.net
HTML: The Living Standardhtml.spec.whatwg.org
pnews 20190603w3.org
W3C and WHATWG to work together to advance the open Web platformw3.org
WHATWGen.wikipedia.org
W3C and WHATWG agreement: Single version of HTML, DOM specificationstechxplore.com
HTML Standardskdwebhostingdesign.com
What is the HTML Living Standard?|SEO / AIO / GEO / LLMO Services in Japanswitchitmaker2.com
The TC39 Processtc39.es
ECMAScript Language (ECMA-262), including JavaScriptloc.gov
interop/2026/README.md at main · web-platform-tests/interopgithub.com
interop/2024/README.md at main · web-platform-tests/interopgithub.com
The Interop Project Explainedblog.openreplay.com
Launching Interop 2025hacks.mozilla.org
Announcing Interop 2026webkit.org
Playwright vs Puppeteer: which to choose?blog.openreplay.com
Puppeteer vs Playwrighttestomat.io
Playwright vs. Puppeteer: Browser Automation Toolstestgrid.io
Puppeteer vs. Playwright: Automated testing tools comparedcontentful.com
Mastering Headless Browser Automation: Architecture, Scaling & Browserbrowserless.io
Top 8 Headless Browser Testing Tools [2026] - DEV Communitydev.to
Running and debugging testsplaywright.dev
Lynx (web browser)en.wikipedia.org
Lynx (web browser) - Wikiwandwikiwand.com
2005 Text Mode Browser Rounduplinuxjournal.com
Using the Lynx text-based Web browser - Computing Tidbitscects.com
Software:Lynx (web browser) - HandWikihandwiki.org
Internet History: Lynx, the Text-Only Web Browser - Cowbop BeBoy's Blogblog.spacehey.com
Launching a new Chromium-based WebView for Android - Engineering at Metaengineering.fb.com
Google Rolls Out Chrome 143 Update for Security Fixknowtechie.com
What Is the Android System WebView and What Can You Do With It?geekflare.com
WebView docs (go/webview-docs) - FAQ for WebView Userschromium.googlesource.com
Browser Engine Differencesinventivehq.com
What is Blink?developer.chrome.com
Browser Engines Explained: Blink vs Gecko vs WebKit - BrowserInsightbrowserinsight.net
Browser Engines Explained: Blink, Gecko, WebKit & Typesitechguides.com
FAQgs.statcounter.com
In fog of browser wars, the victor varies with the metricspcworld.com
Browser Market Share Statistics 2026 — Axis Intelligence Researchaxis-intelligence.com
Browser Market Share 2026: Concentration, Engines, and the Numbers Panels Disagree On - Axis Intelligenceaxis-intelligence.com
Japan Law Will Require Apple to Allow Non-WebKit Browsers on iPhoneforums.macrumors.com
WebKit Keeps Apple in Control of iPhone Browsing - AppleMagazineapplemagazine.com
Michael Tsai - Blog - DMA Compliance: Alternative Browser Enginesmjtsai.com
Japan to force Apple to allow third-party browser engines by Decemberappleinsider.com
Explained: How Japan's Smartphone Act Challenges Apple's Browser Engine Restrictions On iOSetvbharat.com
History of Web Browser Engines from 1990 until todayeylenburg.github.io
Google Chromeen.wikipedia.org
Google Chrome Statistics 2026: Market Share, Users, and Browser Dominance Data - Axis Intelligenceaxis-intelligence.com
Japan Law Will Require Apple to Allow Non-WebKit Browsers on iPhone - MacRumorsmacrumors.com
Core Web Vitals: How to Fix LCP, INP and CLSspaceads.agency
Core Web Vitals 2026: Optimize LCP, INP & CLShafencity.dev
Core Web Vitals 2026: INP, LCP & CLS Optimizationdigitalapplied.com
What developers need to know about Chrome's Memory and Energy Saver modesdeveloper.chrome.com
WCAG 2.2 - Web Content Accessibility Guidelinesquality.arc42.org
Web Content Accessibility Guidelinesen.wikipedia.org
Accessible Rich Internet Applications (WAI-ARIA) 1.3w3c.github.io
WAI-ARIA Technology Notesw3.org
About WCAG and WAI-ARIApressbooks.library.torontomu.ca
The Accessibility Tree: How to Read, Test, and Fix Yoursaccessibilitychecker.org
Progressive Web Apps: Going Offlinedevelopers.google.com
CycleTracker: Service workers - Progressive web appsdeveloper.mozilla.org
Offline-First PWAs: Service Worker Caching Strategiesmagicbell.com
Progressive Web Apps (PWAs) : Understand in 3 Minutes - DEV Communitydev.to
Developing a Progressive Web App (PWA) with React, Service Workers, and IndexedDB for Offline Capabilitiestalent500.com
WebGPU vs WebAssemblymetavert.io
WebGPU vs WebASM: Browser Inference Benchmarkssitepoint.com
WebGPUen.wikipedia.org
WebAssembly & WebGPU in Browser-Game Platforms: Pushing the Frontier of Real-Time Graphics - Technology Orgtechnology.org
Build cross-platform desktop apps with JavaScript, HTML, and CSSelectronjs.org
GitHub - electron/electron: :electron: Build cross-platform desktop apps with JavaScript, HTML, and CSS · GitHubgithub.com
Getting Started with Electron: A Guide To Building Desktop Apps - DEV Communitydev.to
Electron App Development: The Complete 2026 Guidecoderio.com
techcrunch.comtechcrunch.com
Forget Apple, the biggest loser in the Google search ruling could be Mozilla and its Firefox web browserfinance.yahoo.com
US v. Google Antitrust Case: Ruling & Remedies Explainedthelawlion.com
Google Antitrust Ruling: Key Takeaways from the District Court's Decision - Publications - National Taxpayers Unionntu.org
Google Dodges Chrome Sale in Final Antitrust Rulingtechbuzz.ai
Federal Court Endorses Behavioral Remedies, Rejects Structural Relief, in Google Search Antitrust Litigation - EveryCRSReport.comeverycrsreport.com
Google's Search Antitrust Remedies Are Now in Effectsigmalawgroup.com
Chrome Browser Choice Screen - Google Chromegoogle.com
Browser choice? Here’s how EU’s DMA is helping make it realblog.mozilla.org
About the browser choice screen in the EUdeveloper.apple.com
The Effect of Choice Screens on Mobile Browser Usage: Evidence from the EU Digital Markets Act by Jesper Akesson, Kush Amlani, Raul Cepeda Suarez, Emily Chissell, Stefan Hunt, Michael Luca, Gemma Petrie :: SSRNpapers.ssrn.com
DOJ and states appeal Google search antitrust remedies rulingsearchengineland.com
Mozilla Extends Lucrative Deal With Google For 3 Yearstechcrunch.com
Google Backs Down: Will Grant Hotseat in EU Browser Choice Screen - Open Web Advocacyopen-web-advocacy.org
assets.publishing.service.gov.ukassets.publishing.service.gov.uk
WEB BROWSER COMPARISON REPORT - Maxthonblog.maxthon.com
DEV Communitydev.to
Google will not be forced to sell off Chrome or Android, judge rules in landmark antitrust rulingcnn.com
Google stock jumps as judge rules it can keep Chrome in antitrust casecnbc.com
[Discussion] Chromium and the browser monoculture problem — DEV Communitydev.to
AI Agents Now Generate More Web Traffic Than Humans. Here's What That Means for Professionals.theaicareerlab.com
AI Crawler & Bot Traffic Statistics 2026: Key Datadigitalapplied.com
State of Agentic Traffic - June 2026: Browser-agent tooling for developers is catching on fast - HUMAN Securityhumansecurity.com
No playbook, just pressure: Publishers eye the rise of agentic browsersdigiday.com
AI agents now make up the majority of web traffic: What developers need to change — WorkOSworkos.com
The browser wars are no longer about search, they're about owning the AI agent gateway — AgentBreaking Blogagentbreaking.com
Is Chrome the New Internet Explorer? How Chromium Dominance Affects Web Standardsdocs.bswen.com