SVGOMG

Paul Bakaus

概要

SVGOMG: SVGO 用の美しいマテリアルレスポンシブフロントエンド。

改善の可能性

唯一の欠点は、メイン UI がないため、最初の UX がわかりにくいことです。それ以外は、よくできました。

Jake Archibald 氏との Q＆A

ウェブを使う理由

怠惰。完全に怠惰です。私は Windows ネイティブアプリの開発の専門家ではありません。また、OSX ネイティブアプリの専門家でも、iOS、Android、Windows Phone、Linux 向けのネイティブアプリの作成の専門家でもありません。ただし、ウェブはできます。この 1 つのスキルセットで、すべてのプラットフォームで動作する何かを1 回作成できます。

開発中に特に効果的だった点

パフォーマンスには満足しています。JS が利用可能になる前にページがレンダリングされるようにします。実際、最初のレンダリングでは、HTML が 5, 000 バイト、CSS と SVG がインライン化されています。メインのスクリプトと CSS はすべてバックグラウンドで読み込まれます。つまり、キャッシュが空の 3G でも、サイトは 1.5 秒で読み込まれるように見えます。そのほとんどは DNS と SSL です。

オープニング画面は非常にシンプルなので、5K で作成しても問題ありませんでした。多くのサイトが最初のレンダリングを JS に依存していること、さらにはレンダリング前に JS がさらにリクエストを行う必要があるサイトがあることは、本当に困ります。これにより、3G のレンダリング時間が 10 秒近くに達します。モバイルユーザーとして、私はこれを我慢できないでしょう。

メインの JS は 15,000 ですが、SVG を解析して圧縮する部分は含まれません。この部分は、バックグラウンドで追加フェーズとして読み込まれます。インタラクティビティが非常に速く表示され、ユーザーは追加の読み込みに気付かないという点が優れています。ユーザーがそのスクリプトが利用可能になる前に SVG を選択した場合、そのスクリプトの読み込みが処理時間の一部として表示されます。

また、ServiceWorker を使用して、すべてをオフラインで動作させました。オフラインでの作業は非常に便利な機能ですが、私は主にパフォーマンス向上のために使用しています。SVGOMG に再度アクセスすると、ユーザーの接続に関係なく、ほぼ瞬時にレンダリングされます。モバイル接続の状況はさまざまですが、この機能は非常に有用です。

アプリを改善するために API を 1 つ選ぶとしたら、それは何ですか？

将来の JavaScript 機能を利用できるように、Babel を使用しました。一部の機能はプラットフォームでネイティブに動作すると便利です。具体的には、非同期/待機、矢印関数、引数のデフォルト、デストラクチャリングです。

ライブラリを使用して出力を gzip に圧縮し、gzip 圧縮後のサイズを確認する必要がありました。ライブラリを使用するのは面倒です。そのコードは HTTP 用にブラウザにすでに存在し、API がないだけです。理想的には、変換ストリームの一種である必要があります。これにより、全体をメモリに保持せずに出力のサイズをカウントできます。