1. はじめに：Site KitのSpeed計測で現状把握

当ブログはSynology NAS（DS725+）を使った自宅ホスティングで運営しています。ある日、Google Site KitのSpeedタブを確認したところ、気になる数値が出ていました。

• LCP（Largest Contentful Paint）：3.7秒　→　Needs improvement
• CLS（Cumulative Layout Shift）：0　→　Good
• TBT（Total Blocking Time）：50ms　→　Good

LCPはページの「メインコンテンツが表示されるまでの時間」を示す指標です。2.5秒以下がGood、4秒以上がPoorとされており、3.7秒は「要改善」ゾーン。SEOへの影響も気になるため、対策を講じることにしました。

2. LCP 3.7秒の原因を考える

まず疑ったのは画像サイズの問題です。WordPressのメディアライブラリをリスト表示で確認してみると、予想以上に大きなファイルが並んでいました。

• スクリーンショット（配色記事用）：1.7 MB
• ドラッグストア.png：1,023 KB
• トップページ刷新.png：995 KB

Canvaで書き出したアイキャッチ画像がほぼすべてPNG形式で、圧縮されていない状態でした。

なお、メディアライブラリに表示される「5サイズ圧縮します」という表示はWordPress標準機能によるもので、縦横ピクセル数の異なるコピーを5種類作るだけです。ファイルサイズ（容量）は軽くなっていません。今回初めてその仕組みを把握しました。

3. 対策①　EWWW Image Optimizerで画像をWebP化

WebPとは

WebPはGoogleが開発した次世代画像フォーマットです。JPGと比べてファイルサイズが25〜35%小さくなりながら、画質はほぼ同等。PNGのような透過にも対応しています。

Nginx環境（Synology）での設定ポイント

EWWW Image OptimizerのWebP設定で注意が必要なのが配信方法です。一般的なレンタルサーバーはApacheを使っており、表示されるリライトルールをそのまま使えます。しかしSynologyのWebサーバーはNginxのため、Apacheのルールは動作しません。

解決策は「JS WebP リライト」をONにすることです。JavaScriptで配信方法を切り替える方式のため、Nginx設定ファイルの編集が不要で、安全に適用できます。

設定完了後のチェックポイントとして、設定画面のテスト画像が赤い「PNG」表示から「WEBP」表示に変わればOKです。（JS WebPリライトをONにすると、このテスト表示自体が非表示になりますが正常な動作です）

一括最適化の実行

WebP変換のチェックを入れただけでは既存画像は変換されません。設定画面上部の「一括最適化」から全画像の変換を実行します。当ブログの場合、207枚・1004ファイルの処理に約50分かかりました。処理中のNAS CPU負荷は24%程度で、通常3%なので負荷はかかりますが問題のない範囲でした。

変換結果の一例です。

• スクリーンショット（配色記事）：1.7 MB → 869 KB（▼49%）
• トップページ刷新.png：995 KB → 439 KB（▼56%）
• カテゴリ再編.png：747 KB → 370 KB（▼50%）

PNGはWebP変換の効果が特に大きく、軒並み50%前後の削減を達成できました。

4. 対策②　WP Fastest Cacheの設定見直し

続いてWP Fastest Cacheの設定を見直しました。もともと基本的な設定はできていましたが、以下の2項目を追加しました。

• 新規投稿：ON（新記事公開時に関連キャッシュを削除）
• CSS統合：ON（CSSファイルのHTTPリクエスト数を削減）

なお、新規投稿のキャッシュ削除は「すべてのキャッシュを削除」ではなく「ホームページ・カテゴリー・タグのみ削除」を選択しています。過去記事のキャッシュまで全消しする必要はないためです。

また、WP Fastest CacheのLazy LoadはPremium（有料）機能でした。代わりにSWELL設定の高速化タブを確認したところ、「lazysizes.jsを使って遅延読み込みさせる」がすでにONになっており、こちらで対応済みでした。

5. 結果：3.7秒 → 1.5秒（59%改善）

対策後にSite KitのSpeedタブで「Run test again」を実行した結果です。作業直後は2.7秒でしたが、数時間後にキャッシュが蓄積された状態で再測定したところ、さらに大きく改善していました。

• LCP：3.7秒 → 1.5秒（▼59%改善）
• TBT：50ms → 50ms（Good維持）
• CLS：0のまま維持

Googleの基準でGoodは2.5秒以下です。1.5秒はGoodゾーンの中でも余裕のある数値で、当初の目標を大きく上回る結果となりました。

6. NASホスティングで1.5秒を達成できた理由

作業直後の2.7秒から1.5秒へのさらなる改善は、WP Fastest Cacheのキャッシュが蓄積されたことによるものです。

作業直後はキャッシュがまだ空の状態で測定されるため、本来の効果が出にくい状態でした。数時間経過してキャッシュが温まった状態での測定が実力値となります。

自宅NASホスティングはクラウドサーバーと比べてTTFB（サーバー最初の応答速度）にハンデがあると言われています。しかし今回の結果を見ると、画像のWebP化とキャッシュの組み合わせで、NASでも十分にGoodゾーンを達成できることが分かりました。CDN導入などの複雑な対応は不要でした。

7. まとめ

今回の作業で実感したのは、「まず計測してから対応する」ことの重要性です。何となく遅い気がすると思っていても、Site KitのSpeedタブで具体的な数値を把握したことで、対策の優先順位が明確になりました。

NAS自宅ホスティングで同じ課題を感じている方は、まずEWWW Image Optimizerの導入・WebP化から試してみることをおすすめします。設定は5分程度で完了し、効果は即座に測定できます。