Pexelsは、コンテンツクリエイターに優れたユーザー体験を提供すると同時に、簡易に、かつ迅速に導入できて、急速な成長を続ける同社に合わせて拡張できる画像ソリューションを必要としていました。

Pexelsの共同創設者であるBruno Joseph氏は、「アップロード数が増えるにつれて、複雑性も増していきました。また、以前のソリューションは拡張性に乏しく、管理も非常に困難でした」と述べます。

同社のコンテンツはすべてユーザーが作成したものであるため、画像のアップロードや処理、標準化に時間がかかり、画質やサイズにばらつきがあるため、エラーが発生しやすくなります。Pexelsは当初、自社で画像サイズ変更ソリューションを構築し、それはユーザーが新しい画像をアップロードすると、バックエンド処理と画像のサイズ変更が開始されるというものでした。この作業は、同社のRuby on Railsバックエンドで、無料の画像作成・修正プラットフォームImageMagickを使用して実行されていました。しかしこれでは、デバイスサイズやピクセル密度の違いに応じて、サイズの異なる4種類の画像を手動で作成して保存する必要がありました。画像の処理と加工は当初考えていたよりも複雑であることに、同社はすぐに気づかされます。

「imgixは、画像の保存方法を変更する必要はなく、S3バケットに接続するだけで始められましたし、画像用のインフラの拡張について考える必要もなくなりました。何も変更することなく、数百万の画像にも数十億の画像リクエストに対応できるようになったのです」

— 共同創設者、Bruno Joseph氏

「以前のソリューションでは、画像が処理されて表示されるまでに数分かかることがありました。ImageMagickには画像形式の多くが欠けていて、エラーが頻繁に発生したり、各形式の処理に数秒かかかったりするなどの問題がありました。そのため、フォトグラファーのアップロード作業は満足のいくものではなく、処理速度も遅いものでした。数百枚の画像を一度にアップロードすると、15～20 分かかることさえあったのです」と Joseph氏は振り返ります。

このソリューションが持続可能ではないことは、すぐに明らかになりました。非効率的で、無駄にすることはできない同社の貴重な時間とリソースを浪費していたのです。ImageMagickのような人気ツールを使っても、何かが壊れないように処理が必要なエッジケースがまだたくさんありました。

「他のユーザーが同時にアップロードしていると、処理がさらに遅くなったり、時にはバグやその他の問題が発生したり、全く処理できない写真もあったりと、いつも何かしら問題があったので、エッジケースについて対処が必要でした」とJoseph氏は語ります。

Pexelsが検討しなければならなかったのは、ユーザー生成コンテンツだけではありませんでした。自社のウェブサイトとマーケティングのニーズも、画像処理サービスの採用条件に考慮されていたのです。また、モバイルアプリを追加した際、当初のソリューションでは必要なレスポンシブデザインが提供されず、増大するニーズに合わせて拡張することもできませんでした。

「ウェブサイトに必要なものに基づいて、さまざまなサイズにハードコーディングしました」とJoseph氏は述べ、ウェブサイト上の何かを変更したい場合、最大限の効果を得るのにどのバリアントを使うかを選択するかが避けられない問題であったと説明します。「サイズを推定していたので、デバイスやDPRに応じて動的に変化するレスポンシブ画像がなかったのです」。