浏览器对大网站区别对待

# 浏览器对大网站区别对待 来源：https://denodell.com/blog/browsers-treat-big-sites-differently 有些浏览器内置了代码，会检查你访问的是哪个域名，然后根据域名改变页面的渲染方式。没错，你没看错。如果站点 == *X*，就执行 *Y*。 TikTok 获得了特殊待遇。Netflix 也是。Instagram 也是。SeatGuru 也是。 Safari 和 Firefox 都这样做。Chrome 不这样做。 *这告诉了我们一些有趣的东西。* --- 源代码就在这里（https://github.com/WebKit/WebKit/blob/main/Source/WebCore/page/Quirks.cpp），就在这里（https://searchfox.org/firefox-main/source/browser/extensions/webcompat/data/interventions），如果你想看的话。这些都是硬编码在浏览器渲染引擎里的域名检查，它们会说：“如果用户在这个域名上，就用不同的方式渲染”或者“如果他们在那个域名上，就用不同的方式处理那个 API 调用”。这不是一个 bug。这是一个功能，并且它被推送到了数十亿台设备上。 --- ## Firefox 的 about:compat 如果你打开 Firefox，在地址栏输入 `about:compat`（https://www.ghacks.net/2019/02/28/firefoxs-new-web-compatibility-page/），你会看到一个列表，里面是针对特定网站的兼容性干预措施，每个都配有开关。每一个都是针对特定网站的有针对性的修复，你可以将它们关闭，然后看着网站出问题。 Firefox 的 about:compat 页面截图，显示针对特定网站的兼容性干预措施。 Firefox 的 WebCompat 系统（https://github.com/mozilla-firefox/firefox/tree/main/browser/extensions/webcompat）会向特定域名注入自定义 CSS 和 JavaScript，为那些错误嗅探浏览器的网站修改用户代理字符串，并用补丁掩盖那些本会让网页感觉破碎的 bug。这些干预措施在 Mozilla 的 Bugzilla 中都有记录，附带有 bug 报告，有时还有针对相关网站但未成功的联系尝试。 --- ## Safari 的“怪癖”（quirks） Safari 的 WebKit 引擎将其称为“怪癖”，而文件 `Quirks.cpp`（https://github.com/WebKit/WebKit/blob/main/Source/WebCore/page/Quirks.cpp）在 GitHub 上是公开可用的。阅读它就像是上了一堂关于网络实际运作方式的课。 以下是代码中的一条注释： > `Facebook、X (twitter) 和 Reddit 会天真地暂停一个已经滚动出视口的 \<video\> 元素，无论该元素当前是否处于画中画模式。` 因此，浏览器会检测你是否在 facebook.com、x.com 或 reddit.com 上，并改变它处理画中画视频的方式。这些公司写了有问题的视频代码，而浏览器不是等它们修复，而是直接向每个用户推送了变通方案。 另一条注释： > `FIXME：如果 SeatGuru 决定调整他们的网站，就移除这个怪癖。` 有人为 SeatGuru 添加了特定于域名的渲染代码，注释暗示曾尝试联系他们。SeatGuru 没有修复他们的网站，所以浏览器替他们修复了。 提交历史（https://github.com/WebKit/WebKit/commits/main/Source/WebCore/page/Quirks.cpp）读起来很有趣。仅在过去几个月里： - Zillow 的户型图图片没有居中 - TikTok 显示“请升级您的浏览器”的信息 - Instagram Reels 在播放时大小不规则地变化 - Netflix 的“剧集和信息”按钮错误地关闭了弹出框 - Twitch 在切换标签页时暂停了画中画视频 - Amazon Prime Video 根本不让 Safari 用户观看 每一个都获得了针对特定域名的修复，并推送给了所有用户。 --- ## Chrome 与众不同 这些怪癖文件不仅仅是修复有问题的网站；它们往往还在补偿 Chrome 对“正常工作”的定义权。模式如下：Chrome 推出一个功能，开发者使用它（因为 Chrome 主导市场），其他浏览器则匆忙实现该功能或添加特定于网站的怪癖来掩盖差异。等 Safari 或 Firefox 跟上时，怪癖已经推送给了数百万用户。 WebKit 的源代码包含了用户代理覆盖，使 Safari 在访问特定网站（如 Amazon 的视频页面和各种流媒体服务）时假装成 Chrome。这些网站会嗅探 Chrome，并为其他浏览器提供降级体验，因此 WebKit 干脆就撒谎说自己是什么浏览器，而不是让 Safari 用户遭受糟糕体验。 来自当前 Quirks.cpp 源代码： ```cpp auto chromeUserAgent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36"_s; ``` Safari 居然内置了一个伪造的 Chrome 用户代理字符串，随时可以在网站拒绝工作时部署。Firefox 也做同样的事情，它的许多 `about:compat` 干预措施就是用户代理欺骗，告诉网站“是的，我是 Chrome”，因为这些网站会主动阻止非 Chrome 浏览器或在其上出现问题。 Mozilla 维基（https://wiki.mozilla.org/Compatibility/UA_Override_&_Interventions_Testing）解释说，一些网站“完全阻止访问、显示不同的设计或提供不同的功能”，取决于浏览器检测结果。所以 Firefox 推出了变通方案。 这就形成了一个反馈循环。开发者为了 Chrome 进行开发，因为 Chrome 占主导地位。他们的网站在 Chrome 中表现最好。在其他地方遇到 bug 的用户会责怪浏览器而不是网站，于是他们切换到 Chrome，从而加强了 Chrome 的主导地位。 --- ## 问题很深 这些不仅仅是外观上的调整。浏览器会根据你的域名改变基本行为，包括滚动行为、触摸事件处理、视口计算和图片 MIME 类型处理。单是 WebKit 中的列表就长达数千行。 以下是关于模拟鼠标事件的一个例子： > `当在 Amazon 产品图片上平移时，我们要么触摸 #magnifierLens 元素，要么触摸它的前一个兄弟元素。` 浏览器会检查你是否在 Amazon 上，并改变触摸事件到鼠标事件的转换方式，以适配他们的产品缩放功能。Amazon 的网站假设了某些 Safari 默认不提供的事件行为，于是 Safari 就提供了，但仅限 Amazon。 还有针对存储访问、滚动条渲染、自动更正行为和缩放处理的怪癖。每一个都带有域名检查，每一个都被编译到浏览器可执行文件中。 --- ## Chrome 不需要怪癖文件 你可能注意到了。我向你展示了 Firefox 的 `about:compat` 和 WebKit 的 `Quirks.cpp`，但 Chrome 的等效物在哪里？Chrome 实际上并不需要它，这不一定是说 Chrome 的工程更好。网络本来就是为 Chrome 构建的。 当超过 80% 的用户使用基于 Chromium 的浏览器（https://techjury.net/industry-analysis/chrome-browser-market-share/）时，开发者会首先为 Chrome 构建。如果一个网站在 Chrome 中能工作，它就会发布。如果它在 Safari 或 Firefox 中出问题，开发者会在有意或无意中认为那不那么重要。 Chrome 不会添加怪癖；它制定议程。当 Chrome 改变某些东西的工作方式时，网站会进行更新以适应，其他浏览器要么跟进要么出问题。这就是贯穿现代网络的不对称性。 当一个网站在 Safari 中出问题时，WebKit 工程师会添加一个怪癖。当 Chrome 想要改变网络的运作方式时，Chrome 直接改变，其他所有人只能适应。Chrome 不需要怪癖，因为 Chrome 对 Web 标准的解释是其他所有人努力去匹配的版本。 这不是恶意为之，也不完全是 Google 的错；这实际上是市场主导地位的自然结果。浏览器工程师会告诉你，现在的规范本身其实定义得很好了。HTML5 的“活标准”方法通过使规范符合现实，解决了 IE/Netscape 时代的混乱。问题在于开发者依赖未指定的实现细节，然后当这些细节不同时又指责不合规的浏览器。 尽管这可能是真的，但结果并没有改变。当 Chrome 是每个人都针对的实现时，Chrome 未指定的细节就成了事实上的规范。 2000 年代 Internet Explorer 也发生过同样的事情。当开发者为了 IE 构建时，网站在别处出问题，符合标准变成次要的，只要“在 IE 中能工作”就行。我们花了多年时间才从那堆混乱中爬出来。 十年前，人们希望随着网络越来越符合标准，浏览器怪癖最终会消失。你可以说它们确实消失了，但不是因为任何人预期的原因：怪癖并没有消失，它们只是转移到了 Chrome 以外的浏览器中。 --- ## 修复比等待更容易 你可能会奇怪为什么浏览器厂商不直接联系有问题的网站并要求他们修复代码。有时他们确实会这样做，在源代码注释中甚至有一个字段链接到联系尝试，但考虑一下其中的经济学。 浏览器厂商的工作是让网络为用户正常工作，如果一个流行网站在他们的主要浏览器中出问题，而在 Chrome 中正常，用户会责怪浏览器。向第三方提交一个 bug，然后等待数周或数月才能得到可能永远不会到来的修复，这远不如明天就推送一个五行代码的变通方案。 还有一个问题：你究竟该联系谁？写问题代码的开发者可能几年前就离开了公司，拥有那个端点的团队可能不知道这是他们的责任，网站可能处于维护模式，只接收安全补丁而不做其他改动。 从浏览器的角度来看，选择很简单：现在悄悄修复它，省去所有人的麻烦。 一位 WebKit 工程师写了一篇博客文章（https://www.otsukare.info/2023/01/16/webkit-quirks），讲述移除一个针对 FlightAware 的怪癖的过程。该网站比较 CSS transform 矩阵字符串，但 CSS 规范改变了浏览器序列化这些值的方式，浏览器变得符合规范后 FlightAware 出问题了，于是工程师添加了特定域名的代码来修复它。最终联系成功了，FlightAware 修复了他们的代码，怪癖被移除。但在此之前的好几个月里，Safari 用户之所以能有正常体验，完全是因为有人在浏览器中写了一条检查 `flightaware.com` 的 `if` 语句。 --- ## 自查一下 你的网站可能正在获得特殊的渲染处理，而你可能并没有意识到。你受益的那个怪癖不会出现在你的错误日志中，也没有控制台警告说“这个浏览器正在为你弥补错误”。这个修复在设计上就是不可见的。 如果你主要在 Chrome 中测试，你尤其容易暴露。你的网站之所以完美工作，可能不是因为你写了好的代码，而是因为 Chrome 的行为符合你的假设。其他浏览器将不得不选择：要么让你的网站在他们的用户面前崩溃，要么把你加入他们的怪癖文件。 请打开你的网站，在 Firefox 和 Safari 中测试。不是偶尔，不是在大版本发布前，而是*定期*。怪癖文件之所以存在，就是因为开发者没有这么做。 如果你发现你的域名出现在其中一个文件中，考虑审计一下他们绕过的是什么东西。不是因为你必须这么做（毕竟，没有你的干预，网络也还在工作），而是因为在一个你不使用的浏览器里，某位工程师解决了一个你都不知道自己有的问题。 --- ## 我们想要的网络 vs. 我们拥有的网络 规范是地图，但怪癖列表是崎岖的地形。标准本应消除浏览器特有的代码。我们爬出了 IE 时代，庆祝了一番，然后围绕另一个浏览器又挖了同样一个坑。只不过现在浏览器特有的代码存在于非主导地位的浏览器中，修补着一个为占主导地位的浏览器而构建的网络。 我参与过的网站也在这个文件中。你的可能也在。 *而且列表越来越长。* --- 分享这篇文章： [Y Combinator](https://news.ycombinator.com/submitlink?u=https%3A%2F%2Fdenodell.com%2Fblog%2Fbrowsers-treat-big-sites-differently&t=Browsers%20Treat%20Big%20Sites%20Differently) [X](https://x.com/intent/tweet?url=https%3A%2F%2Fdenodell.com%2Fblog%2Fbrowsers-treat-big-sites-differently%3Futm_source%3Dtwitter%26utm_medium%3Dshare_button%26utm_campaign%3Dbrowser_quirks_post) [Mastodon](https://mastodon.social/share?text=https%3A%2F%2Fdenodell.com%2Fblog%2Fbrowsers-treat-big-sites-differently%3Futm_source%3Dmastodon%26utm_medium%3Dshare_button%26utm_campaign%3Dbrowser_quirks_post) [Bluesky](https://bsky.app/intent/compose?text=https%3A%2F%2Fdenodell.com%2Fblog%2Fbrowsers-treat-big-sites-differently%3Futm_source%3Dmastodon%26utm_medium%3Dshare_button%26utm_campaign%3Dbrowser_quirks_post) [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fdenodell.com%2Fblog%2Fbrowsers-treat-big-sites-differently%3Futm_source%3Dlinkedin%26utm_medium%3Dshare_button%26utm_campaign%3Dbrowser_quirks_post) [回到顶部](https://denodell.com/blog/browsers-treat-big-sites-differently#)