摘要
SVGOMG：适用于 SVGO 的漂亮、材质感十足且响应迅速的前端。
我们喜欢什么？
SVGOMG 由我们自己的 Jake Archibald 构建，是使用 Web 技术编写的完全响应式强大工具的几乎完美示例。该应用采用美观的 Material Design 外观，ServiceWorker 可确保应用快速加载且可离线使用，并且在移动设备上实现流畅的转换。
可能的改进
我们唯一要提出的真正问题是，由于缺少主界面，初始用户体验令人困惑。除此之外，您做得很好！
Jake Archibald 访谈
为什么选择网站？
懒惰。完全是懒惰。我不是开发 Windows 原生应用的专家，也不是开发 OSX 原生应用的专家，也不是开发 iOS、Android、Windows Phone 或 Linux 原生应用的专家。不过，我可以做 Web 开发，只需掌握一套技能，就可以一次构建适用于所有这些平台的应用。
开发过程中哪些方面做得非常好？
我对其表现非常满意。我会确保在 JS 可用之前渲染页面。事实上，它只需 5KB 的 HTML 和一些内嵌的 CSS 和 SVG 即可进行首次渲染。主要脚本和 CSS 均在后台加载。这意味着，即使在 3G 网络且缓存为空的情况下，网站也似乎会在 1.5 秒内加载完毕，其中大部分时间都花在 DNS 和 SSL 上。
开屏画面非常简单，因此在 5K 分辨率下完成此操作并不难。有这么多网站需要等待 JS 进行首次渲染，这让我感到非常困扰，有些网站甚至要求 JS 在渲染之前发出进一步的请求。这会将 3G 呈现时间推向 10 秒 - 作为移动用户，我知道自己不会忍受这种情况。
主 JS 为 15k，但不包括解析和缩减 SVG 的部分，这些部分会作为额外的阶段在后台加载。这样做非常棒，因为交互内容会非常快地呈现，用户不会注意到额外的加载。如果用户在该脚本可用之前设法选择了 SVG，则该脚本的加载时间似乎会计入处理时间。
我还使用了 ServiceWorker 来让整个应用在离线状态下正常运行。离线工作是一项很酷的功能，但我主要是为了提高性能而使用它。无论用户使用何种连接，再次访问 SVGOMG 时，页面几乎都会瞬间呈现。鉴于移动网络连接的差异，这非常有价值！
如果您可以使用任何 API 来改进应用，您会选择哪个 API？
我使用了 Babel，以便使用未来的 JavaScript 内容。如果这些功能能够在平台中原生运行，那就太棒了。具体而言，就是 async/await、箭头函数、参数默认值和解构。
我不得不使用库对输出进行 gzip 压缩，以了解其压缩后的大小。使用库来执行此操作有点麻烦，因为该代码已在浏览器中用于 HTTP 内容，只是没有相应的 API。理想情况下，它应该是一种转换流，这样我就可以统计输出大小，而无需将整个内容存储在内存中。