ToolBox Image — ToolBox Imageをブラウザだけで完結するように作った理由

ほとんどの無料オンライン画像ツールは同じように動作します。ファイルをサーバーにアップロードし、サーバーが処理し、結果をダウンロードします。このモデルはシンプルに構築できますが、隠れたコストがあります——あなたのプライバシー、サーバー費用、ファイルサイズとスループットの制限です。

ToolBox Imageは異なるアプローチを採用しています。アプリケーション全体——デコード、エンコード、圧縮、リサイズ、フォーマット変換——がブラウザ内で実行されます。アップロード先のサーバーはありません。画像がデバイスから離れることは決してありません。このアーキテクチャは意図的に選択され、製品に関するすべての決定を形作りました。

ブラウザファーストのアプローチの理由

明白な代替案は従来のサーバーサイドアーキテクチャです。画像をアップロードし、サーバーがImageMagickやSharpなどのツールで処理し、結果を返します。これは機能しますが、解決が難しい一連の問題を生み出します：

• プライバシー。ユーザーはあなたが画像を保存、分析、または漏洩しないことを信頼する必要があります。機密文書——医療画像、デザインモックアップ、個人の写真——の場合、その信頼を得るのは困難です。
• コスト。すべての圧縮はあなたのインフラ上で実行されます。成功すればするほど、支払いが増えます。これにより、ファイルサイズを制限したり、キューを追加したり、有料プランを導入したりする圧力が生じます。
• レイテンシ。低速回線での100MBファイルのアップロードは、処理が始まるまでに数分かかります。接続環境の悪い地域のユーザーにとって、このツールは事実上使用できません。
• スケーラビリティ。1台のサーバーで数十の同時圧縮を処理できます。しかし、数千の場合は？ オートスケーリンググループ、ロードバランサー、CDNアップロードエンドポイントが必要です——これらはすべて複雑さとコストを増大させます。

ブラウザファーストモデルはこれらすべてを一度に解決します。処理は無料（ユーザーのCPUサイクル）、プライベート（データはデバイスから離れない）、そして無限にスケーラブル（各ユーザーが自分のハードウェアを持ち込む）です。

どのように機能するか：WebAssemblyとWeb Workers

10年前、ブラウザで画像コーデックを実行することは不可能でした。今日、WebAssemblyにより、CおよびRustライブラリをブラウザがネイティブに近い速度で実行できる形式に直接コンパイルできます。MozillaのmozJPEG、Googleのlibwebp、libaom AVIFエンコーダー——すべてCで記述——をWebAssemblyにコンパイルしています。ブラウザはそれらがネイティブインストールされているかのように効率的に実行します。

しかし、シングルスレッドのエンコードは大量バッチには低速です。そこでWeb Workersの出番です。各ワーカーは個別のCPUコアで実行され、デバイスが持つコア数だけワーカーを生成します。8コアの最新ラップトップでは、8つの画像が同時に圧縮されます。シングルスレッドでは数分かかる200枚の写真バッチも、数秒で完了します。

犠牲にしたもの

ブラウザファーストアプローチは無料ではありません。最も重要なトレードオフはメモリです。ブラウザタブはデバイスのRAMにアクセスできますが、画像が利用可能メモリを超えたためにタブがクラッシュするのは悪い体験です。安全範囲内に留めるため、個別ファイルは100MB、バッチサイズは200ファイルに制限しています。

また、永続ストレージ、メール配信、分析などのサーバーサイド機能も犠牲にしました。圧縮画像のデータベースも、メールニュースレターも、ユーザーが好むフォーマットの追跡もありません。これはプライバシーに関する私たちの姿勢と哲学的に一致していますが、「最近の圧縮」や「セッション間の保存済みプリセット」などの機能を提供できないことを意味します。

今後の展開

ブラウザはパフォーマンス重視のアプリケーションにとって正当なランタイムになりつつあります。WebAssemblyがガベージコレクション、スレッド、SIMDサポートを獲得するにつれて、アプリケーションスタックのより多くの部分をクライアントサイドに移行できます。さらに高速なピクセル処理のためにWebGPU、シームレスなフォルダ統合のためにFile System Access APIを探求しています。

今のところ、コンプレッサーは稼働中で、毎日数千の画像を処理しています——すべて画像が本来あるべき場所に留まったままです。