こんにちは。サーバーサイド/webフロントエンジニアをやっている @cappyns です。
今回は https://www.sakeai.com/ のSEO対策をするにあたって画像の動的リサイズシステムを実装したので、そちらについて紹介しようと思います。
モチベーション
Sakeaiはユーザーが飲んだ日本酒の口コミを投稿するプラットフォームです。アプリでは口コミを投稿/閲覧することができ、Webでは投稿された口コミを閲覧することができるようになっています。
当然、口コミを表示する際にはユーザーがアップロードした画像も一緒に表示するわけですが、近年のスマホの進化によりユーザーがアップロードする画像の解像度はとても高いです。Webでこれをこのまま表示してしまうと画像のレンダリングに時間がかかり、SEO観点で非常によろしくありません。
解決策としてユーザーが画像をアップロードした時に自動で必要なサイズの画像を生成し、別途保存しておくという手段も考えられました。しかし、その手段では表示箇所によって異なる必要なサイズを全て保存しておかなくてはいけない上、デザイン変更などで必要なサイズが変化した場合には再度全ての画像の新しいサイズを生成し直さなくてはなりません。
それはめんどくさいので今回は保存する画像は1種類にしつつ、アクセス時に動的に画像のサイズを変化させる仕組みを実装しました。
仕様
実装したシステムでは以下のように画像の保存場所やサイズ、リサイズ方法をURLのpathとして表現できるようになっています。
https://img.sakeai.com/[保存場所(サーバー)]/[保存場所(フォルダ)]/[リサイズ方法]/[幅]/[高さ]/[ファイル名]
実際に使っている画像で見てみると、同じ画像でもpathによってサイズやリサイズ方法が変わっていることがわかります。
- https://img.sakeai.com/s3/images/cover/300/300/IXNuyl7y.jpg
- https://img.sakeai.com/s3/images/cover/100/200/IXNuyl7y.jpg
- https://img.sakeai.com/s3/images/contain/300/300/IXNuyl7y.jpg
アーキテクチャ
基本的にはかなり簡単な構成となっていて、s3の画像をlambdaで処理してCloudFront、API Gatewayを経由して配信する形になっています。
少し特殊な点としてSakeaiでは歴史的経緯によって画像が一部XServerに配置されたままになっています。そこでlambdaではアクセス時のパスを見てs3から画像を取得するのか、XServerから画像を取得するのか制御するように実装しています。
費用感
この記事を書いている時点でこのシステムには1日あたり1000リクエスト程度来ていますが、$0.3/monthくらいのコストに収まっています。これからもっとリクエストが増えたとしても全然許容できそうです。
最後に
このシステムによって気軽にいろんなサイズの画像を試すことができました。search console上の指標も上昇してきており、一安心です。
ぜひ画像のリサイズに困ったら参考にしてみてください。