摘要
SVGOMG：可擴充的 Material Design 回應式前端，適用於 SVGO。
我們喜歡哪些功能？
SVGOMG 以我們自己的 Jake Archibald 建構而成，是使用網路技術編寫而成的完善回應與功能最完美的範例。它擁有精美的質感設計外觀，ServiceWorker 可確保應用程式快速載入且可離線使用，並且在行動裝置上順暢轉換。
可能的改善項目
我們唯一必須提供的特殊功能，就是因為缺少主要 UI，初始使用者體驗令人困惑。除此之外，做得好！
問答時間：傑克阿奇巴德
為何要建立網路？
太慢了。總延遲時間。我並非 Windows 原生應用程式的開發專家，我並非 OSX 原生應用程式的專家，也不是為 iOS、Android、Windows Phone 或 Linux 建構原生應用程式的專家。但我可以在網路上做到這一點，而這套技能組合讓我「一次」能在所有平台都找到合適的產品。
在開發過程中，哪些項目表現得很好？
我對它的表現非常滿意。我確定網頁在 JS 可用之前轉譯。事實上，圖片一開始只會使用 5K 的 HTML 轉譯並包含部分內嵌的 CSS 和 SVG。主要指令碼和 CSS 都會在背景載入。這表示即使在 3G 網路使用空白快取的情況下，網站仍會以 1.5 秒載入，其中大部分是 DNS 和 SSL。
開啟畫面非常簡單，因此在 5, 000 下，並不是難題。很令人困擾，許多網站等待 JS 首次轉譯，有些網站甚至需要 JS 才能提出進一步要求才能轉譯。因此 3G 的轉譯時間會縮短至 10 秒，因為身為行動裝置使用者，我自己完全不用擔心這樣。
主要的 JS 為 15k，但不包含剖析及壓縮 SVG 的部分，這些項目在背景中做為額外階段載入。這種做法很棒，因為互動時間非常快，使用者也不會注意到額外的負載。如果使用者在指令碼可用之前選取 SVG，則該指令碼的載入似乎會花費一些處理時間。
我也使用 ServiceWorker 來讓整個工作離線工作。離線工作是一項很酷的功能，但主要是為了提升效能。使用者後續造訪 SVGOMG 時，無論他們使用任何連線，都能立即轉譯。有鑑於行動連線能力不斷變化，這真是太有價值了！
如果你可以用任何 API 改善應用程式，你的應用程式會是什麼？
我使用了 Babel，日後就能使用 JavaScript 東西。能讓他們在平台中原生運作，真是太棒了。具體來說，Async/await、箭頭函式、引數預設值和解構處理。
我必須使用程式庫將輸出內容壓縮，才能找出其 gzip 壓縮檔。使用程式庫執行這項作業相當麻煩，因為瀏覽器已經內建 HTTP 內容的程式碼，所以它沒有 API。在理想情況下，應使用轉換串流類型，這樣我就能在不擁有整個記憶體的情況下計算輸出內容的大小。