なぜ私は、サーバーに触れないイメージコンバータを構築しました

問題:すべての「無料」画像コンバータはあなたのファイルを望んでいます あなたがすぐにWebPに写真のバッチを変換したり、それらを生産に出荷する前にPNGのフォルダを縮小する必要がある場合、あなたはおそらく私がした同じ迷惑に遭遇しました:ほとんどの「無料のオンラインコンバータ」は、最初にリモートサーバーにファイルをアップロードする必要があります。 ランダムなスクリーンショットで大丈夫です。 NDAクライアントアセットの未発表の商品ショットが、サードパーティのサーバーに手渡すことではなく、個人写真を再配布することになっていないので、ブラウザが実際に自分で何をできるのかを見て始めたので、ほとんどの人が想定しています。 ブラウザがすでに、JPG、PNG、またはWebPに再符号化するための再符号化、再符号化、および完全にクライアント側で画像を圧縮するために必要なすべてのものでModern browsers船を行なうことができるもの。ドラッグアンドドロップとバッチアップロード用のFile APIは、JSZip(または類似)のバッチ変換中にUIスレッドが応答し、単一のダウンロード可能なZIPに複数の変換されたファイルをバンドルするためにWebワーダーは、このバックアップが必要です。 ユーザのマシンを離れる画像がない。 なぜこの問題は、明らかなプライバシーの勝利に加えて、, 変換インブラウザは、いくつかの素敵な副作用を持っています: 使いやすさを測るサーバコストは不要。 従来のimage-conversion APIは、すべてのリクエストに対して計算を行う必要があります。 クライアント側のツールは無料でスケールアップします。ユーザーのCPUは動作しません。 アップロード/ダウンロードの往復無し。 大規模なバッチの場合、ネットワークを完全にスキップすることは、サーバーにアップロードして処理されたファイルを取り戻すよりも高速です。 読み込まれるとオフラインで動作します。 PWA スタイルのクライアント・サイド・コンバーターは、完璧な接続でも作業を続けます。 トレードオフ ランチは無料ではありません。非常に大きなバッチ(高解像度の画像の採掘)は、Webワーカーに気をつけていない場合は、メインスレッドを負担することができます。 WebP/AVIFエンコーダの品質と速度はブラウザエンジンにより異なりますので、Chrome/Firefox/Safariでバイト識別出力を保証することはできません。 ブラウザが既にメモリにイメージをロードした前に、サーバー側コントロールを失います。最大ファイルサイズを強制する簡単な方法はありません。 私はこれを小さなツール、ImagArt AIに構築したところ、画像をJPG、PNG、またはWebPに直接変換し、バッチアップロードとZIPエクスポートで圧縮する。 無料で、何もアップロードされていないので、プライバシーのトレードオフは考えていません。 似たようなものをビルドしている場合は、Web Worker のバッチ処理やエンコーダーの品質設定に関するメモを比較し、以下のコメントをドロップしてください.