がいかにして窮地を救ったか - ブラウザーでの大きな画像の処理

一日を救った - ブラウザーで大きな画像を処理する" />

クライアントが、それぞれ 5800 前後の 28 枚の画像をアップロードしましたx 9500 ピクセル、サイズ 28 MB。これらの画像をブラウザで表示しようとすると、タブ全体が 10 分間 にわたってフリーズし、閉じることさえ拒否されました。そしてこれは、小型ラップトップではなく、Ryzen 9 CPU と RTX 4080 GPU を搭載したハイエンド マシン上で行われました。

状況は次のとおりです

当社の CMS (Grace Web) では、管理者が写真でもビデオでもファイルをアップロードすると、アップロードが完了するとすぐにそのファイルが表示されます。これは UX に最適です。アップロードが成功したこと、意図した内容がアップロードされたことを確認し、UI の応答性を示して操作感を向上させます。

しかし、これらの巨大な画像の場合、ブラウザはそれらをほとんど表示できず、フリーズしてしまいました。

問題はアップロード自体ではなく、これらの大きな画像の表示にあることに注意することが重要です。 28 個の巨大なイメージを同時に 1 つずつレンダリングするのは、あまりにも多すぎました。たとえ白紙のページであっても、それはただ…いや。

なぜこれが起こったのか (詳細)?

に画像を表示するたびに、タグを使用すると、ブラウザは CPU、RAM、GPU、そして場合によってはドライブを使用するプロセス全体を実行します。場合によっては、画像の読み込みやレイアウトの再計算中に画像が表示される前に、このプロセスを複数回繰り返すこともあります。ピクセルの計算、ハードウェア間のデータ転送、アルゴリズムの補間などが行われます。ブラウザにとって、これは重要なプロセスです。

ブレーンストーミングされたソリューション

いくつかのオプションを検討しました:

1. アップロード直後にサイズを変更してサムネイルを表示
   • 問題: サイズ変更には時間がかかりすぎる可能性があり、特にサイズ変更キューが空でない場合、即座に変更できるとは限りません。その結果、システムが応答しなくなります。
2. ファイル サイズを確認し、大きなファイルの場合は名前のみを表示します
   • 問題: これは、特にメディア素材のより高度な制御とチェックを必要とするユーザーにとって、ユーザー エクスペリエンスを損なう可能性があります (ちなみに、これらは大きなファイルでも同じであることがよくあります)。

これらのソリューションはどちらも使いやすいとは思えませんでした。私たちは、管理者が必要なものをアップロードできるように制限したくなかったし、ユーザー エクスペリエンスにも妥協したくありませんでした。

電球！ の使用

を思い出しました。要素は GPU をより効果的に利用してコンテンツをレンダリングします。最近、JavaScript と を使用して静かで複雑なゲームを構築している人を見ました。理論的には、大きな画像を より効率的に処理できるはずです。

理論をテストする

を置き換えることにしました。 を含む要素アップロードされた画像を表示します。使用したコード スニペットは次のとおりです:

const canvas = document.createElement('canvas');
const ctx = canvas.getContext('2d');

const img = new Image();
// img.src = URL.createObjectURL(file); // Use this if you're working with uploaded files
img.src = filesroot + data.file_path; // Our existing file path
img.onload = function() {
  // Resize canvas to desired size (for preview)
  canvas.width = 80 * (img.width / img.height); // Adjust scaling as needed
  canvas.height = 80;
  // Draw the image onto the canvas, resizing it in the process
  ctx.drawImage(img, 0, 0, canvas.width, canvas.height);

  file_div.innerHTML = ''; // Prepared <div> in UI to display the thumbnail
  file_div.appendChild(canvas);
};

結果

改善は即時かつ劇的でした!ブラウザは 28 枚の大きな画像を問題なく処理しただけでなく、28,000 x 17,000 ピクセル の 120 MB 画像 を読み込むことでさらに処理を進めましたが、それでも問題なく動作しました。小さなアイコンでした。

違いはどこにあるのでしょうか?

の使用要素の場合、描画は完全に GPU の手中にあり、それらのチップは文字通りこのタスクのために作られています。

• 依然として 28,000 * 17,000 = 476,000,000 ピクセルをレンダリングしようとします。
• この 80 * 80 = 6,400 ピクセルのみを描画します。

内の画像のサイズを変更することで、プレビュー サイズを小さくすることで、ブラウザーが処理する必要のあるデータ量が大幅に削減されます。数億ピクセルを GPU に送信し、数千ピクセルを取り戻すことができます。これは非常に大きなことですよね?

次のステップ

この成功を受けて、現在 を置き換えることを検討しています。 <キャンバス>アプリケーションの他の部分、特に一度に約 250 枚の画像を表示する管理画面で。これらの画像はすでに適切にサイズ変更されていますが、 を使用しているかどうかを確認したいと思います。さらに優れたパフォーマンスを提供できます。

パフォーマンスの向上を測定するためにテストとベンチマークを実施します。私たちの調査結果は、今後の記事で必ず共有する予定です。

重要な注意事項

の使用中私たちの特定のユースケースでは素晴らしい結果をもたらしましたが、 を使用すべきではないことに注意しなければなりません。ウェブサイトの公開部分に画像を表示するため。その理由は次のとおりです:

• アクセシビリティ: 要素はスクリーン リーダーで読み取れるため、視覚障害のあるユーザーを支援します。
• SEO: 検索エンジンは から画像をインデックスします。タグを使用すると、サイトの可視性が向上します。 (同様に、AI トレーニング スクレイパーも画像に「インデックス」を付けます。さて、何ができるでしょうか...)
• 付きピクセル密度を自動的に検出し、完璧にフィットするように大きいまたは小さい画像を表示するために使用できます。できません。の構築方法に関する記事を書きました。

公開 Web サイトの場合は、ユーザーに提供する前にサーバー側で画像のサイズを適切に変更することが最善です。画像のサイズ変更と最適化を自動化する方法に興味がある場合は、役立つと思われるトピックに関する記事を書きました。

結論

私は最適化が大好きです! 私たちは日々、ローカルの高性能ハードウェアを目指して進んでいますが、「それは良いことですが、もっと良くなる可能性がある」場合でも、最適化することで、このような問題を防ぐことができます。始まります。

このアプローチは標準ではありません。そして、私は基準をあまり気にしません。これらは厳しいルールとして扱われることが多いですが、あくまでガイドラインです。この解決策はぴったりです。私たちには、固体の <キャンバス> のない古いデバイスを使用しているクライアントはいません。サポート。したがって、管理するコードが増えたとしても、画像を表示する複数の方法が完璧に適合しており、それが重要なのです!

同じような経験はありますか?どのように対処しましたか?以下のコメント欄でお気軽にあなたの経験を共有したり、質問したりしてください!

以上が がいかにして窮地を救ったか - ブラウザーでの大きな画像の処理の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。