12 月になりました、いよいよ一年の終わりが近付いてきましたが皆様いかがお過ごしでしょうか。西です。

さて、11 月最終週からついに re:Invent2023 が開催されました。弊社からも 11 名が参加しており、AWS 関連のインプットや観光に勤しんでいます。今回の re:Invent2023 で私は「NET209 | Optimize website performance for SEO with Amazon CloudFront」のセッションを聴講しましたので、本稿はそのセッションレポートになります。

セッションの概要

Amazon CloudFront (CloudFront) といえば、コンテンツキャッシュ機能だけでなく、TLS の設定などの充実したセキュリティ設定やレスポンス制御、さらにはエッジコンピューティングサービスとの組み合わせが可能なサービスです。また、re:Invent2023 前には CloudFront Functions KeyValueStore が発表されており、ますます機能が拡充しています。

そんな CloudFront が持つさまざまな機能を検索エンジン最適化 (Search Engine Optimization: SEO) 戦略の観点で捉えて見てみよう、というのが本セッションの主旨だったように思います。たぶん。

ざっくりとした内容

セッションではまず、検索エンジンの結果の順位についての話より始まりました。検索エンジンサービスにおけるシェアの 90% 以上を Google が占めているため、主には Google を想定したおおまかな仕組みや指標 (※) についての話です。

※ 厳密なアルゴリズムは公開されていないため

その後、Google がこれまでアナウンスしている内容を基に、検索結果での評価を上げるためにすべきとされること (SEO 戦略) の紹介が展開されました。 SEO 戦略の指標には様々なものがありますが、発表では主に

リクエスト時間は可能な限り短縮されているか
リクエスト元のデバイスに応じた表示がされているか
通信のセキュリティプロトコルが適切に設定されているか
ドメイン構造がユーザにとってシンプルでわかりやすいものになっているか
メンテナンス時にレスポンスの HTTP ステータスを適切に設定できているか

という点にフォーカスされており、それに併せて対応する CloudFront の機能が紹介されていました。

リクエスト時間は可能な限り短縮されているか

この点は CloudFront の基本機能であるコンテンツキャッシュ機能がによるレスポンスの速度向上が担っている点です。 CloudFront は Edge Locations / Regional Edge Locations という 2 種類の Edge Locations から構成され、ユーザへのコンテンツ配信速度の向上を実現しています。また、コンテンツの圧縮設定についても Distribution ごとに操作可能であり、通信量削減によるレスポンスの通信時間削減も期待できます。

リクエスト元のデバイスに応じた表示がされているか

Web コンテンツを表示する際に、リクエストを行うユーザがどういった端末なのかを判定して適切なレイアウトのコンテンツを表示することはユーザ体験に直結します。 CloudFront ではリクエストヘッダでユーザ端末が PC なのかモバイル端末なのか、iOS なのか Andoroid なのかが判定できます。判定結果から適切なレイアウトでの表示を行わせることや、キャッシングが可能になります。

CloudFront のリクエストヘッダーの追加 - Amazon CloudFront

通信のセキュリティプロトコルが適切に設定されているか

検索エンジンの評価基準の中には HTTPS 対応しているか、という点があります。 CloudFront についてこの観点で考えると、CloudFront とビュワー間の通信を暗号化するプロトコル (TLS / SSL) 設定が該当し、幅広いプロトコルが設定可能となっています。

ビューワーと CloudFront との間でサポートされているプロトコルと暗号 - Amazon CloudFront

ドメイン構造がユーザにとってシンプルでわかりやすいものになっているか

Web サービスの利用者にとってドメイン構造がシンプルであることが望ましいとされています。悪い例としては、サービスや機能の追加によって、Web サイト上にこれまでのドメインとは異なるドメインに関連付いたエンドポイントが連結している場合などが悪い例として該当します。というのも、このようなドメイン構造はレスポンス速度の低下を招く可能性があるためです。こういったケースでは、CloudFront の Lambda@Edge や CloudFront Functions (CF2) によるリダイレクトを活用することで改善可能です。

Lambda@Edge | AWS

メンテナンス時にレスポンスの HTTP ステータスを適切に設定できているか

Web サービスの運営の中では障害や機能追加によるデプロイが発生する時がありますが、そういった場合に適切な HTTP ステータスコードとユーザ側に状況が伝わる一時的なページを用意しておくことが重要となります。 AWS サービスをベースに考えると Amazon S3 によるメンテナンス告知ページへリクエストをリダイレクトさせるケースが該当します。このような設定はユーザだけでなく、検索エンジンにも普段と異なる状態であることが一時的であることを伝えることに役立ち、Web サイトへのネガティブな評価を防ぐために有効です。

追加機能 CloudFront KeyValueStore の紹介

CloudFront といえば re:Invent2023 直前に、エッジコンピューティング機能である CF2 で利用可能な CloudFront KeyValueStore の発表がありました。 CF2 のコードから専用の Key / Value を取得して参照できる機能です。類似機能である Lambda@Edge からは取得できないという制約はありますが、関数内で URL 等のハードコーディングを避けた実装が可能となります。

SEO 戦略の観点では先に述べたようにリダイレクト管理が重要になりますが、CF2 によるリダイレクト実装がより柔軟な形で可能になるのでははないでしょうか。

CloudFront Functions 用の低レイテンシーデータストア、Amazon CloudFront KeyValueStore の紹介 | Amazon Web Services ブログ

おわりに

本稿では re:Invent2023 のセッション「NET209 | Optimize website performance for SEO with Amazon CloudFront」についてのレポートをまとめました。 CloudFront の各機能をふりかえる良い機会であったと同時に、新機能である CloudFront Functions KeyValueStore についての活用方法についても言及がありました。今回の対象は CloudFront でしたが、他サービスに対してもある特定の観点で着目して考えてみる、というのは新しい発見があって楽しいのではないかと思います。