【実録】自分で作ったWordPressサイトを静的HTML化したら、表示8.3秒→0.8秒・PageSpeed57点→100点になった全記録

「WordPressは重い」とよく言われます。けれど、定番の対策をやり切ったあとに何が残るのかは、あまり語られません。

この記事は、私自身がWordPressで制作した「繋がる花文字」様の公式サイトを、自分で「遅すぎる」と判断して作り直した記録です。測定はすべてGoogle公式のPageSpeed Insightsで、数字もスクリーンショットも実物をそのまま載せています。

まず結果から：WordPressの静的化で57点・8.3秒 → 100点・0.8秒

対象は、花文字作家「繋がる花文字」様の公式サイトです。作品ギャラリー、教室・体験レッスンの案内、オーダーの受付（LINE・Instagram）を備えています。

測定は、2026年8月20日に、PageSpeed Insightsの「携帯電話」で行いました。BeforeとAfterは同じ日に測っています。

TBTとCLSは、WordPress時代から良好でした。つまり、重かったのは「操作の反応」ではなく、画面が出るまでの待ち時間です。

なお、Afterの測定URLの末尾に「?v=9」が付いているのは、古いキャッシュを避けるために付けたものです。スマホでタップした瞬間に作品の画像がパッと開く、そんなサイトになりました。

なぜWordPressのサイトは遅かったのか：自分で作って、自分で「遅い」と思った話

定番の高速化を一通りやっても、57点だった

このサイトは最初、私がいつものやり方でWordPressで作りました。デザインも整い、納品できる状態まで仕上がっていた——はずでした。

ところが、スマホで実機テストを繰り返すうちに、どうしても拭えない違和感が出てきます。「……ちょっと表示がもたつく。遅いな」と。

測ってみると、冒頭の57点・8.3秒でした。手を抜いていたわけではありません。定番の高速化は、次のとおり一通りやっていました。

ここまでやったうえでの57点です。この記事でいちばん伝えたいのは、ここだと思っています。

決定打は、Google Fontsの読み込みだった

正直に言うと、当時の詳細な測定項目の記録は、もう手元に残っていません。サイトを作り替えてしまったため、冒頭の57点のスクリーンショットが、唯一残った当時の証拠です。

したがって、「フォントだけで何点分」という切り分けた数字は出せません。ただ、決定的に重さを生んでいた原因は、はっきり覚えています。Google Fonts（ウェブフォント）の読み込みでした。

デザインを整えるために、WordPressのテーマ経由でGoogle Fontsを外部から読み込んでいたのですが、これが想像以上の足かせでした。

• 日本語のウェブフォントは、とにかく重い：ひらがな・カタカナ・漢字と収録文字数が膨大なため、データは数百KB〜数MB規模になりがちです。
• 外部への追加リクエスト＋表示のブロック：別ドメインのGoogle Fontsを取りに行く通信が増えます。読み込み方によっては「フォントが届くまで文字が出ない」状態になり、ページ全体の表示開始そのものを遅らせます。

これに、次の2つが重なっていました。

• 作品を魅せるための“重さ”：花文字は作品写真が主役で、美しさを保つ高解像度画像は、そのまま読み込み負荷になります。
• WordPressという仕組みそのもの：アクセスのたびにデータベースと通信してページを組み立て、テーマやプラグインのCSS・JavaScriptを何本も読み込みます。

有料の高速テーマや画像圧縮プラグインでも、この「フォント＋仕組み」の重さまでは、構造的に取り切れませんでした。

静的化でやったこと：外部フォントをやめ、仕組みごと作り替える

小手先のチューニングではなく、仕組みそのものを変える判断をしました。「作品と想いをじっくり見せるサイト」という目的はそのままに、中身だけを静的HTMLに入れ替える方針です。

フォントは「外部読み込みをやめて、端末標準のフォントにした」

今回いちばん効いたと見ているのが、フォントの扱いです。Google Fontsの外部読み込みをやめ、ウェブフォントそのものを使わずに、端末にもともと入っているフォント（システムフォント）で表示する形にしました。

フォントの処理には、大きく4つの選択肢があります。今回選んだのは、いちばん下の方法です。

見出しは明朝体、本文はゴシック体を指定しています。iPhoneやMacならヒラギノ、Windowsなら游ゴシック・游明朝やメイリオが使われます。

その結果、フォントのダウンロードも、「文字が出るまで真っ白」の待ち時間も無くなりました。表示開始が一気に速くなったのは、この変更が大きかったと感じています。

そのほかに効いた4つの処理

フォント以外では、次の処理を入れました。

• 「毎回組み立てる」をやめた：データベースを使わず、完成済みのHTMLをそのまま配信する形へ。アクセスのたびの生成処理が消え、待ち時間の根本が無くなりました。
• 画像を軽く、かつ賢く：作品写真はWebPへ変換し、画面に入っていない画像は後から読み込みます（遅延読み込み）。ただし、最初に見える主役の画像は遅延させず、最優先で表示しています。
• 読み込みを止める要素を外した：表示を妨げていたCSS・JavaScriptを整理し、CSSはインライン化して「描画をブロックする待ち時間」を解消しました。
• 特別なサーバーには置いていない：配信は、いまも一般的なレンタルサーバーです。速さの差を生んだのは、サーバーではなく、中身の作り方でした。

あわせて読みたい

WordPressの静的化を代行で頼む費用と手順は？数十万円を抑えるコツと向き不向き

WordPressの静的化を代行で頼むと費用はいくらか、どんな手順かを発注者目線で整理。素材流用とAIで15万円前後（税抜・目安）から。引き継げるもの・作り直すもの、向く会社と向かない会社まで、案内として解説します。

ページを見る →

代わりに手放したもの、そして得られたもの

先にデメリットから書きます。ウェブフォントで書体を固定していたWordPress時代と違い、いまは端末に入っているフォントで表示されるため、同じページでもiPhoneとWindowsで書体の印象が少し違います。

一方で、得られたものもありました。

• 狙われる入口が減る：動くプログラムやデータベースが無いので、改ざんや乗っ取りの入口が小さくなります。
• 保守の手間が軽い：プラグインやテーマの更新に追われる運用から離れられます。

速さだけでなく、「持っていて気が楽なサイト」になったことも大きな収穫でした。

WordPressの静的化で学んだ「引き算」の考え方

Web制作をしていると、つい「新しい機能を足すこと」「高機能にすること」が進化だと思いがちです。でも今回、自分で作ったものに自分でダメ出しをして作り直す、という遠回りをして、強く感じたことがあります。

お客様のためになる仕事は、足し算ばかりではありません。目的に合わせて不要な複雑さを削ぎ落とす「引き算」こそ、一番身軽で、長く使えるサイトを作る近道でした。

あわせて読みたい

PageSpeedのスコアを改善するには｜57点→100点の実例と発注側の視点

PageSpeed Insightsのスコアが低い——何点を目指せばいいのか、どこを直すのか、誰に頼むのか。ラボとフィールドの違い、点数を追わない判断軸、そして静的化で57点→100点にした実例まで、発注側の目線で解説します。

ページを見る →