博士

ロボ子、今日はウェブサイトの画像最適化戦略の進化について話すのじゃ。

ロボ子

画像最適化、奥が深そうですね！

博士

最初は「Do Nothing」、つまり何もせずにユーザーがアップロードした画像をそのまま提供していたらしいぞ。でも、これだと読み込みが遅くて帯域も無駄になるのじゃ。

ロボ子

確かに、高画質の画像は重すぎますよね。

博士

次に「同期的なアップロードと最適化」が出てきた。アップロード時に最適化するけど、フォーマットの進化に対応したり、CPU負荷が集中したりするのが問題だったのじゃ。

ロボ子

JPEGからWebPへの移行は大変そうです。

博士

そこで「専用サービスへの画像処理の移行」じゃ。でも、最適化版がいつ使えるか分からなかったり、最適化戦略を変えるたびに再処理が必要になったりするのじゃ。

ロボ子

最適化のタイミングが重要なんですね。

博士

そして「画像処理プロキシ」。リクエストに応じてその場で最適化するけど、CPUを消費してコストがかかるのじゃ。

ロボ子

オンデマンド最適化は便利そうですが、負荷も高そうですね。

博士

「プロキシの前のプロキシ」でキャッシュを追加したけど、キャッシュがボトルネックになることもあったのじゃ。

ロボ子

キャッシュは重要ですが、管理が大変そうです。

博士

「CDN + 画像処理プロキシ」でグローバル配信できるようになったけど、管理が複雑になったのじゃ。

ロボ子

CDNは必須になりつつありますよね。

博士

「サードパーティサービス」は便利だけど、サービス停止が怖いし、料金も分かりにくいことがあるのじゃ。

ロボ子

依存先が増えるのはリスクがありますね。

博士

そして最新の戦略が「クライアントインテリジェンス & キャッシュプロキシと画像処理プロキシのバンドル」じゃ！クライアントが直接最適化された画像を取得しようとして、失敗したらプロキシ経由でリクエストするのじゃ。

ロボ子

なるほど、クライアント側で賢く判断するんですね！

博士

そう！初回は遅いかもしれないけど、後続のリクエストは速くなる。既存のインフラを再利用できるのも良い点じゃ。

ロボ子

Imgproxy-cacheプロジェクトで実装されているんですね。Tigrisと組み合わせるとCDNのような動作を無料で実現できるとは！

博士

GitHubリポジトリ[err0r500/imgproxy-cache](https://github.com/err0r500/imgproxy-cache)で確認できるぞ。すごいじゃろ？

ロボ子

本当にすごいですね！勉強になります。

博士

というわけで、画像最適化の歴史は、まさにエンジニアの知恵比べ！…って、ロボ子、もしかして全部理解したのじゃ？

ロボ子

はい！完璧です！

博士

うそじゃ！じゃあ、今すぐこの知識を使って、私の部屋のポスターを全部WebPに変換するのじゃ！