摘要
SVGOMG：适用于 SVGO 的精美 Material 响应式前端。
我们喜欢什么？
SVGOMG 由我们自己的 Jake Archibald 构建，是使用 Web 技术编写的完全响应且功能齐全的工具，堪称完美的例子。它拥有精美的 Material Design 外观，ServiceWorker 确保应用快速加载、可离线使用，且过渡在移动设备上很流畅。
可能的改进
我们必须要提供的唯一一个真正的棘手问题是，由于缺少主界面，初始用户体验令人感到困惑。除此之外，干得不错！
Jake Archibald 访谈
为何要浏览网页？
懒散。完全懒散。我不是 Windows 原生应用的开发专家，也不擅长 OSX 原生应用，也不擅长为 iOS、Android、Windows Phone 或 Linux 创建原生应用。不过，我可以在 Web 上执行这些操作，而且只需掌握这套技能，就能构建一款能够在所有这些平台上正常运行的应用。
在开发过程中，哪些方面做得好？
我对它的表现非常满意。我要确保网页先呈现再加载 JavaScript 可用。事实上，在首次渲染时，只需 5k HTML 并加上一些内嵌的 CSS 和 SVG。主要脚本和 CSS 均在后台加载。这意味着即使使用 3G 网络，在缓存为空的情况下，网站也要在 1.5 秒内完成加载，并且其中大部分是 DNS 和 SSL。
打开初始屏幕非常简单，因此以 5K 画质呈现并不具有挑战性。许多网站会等待 JS 进行首次渲染，有些网站甚至要求 JS 在渲染之前发出进一步的请求，这让我非常困扰。这会将 3G 渲染时间推到 10 秒。我知道，作为一名移动用户，我不会忍受这个过程。
主 JS 为 15k，但不包含解析和缩小 SVG（作为后台额外阶段加载）的部分。这非常棒，因为互动功能可以非常快速地启动，而且用户没有注意到额外的加载环节。如果用户设法在该脚本可用之前选择了 SVG，该脚本的加载似乎是处理时间的一部分。
我还使用了 ServiceWorker 让整个项目离线工作。离线工作是一项非常酷的功能，但我主要是为了提高性能。用户对 SVGOMG 的后续访问几乎会立即呈现，无论用户使用何种连接。鉴于移动网络的网络连接状况各不相同，这非常有价值！
如果您可以使用任何 API 来改进您的应用，您希望是什么？
我使用了 Babel，以便在日后使用 JavaScript 技术。如果能够让其中一些组件在平台中以原生方式运行，那就太棒了。具体而言，async/await、箭头函数、参数默认值和解构。
我必须使用库对输出进行 gzip 操作，以了解其 gzip 压缩后的大小。为此，使用库有点令人厌烦，因为对于 HTTP 内容的浏览器中已经存在该代码，根本上就没有 API 供其使用。理想情况下，它应该属于某种转换流，这样我就可以计算输出的大小，而无需将整个内容保留在内存中。