Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationEventAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
2
Help us understand the problem. What are the problem?

posted at

updated at

ECサイトでのFastly活用チェックポイント

この文書で表現したいこと

いまや高速で使いやすいECサイトを作成するのにCDNの使いこなしは不可欠になりました。

ここで「CDNを使いこなして高速化する」にはどのように考えたらよいのかをFastly、VCLを題材に論点を整理します。
この整理を元に実際の設定を吟味、作り込みして、皆さんのECサイトのパフォーマンスを向上させてください。

何をキャッシュさせるか、させないか

ECでは金銭情報、在庫などの情報、個人情報を扱うため他のサービスに対してさせないべきかの決定がパフォーマンス上、ビジネス上、法令遵守上、信用上いずれとても重要なポイントになります。
逆にキャッシュした方が良い情報や、中間的な「ほどよい時間キャッシュした方が良いもの」もあるため、私の経験よりその性質で以下の5種類に分類します。

  1. 在庫などリアルタイムで変わる情報
  2. 個人情報などパーソナライズされた情報
  3. 時刻で変化する情報など定期的に変更される情報
  4. あまり変化しないがオリジンが変化した場合に数分で反映されて欲しい情報
  5. あまり変化しない情報

1や2はCDNやブラウザにキャッシュさせずに都度オリジンから配信することが基本です。(=キャッシュ禁止コンテンツ)

3は長めのTTLと短めのブラウザキャッシュでCDNにキャッシュさせておき、
オリジンで情報が更新させてたタイミングでキャッシュパージをすることが望ましいです。(定期パージコンテンツ)

4は商品詳細、商品リストページのhtmlなどを想定します。これは短めのTTLで短期間CDNにキャッシュさせる様にします。(準安定コンテンツ)

5はjsやcssなど一般によくCDNのキャッシュ対象になるコンテンツです。(安定コンテンツ)

サイトの構造

非キャッシュコンテンツ、定期パージコンテンツ、準安定コンテンツ、安定コンテンツの4種類のミックスを適切に行うことで効果的になキャッシュを狙います。

種類 分類
css,js,画像等 安定コンテンツ
多くのお客様に共通して見せたいページのhtml 準安定コンテンツ、または定期パージコンテンツ
パーソナライズされたコンテンツ キャッシュ禁止コンテンツ

とするのが基本だということです。

つまり、ページを読み込みパースする際のクリティカルパスになるhtmlを準安定コンテンツまたは定期パージコンテンツとしてCDNキャッシュし、
そこから呼び出されるcss、js、画像は安定コンテンツとして確実にCDNキャッシュにヒットさせ、
これらキャッシュコンテンツから分離してキャッシュ禁止コンテンツを扱うようにします。
キャッシュ禁止コンテンツはAPIで提供するようにしてDOM上で表示を作ることが好ましいでしょう。

各コンテンツのヘッダ、キャッシュポリシ

キャッシュ禁止コンテンツ

Cache-control: privateとすることを強くお勧めします。
vclでpassすることでキャッシュしないことは可能ですが、ECにおいて非キャッシュコンテンツはCDN、ブラウザいずれでも確実にキャッシュしないことを確認できるようにする必要があります。
万が一間違ってキャッシュした場合即、個人情報事故になることがありますから、
明示的にキャッシュされないことを保証するためにpassは使わずCache-control: privateを使うことしましょう。

定期パージコンテンツ

普段はCDNにキャッシュさせておき、オリジンコンテンツが変更されたときに確実に更新する必要があります。
商品毎に情報が更新される場合には共通してパージする必要があるURLに同じSurrogate Keysを指定しておき、オリジンシステム側からPurge APIを叩くことでキャッシュパージする方法が最も効率がよいでしょう。

準安定コンテンツ

定期パージコンテンツと違って不定期ではあるがオリジンの情報が更新され1~2分程度であれば古い情報が表示されても許容できる場合です。
前の項の通りできるだけユーザ共通部分はこの分類になるようにし、キャッシュ禁止コンテンツはAPIとしてフロントで合成することで大きな高速化が期待できます。
この場合は1~2分程度のTTLを指定して短い時間でもキャッシュするようにします。
例え短いTTLであってもその間オリジンにまで到達するリクエストは高々1つになるため高速化とサーバ負荷の低減に十分な威力を発揮します。

安定コンテンツ

長いTTLや長いブラウザキャッシュを指定することでオリジンにほとんどリクエストが来ないように設定すると良いでしょう。
長いブラウザキャッシュでの事故が不安な場合はクエリパラメータ付きURL、長いTTLが不安な場合はSurrogate Keysを活用して任意のタイミングでキャッシュを無効化できるように備えておけば安心して運用できます。

期待される効果

ECサイト一般ではhtmlの読み込みが起点になり、そこから各画像の読み込みやCSS、jsのロード、APIの実行のように繋がっていきます。
つまりhtmlの読み込みの高速化は全体のロード時間、First Contentful Paintいずれにもオールマイティに効く要素なわけですが、これは経験上かなり高速化したECパッケージやCMSからさらに約600msの高速化はできるという感触を得ています。
パーソナライズ情報等キャッシュ禁止コンテンツのAPI化をすすめ、そこにhttp/2を採用することでコンテンツのフェッチ処理が並列で進むようになるため数百から1000ms程度の高速化が期待できます。

実際にはこれらの施策の積み重ねでロード時間、First Contentful Paintとも半分程度になることがほとんどでした。

まとめ

  • 動的、静的、プライバシーなどに注目してコンテンツを分類しました
  • キャッシュ効果を最大化するサイトの構成を考えました
  • サイトを構成する際にそれぞれのコンテンツの振る舞いに何をどう期待するかを定義しました
  • 各コンテンツの期待される振る舞いからキャッシュポリシーを設定するべきかの指針を決めました

CDNは通信量(バイト数、リクエスト数)で課金されることがほとんどなので、使いこなして性能を引き出しても、使いこなくてもほとんど料金は変わりません。
使いこなし次第で、性能が向上して料金が安くなることがありますからぜひこちらを参考に最適化を図ってみてください。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
2
Help us understand the problem. What are the problem?