タグ
#ページ高速化
ページ高速化に関する記事を公開しています。
Cloudflare にデプロイしたのに反映されないのはブラウザのキャッシュ
デプロイ後にブラウザで開くと古いページのままで、ハードリロードすると新しくなる状態になりました。エッジは正しく更新されていて、原因はレスポンスに Cache-Control が 1 つも無かったことです。指示が無いとブラウザは Last-Modified から有効期限を推測するため、古い記事ほど長く保持されます。エッジ用のヘッダはエッジで取り除かれるので、ブラウザ向けの指示は別に出す必要がありました。
キャッシュを 30 日にしても D1 の読み取りが減らない原因
エッジキャッシュの保持時間を 5 分から 30 日へ延ばしても、データベースの読み取りが目標の 2 倍を超えたままでした。クエリ単位で分解すると 7 割がサイドバーの件数表示のための集計で、しかもサイドバーを消しても止まりませんでした。CMS のミドルウェアが全ページでターム一覧を先読みしていたためです。切り分けに使ったのは 1 起動あたりの読み取り行数と、クエリの実行回数がリクエスト数の何倍かという比率でした。
Cloudflare D1 の読み取りが 1 日 2,100 万行になった原因
1 つの Cloudflare アカウントで CMS のサイトを 8 つ運用していて、データベースの読み取りが 1 日 2,100 万行ありました。使用量は返した行数ではなくスキャンした行数で数えられるため、1 ページ表示するたびに数千行が乗っていたのが原因です。CMS を使っていてクエリを自分で書いていない状況で、キャッシュの保持時間とテンプレートの見直しだけで 91% 減らした記録です。1 リクエストあたりの単価が、1 アカウントに載せられるサイト数の上限を決めていました。
D1 の無駄なクエリを削ったらクエリ数が増えた原因
エッジ SSR（Cloudflare Workers + D1）ではレイテンシの支配項は CPU ではなく DB への往復回数です。明らかに無駄なクエリを削ったら本数が 19→22 に増えた——その裏にあるリクエスト内キャッシュの重複排除という機構と、推測で書き換えず「表示が変わっていないこと」を HTML のバイト一致で証明しながら最適化するウォーム A/B 計測の手順をまとめます。
JavaScriptを最適化してページ表示を高速化する
JavaScriptの主な最適化アプローチは、「圧縮」「ファイルのバンドル」「軽量ライブラリの使用」です。ライブラリを使う場合は「読み込む順番」にも気をつけなければいけません。ファイルサイズが大きくなりがちなので、上手く最適化しましょう。
CSS最適化はどこまで自動化されたか — 圧縮・不要CSS削除・インライン化の現在地
2026年現在、CSSの圧縮・不要CSSの削除・インライン化はどこまでビルドツール任せにできるのか。Bootstrap 5.3.8で実測した圧縮効果（gzip後の差は約9%）をもとに、手を動かす価値が残っている部分と、もう自動化されている部分を切り分けます。
Webページの表示速度はどうすれば上がるのか
Webページを高速化する方法はいくつもありますが、基本的には、スペックの良いWebサーバーにを使う、画像を遅延読み込みする、重いファイルの読み込みを最適化する、ページの構成を見直す、の4点に集約されます。それぞれどのように最適化すればいいのかシェアします。