diff --git a/src/content/zh-CN/2020/capabilities.md b/src/content/zh-CN/2020/capabilities.md new file mode 100644 index 00000000000..e7bb6a15f14 --- /dev/null +++ b/src/content/zh-CN/2020/capabilities.md @@ -0,0 +1,332 @@ +--- +part_number: II +chapter_number: 13 +title: 能力 +description: 2020年 Web Almanac网络年鉴中的能力篇，涵盖了全新的、强大的网络平台API。 +authors: [christianliebel] +reviewers: [tomayac] +analysts: [tomayac] +translators: [chengxicn] +discuss: 2049 +results: https://docs.google.com/spreadsheets/d/1N6j1qKv7vc51p1W9z_RrbJX9Se3Pmb-Uersfz4gWqqs/ +queries: 13_Capabilities +christianliebel_bio: Christian Liebel 是Thinktecture, 的顾问，支持来自不同业务领域的客户实现一流的网络应用。他是微软开发者技术的MVP，也是 Web/能力 和 Angular的 Google GDE，并且参加了W3C Web应用工作组。 +featured_quote: 2020年的Web能力（Capability）状态是健康的，因为新的、强大的API定期与基于Chromium的浏览器的新版本一起发布。一些API已经进入了其他非Chromium的浏览器。 +featured_stat_1: 0.0006% +featured_stat_label_1: (Chrome) 使用异步剪贴板API加载页面 +featured_stat_2: 0.49% +featured_stat_label_2: 使用存储管理API的网站 +featured_stat_3: 363 +featured_stat_label_3: 网站允许安装相关应用程序 +--- + +## 介绍 + +[渐进式Web应用](./pwa) (PWA)是一种基于网络技术的跨平台应用模型。在 Service Workers的帮助下，这些应用即使在用户离线时也可以运行。[Web应用程序清单](https://developer.mozilla.org/zh-CN/docs/Web/Manifest) 允许用户将PWA添加到主屏幕或程序列表中。当从那里打开时，PWA将作为原生应用Native App出现。然而，PWA只能使用通过Web平台API暴露的功能和能力，而无法调用任意的本地接口，这使得Native App和Web App之间留下了一个缺隙。 + +[能力项目](https://www.chromium.org/teams/web-capabilities-fugu)，非正式的被称为Project Fugu，是谷歌、微软和英特尔通过跨公司的努力来弥补web和原生之间差距的工程项目。这对于保持web作为一个平台的相关性非常重要。为此，Chromium的贡献者们实现了新的API，将操作系统的能力（capability）暴露给网络，同时维护用户的安全、隐私和信任。这能力包括但不局限于: + +- [文件系统访问 API](https://web.dev/file-system-access/) 用于访问本地文件系统的文件 +- [文件Handling API](https://web.dev/file-handling/) 为特定的文件扩展注册一个 handler +- [异步剪贴板 API](https://web.dev/async-clipboard/) 访问用户剪贴板 +- [Web共享 API](https://web.dev/web-share/) 和其他应用共享文件 +- [联系人 API](https://web.dev/contact-picker/) 从用户地址簿访问联系人 +- [形状检测 API](https://web.dev/shape-detection/) 用于高效检测图像中的人脸或条形码 +- [Web NFC](https://web.dev/nfc/), [Web 串口](https://web.dev/serial/), [Web USB](https://web.dev/usb/), [Web 蓝牙](https://web.dev/bluetooth/)，以及其他 API (完整列表请参考 [Fugu API Tracker](https://goo.gle/fugu-api-tracker)) + +任何人都可以通过[在Chromium bug追踪器中创建一个票据](https://bit.ly/new-fugu-request)来提出一个新的能力。Chromium的贡献者会对这些建议进行审查，并通过相应的标准机构与其他开发者和浏览器厂商讨论所有的API。同时，Fugu团队在Chromium中实现API，在Chromium中，它最初是在一个标记后面实现的。后期，API会通过[原点试用](https://web.dev/origin-trials/)(origin trial)向有限的受众开放。在这个阶段，开发者可以注册一个令牌，在特定的原点上测试API。如果这个API被证明足够强健，API就会在Chromium中发布，如果其他浏览器厂商也决定这样做，也会在其他浏览器中发布。[能力状态](https://web.dev/fugu-status/)网站显示了不同的能力API在这个进程中的位置。 + +能力项目的代号 "Project Fugu "是以日本的一道菜命名的：如果正确的加工食材，那么河豚的肉是一种特别的味蕾体验。然而如果食材加工不当，则可能是致命的。Fugu项目强大的API对于开发者来说是非常令人兴奋的。但是，它们可能会影响到用户的安全和隐私。因此Fugu团队特别关注这些问题。例如，新的接口要求网站通过安全连接（HTTPS）发送。其中一些功能需要用户的动作，如点击或按键，以防止欺诈。别的功能则需要用户的明确许可。开发者可以用一种渐进式的功能扩展来使用所有的API：通过对API的特性检测，应用程序在缺乏对这些能力支持的浏览器中不会崩溃。在支持这些功能的浏览器中，用户可以获得更佳的体验。这样一来，Web应用就会根据用户的特定浏览器[渐进式增强](https://web.dev/progressively-enhance-your-pwa/)。 + +本章根据HTTP Archive和[Chrome平台状态](https://chromestatus.com/metrics/feature/timeline/popularity)的使用数据，综述了各种现代Web API，还有2020年Web能力的状态。由于一些接口是全新的，它们的（相对）使用率非常低。因此，与大多数章节不同，HTTP Archive的使用量统计将以页面的绝对数量而非相对百分比的形式呈现。由于[技术限制](./methodology#metrics)，HTTP Archive只有那些既不需要权限，也不需要用户动作的API的数据。在没有数据的情况下，将根据Chrome平台状态显示Google Chrome浏览器中的页面加载百分比。即使有些数字太小，统计数据不一定有意义，但在很多情况下仍然可以从数据中读出趋势。另外，这些统计数据还可以作为本章未来年度版本的基线，来回顾这些API的成熟度和改进采用情况。除非另有说明，否则这些API只适用于基于Chromium的浏览器，其规范还处于标准化的早期阶段。 + +## 异步剪贴板API + +在`document.execCommand()`方法的帮助下，网站已经可以访问用户的剪贴板。但是这种方法受到了一定的限制，因为API是同步的（使得处理剪贴板条目很困难），而且它只能与DOM中选定的文本交互。这就是[异步剪贴板API](https://webkit.org/blog/10855/async-clipboard-api/)([W3C工作草案](https://www.w3.org/TR/clipboard-apis/#async-clipboard-api))的作用。这个新的API是异步的，这意味着它不会因为大块数据而阻塞页面或等待授予权限，同时它还允许在支持的浏览器（如Chrome、Edge和Safari）中从剪贴板复制或粘贴图片。 + +### 读访问 + +异步剪贴板API提供了两种从剪贴板读取内容的方法：一种是针对纯文本的速记方法，称为`navigator.clipboard.readText()`，另一种是针对任意数据的方法，称为`navigator.clipboard.read()`。目前，大多数浏览器只支持HTML内容和PNG图片作为附加数据格式。由于剪贴板可能包含敏感数据，从剪贴板读取数据需要得到用户的同意。 + +{{ figure_markup( + image="async_clipboard_api.png", + alt="使用异步剪贴板 API的Chrome浏览器的页面加载百分比", + caption='在Chrome中使用异步剪贴板 API的页面加载百分比。
(来源: 异步剪贴板读, 异步剪贴板写)', + description="异步剪贴板 API使用情况图，基于Chrome浏览器中使用该功能的页面加载百分比。它比较了读和写方法的使用情况，显示在2020年期间，写的使用量呈指数级增长，而读的使用量则呈线性增长。在2020年10月，在Chrome浏览器所有页面加载过程中，0.0003%的页面加载过程中调用了读，0.0006%的页面加载过程中调用了写。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vTxqot9ALgxcgOVJntkzIKnkpo3idIPy-tL0t_nzC5BwFuq0ThgK5OXOYVVOpama4vB2EyggX813d33/pubchart?oid=1740212588&format=interactive", + sheets_gid="2077755325" + ) +}} + +由于异步剪贴板API比较新，所以目前的使用率相当低。2020年3月，Safari在版本13.1中增加了对异步剪贴板API的支持。在2020年间，`read()`API的使用率越来越高。在2020年10月的谷歌Chrome浏览器中，0.0003%的页面加载过程中调用了该API。 + +### 写访问 + +除了读取操作外，异步剪贴板API还提供了两种向剪贴板写入内容的方法。同样，有一个针对纯文本的速记方法，叫做`navigator.clipboard.writeText()`，还有一个针对任意数据的方法，叫做`navigator.clipboard.write()`。在基于Chromium的浏览器中，当标签页处于活动状态时，向剪贴板写入内容不需要权限。但是，当网站处于后台时，试图向剪贴板写入数据则需要权限。由于这种方法需要先有用户的动作和权限，所以不在HTTP Archive指标的范围内。与`read()`方法相比，`write()`方法的使用量呈指数级增长，在2020年10月占了所有页面加载过程的0.0006%。 + +[原始剪贴板访问API](https://bugs.chromium.org/p/chromium/issues/detail?id=897289)是Fugu的另一个能力，它甚至可以通过允许从剪贴板复制或粘贴任意数据来进一步增强异步剪贴板API。 + +## 存储管理(StorageManager)API {存储管理storagemanagerapi} + +Web浏览器允许用户以不同的方式在用户系统上存储数据，如Cookie、索引数据库(IndexedDB)、Service Worker的缓存存储或Web存储(本地存储、会话存储)。在现代的浏览器中，取决于浏览器，开发者可以轻松[存储数百兆甚至更多](https://web.dev/storage-for-the-web/)。当浏览器的空间耗尽时，可以清除数据，直到系统不再超过限制（可能导致数据丢失）。 + +归功于[存储管理API](https://developer.mozilla.org/en-US/docs/Web/API/StorageManager)，它是[WHATWG 存储动态标准](https://storage.spec.whatwg.org/#storagemanager)的一部分，使得浏览器在这方面的表现不再像一个黑盒子了。这个API允许开发者估计剩余的可用空间，并选择加入[持久性存储](https://web.dev/persistent-storage/)，这意味着当磁盘空间不足时，浏览器不会清除网站的数据。因此，该API在`navigator` 对象上引入了一个新的`StorageManager`接口，目前在Chrome、Edge和Firefox上都支持。 + +### 预估可用存储 + +开发者可以通过调用`navigator.storage.repair()`来估计可用的存储空间。该方法返回一个承诺(promise)，解析为一个具有两个属性的对象：`usage`显示应用程序使用的字节数，`quota`包含可用的最大字节数。 + +{{ figure_markup( + image="storage_manager_api_estimate.png", + alt="使用存储管理 API的预估方法的页数。", + caption="使用存储管理 API的预估方法的页数。", + description="根据HTTPArchive监控的页面数量，存储管理 API的预估方法的使用情况图。它比较了移动设备和桌面设备上的使用情况。它显示了桌面上的线性增长，而它同时显示了移动设备的爆炸性增长。在10月份，大约有34000个移动网站和27000个桌面网站利用它。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vTxqot9ALgxcgOVJntkzIKnkpo3idIPy-tL0t_nzC5BwFuq0ThgK5OXOYVVOpama4vB2EyggX813d33/pubchart?oid=1853644024&format=interactive", + sheets_gid="1811313356", + sql_file="durable_storage_estimate_usage.sql" + ) +}} + +Chrome浏览器从2016年开始支持存储管理API，Firefox以及基于Chromium的新Edge浏览器是从2017年开始支持的。HTTP Archive数据显示，27,056个桌面页面（0.49%）和34,042个移动页面（0.48%）使用了该API。在2020年之间，存储管理器API的使用量不断增长。这也使得该接口成为本章中最常用的API。 + +### 选择加入持久存储 + +Web存储有两类。"尽力"和 "持久"，第一种是默认的。当设备的存储空间不足时，浏览器会自动尝试释放出尽力存储空间。例如，基于Firefox和Chromium的浏览器会从最近使用最少的源回收存储。然而，这带来了丢失关键数据的风险。为了防止回收，开发者可以选择持久存储。在这种情况下，即使空间不足浏览器也不会清除存储。用户仍然可以选择手动清理存储。要选择持久存储，开发者需要调用`navigator.storage.persist()`方法。根据浏览器和网站的参与情况，可能会出现权限提示，或者自动接受和拒绝请求。 + +{{ figure_markup( + image="storage_manager_api_persist.png", + alt="使用存储管理 API的持久方法的页面数。", + caption="使用存储管理 API的持久方法的页面数。", + description="根据HTTPArchive监控的页面数量，存储管理 API的持久化方法的使用情况图。它比较了移动设备和桌面设备上的使用情况。在桌面页面上，使用量几乎是稳定的，而在移动设备上则有更多的波动。在2020年10月，有25个桌面页面和176个移动页面利用该API。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vTxqot9ALgxcgOVJntkzIKnkpo3idIPy-tL0t_nzC5BwFuq0ThgK5OXOYVVOpama4vB2EyggX813d33/pubchart?oid=644836316&format=interactive", + sheets_gid="1095648844", + sql_file="durable_storage_persist_usage.sql" + ) +}} + +`persist()`API的调用频率低于`estimate()`方法。只有176个移动网页使用了这一API，桌面站点只有25个。桌面上的使用量保持于低位，同时在移动设备上也没有明显的趋势。 + +## 新的通知API + +在推送和通知API的帮助下，Web应用早已能够接收推送消息和显示通知横幅。不过，还有一些部分缺失。到目前为止，推送消息必须通过服务器发送；它们不能被安排离线。此外，安装到系统中的Web应用也不能在其图标上显示角标。角标和通知触发器API可以实现这两种情况。 + +### 角标（Badging）API {角标-badging-api} + +在一些平台上，会较常见到应用程序在图标上显示一个角标来表明打开操作的量。例如，角标可以显示未读邮件、通知或待办事项的数量。[角标API](https://web.dev/badging-api/) ([W3C非官方草案](https://w3c.github.io/badging/))允许已安装的Web应用程序在其图标上显示这样的角标。通过调用`navigator.setAppBadge()`，开发者可以设置角标。这个方法需要一个数字来显示在应用程序的角标上。然后浏览器负责在用户的设备上显示最接近的表示。如果没有指定数字，则会显示一个通用的角标（例如，macOS上的一个白点）。调用`navigator.clearAppBadge()`会再次移除角标。角标API是电子邮件客户端、社交媒体应用或消息工具的绝佳选择。Twitter PWA利用角标API在应用程序的角标上显示未读通知的数量。 + +{{ figure_markup( + image="badging_api.png", + alt="使用角标 API的Chrome浏览器的页面加载百分比", + caption='在Chrome浏览器中使用角标 API的页面加载百分比。
(来源: 角标设置, 角标清除)', + description="角标 API 使用情况的图表，基于 Chrome 浏览器中使用该功能的页面加载百分比。它比较了设置方法和清除方法。随着时间的推移，两种方法的使用量都在增长，一般来说，设置方法的调用频率更高。在2020年10月，这两种方法都会有一个突飞猛进的增长，最高峰时，设置方法占页面加载的0.025%，清除方法占页面加载的0.016%。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vTxqot9ALgxcgOVJntkzIKnkpo3idIPy-tL0t_nzC5BwFuq0ThgK5OXOYVVOpama4vB2EyggX813d33/pubchart?oid=1145004925&format=interactive", + sheets_gid="1154751352" + ) +}} + +2020年4月，谷歌Chrome版本81支持了新的角标API，随后微软Edge版本84在7月支持。在Chrome支持了这个API后，使用量直线上升。2020年10月，在谷歌浏览器中0.025%的页面加载中，`setAppBadge()`方法被调用。`clearAppBadge()`方法被调用的次数较少，在大约0.016%的页面加载中被调用。 + +### 通知触发器API + +推送API需要用户在线接收通知。一些应用程序，如游戏、提醒或待办应用、日历或闹钟，也可以在本地确定通知的目标日期，并做出安排。为了支持这个功能，Chrome团队正在试验一个新的API，名为[通知触发器](https://web.dev/notification-triggers/)([解释](https://github.com/beverloo/notification-triggers/blob/master/README.md)，还没有进入标准轨道)。这个API在`options`映射中添加了一个名为`showTrigger` 的新属性，可以传递给Service Worker注册时的 `showNotification()` 方法。该API的设计是为了在未来允许不同类型的触发器，尽管目前只实现了基于时间的触发器。对于基于某个日期和时间的通知调度，开发者可以创建一个新的`TimestampTrigger`实例，并将目标时间戳传递给它。 + +```js +registration.showNotification('Title', { + body: 'Message', + showTrigger: new TimestampTrigger(timestamp), +}); +``` + +{{ figure_markup( + image="notification_triggers_api.png", + alt="在Chrome浏览器中使用通知触发器API的页面加载百分比", + caption='在Chrome浏览器中使用通知触发器API的页面加载百分比。
(来源: 通知触发器)', + description="通知触发器API使用情况的图表，基于使用该功能的Chrome浏览器中页面加载的百分比。它显示了2020年3月的峰值，约占页面加载的0.00003%，在2020年10月下降到零。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vTxqot9ALgxcgOVJntkzIKnkpo3idIPy-tL0t_nzC5BwFuq0ThgK5OXOYVVOpama4vB2EyggX813d33/pubchart?oid=1388597384&format=interactive", + sheets_gid="1740370570" + ) +}} + +从Chrome 80到83版本，Fugu团队首次在初期试用中尝试使用通知触发器，之后由于开发者反馈不足而暂停开发。从2020年10月发布的Chrome 86开始，API再次进入初期试用阶段。这也解释了通知触发API的使用数据，在2020年3月左右的第一次初期试用中的调用达到了峰值，在Chrome浏览器中占0.000032%的页面加载量。 + +## 屏幕唤醒锁定API + +为了节约能源，移动设备会将屏幕背光变暗，最终关闭设备的显示屏，这在大多数情况下是合理的。然而，在某些情况下，用户可能希望应用程序明确地保持显示屏的唤醒，例如，在做饭时阅读菜谱或观看演示时。[屏幕唤醒锁定API](https://developer.mozilla.org/en-US/docs/Web/API/Screen_Wake_Lock_API)([W3C工作草案](https://www.w3.org/TR/screen-wake-lock/))通过提供一种保持屏幕开启的机制来解决这个问题。 + +`navigator.wakeLock.request()`方法创建一个唤醒保持锁。这个方法需要一个`WakeLockType`参数。在未来，唤醒保持API可以提供其他的保持类型，比如关闭屏幕但保持CPU开启。目前，该API只支持屏幕唤醒的保持，所以只有一个可选的参数，默认值为`screen`。该方法返回一个承诺，该承诺解析为一个`WakeLockSentinel`对象。开发者需要存储这个引用，以便以后调用它的`release()`方法，释放屏幕唤醒保持锁。当标签页处于非活动状态，或者用户将窗口最小化时，浏览器会自动释放保持锁。另外，浏览器可能会拒绝请求，拒绝承诺，例如由于电池电量不足的时候。 + +{{ figure_markup( + image="screen_wake_lock_api.png", + alt="使用屏幕唤醒锁定 API的页面数量。", + caption="使用屏幕唤醒锁定 API的页面数量。", + description="屏幕唤醒锁定API使用情况图，基于HTTP Archive监控的页面数量，对比桌面和移动页面。在2020年10月，该API被10个桌面页面和5个移动页面使用。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vTxqot9ALgxcgOVJntkzIKnkpo3idIPy-tL0t_nzC5BwFuq0ThgK5OXOYVVOpama4vB2EyggX813d33/pubchart?oid=718278185&format=interactive", + sheets_gid="1008442251", + sql_file="wake_lock_acquire_screen_lock_usage.sql" + ) +}} + +BettyCrocker.com是美国一家很受欢迎的烹饪网站，在屏幕唤醒锁定 API的帮助下，他们为用户提供了一个防止烹饪时屏幕变黑的选项。在一项[案例研究](https://web.dev/betty-crocker/)中，他们公布了平均会话时长是正常时长的3.1倍，跳出率降低了50%，购买意向指标增加了约300%。因此，界面对网站或应用的成功与否，分别有直接可衡量的影响。2020年7月，屏幕唤醒保持API与谷歌浏览器84一起发布。HTTP Archive 只有4月、5月、8月、9月和10月的数据。Chrome 84发布后，使用量迅速上升。2020年10月，该API在10个桌面和5个移动页面上被采用。 + +## 空闲检测API + +一些应用程序需要确定用户是否在活跃的使用设备，或是否处于闲置状态。例如，聊天应用可能会显示用户不在。有多种因素可以考虑，例如缺乏与屏幕、鼠标或键盘的交互。[空闲检测 API](https://web.dev/idle-detection/)([WICG 社区小组报告草案](https://wicg.github.io/idle-detection/))提供了一个抽象的 API，允许开发者在给定一定阈值的情况下，检查用户是否处于闲置状态或锁屏状态。 + +为此，API在全局`window`对象上提供了一个新的`IdleDetector`接口。在开发者使用这个功能之前，他们必须先调用`IdleDetector.requestPermission()`来请求权限。如果用户授予权限，开发者就可以创建一个新的`IdleDetector`实例。这个对象提供了两个属性。`userState`和`screenState`，包含各自的状态。当用户或屏幕的状态发生变化时，它将引发一个`change`事件。最后，需要通过调用其`start()`方法来启动空闲检测器。该方法需要一个配置对象，有两个参数：一个`阈值`定义用户必须处于空闲状态的时间，单位是毫秒（最小是一分钟），开发者可以选择给`abort`属性传递一个`AbortSignal`，它的作用是在以后中止空闲检测。 + +{{ figure_markup( + image="idle_detection_api.png", + alt="使用空闲检测API的Chrome浏览器的页面加载百分比", + caption='使用空闲检测 API 的 Chrome 浏览器中页面加载的百分比。
(Source: 空闲检测)', + description="空闲检测API使用情况图，基于Chrome中使用该功能的页面加载百分比。只有2020年7月和10月的数据，显示该API的采用率非常低。.", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vTxqot9ALgxcgOVJntkzIKnkpo3idIPy-tL0t_nzC5BwFuq0ThgK5OXOYVVOpama4vB2EyggX813d33/pubchart?oid=963792757&format=interactive", + sheets_gid="1324588405" + ) +}} + +在写这篇文章的时候，空闲检测API正处于初期试用阶段，所以它的API形态在未来可能会发生变化。出于同样的原因，它的使用率非常低，几乎无法衡量。 + +## 周期性后台同步API + +当用户关闭一个Web应用时，它就无法再与其后端服务进行通信。在某些情况下，开发人员可能仍然希望或多或少地定期同步数据，就像本地应用程序一样。例如，新闻应用可能希望在用户醒来之前下载最新的头条新闻。[周期性后台同步API](https://web.dev/periodic-background-sync/)([WICG 社区小组报告草案](https://wicg.github.io/periodic-background-sync/))力图弥合web和原生应用之间的这个差距。 + +### 注册定期同步 + +周期性后台同步 API 依赖于即使在应用关闭时也能运行的 Service Worker。与其他功能一样，这个API首先需要用户的许可。该API实现了一个名为`PeriodicSyncManager`的新接口。如果存在，开发者可以在Service Worker的注册上访问这个接口的实例。要在后台同步数据，应用程序必须先进行注册，在注册时调用`periodicSync.register()`。这个方法需要两个参数：一个是`tag`，这是一个任意的字符串，用于以后再次识别注册；一个是配置对象，需要一个`minInterval`属性。这个属性由开发者定义了所需的最小间隔时间，单位为毫秒。然而，浏览器最终决定它实际调用后台同步的频率。 + +```js +registration.periodicSync.register('articles', { + minInterval: 24 * 60 * 60 * 1000 // one day +}); +``` + +### 定期同步间隔的响应 + +对于间隔的每一个周期，如果设备在线，浏览器会触发服务工作程序的 "periodicsync "事件。然后，服务工作程序脚本可以执行必要的步骤来同步数据。 + +```js +self.addEventListener('periodicsync', (event) => { + if (event.tag === 'articles') { + event.waitUntil(syncStuff()); + } +}); +``` + +在撰写本文时，只有基于Chromium的浏览器实现了这个API。在这些浏览器上，必须先安装应用程序（即添加到主屏幕上），然后才能使用该API。网站的[网站参与度评分](https://www.chromium.org/developers/design-documents/site-engagement)定义了是否可以调用周期性同步事件以及调用的频率。在目前保守的实现中，网站每天可以同步一次内容。 + +{{ figure_markup( + image="periodic_background_sync_api.png", + alt="使用周期性后台同步 API的页面数量。", + caption="使用周期性后台同步 API的页面数量。", + description="基于HTTPArchive监控的页面数量的周期性后台同步 API使用情况图。它比较了移动和桌面设备上的使用情况。自2020年4月以来，该API被一到两个桌面和移动页面使用。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vTxqot9ALgxcgOVJntkzIKnkpo3idIPy-tL0t_nzC5BwFuq0ThgK5OXOYVVOpama4vB2EyggX813d33/pubchart?oid=1444904371&format=interactive", + sheets_gid="386193538", + sql_file="periodic_background_sync_usage.sql" + ) +}} + +目前，该接口的使用率非常低。在2020年，HTTP Archive监测到的网页中只有一两个页面使用了这个API。 + +## 同原生应用商店集成 + +PWA是一种多功能的应用模式。然而，在某些情况下，提供一个单独的原生应用可能仍然是有意义的：例如，如果应用需要使用网络上无法使用，或者基于应用开发团队的编程经验的功能。当用户已经安装了一个原生应用时，应用可能不希望发送两次通知或推广安装相应的PWA。 + +为了检测用户在系统中是否已经有相关的原生应用或PWA，开发者可以在`navigator`对象上使用[getInstalledRelatedApps()方法](https://web.dev/get-installed-related-apps/)([WICG社区组报告草案](https://wicg.github.io/get-installed-related-apps/spec/))。该方法目前由基于Chromium的浏览器提供，适用于Android和通用Windows平台（UWP）应用。开发者需要调整本地应用捆绑以引用网站，并将本地应用的信息添加到PWA的Web应用清单中。调用`getInstalledRelatedApps()`方法将返回用户设备上安装的应用列表。 + +```js +const relatedApps = await navigator.getInstalledRelatedApps(); +relatedApps.forEach((app) => { + console.log(app.id, app.platform, app.url); +}); +``` + +{{ figure_markup( + image="get_installed_related_apps.png", + caption="使用 getInstalledRelatedApps() 的页面数量", + description="getInstalledRelatedApps() 使用情况的图表，基于HTTP Archive监控的页面数量。它比较了移动设备和桌面设备上的使用情况。它显示了移动设备的稳定增长，在2020年10月达到顶峰，为363页，而桌面页面为44页。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vTxqot9ALgxcgOVJntkzIKnkpo3idIPy-tL0t_nzC5BwFuq0ThgK5OXOYVVOpama4vB2EyggX813d33/pubchart?oid=1774881171&format=interactive", + sheets_gid="860146688", + sql_file="get_installed_related_apps_usage.sql" + ) +}} + +在2020年期间，`getInstalledRelatedApps()`API在移动网站上呈现出稳定的增长。10月份，HTTP Archive跟踪的363个移动页面使用了这个API。在桌面页面上，该API的增长速度没有那么快。这也可能是由于Android商店目前提供的应用明显多于微软商店为Windows提供的应用。 + +## 内容索引 API + +Web应用可以使用各种方式离线存储内容，比如Cache Storage，或者IndexedDB。然而，对于用户来说，很难发现哪些内容是离线可用的。[内容索引API](https://web.dev/content-indexing-api/)([WICG编辑草案](https://wicg.github.io/content-index/spec/))可以让开发者更加突出地暴露内容。目前，Android上的Chrome是唯一支持该API的浏览器。该浏览器在下载菜单中显示了 "为您提供的文章 "列表。通过内容索引 API 索引的内容将出现在那里。 + +内容索引 API 通过提供新的`ContentIndex`接口扩展了 Service Worker API。这个接口可以通过Service Worker注册的`index`属性获得。`add()`方法允许开发者向索引中添加内容。每个内容必须有一个ID、一个URL、一个启动URL、标题、描述和一组图标。可以选择将内容分成不同的类别，如文章、主页或视频。`delete()`方法允许再次从索引中删除内容，`getAll()`方法返回所有索引条目的列表。 + +{{ figure_markup( + image="content_indexing_api.png", + alt="在Chrome浏览器中使用内容索引API的页面加载百分比", + caption='在Chrome浏览器中使用内容索引API的页面加载百分比。
(来源: 内容索引)', + description="内容索引 API 使用情况图，基于 Chrome 中使用该功能的页面加载百分比。它显示出一开始的使用率相对较低，直到2020年10月突然增长了十倍，在Chrome浏览器中0.0021%的页面加载中使用。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vTxqot9ALgxcgOVJntkzIKnkpo3idIPy-tL0t_nzC5BwFuq0ThgK5OXOYVVOpama4vB2EyggX813d33/pubchart?oid=258329620&format=interactive", + sheets_gid="626752011" + ) +}} + +内容索引API在2020年7月与Chrome 84一起推出。版本发布后，在Chrome浏览器中约0.0002%的页面加载过程中使用了该API。到2020年10月，这个数字几乎增加了十倍。 + +## 新的传输API + +最后，目前有两种新的传输方式正在进行初期试用。第一种允许开发者使用WebSockets接收高频消息，而第二种则在HTTP和WebSockets之外引入了一个全新的双向通信协议。 + +### WebSockets的背压机制 + +WebSocket API 是网站和服务器之间双向通信的绝佳选择。但是，WebSocket API 不允许背压，因此处理高频消息的应用程序可能会冻结。[WebSocketStream API](https://web.dev/websocketstream/)([解释](https://github.com/ricea/websocketstream-explainer/blob/master/README.md)，尚未进入标准轨道)希望通过用流来扩展WebSocket API，为其带来易于使用的背压支持。开发者不需要使用通常的`WebSocket`构造函数，而是需要创建一个新的`WebSocketStream`接口实例。流的`connection`属性返回一个承诺，该承诺解析为一个可读和可写的流，允许分别获得一个流读取器或写入器。 + +```js +const wss = new WebSocketStream(WSS_URL); +const {readable, writable} = await wss.connection; +const reader = readable.getReader(); +const writer = writable.getWriter(); +``` + +WebSocketStream API透明地解决了背压问题，因为流读取器和写入器只有在安全的情况下才会进行。 + +{{ figure_markup( + image="websocketstreams.png", + alt="使用 WebSocketStreams 的 Chrome 浏览器中的页面加载百分比", + caption='使用 WebSocketStreams 的 Chrome 浏览器中页面加载的百分比。
(来源: WebSocketStream)', + description="WebSocketStreams 使用情况图，基于使用该功能的 Chrome 浏览器中页面加载的百分比。它显示了2020年6月和7月的峰值，其中API在大约0.0008%的页面加载中被使用。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vTxqot9ALgxcgOVJntkzIKnkpo3idIPy-tL0t_nzC5BwFuq0ThgK5OXOYVVOpama4vB2EyggX813d33/pubchart?oid=1714443590&format=interactive", + sheets_gid="691106754" + ) +}} + +WebSocketStream API已经完成了第一次初期试用，现在又回到了实验阶段。这也解释了为什么目前这个API的使用率很低，几乎无法衡量。 + +### 启用QUIC + +[QUIC](https://www.chromium.org/quic) ([IETF Internet-Draft](https://www.ietf.org/archive/id/draft-ietf-quic-transport-31.txt))是一种基于UDP实现的多路复用、基于流的双向传输协议。它是在TCP之上实现的HTTP/WebSocket API的替代品。[QuicTransport API] (https://web.dev/quictransport/)是用于向QUIC服务器发送消息和接收消息的客户端API。开发者可以选择通过数据包不可靠地发送数据，或者通过使用其流API可靠地发送数据。 + +```js +const transport = new QuicTransport(QUIC_URL); +await transport.ready; + +const ws = transport.sendDatagrams(); +const stream = await transport.createSendStream(); +``` + +QuicTransport 是 WebSockets 的有效替代方案，因为它支持 WebSocket API 的用例，并增加了最小延迟比可靠性和消息顺序更加重要的场景的支持。这使得它成为处理高频事件的游戏和应用程序的良好选择。 + +{{ figure_markup( + image="quic_transport.png", + alt="使用QuicTransport的Chrome浏览器的页面加载百分比", + caption='使用QuicTransport的Chrome浏览器的页面加载百分比。
(Source: QuicTransport)', + description="QuicTransport使用情况图表，基于使用该功能的Chrome浏览器中页面加载的百分比。它显示了2020年10月的峰值，其中API在大约0.00089%的页面加载中被使用。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vTxqot9ALgxcgOVJntkzIKnkpo3idIPy-tL0t_nzC5BwFuq0ThgK5OXOYVVOpama4vB2EyggX813d33/pubchart?oid=1571330893&format=interactive", + sheets_gid="708893754" + ) +}} + +该接口的使用率还很低，几乎无法衡量。在2020年10月，它的使用率强势上升，目前在Chrome浏览器中0.00089%的页面加载中存在。 + +## 结论 + +2020年的Web能力（Capability）状态是健康的，因为新的、强大的API定期与基于Chromium的浏览器的新版本一起发布。一些接口，如内容索引API或空闲检测API，有助于为某些Web应用添加最后的润色。其他API，如文件系统访问和异步剪贴板API，允许一个全新的应用类别，即生产力应用，来最终完全转移到Web上。一些API，如异步剪贴板和Web共享API已经进入了其他非Chromium浏览器。Safari甚至是第一个实现Web共享API的移动浏览器。 + +通过[严格的程序](https://developers.google.com/web/updates/capabilities#process)，Fugu团队确保了这些能力的访问是以安全和隐私友好的方式进行的。此外，Fugu团队还积极征求其他浏览器厂商和网络开发者的[反馈](mailto:fugu-dev@chromium.org)。虽然这些新API的使用率大多比较低，但本章介绍的一些API却呈现出指数级甚至爆炸般的增长，例如角标或内容索引API。2021年Web能力的状况将取决于Web开发者自身。笔者鼓励社区构建优秀的Web应用，以向后兼容的方式利用强大的API，帮助把Web建设成为一个更强能力的平台。 diff --git a/src/templates/zh-CN/2020/methodology.html b/src/templates/zh-CN/2020/methodology.html new file mode 100644 index 00000000000..290fe0b4ada --- /dev/null +++ b/src/templates/zh-CN/2020/methodology.html @@ -0,0 +1,476 @@ +{% extends "base/methodology.html" %} + +{% block title %}方法论 | Web Almanac 源于 HTTP Archive{% endblock %} + +{% block description %}描述2020年网络年鉴是如何编写的。所使用的数据集和工具，以及项目的运作方式。{% endblock %} + +{% block twitter_image_alt %}{{ year }} Web Almanac 方法论y{% endblock %} + +{% block index %} + +{% endblock %} + +{% block main_content %} +
+ + + + + + + + + + +

概述

+ +

+ Web Almanac 是一个由 HTTP Archive 组织的项目. HTTP Archive 于2010年由Steve Souders创立，其任务是跟踪web是如何构建的。它按月评估数以百万计的网页，并使它的TB级别的元数据可供BigQuery分析。 +

+ +

+ Web Almanac网络年鉴的使命是成为一个关于网络状态的年度公共知识库。我们的目标是通过让主题专家提供符合实际情况的见解，使HTTP Archive的数据仓库更容易被Web社区使用。 +

+ +

+ 2020年版 Web Almanac 分为四个部分：内容、体验、发布和分发。在每个部分中，有几个章节从不同的角度探讨其总体主题。例如，第二部分在性能、安全和可访问性等章节中探讨了用户体验的不同角度。 +

+
+ +
+

关于数据集

+ +

+ HTTP Archive 数据集每月持续更新新的数据。对于2020年版的Web Almanac，除非本章另有说明，否则所有的指标都来自于2020年8月的抓取。这些结果可以用2020_08_01为前缀在BigQuery公开的查询。 +

+ +

+ Web Almanac中列出的所有指标都可以通过BigQuery上的数据集公开重现。您可以在我们的GitHub 仓库浏览我们的所有章节使用的查询。 +

+ +

+ 请注意，其中一些查询相当大，如果你自己运行可能比较昂贵 ，因为BigQuery是按TB收费。为了帮助控制你的开支，请看 Tim Kadlec的文章 在不破产的情况下来使用BigQuery。 +

+ +

+ 例如，要了解每个桌面和移动页面的JavaScript字节数的中位数，请参阅 01_01b.sql: +

+ +
+ {# To generate this markup temporarily add a ```sql code block to a chapter and generate that chapter and you'll get the HTML #} + 
#standardSQL
+# 01_01b: Distribution of JS bytes by client
+SELECT
+  percentile,
+  _TABLE_SUFFIX AS client,
+  APPROX_QUANTILES(ROUND(bytesJs / 1024, 2), 1000)[OFFSET(percentile * 10)] AS js_kbytes
+FROM
+  `httparchive.summary_pages.2019_07_01_*`,
+  UNNEST([10, 25, 50, 75, 90]) AS percentile
+GROUP BY
+  percentile,
+  client
+ORDER BY
+  percentile,
+  client
+
+ +

+ 每个指标的结果都可以在章节对应的电子表格中公开查看，例如JavaScript 结果。 滚动到每一章的底部，可以看到它们的查询、结果和读者评论的链接。 +

+
+ +
+

网站

+ +

+ 数据集中有 7,546,709 个网站。其中，移动网站 6,347,919 个，桌面网站 5,593,642 个。大多数网站都包括在移动和桌面子集中。 +

+ +

+ HTTP Archive 从 Chrome用户体验报告中获取其网站的URL。Chrome用户体验报告是谷歌的公共数据集，汇集了数百万Chrome用户活跃访问的网站的用户体验。这给了我们一个最新的网站列表，并反映了真实的web使用情况。Chrome用户体验报告数据集包括一个因子系数维度，我们使用它来获取桌面或移动用户访问的所有网站。 +

+ +

+ Web Almanac使用的2020年8月的HTTP Archive爬取，是利用了最新可用的Chrome用户体验报告版本作为它的网站列表。 202006数据集于2020年7月14日发布，收集了Chrome用户在6月份访问的网站。 +

+ +

+ 与 2019 Web Almanac中的网站相比，被分析的网站数量有20-30%的增长。 Paul Calvano 在他的 2020年Web的增长 文章中分析了这一增长。 +

+ +

+ 由于资源限制， HTTP Archive 只能对每个网站测试一个在Chrome UX报告之中的页面。为了兼顾这一点，只包括主页。请注意，这将引入一些偏见的结果，因为一个主页不一定代表整个网站。 +

+ +

+ HTTP Archive 也被认为是一个实验室测试工具，这意味着它从数据中心测试网站，而不是从真实的用户体验收集数据。因此，所有网站主页都是在一个处于登出的空缓存状态进行测试的，这也意味着不能反映出真实用户是如何访问的。 +

+
+ +
+

指标

+ +

+ HTTP Archive 收集了数以千计关于如何构建web的指标。它包括一些基本指标，如每个页面的字节数、页面是否通过HTTPS加载，以及单个请求和响应头。这些指标中的大多数是由WebPageTest提供， 它作为每个网站的测试运行工具。 +

+ +

+ 其他测试工具用于提供关于页面的更高级的指标。 例如， Lighthouse 被用来对页面进行审计，以分析它在可访问性和SEO等方面的质量。下面的 工具 小节将更详细地介绍这些工具。 +

+ +

+ 为了解决实验室数据集的一些固有限制，Web Almanac 还利用了 Chrome UX Report 来度量用户体验，特别是在Web性能方面。 +

+ +

+ 有些指标是完全无法达到的。例如，我们不一定有能力检测用于创建网站的工具。如果一个网站是使用create-react-app构建的，我们可以看出它使用的是React框架，但不一定是使用了特定的构建工具。除非这些工具在网站代码中留下可探测的指纹，否则我们无法测量它们的使用情况。 +

+ +

+ 其他的指标不一定是不可能度量的，但是是具有挑战性的或者不可靠的。例如，web设计的某些方面本质上是可视化的，可能很难量化，比如页面是否有插入式模态对话框。 +

+
+ +
+

工具

+ +

+ Web Almanac 是在以下开源工具的帮助下实现的。 +

+
+ +
+

WebPageTest

+ +

+ WebPageTest 是一个卓越的web性能测试工具，同时是HTTP Archive的骨干。我们使用一个WebPageTest的私有实例 ，携带着私有的测试UA，它是测试每个web页面的实际浏览器。桌面和移动网站在不同的配置下进行测试: +

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
配置桌面移动
设备Linux VM模拟 Moto G4
用户代理UA + Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.105 Safari/537.36 PTST/200805.230825 + + Mozilla/5.0 (Linux; Android 6.0.1; Moto G (4) Build/MPJ24.139-64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.146 Mobile Safari/537.36 PTST/200815.130813 +
位置 + Redwood City, California, USA
+ The Dalles, Oregon, USA + 		+ Redwood City, California, USA
+ The Dalles, Oregon, USA +
连接有线 (5/1 Mbps 28ms RTT)3G (1.600/0.768 Mbps 300ms RTT)
可视区域Viewport1024 x 768px512 x 360px
+
+ +

+ 桌面网站在Linux虚拟机的桌面Chrome环境中运行。网络速度等于有线连接。 +

+ +

+ 移动网站在模拟的Moto G4设备上运行，网络速度相当于3G连接。注意，模拟的移动用户代理标识为Chrome 65，但实际的浏览器是Chrome 84。 +

+ +

+ 测试是从两个位置发起的: 美国加利福尼亚和俄勒冈。HTTP Archive 维护它自己的测试代理硬件，位于加利福尼亚的互联网档案 数据中心。另外的测试代理是根据需要，添加了谷歌云的位于俄勒冈的 us-west-1 。 +

+ +

+ HTTP Archive 的 WebPageTest 私有实例和最新的公有版本保持一致，使用 自定义指标来增强。这些是测试结尾时在每个网站上评估测试的JavaScript片段。感谢众多数据分析师的 贡献 ， 特别是Tony McCreath的艰巨的努力， 2020年版的Web Almanac 网络年鉴极大地扩展了HTTP Archive的测试基础架构的功能，增加了3000多行新代码。 +

+ +

+ 每个测试的结果都被保存为 HAR 文件，这是一个JSON格式的存档文件，包含网页的元数据。 +

+
+ +
+

Lighthouse

+ +

+ Lighthouse 是一个谷歌做的自动化的网站质量保证工具。它审核web页面以确保它们不包含阻碍用户体验的资源，如未优化的图像和不可访问的内容。 +

+ +

+ HTTP Archive 为所有的移动网页运行最新版本的Lighthouse — 因为资源的限制问题并没有包括桌面版本的页面。 在2019年八月的爬取中， HTTP Archive 使用了 6.2.0 版本的Lighthouse。 +

+ +

+ Lighthouse 在 WebPageTest中运行自己独特的测试，它有自己的配置文件: +

+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
配置值
CPU 降速1x/4x
下载吞吐1.6 Mbps
上传吞吐0.768 Mbps
RTT150 ms
+
+ +

+ 如需了解更多关于Lighthouse以及HTTP Archive中可用的审计，请参考 Lighthouse 开发者文档. +

+
+ +
+

Wappalyzer

+ +

+ Wappalyzer 是用于检测web页面使用的技术的工具。 有 64 类技术被用于测试， 从JavaScript框架到CMS平台，甚至加密货币挖掘。支持的技术超过1400种。 +

+ +

+ HTTP Archive 为所有的页面运行最新版本的 Wappalyzer。 截止2020年8月 Web Almanac 使用 6.2.0 version 的Wappalyzer。 +

+ +

+ Wappalyzer为很多章节提供动力，它分析开发人员工具的流行程度，例如 WordPress，Bootstrap，和jQuery。比如 电商 和 CMS 章节非常依赖于Wappalyzer探测出的各自的 电商 和 CMS 类别。 +

+ +

+ 所有的检测工具，包括Wappalyzer都有其局限性。他们的结果的有效性总是取决于他们的检测机制有多准确。Web Almanac网络年鉴将在使用Wappalyzer的每一章中添加注释，但由于特定的原因，其分析可能不准确。 +

+
+ +
+

Chrome用户体验报告

+ +

+ The Chrome用户体验报告 是Chrome真实用户体验的公共数据集。体验是根据网站的来源分类的，例如https://www.example.com。数据集包括用户体验指标的分布，如绘制、加载、交互和布局稳定性。除了按月分组，体验也可以按维度划分，比如国家地理位置、外形因素(桌面、手机、平板电脑)和网络连接类型(4G、3G等)。 +

+ +

+ Web Almanac网络年鉴参考了Chrome UX报告中的真实用户体验数据，使用了2020年7 8月的数据集 (202008)。 +

+ +

+ 关于数据集，你可以在这里了解更多：web.dev上的在BigQuery使用Chrome 用户体验报告 指南。 +

+
+ +
+

第三方资源网络

+ +

+ 第三方资源网络 是一个研究工程，由 Patrick Hulce创立，他是2019 第三方资源 章节的作者，它使用HTTP Archive和Lighthouse数据来识别和分析第三方资源对网络的影响。 +

+ +

+ 如果域名出现在至少50个独立的页面，则会被认为是一个第三方提供者，该项目还将提供商按其各自的服务分类，如广告、分析和社交。 +

+ +

+ Web Almanac网络年鉴中的一些章节使用了来自这个数据集的域名和类别来理解第三方的影响。 +

+
+ +
+

Rework CSS

+ +

+ Rework CSS 是一个基于JavaScript的CSS解析器。它采用整个样式表并生成一个json编码的对象，以区分每个样式规则、选择器、指令和值。 +

+ +

+ 在 CSS 章节，这个特殊用途的工具显著地提高了数据库中许多度量标准的准确性。所有外部样式表中的CSS和每个页面的内联样式块都被解析和查询，让这个分析工作成为可能。阅读这段 来了解更多关于它如何同BigQuery上的HTTP Archive数据集来集成。 +

+
+ +
+

Rework Utils

+ +

+ 今年的CSS 章节是由 Lea Verou 领导的，对 CSS 的状态进行了显著的更加详细的研究，分布在 100+ 个查询。作为对比，这比2019年的查询多了2.5倍。为了使这种规模的分析可行， Lea 开源了 Rework Utils。这些实用程序通过提供有用的脚本来更轻松地提取CSS见解，将Rework的JSON数据提升到了一个新的水平。你在CSS章节中看到的大部分统计数据都是由这些脚本提供的。 +

+
+ +
+

Parsel

+ +

+ Parsel 是一个CSS选择器解析器和特异性计算器， 最初是由 CSS 章节带头人 Lea Verou撰写，并且作为一个独立的库进行开源。它被广泛用于所有与选择器和特异性相关的CSS指标。 +

+
+ +
+

Analytical process

+ +

+ 在一百多位网络社区贡献者 的协调下， Web Almanac花了大约一年的时间来规划和执行。本节介绍了我们为什么要选择Web Almanac的章节，如何查询它们的指标，以及如何诠释它们。 +

+
+ +
+

计划

+ +

+ 2020年网络年鉴于2020年6月启动，由于与COVID-19和社会正义抗议活动有关的动荡，时间晚于2019年的时间表。2020年的这些和其他事件是整个制作过程中的一股暗流，除了像这样一个快节奏的项目的压力之外，也给我们的贡献者带来了很多额外的压力。 +

+ +

+ 正如我们在 去年的方法论指出的那样: +

+ +
+ Web Almanac网络年鉴未来版本的一个明确目标是鼓励更多未被充分代表和异质的声音作为作者和审稿者。 +
+ +

+ 为此，今年我们对寻找和选择作者的方式进行了系统的改革： +

+ + + +

+ 我们希望今后能对这一进程进行改进，以确保 Web Almanac 网络年鉴成为一个更加多样化和更具包容性的项目，供稿人来自各种背景。 +

+ +

+ 最后，在2020年7月，经过一轮轮的头脑风暴和提名，22个章节被固定，我们为每个章节组建了内容团队，负责撰写、审核和分析。 +

+
+ +
+

分析

+ +

+ 在2020的7月和8月, 随着指标和章节的列表稳定下来，数据分析师对指标的可行性进行了筛选。在一些情况下，自定义指标 需要被创建来填补我们分析能力的空白。 +

+ +

+ 2020年8月, HTTP Archive 数据管道爬取了数百万网站，收集到的元数据用于了Web Almanac网络年鉴。 +

+ +

+ 数据分析者开始编写查询来提取每个指标的结果。总计数百个查询是手动编写的! 你可以在这个项目的Github仓库的章节 query repository的目录下浏览所有的查询代码。 +

+
+ +
+

诠释

+ +

+ 作者与分析者一起正确地解释结果并得出适当的结论。当作者撰写他们各自的章节时，他们利用这些统计数据得出支持他们的web状态理论的框架。审稿者与作者一起工作，以确保他们的分析在技术上的正确性。 +

+ +

+ 为了让读者更容易理解结果，web开发人员和分析人员创建了数据可视化嵌入到本章中。为了使结论更容易理解，一些可视化方法被简化了。例如它没有显示一个完整的分布柱状图，而是只显示了少量的百分比。除非另有说明，所有分布都是用百分位数汇总的，特别是中位数(第50的百分位数)，而不是平均值。 +

+ +

+ 最后，编辑修改了章节，以纠正简单的语法错误，确保阅读体验的一致性。 +

+
+ +
+

展望未来

+ +

+ 2020年版的 Web Almanac 是第二个版本，我们希望继续作为网络社区的年度传统，进行反思，并致力于积极变革。我们付出了巨大的努力才走到今日，这多亏了许多有奉献精神的 贡献者 我们希望尽可能多地利用这些工作，使未来的版本更加精简。 +

+ +

+ 如果您对2021年版的Web Almanac网络年鉴有兴趣，请填写 感兴趣表格。让我们一起努力，追踪网络的状态! +

+
+{% endblock main_content %}