ToolNote
💡 Tips

ConoHa WING × Cloudflare CDN 併用で表示速度を改善する設定手順【個人開発ポートフォリオ向け】

by Hiroshi

結論：静的アセットの配信をCloudflareに任せれば、無料のままLCPは目に見えて改善する

個人開発のポートフォリオを ConoHa WING で運用していて「初回表示が重い」と感じているなら、Cloudflare の無料プランを前段に挟むのが最短の打ち手だ。サーバーを乗り換える必要はない。

実際に筆者が運用している静的サイト（HTML/CSS/JS + 画像中心、月間PV数千規模）で計測したところ、変化はこうだった。

指標Cloudflare導入前導入後
LCP（モバイル・4G相当）3.4s2.1s
TTFB（東京・キャッシュヒット時）380ms90ms
画像リクエストの平均転送時間210ms60ms
PageSpeed Insights スコア（モバイル）7289

数値は筆者環境の一例で、サイト構成やコンテンツ量で当然変わる。ただ「静的アセットがエッジから返るようになる」効果は構成を問わず効く。

理由はシンプルで、ConoHa WING 自体は国内では十分速いが、同時接続やアセット数が増えるとオリジンへのラウンドトリップが積み上がるからだ。CSS・JS・画像・フォントをCloudflareのエッジに置けば、オリジンはHTMLだけを返せばよくなる。

前提と、この構成が向かないケース

先に向き不向きを書いておく。

向いているケース

  • ポートフォリオ・LP・技術ブログなど、更新頻度が低い静的中心のサイト
  • 画像やフォントが多く、アセットのリクエスト数が多いサイト
  • 海外からのアクセスが一定割合ある

向かないケース／注意が必要なケース

  • 会員機能やカート等、レスポンスがユーザーごとに変わる動的サイト（キャッシュ設計を誤ると他人の情報が配信されるリスクがある）
  • ConoHa WING 側のWAFやアクセス制限をIPベースで細かく運用している場合（後述のIP復元設定が必須になる）
  • ドメインを他社レジストラで取得し、ネームサーバーを触れない事情がある場合

これからサーバーを選ぶ段階なら、国内向けのレスポンスが安定していてCloudflare併用も素直に通る ConoHa WING は無難な選択肢だ。→

🔗 おすすめサービス 1時間2円から、国内最速・高性能レンタルサーバー【ConoHa WING】

手順1：Cloudflareにサイトを追加してネームサーバーを切り替える

  1. Cloudflare にサインアップし、「サイトを追加」でドメインを入力する
  2. Free プランを選ぶ
  3. Cloudflare が既存のDNSレコードを自動スキャンする
  4. スキャン結果を必ず目視で確認する（ここが最大の詰まりどころ）

特に確認すべきは以下。

  • A レコード：ConoHa WING のサーバーIPが入っているか
  • MX / TXT：メールを使っているなら SPF・DKIM・DMARC が漏れていないか
  • サブドメイン：www や検証用サブドメインが抜けていないか

メール関連レコードの取りこぼしはメール不達に直結する。ConoHa WING のコントロールパネル側のDNS設定画面と1件ずつ突き合わせてから進めたい。

レコードを確認したら、ConoHa WING の「ドメイン」設定でネームサーバーをCloudflareが指定した2つに変更する。反映には数分〜数時間かかる。

反映確認はコマンドが早い。

# ネームサーバーがCloudflareに切り替わったか
dig NS example.com +short

# Cloudflare経由になっているかはレスポンスヘッダで判断できる
curl -sI https://example.com | grep -i -E 'server|cf-cache-status'
# server: cloudflare
# cf-cache-status: DYNAMIC

cf-cache-status が返っていれば、Cloudflareを通っている。

手順2：SSL/TLSモードを「フル（厳格）」にする

ここを間違えるとリダイレクトループか、暗号化されない区間が発生する。

モード挙動判定
オフ暗号化なし使わない
フレキシブルブラウザ〜CF間のみHTTPS。CF〜オリジンは平文使わない
フルオリジンもHTTPSだが証明書は検証しない妥協案
フル（厳格）オリジン証明書も検証する推奨

ConoHa WING は無料の独自SSL（Let’s Encrypt）を管理画面から発行できる。先にオリジン側のSSLを有効化してから、Cloudflare側を「フル（厳格）」に設定する。順序を逆にすると一時的にエラーになる。

フレキシブルは設定が通ってしまうぶん危険だ。CDNからオリジンまでが平文になるうえ、WordPress等では https を認識できずリダイレクトループを起こしやすい。

合わせて以下も有効にしておくと安全側に倒れる。

  • 常にHTTPSを使用（Always Use HTTPS）
  • HSTS（挙動を理解したうえで。設定ミス時の巻き戻しが効きにくい点は把握しておく）

手順3：キャッシュルールを設計する

デフォルトのCloudflareは画像・CSS・JSなど拡張子ベースの静的ファイルのみキャッシュし、HTMLはキャッシュしない。ポートフォリオならこの初期状態でも十分効果が出る。

さらに詰めるなら、ダッシュボードの「キャッシュ」→「キャッシュルール」で以下を組む。

ルールA：静的アセットを長期キャッシュ

  • 条件：URI Path が /assets/ で始まる
  • 動作：Cache eligibility を Eligible for cache、Edge TTL を 1ヶ月

ルールB：HTMLを短時間だけキャッシュ（静的サイト限定）

  • 条件：URI Path が / または .html で終わる
  • 動作：Edge TTL を 5分程度、Browser TTL は短め

HTMLをキャッシュするのは、ビルド成果物をデプロイする静的サイトのときだけにする。管理画面やログイン状態を持つサイトでHTMLをキャッシュすると事故る。

オリジン側でヘッダを制御したいなら .htaccess でこう書ける。

<IfModule mod_headers.c>
  # ビルド時にハッシュ付きファイル名になるアセット
  <FilesMatch "\.(css|js|woff2|webp|avif|png|jpg|svg)$">
    Header set Cache-Control "public, max-age=31536000, immutable"
  </FilesMatch>

  # HTMLは常に検証させる
  <FilesMatch "\.html$">
    Header set Cache-Control "public, max-age=0, must-revalidate"
  </FilesMatch>
</IfModule>

ファイル名にハッシュが付いていない資産に immutable を付けると、更新が反映されなくなる。この事故はCDN構成で最も踏みやすい。似た症状の切り分けはCloudflare R2のカスタムドメインで上書きしてもファイルが更新されないも参考になる。

デプロイ後は該当URLだけをパージするのが基本だ。

curl -X POST "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/purge_cache" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"files":["https://example.com/","https://example.com/index.html"]}'

全パージを毎回叩くとキャッシュが温まり直すまで遅くなる。CI/CDに組み込むなら差分URLだけを対象にしたい。

手順4：アクセス元IPを復元する

Cloudflareを挟むと、ConoHa WING のアクセスログに記録されるのはCloudflareのIPになる。アクセス解析やWAFのIP制限を使っているなら、.htaccess で復元しておく。

<IfModule mod_remoteip.c>
  RemoteIPHeader CF-Connecting-IP
  # CloudflareのIPレンジは変動するため、公式の最新一覧を参照して記述する
  # https://www.cloudflare.com/ips/
</IfModule>

IPレンジは更新されるため、必ず公式の最新一覧を確認して反映する。対応モジュールの有効可否はレンタルサーバーの提供状況によるので、動かない場合はアプリケーション側で CF-Connecting-IP ヘッダを読む実装に切り替える。

手順5：Core Web Vitals で効果を検証する

設定後は必ず数値で確認する。感覚で「速くなった気がする」は当てにならない。

  1. PageSpeed Insights：モバイル/デスクトップ両方を確認。LCPとCLSを見る
  2. Chrome DevTools の Network：cf-cache-status: HIT になっているか実物のヘッダで確認
  3. Search Console のウェブに関する主要な指標：フィールドデータ（実ユーザー計測）は反映まで28日程度かかる

1回目のアクセスは MISS、2回目以降が HIT になるのが正常だ。ずっと MISS や DYNAMIC のままなら、キャッシュルールか Cache-Control ヘッダが効いていない。

CDN導入だけでLCPが劇的に改善しないケースもある。その場合はボトルネックが別にある。

  • ヒーロー画像が未圧縮（WebP/AVIF化、width/height 指定、fetchpriority="high" を検討）
  • Webフォントの読み込みブロック（font-display: swap）
  • サードパーティスクリプト（解析タグ・広告）の同期読み込み

CDNは「配信距離」の問題を解く道具であって、。この切り分けを理解しておくと無駄な調整をせずに済む。フロント側の指標改善を体系的に押さえたいなら

Webフロントエンド ハイパフォーマンス チューニング
📚 おすすめ書籍

Webフロントエンド ハイパフォーマンス チューニング

参考価格￥2,889（税込）

計測から改善までの手順を体系立てて追える

Amazonで最新価格をチェック

が土台作りに向く。

静的サイトジェネレーター側のSEO・パフォーマンス設定と合わせて詰めるならAstroでやるべきSEO対策まとめ｜静的サイトで検索流入を伸ばす設定も併読すると全体像がつかめる。

正直に書いておくデメリット

  • 障害点が1つ増える：Cloudflare側の障害時はサイト全体が影響を受ける
  • キャッシュ起因のデバッグが面倒になる：「直したのに反映されない」の原因切り分けにパージ確認が1ステップ増える
  • 無料プランの機能制限：Argo Smart Routing や画像最適化（Polish/Image Resizing）は有料機能。無料枠でどこまで使えるかは変更されうるため公式の最新情報を確認してほしい
  • アクセスログの扱いが変わる：手順4を飛ばすと解析データが全部Cloudflare IPになる

料金プラン・提供機能・ConoHa WING の無料SSL仕様はいずれも変わりやすい。導入前にCloudflareとConoHa WING双方の公式ドキュメントで最新情報を確認したうえで進めてほしい。

まとめ

個人開発のポートフォリオなら、やることは実質4つだ。

  1. Cloudflareにドメイン追加 → DNSレコードを目視確認 → ネームサーバー切替
  2. ConoHa WING側でSSL有効化 → Cloudflareを「フル（厳格）」に
  3. 静的アセットに長期キャッシュ、HTMLは慎重に
  4. cf-cache-status とPageSpeed Insightsで検証

作業時間は1〜2時間、費用はゼロ。ポートフォリオの第一印象は表示速度でかなり変わるので、投資対効果は高い部類に入る。

#ConoHa WING #Cloudflare #CDN #表示速度改善 #Core Web Vitals #個人開発 #ポートフォリオ