目次
相談するこんな方におすすめ
- microCMSの無料プランを使っている
- 記事が増えてきて転送量が気になり始めた
- 画像の圧縮作業を毎回やるのが面倒
この記事を読むと
Before：記事が増えるたびに20GB上限が近づいてきてヒヤヒヤ
After：コード1箇所の変更で、画像配信を自動で最適化できる状態に
課題：記事が増えて転送量が気になり始めた
Kumonoのコーポレートサイトは、Astro + microCMSで構築しています。
microCMSは無料のHobbyプランを使っていて、転送量の上限は月20GBです。
ブログ記事が40本くらいになったあたりで、管理画面を見たら月12GBほど使っていました。今後100記事くらいまで増やす予定なので、このペースだと上限が見えてくるなとなりました。
毎回画像をSquooshで圧縮してからアップロードする運用も考えましたが、正直めんどくさい。何かいい方法ないかなと調べて対処したので今後の備忘を兼ねてブログにします。
調査：何が転送量を食っているのか
microCMSの管理画面で「データ転送量」を見ると、日ごとの内訳が確認できます。
当社のサイトはAstro（静的サイト生成）で構築しているので、ビルド時にAPIからJSONを取得するだけです。画像はmicroCMSのCDNから直接配信される仕組みです。
つまり、転送量の大部分は「閲覧者が画像を取得する分」になります。
アップロード済みの画像を確認すると、4MBを超えるものもちらほら。Geminiで生成した画像とか、一眼で撮った写真をそのまま上げていたのが原因でした。
閲覧者が記事を開くたびに4MBの画像をダウンロードする。PVが増えればそれだけ転送量も増える。これではうれしい悲鳴というか、もう見ないで〜という本末転倒なジレンマが起こってしまいます。
解決策：画像APIを使えばいい
対策を調べていたら、microCMSの公式ヘルプに「データ転送量を節約する方法」というページがありました。
https://help.microcms.io/ja/knowledge/reduce-data-costs
そこで紹介されていたのが「画像API」。画像のURLにパラメータを付けるだけで、WebP変換やリサイズをしてくれる機能です。
たとえば、こんな感じです。
# 元画像（4MB）
https://images.microcms-assets.io/.../image.png
# パラメータ付き（数百KB）
https://images.microcms-assets.io/.../image.png?w=1024&fm=webp&q=80
ポイントは元画像を差し替えなくていいことです。
microCMS側で変換してから配信してくれるので、すでにアップロード済みの画像もそのままでOK。しかも転送量は「変換後のサイズ」で計算されます。
これを取り入れていきましょう。
実装：やったことと実際のコード
やることはシンプルで、画像URLにパラメータを付けるだけです。
<!-- Before -->
<img src={blog.eyecatch.url} />
<!-- After -->
<img src={`${blog.eyecatch.url}?w=1024&fm=webp&q=80`} />
当社では後から設定変更しやすいようユーティリティ関数にまとめて、用途別にサイズを分けました。
- アイキャッチ：w=1200
- サムネイル：w=640
- アイコン：w=160
リッチエディタ内の画像も、HTMLを置換する関数で対応しています。
結果と注意点
結果
4MBとか大きなサイズの画像が、配信時には多くても数百KB程度に。転送量は8割ほど削減できる見込みです。これで安心して記事作れます。
元画像はmicroCMSにそのまま残っているので、万が一画質に問題があればパラメータを外すだけで元に戻せます。
注意点
いくつか気をつけることがあります。
- SVGは画像API非対応：SVGファイルにパラメータを付けるとエラーになるので除外が必要
- 管理画面でのプレビュー：管理画面で画像を表示したときは元サイズで転送量がカウントされる
- 品質の確認：q=80で十分きれいですが、テキスト多めの図解などは実際に確認しておくと安心
まとめ
- microCMSの転送量は、閲覧者への画像配信で増える
- 画像APIを使えば、元画像を差し替えずに配信サイズを削減できる
- URLにパラメータを付けるだけなので、実装コストも低い
無料プランの上限が気になり始めたら、まずは画像APIを試してみるのがおすすめです。
対策して、それでもたくさん読まれるようになったらそんなありがたいことはないわけで、その時はプラン課金していきたいと思います。
