経緯
こちらの記事で当ブログをCloud CDNに連携させましたが、PageSpeed Insightsでパフォーマンス計測してみると残念な結果になっています。
※左がモバイルの測定結果、右がPCの測定結果です。
どうみてもCDN配信のパフォーマンスにはなっていません。
モバイルの結果は特に悲惨な事になっています。
ミスキャッシュが多発していると思うので、原因を調べてみることにしました。
Cloud CDNにキャッシュされるコンテンツ
Cloud CDNのマニュアルをみると下記条件を全て満す必要があるとのことです。
調べていて分かったのですが、GAEのエッジキャッシュも同様とのことでした。
- キャッシュ要件は基本的にRFC 7234に準拠
- Cloud CDN が有効になっているバックエンド サービスまたはバックエンド バケットから提供されているコンテンツであること
GET
リクエストに対するレスポンスであること- ステータスコードが
200
、203
、206
、300
、301
、302
、307
、410
のいずれかであること public
ディレクティブを含むCache-Control
ヘッダーがあることmax-age
またはs-maxage
ディレクティブを含むCache-Control
ヘッダー、あるいは将来のタイムスタンプを含むExpires
ヘッダーがあること有効な
Content-Length
、Content-Range
、Transfer-Encoding
ヘッダーのいずれかを含むことたとえば、レスポンスのサイズに正しく一致する
Content-Length
ヘッダーなど- 最大サイズ以下であること
Cloud CDNにキャッシュされないコンテンツ
キャッシュされる条件を満たしていないもの、または下記公式Doc記載内容に該当するものはキャッシュされないようです。
調査方法
CDNにキャッシュさせるためにapp.yaml
でdefault_expiration: "14d"
(検証のため2週間に期間設定)を定義しているのですが、キャッシュヒット/ミスキャッシュが混在している感じになっているぽい挙動をしています。
違いを調べるため以下GCP公式Docの内容に沿って詳細を調べてみました。
Cloud CDNへのリクエストログの確認
リクエストログをみる事で、
- Cloud CDN
- バックエンド
のどちらでレスポンスが返ってきているか確認することが出来ます。
※バックエンドにリクエストしているものがキャッシュミスとなっているコンテンツとなります。
Cloud CDNトラブルシューティング(curlコマンドでの結果確認)
前述のCloud CDNでキャッシュされる条件を満たすものが全て含まれている、またはいずれか欠落しているかを確認する手順になります。
調査結果
キャッシュヒットしているもの
キャッシュヒットしているもはCSSファイルやWebFontなどで、ごく少数の物しかCloud CDNにキャッシュされていないことが分かりました。
curlコマンドの出力結果は次の通りです。
curl -s -D - -o /dev/null https://yamavlog.com/wp-content/themes/cocoon-master/plugins/slick/fonts/slick.woff
HTTP/2 200
date: Tue, 01 Sep 2020 09:59:43 GMT
expires: Tue, 15 Sep 2020 09:59:43 GMT
etag: "E07SfA"
x-cloud-trace-context: 7d5b12d8669eb9b43ab7ced0cd0adcea
content-type: font/woff
server: Google Frontend
via: 1.1 google
content-length: 1380
age: 59050
cache-control: public, max-age=1209600
alt-svc: clear
キャッシュ要件を満たしています。
ミスキャッシュしているもの
Cloud CDNのリクエスログをみたところトップページや記事などのリクエストは全てミスキャッシュとなっており、バックエンド(GAE)から配信されていることが分かりました。
curlコマンドの出力結果は次の通りです。
curl -s -D - -o /dev/null https://yamavlog.com/
HTTP/2 200
content-type: text/html; charset=UTF-8
vary: Accept-Encoding
link: <https://yamavlog.com/wp-json/>; rel="https://api.w.org/"
link: <https://wp.me/bXhYl>; rel=shortlink
x-cloud-trace-context: 1bb4ae3c7af0a1be41171662310dbab5
date: Wed, 02 Sep 2020 02:05:43 GMT
server: Google Frontend
content-length: 580128
via: 1.1 google
alt-svc: clear
cache-controlヘッダ(またはExpires)が含まれていないことが原因な気がします。
AWS CloudFrontが設定されているサイトコンテンツのレスポンスを確認したところ、同様にCache-controlヘッダがなかったのですが、CDNからレスポンスが返ってきていました。
AWS CloudFrontは通過するコンテンツを全てキャッシュしてくれているっぽいです。
まとめ
Cloud CDNは通るコンテンツは条件を満たさないとキャッシュしないということが理解できました。
※マニュアル読めよというツッコミが聞こえてきそうですが、ご容赦を、、、
※マニュアルにも書いてましたが、将来的にCloudCDNのキャッシュ要件が緩和される可能性はあるとのこと
原因が分かったので、キャッシュ要件が緩めのCDNサービスを利用しようか検討してみようと思います。
追記1
外部CDNのCloud Flareを試しました(当ブログのシステム構成では使えませんでした、、、)
記事にしましたので、宜しければご覧下さい。
追記2
GCPのbeta版機能でリリースされた
- Chache Mode
- TTL orverrides
を利用することで、Cloud CDNのキャッシュ要件を大幅に緩和することができ、Cloud CDNで当ブログのコンテンツの大半が無事キャッシュできるようになりました。
詳細はこちらの記事をご覧下さい。