Webページの読み込みを高速化：4つの画像最適化戦略のテスト

サイトのページ読み込み速度の低下と、コンバージョンの減少に伴うバウンス率の増加との間の強い相関関係について、統計が繰り返されています。 「肥大化した」ペイロード（最適化が不十分な画像と冗長なHTMLコード）によってサイトの速度が低下していると言っても、アメリカを発見することはできません。これにより、サーバーは不要な作業を強制されます。この作業の巨大な層は、画像の最適化の問題に関連しています。 



正しく選択された画像は、それ自体で注目を集め、コンバージョンを増やし、ソーシャルネットワークやその他の訪問者とのやり取りに関する情報を広めるのに役立ちます。したがって、それらは引き続きWebページに積極的に投稿されます。しかし、これがこれらのページの読み込み速度にどのように影響するかは興味深い質問です。それはすべて最適化戦略に依存します。



画像は静的コンテンツであるという論文に依存する戦略はあまり効果的ではないと思います（私はこのアイデアを発展させ、記事全体で議論します）。現在、モバイルデバイスはインターネットトラフィックの大部分を占めていますが、問題があります。これらのデバイスは、サイズ、画面解像度、オペレーティングシステム、およびアプリケーションソフトウェア（ブラウザなど）が異なります。 Webページをすばやく作成する方法（！）そして、任意のプラットフォームに正しくロードし、同時に同じように見えるようにする方法は？



この記事では、開発段階、プロジェクトアセンブリ、および/または完成したWebサイトの保守段階で、画像最適化のソリューションを削減します。 



確かに、一部の最適化戦略は、設計と開発のプロセスを大幅に複雑にするだけでなく、メンテナンスの頭痛の種を追加する可能性があります。私は一般的に、組み立て中のリソースと時間の浪費の増加について沈黙しています。画像を最適化するための多くの方法とツールがあります。しかし、それらのいくつかは、複雑で反復的なプロセスを自動化せずに使用するのは簡単ではありません。 4つの戦略を検討し、さまざまなデバイスに対してより適切に自動化して柔軟な（動的な）画像最適化を行うことができる戦略を見つけます。



4つの戦略をテストします。まず、画像の最適化を行わずに、すべてのブレークポイントと画像オプションを含む単純な適応コードをサーバーにフィードします。次に、ビルド段階での最適化について見ていきます。ここでは、特別なツールとサービスが必要なイメージのバリエーションの準備に役立ちます。3番目の戦略は、実行時の最適化です。ページを送信する前に、自動化されたツールまたはオンラインサービスが、特定のテンプレートに従って、またはブラウザーからの情報に基づいて、画像に最適化を適用します。最後の戦略は、他の専門サービスを通じて取得したデバイスとブラウザーに関する情報を使用して、最適化された画像を生成および配信することです（記事の最後でそれらについて確実に説明します）。

注意！ネタバレ！

デバイス固有の画像最適化戦略が最良の結果をもたらします。この記事では、各戦略を実装することの長所と短所、およびそれらがWebアプリケーション開発プロセスに与える影響について説明します。



画像最適化の最終的な目標は、Webページの読み込み速度を向上させることです。 Google PageSpeedInsight を使用してページを監査しています。これにより、個々の戦略の有効性を簡単に分析できます。上で書いたように、モバイルページを監査します。

戦略＃1：最適化なしのレスポンシブコード

画像の最適化を使用せずに標準のレスポンシブコードを使用しました。ブラウザは、画面サイズに基づいて、サイズの異なる同一の画像のセットから多かれ少なかれ適切なオプションを選択するだけです。さまざまなサイズの画像のコードには、いくつかのブレークポイントがあります。それらは、携帯電話、タブレット、デスクトップコンピューターのディスプレイサイズによって決まります。



しかし、ここでも問題があります。そのような構成は何千もあり、毎日さらに多くの構成があります。ブレークポイントをどんどん追加する必要があります。ただし、これにはより多くの開発時間が必要であり、コードベースの過成長につながり、将来的には混乱やエラーにつながります。 



srcset属性に4つのブレークポイントがある例を次に示します。



<img srcset = "image-1920.jpg 1920w、



  image-1280.jpg 1280w、image-640.jpg 640w、image-480.jpg 480w"サイズ= "（最小幅：36em）50vw、100vw" src = " image-320.jpg "alt ="レスポンシブ画像構文 "/>

次に、プロジェクトに含める ことができるこのコードの量について考えます... 



さらに、リストされている各サイズの画像を個別に作成する必要があります。これには時間がかかり、追加のストレージスペースも必要です。



CSSメディアクエリを使用して応答性を実装することもできます。または、newとelementsを使用することもできます <source>



。ここで、<picture>は、1つ以上の<source＆gt要素と1つの<img＆gt要素のコンテナです。ただし、これらのアプローチのすべてがスケーラブルなソリューションを可能にするわけではありません。



最後に、これらのアプローチでは、デバイスの詳細は考慮されていません。このようなコードを書くたびに、使用するブレークポイントと必要な画像サイズを推測しようとしているだけです。さらに、今日うまく選択したオプションが明日機能するという保証はありません。

利点：

• ソフトウェアを購入したり、追加のソフトウェアやサービスのサブスクリプションにお金を払ったりする必要はありません。
• 十分に文書化された標準に基づいてレスポンシブコードを書くのは比較的簡単です。 

短所：

• さまざまなサイズの画像を保存するには、追加のスペースが必要です。
• このような「適応型多分散」を実装するには、追加の時間と労力が必要です。
• コードの成長とそのメンテナンスの複雑さ。
• このコードは、すべてのブラウザで同じように機能するわけではありません。
• デバイスコンテキストに依存しません。
• スケーリングには、個別のCDN（コンテンツ配信ネットワーク）が必要です。
• 新しいデバイスや画像形式などの完成には長い時間がかかります。

試験結果

テストでは、圧縮なしでも、最適な形式を選択しなかったことが示されています。そして、私の画像は大きすぎます。

戦略＃2：ビルド時の最適化 

画像バリエーションの作成を容易にする1つの方法は、Kraken、 Compressor.io、mozjpeg、squoosh などの特殊な画像編集または圧縮サービスを使用すること です。



画像とサービスプロセスをアップロードし、サーバー上の画像を最適化します。次に、プロジェクトで最適化された画像を使用できます。非可逆または可逆圧縮、サイズ変更、ダウンスケーリングなど、標準またはカスタムの最適化設定を設定できます。一部のサービスでは、必要なサイズに応じて、同じ画像の複数のバージョンを一度に提供できます。



壊れたものを探して、GruntまたはGulpビルダーを使用して画像を最適化した場合はどうなり ますか？これを行うには、ビルド中に実行する適切なタスクを割り当てるだけで十分です。画像処理自体は、imageminjsパッケージで処理できます 。



npmを介してインストールすることも、コマンドラインインターフェイスを介して使用することもできます。これは、さまざまな画像フォーマットを圧縮するためのプラグインとモジュラーソリューションである：例えば、imageminの用途は mozjpeg JPEGとするために pngquantのPNG圧縮のため。画像最適化オプションの設定は、多くのSaaSツールに似ています。



この戦略を実装する場合、最大の負担は開発者にあります。まず、サードパーティのツールを調整して画像のバッチ処理を自動化し、次に定期的にコードを更新して新しい画像形式をサポートする必要があります。

利点：

• 画像の最適化は外部サーバーで実行されます。
• サービスは画像を十分迅速に処理します。
• 最適化制御は、開発および展開ワークフローに組み込むことができます。
• サービスには、最適化パラメーターを設定するための便利なインターフェースがあります。
• かなり豊富な機能を備えた多くの無料ツール（または無料プラン）。

短所：

• ここでも、適応型多分散を実装するには多くの時間がかかります。
• デバイスのコンテキスト（サイズ、画面解像度など）にはまだ依存していません。
• 多くの画像を保存するためのスペースがまだ必要です。
• まだCDNが必要です。
• APIを介してサードパーティ製品との統合をさらに実装するには、さらに多くの工数が必要です。
• 画像の新しいバリアントが表示されるたびに、既存のバリアントに対して最適化プロセス全体を実行する必要もあります。
  
  
  
  

試験結果

ポイントに関しては、最初の戦略よりもわずかに優れています。圧縮に関する苦情は落ち着きましたが、フォーマットと大きすぎるサイズについての苦情は残っています。





総ペイロードが1.4MBに減少したことに注意することが重要です。これは、戦略のないソリューションよりも80％少なく、アダプティブコードのある戦略よりも50％少なくなります。 

戦略＃3：実行時の最適化

特定のデバイスからページにアクセスすると、ブラウザはHTTPヘッダー付きのリクエストをサーバーに送信します。ヘッダーには、アクセスコンテキストと画像形式に関する情報が格納されます。



ランタイム最適化は、応答（コンテンツ）がブラウザーに送信される直前にサーバー上で実行されます。この最適化の目標は、送信されるデータ量を減らしてWebページの読み込みを高速化することです。 



たとえば、Chromeブラウザのヘッダーは次のようになります



。image/ avif、image / webp、image / apng、image / *、* / *; q = 0.8



クライアントヒントの登場により、さらに多くの情報を転送できます。たとえば、DPR（デバイスのピクセル比、「ピクセル密度」、解像度と同様の値）およびビューポート幅（画面幅）などのフィールド。



クライアントヒントは、ブラウザがHTTPリクエストヘッダーで、受信するコンテンツの種類をサーバーに通知するためのプロトコルです。クライアントヒントは、ブラウザに関する情報を含むHTTPリクエストヘッダーにフィールドを追加します。このプロトコルの重要な機能の1つは、ページに必要な画像のサイズについてサーバーに通知することです。



ランタイムオプティマイザは、このデータを使用して、画像を圧縮する方法と、画像を出力する形式を決定します。ただし、柔軟なサイズ変更を行うには、ブレークポイントに基づいて適応ロジックを手動で実装する必要があります。



これらのタスクは、CloudinaryやimgixなどのSaaSオプティマイザーによって実行されます。これらのプラットフォームには通常、イメージサーバーまたはプロキシがコンテンツを最適化する最適な方法を決定するときに自動最適化オプションがあります。ただし、APIを使用して（通常は単純なURLパラメーターを使用して）最適化パラメーターを自分でカスタマイズすることもできます。



ImgIxは、キャッシュに追加する前にリアルタイムの画像処理を可能にするCDN（Amazon CloudFront）アドオンです。 ImgIxは、画像処理に必要なすべての機能に加えて、モノクロ、ブラー、ハーフトーンなどの多くの追加機能を提供します。



多くの場合、このようなサービスはCDNとしても機能します。また、Cloudinaryには独自のDAM（デジタル資産管理）システムがあります。



すべてが正常ですが、そのようなオプティマイザはまだデバイスコンテキストを分析できません。HTTPヘッダーは、ユーザーエージェントのデータを伝達し、たとえばAndroidデバイスのChromeブラウザからページが開かれたことを通知することができます。しかし、これだけでは十分ではありません。それが電話であるかタブレットであるか、そしてその対角線の画面解像度は何であるかについては何も言われていません。 



画像は、独自のリソースではなく、プラットフォームのサーバーにも保存されます。ただし、通常、新しいイメージの場合に備えて、ある程度の余裕を持ってディスク容量の割り当てが固定されています。

利点：

• 画像を最適化するために必要な労力はごくわずかです。
• run-time CDN ;
• , , DAM ;
• URL;
• , /
• , ;

:

• , ;
• src , , -;
• - ;
• 通常、最初のリクエストでは動作が遅くなります。これは、サービスがサードパーティのソースからイメージを取得してから、キャッシュをまったく使用せずに最適化する必要があるためです。

試験結果

圧縮とフォーマットに関する苦情はほとんどなくなりましたが、それでも

サイズに問題があります。





前の2つの戦略と比較すると、ペイロードは88％減少しています。今ではわずか897KBです。

戦略＃4：デバイスコンテキストに合わせて最適化

前の戦略と同様に、イメージサーバーを備えたサービスが必要です。動的な状況依存の最適化には、リクエストヘッダーを使用する必要があります。たとえば、ブラウザはHTTPリクエストでAcceptを介してAVIFのサポートを宣言できます。次に、サービスは、AVIF形式でどのような画像を表示するかを検討します。そして、ここから「魔法」が始まります。



たとえば、ImageEngineサービスについて考えてみます 。WURFL jsライブラリを使用して、アクセスコンテキストからデバイスに関する完全な情報を取得できます。 ..。ブラウザとOSに加えて、デバイスの正確なメーカーとモデル、および画面の特性（解像度、PPI、その他多数）を判別できます。また、すべてのサービスが機能するとは限らない、save-dataヘッダーを含むクライアントヒントもサポートします。



これにより、このようなオプティマイザーは、ペイロードと画質の最適なバランスを確保しながら、あらゆる場面でより適切な画像オプションを提供できます。



これらのサービスは、CDNを使用して、画像配信を高速化し、キャッシュヒット率を向上させます。このアプローチは、画面パラメータが異なるデバイスが非常に多いため、インターネットのモバイルセグメントで大きな利点があります。



この戦略では、コードを完成させる必要はほとんどありません。imgタグのsrc属性値を最適化サービスにリンクすることで、それらを更新するのは簡単です。そしてそれがすべてです。 

利点：

• 開発とメンテナンスに最小限の労力を必要とします。
• 効果的に構成して忘れることができます（自動最適化設定を使用する場合）。
• URLのディレクティブを使用した画像の自動および手動最適化。
• 最高の品質を維持しながら、画像ペイロードを最大限に節約できます。
• この戦略を実装して、ほんの数分で使い始めることができます。
• 最適化サービスは通常、最高の価格/帯域幅比を提供します。
• コードベースの過成長はありません。適応コードもブレークポイントもありません。

短所：

• src , , - ( ); 
• ;
• , , .

これで、Google PageSpeedInsightsは満足しています。 



ほとんどの指標は大幅に改善されました。サービスは、新しい画像形式（たとえば、アクセスコンテキストに応じて最適に圧縮されたAVIF）を使用して自動的に開始 されました。さらに、画面サイズが異なると、画像の長さと幅が自動的に変更され、拡大縮小されます。



総ペイロードは約95％減少しました。

そして、あなたは幸せになります

ご覧のとおり、すべての戦略には長所と短所があります。画像最適化サービス、特にデバイスコンテキストに基づくサービスには、確かに優位性があります。



3番目と4番目の戦略では、イメージの作成、保守、保存の段階で、問題を最小限に抑えて開発プロセスを合理的に構築できます。さらに、複雑でスケーラブルでないレスポンシブコードを書く必要はありません。画像の最適化は、新しいビジネス要件とニーズを満たすために確実かつ柔軟に機能します。



APIまたは単純なURLパラメータを使用して調整を行うことができるため、画像最適化設定を制御できなくなる心配はありません。



もちろん、あなたはそのような喜びのためにお金を払わなければならないでしょう。しかし、サービスの代表者は、個人だけでなく中小企業にも安価な料金プランが提供されることを保証します。

---

Macleodのクラウド VDSは、ウェブサイトのホスティングに最適です。



上記のリンクを使用するか、バナーをクリックして登録すると、任意の構成のサーバーをレンタルした最初の月が10％割引になります。