MDN 2018 年 3 月变更日志

编者注: 变更日志 是“对项目所做的所有重大更改的日志或记录。[它] 通常包括更改记录,例如错误修复、新功能等。”

发布变更日志是开源的传统,也是网络上长期以来的做法。我们认为 Hacks 的读者以及使用和贡献 MDN Web 文档 的人士会对了解 MDN 工程团队的工作以及他们在特定月份的影响感兴趣。我们还将介绍代码贡献机会、有趣项目以及参与的新方法。

3 月完成

以下是 3 月对支持 MDN Web 文档代码、数据和工具 所做的更改。

以下是 4 月的计划

在 Hack on MDN 活动中改进了兼容性数据

3 月,MDN 团队专注于浏览器兼容性数据项目,在巴黎与数十位合作者会面,参加“Hack on MDN”活动。这项工作带来了 BCD 存储库中的 221 个拉取请求,以及其他存储库中的额外工作。有关在那一周创建的工具和更新的数据的详细信息,请参阅 Jean-Yves Perrier 的 Hack on MDN 文章

我们在 3 月审查并合并了 250 多个 PR。兼容性数据转换从 57% 完成度跃升至 63%。Jeremie Patonnier 领导了转换 SVG 数据的工作 (BCD PR 1371)。API 数据也是重点,包括转换现有的 MDN 表格以及使用其他数据源来填充缺失的 API。

BCD 存储库中现在有 264 个未完成的 PR,大约一个月的量,而且贡献不断涌现。BCD 是今年 Mozilla 拉取请求 (880 个) 和作者 (95 个) 最活跃的 GitHub 存储库之一,仅次于 rust (1268 个 PR,267 个作者)。贡献率不断上升,因此 BCD 可能会在 2018 年第二季度排名第一。

Graph that shows weekly commits to the browser-compat-data project growing from about 25 commits per week to over 60 per week in March.

尝试使用 Brotli 压缩

Brotli 是一种由 Google 开发的压缩算法,专为提供 Web 资源而设计,它可以胜过广泛使用的 gzip 算法。到 2017 年底,所有主要浏览器都支持 br 内容编码方法,Florian 在 错误 1412891 中请求在 MDN 上测试 Brotli。Maton AnthonyPR 4686 中编写了一个与 Python-2 兼容的 Brotli 中间件,默认压缩级别为 11。此中间件于 3 月 7 日上线。

Brotli 确实比 gzip 更有效地压缩了我们的内容。首页从未压缩的 36k 压缩到 gzip 的 9.5k,压缩到 Brotli 的 7k。结果在像 CSS display 页面 这样的维基页面上更好,从未压缩的 144k 压缩到 gzip 的 20k,压缩到 Brotli 的 15k。

然而,Brotli 对 MDN 性能产生了负面影响。由于中间件负载增加,服务器测量的平均响应时间变慢,从 75 毫秒变为 120 毫秒。Google Analytics 显示页面下载时间提高了 6%(快了 1 毫秒),但平均服务器响应时间下降了 23%(慢了 100 毫秒)。我们没有看到静态资产的任何益处,因为 CloudFront 处理 gzip 压缩并忽略 Brotli。

Antony 将压缩级别调整为 5 (Kuma PR 4712),根据 Brotli 状态文章 测试,该压缩级别在压缩时间上与 gzip 9 相当,但仍能生成更小的资产。当此中间件于 3 月 26 日上线时,我们看到了类似的结果,我们的响应时间恢复到使用 Brotli 之前的水平,但在使用 br 时,HTML 大小略有改善。

Graph of average server response time from New Relic, showing a doubling from about 50 ms to 100 ms around March 7, then back to 50 ms after March 21.

当我们在 4 月发布 CloudFront 时,CDN 将负责压缩,Brotli 将再次消失。它看起来是一项很有前景的技术,但需要一个支持它的 CDN,并且最适合使用“预压缩”工作流而不是“按需”中间件工作流,这意味着它在一段时间内不适合 MDN。

发布调整和修复

3 月合并了 370 个 PR

其中 137 个来自首次贡献者

其他重要的 PR

计划于四月

我们将忙于四月,Hack on MDN 活动的成果,审查 PR 并将原型转换为生产代码。我们也将继续致力于其他项目。

准备好 HTML 交互式示例以投入生产

交互式示例正在从快速实验过渡到发布功能。Will Bamberg 在三月发布了 将交互式示例引入 MDN,详细说明了这个项目从想法到实现的过程。

交互式示例团队将加强代码和流程,为贡献者和未来的支持建立更好的基础。同时,他们将确定 HTML 示例的设计,这些示例通常需要混合使用 CSS 和 HTML 来说明用法。

发布 CDN 和 Django 1.11

Ryan Johnson 完成了 60 个左右 MDN 端点的缓存头,他和 Dave Parfitt 在暂存站点前面添加了 CloudFront。我们将花费一些时间进行自动化和手动测试,然后重新配置生产环境,使其也位于 CDN 后面。

我们错过了 Django 1.11 更新的 4 月 1 日截止日期。我们计划专注于 4 月更新所需的最低限度任务,并将其他任务(例如更新过时但兼容的第三方库)推迟到以后。

改善前端开发人员的体验

Schalk Neethling 有时间熟悉 MDN 的前端代码,使用像 Sonarwhal 和 Chrome Devtools 的性能和网络面板来查找 Chrome 访问者访问 MDN 时遇到的性能问题。他整理了一份他认为会改善开发和性能的更改列表。

Analyzing the performance of developer.mozilla.org with Chrome developer tools, showing how long it takes to download assets, run javascript, etc. JS starts running around 1 second, and the page is ready around 3 seconds.

一个快速获胜的方法是将 FontAwesome 的自定义字体面替换为 SVG 图标。不再在一个文件中加载所有图标,而只加载页面使用的图标。SVG 将包含在 HTML 中,避免额外的 HTTP 请求。SVG 图标会自动缩放,因此它们在所有设备上看起来都很好。这也应该改善开发体验。使用 "\f108\0020\eae6" 这样的字符编码很容易出错,而使用 "icon-ie icon-mobile" 这样的名称则清晰得多。

Schalk 正在考虑前端开发的其他挑战,以及如何引入当前的工具和技术。他正在清理代码,使其更一致,并在 MDN Fiori 中正式化规则,这是一个前端风格指南和模式库。这可能是转向 UI 组件结构(如 React)的第一步。

一个更大的改进将是更新前端构建管道。MDN 的构建系统是在多年前(由 Python 开发人员)开发的,当时 JavaScript 还不成熟,系统也没有跟上。Webpack 广泛用于捆绑代码和资产以进行部署,而新的管道可以让开发人员使用更广泛的工具生态系统(如 Babel)来编写现代 JavaScript。

最后,我们继续寻找测试 JavaScript 的正确方法。我们目前使用 Selenium 在浏览器环境中自动执行测试。我们遇到过 问题,无法获得一组稳定的工具来进行一致的 Selenium 测试,并且它已被证明对于 JavaScript 的单元测试来说过于笨重。Schalk 在使用 Jest 方面有很好的经验,并希望在 4 月开始使用 Jest 测试 MDN Javascript。

关于 John Whitlock

John 是一位 Web 开发人员,负责 MDN Web Docs 的引擎。

更多 John Whitlock 的文章…


一条评论

  1. Benny Powers

    听起来很棒。干得好。

    我真的希望你能考虑使用 Web Components 和/或类似 lit-html 的东西,而不是 React。为什么要在 CD 中构建 JSX,当你在浏览器中可以运行标准 JavaScript 呢?使用 polyfilling 和差异化服务来以最小的性能成本支持旧版浏览器。

    你们是英雄,继续努力!

    2018 年 4 月 16 日 上午 07:28

本文的评论已关闭。