Web 画像処理における最も一般的な 10 の間違いとその解決策

Web 画像を扱う際によくある 10 の間違いとその解決策

画像は、最新の Web サイト開発において最も重要な部分です。現在、統計によると、画像は Web サイトの総帯域幅の 60% を占めています。これは、最先端の Web サイトのデザインを扱う場合にはさらに顕著になります。ピンのようなレイアウトを使用する画像が豊富なソーシャル ネットワークでは、この数値は 85% に達する可能性があります。

残念ながら、帯域幅は高価です。トラフィックの多い Web サイトの場合、帯域幅が IT プログラマーのコストの原因となる可能性が高く、Web ホスティングとストレージのコストを簡単に超えます。さらに、このような大量のトラフィックには時間がかかるため、訪問者がサイトを閲覧するときに画像が読み込まれるまでに長い時間を費やす可能性があります。

私たちが毎日遭遇しがちな問題のいくつかと、それらをどのように解決できるか（そして解決すべきか）をリストしました。

1. ブラウザー側で画像のサイズを変更するという贅沢

開発者が使用するショートカットは、サーバー側で画像のサイズを変更するのではなく、ブラウザー側で画像のサイズを変更することであることがよくあります

。同様に、Web サイトに特定のサイズのサムネイルが多数ある場合、新しいグラフィック デザインではサムネイル サイズをわずかに変更する必要があり、開発者は場合によってはランダムに、場合によっては意図的に変更します。 、元の大きいサイズの画像を使用し、ブラウザの画像の CSS の高さと幅を調整するだけで画像がサムネイルのように見えます

最新のブラウザでは、最終的な結果は本物に見えますが、帯域幅が異なります。古いブラウザでは、画像のサイズを変更するアルゴリズムが効率的ではないため、この問題はより顕著になります。

この問題はあなたが思っているよりも一般的であり、多くの Web サイトにアクセスする際に発生する可能性があります。たとえば、Yahoo のトップページにアクセスすると、すべてのサムネイル ピクセルがここに読み込まれていることがわかります。 「ニュースは、表示されるサイズの 2 倍です。

修正方法: 開発者/デザイナー向け – 公開したい画像が、その画像を必要とする Web サイトのサイズに完全に適合していることを確認してください。たとえ同じ画像であっても、異なるページに合わせて異なるサイズのサムネイルを使用し、異なるサイズのサムネイルを作成します。すべてが同じ大きな画像を使用せず、ブラウザーに依存してサイズを変更することをお勧めします。

JPEG 画像には、不必要に高品質な画像が含まれています。それ以来、この非可逆圧縮形式により、Web 開発者は他の競合他社よりも低い帯域幅コストで高解像度の画像を読み込むことができるようになりました

そして、私たちは開発者やグラフィック デザイナーの活躍を続けています。画像に JPEG 圧縮を試さないでください。実際、ほとんどの Web サイトでは、表示品質を大幅に低下させることなく JPEG 品質を安全に下げることができます

そして、85% の JPEG 画質が一般的であることがわかります。多くの Web サイトは一般に 95% であり、実際には、品質レベルを低くすることで全体のエクスペリエンスを損なうことなく、帯域幅の問題を大幅に解決できます。その結果、帯域幅の消費量が増加し、ユーザー エクスペリエンスに影響が生じます。

2 つの写真の品質。上はほぼ同じです。左側の 95% 品質の JPEG のサイズは 34KB ですが、右側の 80% 品質の JPEG はわずか 17KB で、ダウンロード時間は 2 倍かかります。品質の低下が無視できる程度であれば、それだけの価値があります。

修正方法: 低品質の JPEG を使用すると、低品質の JPEG を使用すると非常に妥当な結果が得られることがわかりました。もちろん、常に見栄えが良くなりますが、品質の向上は、高品質の画像に伴う追加の帯域幅と待ち時間に常に価値があるとは限りません。

3. エラー 画像ファイルの種類

現在の Web サイトは JPEG、PNG、GIF です。平均して、JPEG と GIF は Web サイトの約 40% を占め、PNG は残りの 20% を占めます。

これら 3 つの形式の良い点 (そして悪い点) は、それぞれが Web サイト内で異なる役割を持つことです。間違った画像形式を使用すると、訪問者の時間とあなた自身のお金の無駄になります。

Cloudinary で最もよくある間違いは、写真の配信に PNG を使用することです。 PNG についてよくある誤解は、PNG がロスレス形式であり、写真の代替となる可能性が最も高いということです。一般的に言えば、これは真実であり、実際には最適化する必要はありません。 PNG ファイル サイズのほんの一部だけで、同等の品質の高品質 JPEG 画像を取得できます。

左側のPNG画像のサイズは110KBです。右側は JPEG 画像で、見た目は似ていますが、サイズはわずか 15 KB です。

解決方法: コンテンツの表示にどの画像形式が適しているかに常に注意してください。 PNG は、コンピューターで生成された画像 (グラフ、ロゴなど) または画像の一部を透明にする必要がある場合 (画像オーバーレイ) に使用する必要があります。キャプチャした画像を表示するには JPEG を使用する必要があります。アニメーションを表示する場合 (Jjax を使用してアニメーションを読み込む場合など)、GIF を使用する必要があります。これらは一般的なガイドラインであり、PNG はほぼすべての面で GIF よりも優れていることに注意してください。

4. 最適化されていない画像を投稿する

PNG が可逆形式であることは知っていますが、さらに圧縮できることをご存知ですか?同じ精度で画像を投稿すると、無料の PNG 圧縮ツールを使用して PNG サイズを最大 50% 縮小できます。同じ詳細画像ですが、サイズは半分ですか?私を精神薄弱者だと思ってください。残念ながら、多くの開発者や Web サイトデザイナーはこのステップを省略し、最適化されていない画像を公開しています。

解決方法: PNGCrush と OptiPNG は 2 つのオープンソースの画像最適化ライブラリです。まだ使用したことがない場合は、ぜひ使用してください。自動最適化プロセスが必要ない場合は、Yahoo のスマッシュを使用できます。手動圧縮PNGサービスを提供します。

上記はYahooスマッシュの使用例です。出来た。

5. 画像のメタデータを削除するのを忘れる

最近の Web サイトの多くでは、訪問者が写真をアップロードできます。ユーザーのプロフィール写真であれ、最近の旅行で共有された写真であれ、これらには最新のカメラからの生の情報が含まれており、多くのメタ情報が写真に組み込まれている可能性があります。

メタデータはEXIF/IPTC形式であり、カメラのモデル、日付と時刻の情報、絞り、シャッタースピード、焦点距離、測光モード、ISO、全地球測位、その他多くの情報を含む大量のカメラと写真の情報が含まれています。情報。

ほとんどの場合、メタ情報を削除することは素晴らしいアイデアです。プライバシーとファイルサイズの削減に最適です。残念ながら、開発者が時間をかけてメタ情報をクリアすることはほとんどなく、これにより帯域幅が増加し、ユーザーのブラウジング エクスペリエンスが損なわれます。

解決方法: 画像やユーザーがアップロードした写真からメタ情報を必ず削除してください。この情報が必要な場合は、イメージの一部としてではなく、範囲内で利用できることを確認してください。ヒント: 画像のメタ情報は Web サイトには必要ありませんが、写真を正しく表示するためには、画像の元の写真の向きという情報が重要です。 Exif情報を消去する場合は、Exif情報に基づいて画像を正しい向きに回転してください。

6. サーバーから画像を直接公開する

Web サイトのコンテンツを準備したら、次の目標は、Web サイトのすべての画像をできるだけ早く訪問者に配布することです。

Cloudinary で最も一般的な Web サイトの問題の 1 つは、開発者が画像を独自のサーバー (多くの場合 Web サイトと同じマシン) に保存していることです。ここでは 2 つのことが起こっています。1 つ目は、サーバーが独自の Web サイト コンテンツの公開に集中せずに画像の公開で忙しいこと、2 つ目は、最も素晴らしい画像配信ソリューションの 1 つであるコンテンツ配信ネットワーク (コンテンツ配信ネットワーク) を利用できないことです。

解決方法: コンテンツ配信ネットワークは、Web サイト自体が世界中の多数のサーバーに依存して画像の公開を管理するよりもはるかに高速に Web サイト上の画像を管理する使いやすいサービスです。 、または「ボーダー」と言います。訪問者が Web サイトを閲覧すると、画像ができるだけ早く公開されるように自動的に最寄りのボーダー サーバーにルーティングされ、必要な帯域幅に基づいて CDN の料金が大幅に削減され、ホスティングよりわずかに低くなります。サービス プロバイダーのボックスは高価ですが、現在の CDN の価格は非常に手頃なので、使用する価値があります

サインアップするだけで、そのメリットを享受できるようになります。開始します。

7. 静的アイコンは個別に提供されます

Web サイトには、写真やサムネイルに加えて、ロゴ、矢印、星、シンボル、ロゴなどの補助画像もあり、Web サイトのユーザー エクスペリエンスを向上させることができます。アップボタン、影、境界線、その他の画像フラグメントを使用すると、アーティストの要件に応じてさまざまなウィジェットを動的に作成できます

ウェブサイトには信じられないほど小さな画像がたくさんあります。検索結果ページをよく利用する人なら、そのシンプルなインターフェースに感銘を受けるかもしれません。 アイコンがほとんど見えませんね、大きな間違いですよね？ Google の検索結果ページには 80 個以上の小さなアイコンがあります (!)

開発者がよく犯す間違いは、これらの小さなアイコンをそのまま Web サイトに埋め込むことです。ブラウザが非常に多くの画像をダウンロードするには、かなりの時間がかかります。写真をダウンロードするとき、私たち訪問者はネットワーク遅延に耐える必要があります。平均的なブラウザーは同時に 6 枚までの写真しかダウンロードできないため、遅延は写真のダウンロード バッチによって倍増されます。訪問者はブラウザがこれらすべての画像のダウンロードを完了するまで待つ必要があり、Web サーバーは非常に多くのダウンロード リクエストを処理するために応答しなくなる可能性があります。訪問者は待つことをあきらめて、毎日の閲覧活動を続けることさえあるかもしれません。

修正方法: 簡単な解決策は、すべての小さなアイコンを含む 1 つの画像である CSS スプライトを使用することです。 Web ページはサーバー上のこの 1 つの画像からダウンロードおよび変更され、ページの HTML は代替 CSS クラス名を使用して、大きな画像内の小さな画像を指します。

現在、Google の訪問者は 80 枚の画像の代わりに 1 枚の画像だけをダウンロードします。ユーザーのブラウザは、これらの 1 つの画像を Google のサーバーからすぐにダウンロードしてキャッシュし、すべての画像がすぐにレンダリングされます。

8. CSS3 が使用できる場合は画像を使用します

Web サイトのデザインを HTML 要素に変換するとき、多くの開発者は依然としてボタンを画像としてデザインします。古いブラウザでは、シャドウ、円弧コーナー、特殊フォントを実装するための CSS の使用がサポートされていないため、開発者はこれまで、小さな画像を使用して上記の機能を実現する、つまり画像ベースのソリューションを使用することに慣れてきました。

残念ながら、このソリューションには大量の画像が必要であり、最終的に視聴者のエクスペリエンスに悪影響を及ぼし、管理も難しく、開発に必要な時間とコストが増加します (画像に埋め込まれたテキストを変更する方法を考えてください)。

最新のブラウザは、影、角丸長方形、特殊フォント用の単純な CSS の使用をサポートしています。しかし、依然として多くの Web サイトが画像ベースのボタンを使用しているのを目にします。これはよくあるタイプの間違いです。たとえば、CNN ボタンのこの部分を見てください -

この小さなトリックは、単純な CSS コマンドを使用して簡単に実装できる 61 KB の画像であり、帯域幅の消費を削減しながら読み込み時間とユーザー エクスペリエンスを向上させます

解決方法: 必ず確認してください。グラフィック デザイナーが CSS3 ベースの要素を使用できるようにする場合は、インターフェイスが少なくとも設計された機能を確実に維持できるようにする必要があります。 (元の効果を完全に表示することはできませんが)、CSS3 PIE などの CSS3 シミュレーション ソリューションを選択します

9. 間違った画像キャッシュ設定

一般に、Web サイトには画像文化の変化がほとんどありません。 HTTP キャッシュ ディレクティブを使用すると、他のサービス (CDN、プロキシなど) と同様に、訪問者のブラウザでこれらの画像をキャッシュできるようになります。画像がキャッシュされると、今後 Web サイトにアクセスすると、画像を何度もダウンロードするのではなく、キャッシュが使用されます。

正しいキャッシュ設定により、ページの読み込み時間が短縮され、Web サイトの帯域幅とコストも削減され、ユーザー エクスペリエンスが向上します。

残念ながら、キャッシュが正しく利用されていないケースが多く見られます。最も一般的には、Web サイト訪問者には新しい画像ではなく古い画像が表示されると考えられるため、画像を更新するときにキャッシュ設定に時間がかかることが懸念されます。

この一見厄介な状況は、画像 URL にフィンガープリント (MD5、タイムスタンプなど) を追加することで簡単に回避できます。画像の URL にフィンガープリントを追加すると、画像とその URL がいつ変更されたかを知ることができます。 URL が変更されると、ブラウザは画像を強制的に再読み込みします。現在の Web 開発プラットフォームは、このようなフィンガープリントをすべての画像に自動的に追加できるため、この問題をソースから解決できます。

解決方法: サイト全体で画像をアクティブにキャッシュし、可能であれば画像の「Expires」HTTP ヘッダーを設定することを強くお勧めします。画像 URL のフィンガープリントに加えて、Web サイトのパフォーマンスを即座に向上させることができます。

10. すべての配信メディアで同じ画像サイズを使用してください

あなたのウェブサイトはさまざまなデバイスで閲覧されています。近年、モバイル ユーザーやタブレット ユーザーが増加しているため、Web サイトのトラフィック分析を見てみましょう。これらのデバイスからの訪問者が大幅に増加していることがわかります。

Web サイトにモバイル訪問者がいる場合でも、Web サイト コンテンツのモバイル バージョンを提供する予定がある場合でも、決定すべきことは 1 つあります。画像を送信する方法です。モバイル デバイスでは同じ画像でも、デスクトップでは解像度が低すぎます。

開発者が、異なる解像度で同じ画像を提供し、クライアント上で画像をスケーリングすることでトラブルを避けようとしているのをよく見かけます。画像は素晴らしく見えますが、ユーザーは大きな画像をロードするのに時間を無駄にし、追加の帯域幅料金を支払うことになります。これは、大量の高解像度画像に追加料金を支払う必要がある 3G ユーザーやローミング ユーザーにとって特に不公平です。

その逆は、最低の標準を使用し、すべてのデバイスで非常に低解像度の画像を使用することで、新しい高解像度のデバイスではサイトのパフォーマンスが低下します。

解決方法: 解決策は簡単です。ユーザー エージェントまたはクライアント側の Javascript コードを通じて、訪問者のモバイル デバイスと解像度を特定します。正確な解像度を取得した後、最適な画像がサーバーから取得されます。もちろん、これには元の画像のサムネイルのセットを提供する必要があります。このプロセスを自動化する優れた JavaScript パッケージがすでにいくつかあります。

概要

この記事で説明されている最も一般的な Web サイトの画像処理の問題は、実際に Cloudinary で遭遇する最も一般的な問題です。問題が非常に多いというわけではありません。私たちは、より大きな影響を与える問題を解決しようとしているだけです。研究の出発点として使用し、適切な解決策を見つけられるように、それを提案して一般的な説明をします。

Cloudinary について聞いたことがない場合は、Cloudinary が上記の問題と上記以外の問題を解決したことを喜んでお伝えします。Cloudinary にアップロードされた各画像は、任意のサイズ、形式、品質のサムネイルで動的に生成できます。 Cloudinary は、さまざまな設定で顧客の期待に応える構成を見つけます。すべての画像は自動的に削除され、適切なキャッシュを使用して最適化されます。最後に、Cloudinary のクラウドの動的画像サイズ変更機能がレスポンシブ デザインに完全に適応していることにも言及する価値があります。