SECTION 01

なぜいま「表示速度」なのか｜2026年のSEO・AI検索の新常識

表示速度の話題は、2015年前後のモバイルフレンドリーアップデートの頃から何度も繰り返し登場してきました。「また表示速度の話か」と思われる経営者様も少なくないはずです。ただ、2026年のいま改めて真剣に向き合うべき理由は、過去とは質的に異なります。検索エンジンが順位判定に使うだけでなく、AI検索エンジンが「引用する記事を選ぶとき」にも速度を参照している可能性が高い、というのが最新のポイントです。

Googleが2021年から正式採用した Core Web Vitals

Core Web Vitals（コアウェブバイタル）は、Google が公式に定めたユーザー体験の指標です。2021年6月のページエクスペリエンスアップデートで検索順位の評価要因として正式採用され、以降5年間にわたって継続運用されています。当初の3指標は LCP・FID・CLS でしたが、2024年にFIDは INP（Interaction to Next Paint）に置き換えられ、反応性をより厳密に測る方向へ進化しました。2026年時点でも、この3指標で合格閾値を満たすことが、安定した検索順位を維持する基礎条件として扱われています。

AI Overviews 引用選定に速度が効くという観測

2024年以降、Google 検索では生成AIが検索結果の上部に回答を生成する「AI Overviews」が本格稼働しました。生成AIが回答を組み立てる際、参照元として複数のサイトから文章を引用しますが、引用候補として選ばれるサイトには「ページ速度が速い」サイトが優位になる傾向が観測されています。Googleはこれを明言していませんが、AIが回答を組み立てるためには短時間でページをクロールする必要があり、遅いサイトは機会そのものを失う構造と考えられます。検索結果に表示されるだけでなく、AIに引用されるためにも速度が必要、というのが2026年の新常識です。

スマホ3G環境では0.5秒の遅延で離脱率が大きく上昇

ページ速度と離脱率の関係は、Google 自身の公開資料でも繰り返し取り上げられています。モバイル環境でページ読み込みが1秒から3秒に遅れるだけで、離脱率は32%上昇するという分析が過去に発表されました。3秒から5秒になるとさらに上昇し、6秒以上のページでは訪問者の過半が離脱します。熊本県内のように車移動が多く、電波状況が不安定な郊外エリアからのアクセスでは、この影響はさらに強く現れます。「遅いサイト＝見られない＝集客にも引用にも不利」という構造が、いまの現実です。

Lighthouseで90点を取る最短ルートは、画像・JS・フォントの3つを最適化することです。

SECTION 02

Core Web Vitals の3指標を正しく理解する

Lighthouse の改善に取り組む前に、まず Core Web Vitals の3指標の意味と合格ラインを正確に押さえておく必要があります。この3つはそれぞれ異なる側面からページ体験を測定しており、改善手段も別物です。闇雲にスコアを上げようとしても効果は出ませんが、3指標のうちどれが不合格なのかを特定すれば、打ち手は自動的に絞れます。

LCP（Largest Contentful Paint）— 2.5秒以内が合格ライン

LCP は、ページを開いてから最も大きい要素（通常はヒーロー画像やメインのテキストブロック）が表示されるまでの時間です。訪問者が「このページ、ちゃんと開いた」と認識するタイミングの代理指標と考えてください。合格ラインは2.5秒以内、2.5秒〜4秒は要改善、4秒超は不合格です。LCPが遅い原因は、サーバー応答の遅延、画像の重さ、レンダリングを止めるJS/CSS、フォント読み込みの4つに集約されます。

INP（Interaction to Next Paint）— 200ms以内が合格ライン

INP は、ユーザーがボタンをタップしたりリンクをクリックしたりした瞬間から、次の描画が発生するまでの遅延を測る指標です。旧FIDの後継として2024年3月にCore Web Vitalsの正式指標に昇格しました。合格ラインは200ミリ秒以内、200〜500msは要改善、500ms超は不合格です。INPが悪いサイトは、重いJavaScriptの実行、長時間動くイベントハンドラ、サードパーティ広告タグの処理時間が主な原因です。

CLS（Cumulative Layout Shift）— 0.1以下が合格ライン

CLS は、ページ表示中にレイアウトがどれだけズレたかを測る指標です。「押そうとしたボタンが広告の読み込みでずれて別のリンクを押してしまった」という体験を数値化したもの、と考えると分かりやすいです。合格ラインは0.1以下、0.1〜0.25は要改善、0.25超は不合格です。CLSが悪いサイトは、画像やiframeにサイズ指定がない、Webフォント読み込み中に文字サイズが変わる、後から広告が挿入される、といった原因が典型的です。

Core Web Vitalsは、LCP・INP・CLSの3指標でユーザー体験を測定するGoogleの基準です。

重要なのは、3指標のうちどれか1つでも不合格だと「不合格ページ」として扱われる点です。LCPとCLSは合格でもINPが不合格なら、ページ全体の評価が落ちます。Lighthouse の Performance スコアを上げる前段階として、Search Console の Core Web Vitals レポートでどの指標が足を引っ張っているかを確認してください。打ち手の優先順位が自動的に決まります。

SECTION 03

PageSpeed Insights と Lighthouse の違いと使い分け

表示速度の測定ツールで最もよく使われるのが、PageSpeed Insights と Lighthouse です。どちらも Google が提供していて名前が似ているため混同されがちですが、両者は「測定方法」と「結果の性質」が異なります。この違いを押さえないと、数値に一喜一憂してしまい、正しい判断ができなくなります。

PageSpeed Insights はフィールドデータ＋ラボデータ

PageSpeed Insights（pagespeed.web.dev）は、Web上でURLを入力するだけで測定できるツールです。結果画面の上段に表示されるのが「フィールドデータ（実測値）」、下段が「ラボデータ（シミュレーション値）」になっています。フィールドデータは、Chrome User Experience Report（CrUX）という実ユーザーの計測データベースから取得され、過去28日間の実ユーザー体験を反映します。ラボデータはその場で仮想デバイスを使って計測した値で、1回きりのシミュレーション結果です。

Lighthouse はラボデータのみ（Chrome DevTools から起動可能）

Lighthouse は Chrome ブラウザに標準搭載されている監査ツールです。DevTools を開いて「Lighthouse」タブから実行すると、そのPCからその時点で接続した1回の計測結果が返ってきます。測定されるのはラボデータのみで、実ユーザーのデータは含まれません。開発者が手元で改善を繰り返すときの確認用には最適ですが、「実ユーザーにとって速いか」は PageSpeed Insights のフィールドデータを別途見る必要があります。

どちらを信じるか — フィールドデータ（実ユーザー）優先

ラボデータとフィールドデータに乖離がある場合、どちらを信じるべきか迷いますが、優先すべきは常にフィールドデータです。Googleが検索順位の判定に使うのもフィールドデータ側だからです。Lighthouse の点数が90点なのにフィールドデータが赤い、というケースは実在します。この場合、「開発者のPCでは速いが、実ユーザーの環境では遅い」という状態を意味し、原因としては地域別のCDN配信、モバイル端末の低スペック、3G回線での読み込みなどが考えられます。

スコアの見方と「改善できる項目」の読み方

PageSpeed Insights / Lighthouse のレポートには、スコア下部に「改善できる項目（Opportunities）」というセクションがあります。ここに並んでいる警告の上から順に対処するのが、Lighthouseで点数を上げる最短ルートです。各項目には「この改善で〇〇秒短縮できる」という推定値が付いており、その数値が大きい順に効果があります。細かい警告を全て潰そうとせず、上位3〜5件だけに集中するのが効率的です。

SECTION 04

画像最適化｜WebP/AVIF 変換と遅延読込

Lighthouse のスコアを押し下げる最大の原因は、8割以上のサイトで「画像」です。逆に言えば、画像まわりをきちんと最適化するだけで、70点台のサイトが90点に到達するケースは珍しくありません。本章では2026年時点で標準とされる画像最適化の4項目を、実装コードと一緒に整理します。

① WebP への変換（JPEG/PNGからの手順）

WebP は Google が2010年に開発した画像フォーマットで、JPEG と比べて同じ画質で約25〜35%ファイルサイズが小さくなります。2020年代に入ってからはほぼ全てのモダンブラウザ（Chrome・Firefox・Safari・Edge）で対応しており、互換性の心配はほぼなくなりました。既存の JPEG/PNG 画像は、Squoosh（squoosh.app）のようなWebツールや、ImageMagick のCLI、WordPressプラグイン（EWWW Image Optimizer など）で一括変換できます。

② AVIF への移行（2026年はAVIF優先）

AVIF は AV1 動画コーデックの静止画版で、2019年に登場した比較的新しいフォーマットです。JPEGと比べて約50%、WebPと比べても20〜30%サイズが小さくなるうえ、暗い部分のディテール再現性が高いという特徴があります。2026年時点ではChrome・Firefox・Safari（16以降）が対応済みで、実用レベルに達しました。新規に画像を配信する際は、まずAVIFで配信し、非対応ブラウザにはWebPへフォールバックするのが現代の標準構成です。

AVIFはWebPより圧縮率が高く、2026年時点の最適フォーマットです。

③ picture タグでのフォールバック実装

AVIF優先、WebPフォールバック、それも非対応ならJPEG——この3段構成を実装するには、HTML5 の picture 要素を使います。以下がCREVIAで標準として使っている実装パターンです。

picture 要素で並べる際は、必ず source を上から優先度の高い順に記述してください。ブラウザは最上段から対応可否を判定して、最初に対応している source を採用します。また、img 要素には width と height を必ず記述することで、画像読み込み前の領域確保ができ、CLSの改善にも直結します。

④ loading=”lazy” と decoding=”async” の正しい使い方

画像の遅延読込（lazy loading）は、スクロールで見えない位置にある画像を、表示範囲に入るまで読み込まない仕組みです。img タグに loading=”lazy” を追加するだけで、モダンブラウザがネイティブに対応します。ただし、ファーストビューに表示される画像には loading=”lazy” を付けてはいけません。付けると初回表示が逆に遅くなり、LCPが悪化します。ヒーロー画像・ロゴ・メインビジュアルなどのAbove The Fold画像は loading=”eager”（または属性なし）、それより下の画像は loading=”lazy” というのが正しい使い分けです。

併せて、decoding=”async” 属性も追加しておくと、画像のデコード処理がメインスレッドをブロックしなくなり、INPの改善にも寄与します。loading と decoding の2つをセットで付ける、というのがCREVIAで標準としている運用です。

⑤ 画像サイズの事前指定で CLS を 0 に近づける

CLSを0に近づける最大のコツは、全ての画像・iframe・埋め込みメディアに width と height を事前指定することです。指定しないと、ブラウザは画像の読み込みが始まるまで領域の大きさを確定できず、読み込み後にレイアウトがズレます。これがCLSを悪化させる最大の原因です。CSSでアスペクト比だけ指定するパターン（aspect-ratio プロパティ）も使えますが、確実なのはHTML属性でwidth/heightを直接書いておく方式です。

SECTION 05

JavaScript の最適化｜不要コードとレンダリングブロックを削る

画像の次にスコアを押し下げる犯人が JavaScript です。Lighthouse レポートの警告欄に「JavaScriptの実行時間の削減」「使用していないJavaScriptの削除」「メインスレッドの作業を最小限に抑える」といった項目が並んでいる場合、サイトに読み込まれているJSの量そのものが過剰になっています。本章ではJSまわりの最適化を5項目で整理します。

① Render Blocking JS の特定方法

Render Blocking（レンダリングブロック）とは、HTMLのパース中に同期的に実行され、ページ描画を遅らせる JavaScript・CSS を指します。Lighthouse のレポートの「レンダリングを妨げるリソースの除外」という警告で検出され、実行時間と短縮可能秒数が数値で表示されます。最初にこの警告の上位3件を洗い出し、それぞれが本当に頭で読み込む必要があるか判定するところから始めます。

② async / defer の使い分け

script タグに付けられる async と defer は、どちらも JavaScript の読み込みをブロックしないための属性ですが、実行タイミングが異なります。async は「ダウンロード完了と同時に実行」、defer は「HTMLパース完了後に順番通り実行」です。外部ライブラリや広告タグは async、自社で書いたスクリプトやDOM操作を含むものは defer、という使い分けが基本です。いずれも script タグに1単語追加するだけなので、優先的に対応しておく価値があります。

③ Tree Shaking と未使用JSの削除

Tree Shaking は、Webpack や Vite などのモジュールバンドラが持つ機能で、実際に使用されていないコードを自動的に削除する仕組みです。たとえば巨大なUIライブラリから1つのコンポーネントだけ使っている場合、Tree Shaking が効いていれば残り全体は出力されません。プロジェクト単位でビルド設定を見直すことで、JS のファイルサイズが半分以下になるケースも多くあります。

④ サードパーティスクリプトの遅延読込

Google Analytics、広告タグ、チャットウィジェット、SNSの埋め込み——こうしたサードパーティスクリプトは、各社ともに数十〜数百KBのJSを追加で読み込みます。これらは本来、ページ描画の直後に実行する必要はありません。window.onload 以降に遅延実行するか、Intersection Observer でスクロール到達時に読み込むことで、LCPとINPの両方が改善します。特に Google Tag Manager を経由している場合、各タグの「トリガータイミング」を見直すだけでも効果があります。

⑤ WordPressで「重いプラグイン」を見つける手順

WordPress の場合、遅さの原因はプラグインに潜んでいることが大半です。Query Monitor というプラグインをインストールすると、各プラグインが消費している実行時間とSQLクエリ数が可視化されます。5年以上使われていない、または公式更新が止まっているプラグインを3つ以上使っているサイトでは、これらを棚卸しして削除するだけでスコアが大きく改善することが多いです。

SECTION 06

CSS の最適化｜Critical CSS と Minify

CSSは、JavaScriptほどスコアへの影響は大きくありませんが、Above The Fold（スクロール前に見える範囲）の描画速度に直結する重要な要素です。本章ではCSSまわりの最適化を4項目で整理します。

① Above The Fold の Critical CSS をインライン化

Critical CSS とは、ファーストビューの描画に必要な最小限のCSSのことです。このCSSを head 内に直接 style タグとして書き込む（インライン化する）ことで、外部CSSファイルの読み込みを待たずにファーストビューを描画できます。全てのCSSをインライン化するとHTMLが膨らむので、Critical CSSだけをインライン化し、残りは別ファイルで非同期読み込みするのが定石です。

② 残りのCSSを preload で非同期読込

Critical CSS 以外の残りのCSSは、link rel=”preload” を使って非同期に読み込みます。具体的には link rel=”preload” as=”style” onload=”this.rel=’stylesheet'” という書き方で、「早めにダウンロードは始めるが、読み込み完了まで描画はブロックしない」という動作になります。この組み合わせで、LCPを1秒以上短縮できるケースが多く見られます。

③ Minify（余白削除）と Brotli 圧縮

Minify は、CSS・JS・HTML からスペース・改行・コメントなどの無駄な文字を削除する処理で、ファイルサイズが20〜30%縮みます。ビルド時に自動で走らせるのが一般的です。さらにサーバー側で Brotli 圧縮（または Gzip 圧縮）をかけることで、転送量がさらに70%前後削減されます。Cloudflare 無料プランでも Brotli は有効化できるので、ほぼ必須の設定と考えてください。

④ 未使用CSSのパージ

Lighthouse の警告で「使用していないCSS」と表示される項目は、PurgeCSS や UnoCSS といったツールで自動的に削除できます。Tailwind CSS のようなユーティリティファーストのフレームワークでは、未使用クラスを削除しないと生成CSSが数MBになることもあるため、ビルド設定でのパージ設定は必須です。既存のレガシーCSSでも、ページごとに使っていないセレクタを棚卸しすれば、数百KB削減できるケースは珍しくありません。

SECTION 07

フォント最適化｜サブセット化と preload

日本語サイトで見落とされがちなのがフォント最適化です。英語圏では数十KB程度のフォントファイルで済みますが、日本語フォントは漢字を含むため2MBを超えることも珍しくなく、単独でLCPを1秒以上悪化させる要因になります。

① 日本語フォントの巨大さ問題

Noto Sans JP のような日本語Webフォントは、全ての漢字・ひらがな・カタカナ・記号を含めるとファイルサイズが2MB以上になります。このまま読み込むと、フォント読み込み中は文字が表示されない FOIT（Flash of Invisible Text）が発生し、LCP/CLSの両方を悪化させます。対策は、実際に使う文字だけを抽出した「サブセットフォント」を作成することです。

② サブセット化で数十KBまで削減

サブセット化は、pyftsubset（Python製ツール）や Subset Font（Web UIツール）を使って、必要な文字コード範囲だけを切り出す処理です。企業サイトで使う文字は、常用漢字2,136字＋ひらがな＋カタカナ＋記号で大半をカバーできるため、サブセット化後のフォントは200KB前後まで削減できます。元のサイズから見れば90%以上の削減で、体感速度への寄与は非常に大きい項目です。

③ font-display: swap で FOIT を防ぐ

CSSの @font-face ルール内で font-display: swap を指定することで、フォント読み込み完了前でも、システムフォントで仮表示を行うようになります。読み込みが完了した時点で指定フォントに切り替わる挙動です。FOIT（文字が見えない時間）が FOUT（Flash of Unstyled Text：装飾なしで一瞬表示）に変わりますが、ユーザー体験としてはFOUTの方が圧倒的に優位で、Lighthouseの点数にも反映されます。

④ preload で Above The Fold のフォントを先読み

link rel=”preload” as=”font” を使って、ファーストビューで使うフォントファイルを先読み指示しておくと、HTMLのパースと並行してフォントのダウンロードが進みます。ヒーロー画像のキャッチコピーが太字ゴシックの場合など、タイポグラフィが強いデザインでは、この1行の追加だけでLCPが数百ミリ秒改善します。crossorigin=”anonymous” 属性を付け忘れると二重ダウンロードになるので、そこは注意が必要です。

SECTION 08

CDN とキャッシュ戦略｜Cloudflare 無料プランで十分か

ここまでの改善でスコアが90点に届かないサイトは、サーバー応答速度（TTFB：Time to First Byte）そのものが遅い可能性が高いです。対策は2つ、CDN導入と適切なキャッシュ戦略。本章ではCloudflareの無料プランでどこまでカバーできるかを含めて整理します。

① CDNの基本（世界中のエッジサーバーから配信）

CDN（Content Delivery Network）は、世界中に分散配置されたエッジサーバーからコンテンツを配信する仕組みです。オリジンサーバー（WordPressが動いているサーバー本体）から直接配信するのではなく、訪問者の地理的に近いエッジから画像・CSS・JSを配信することで、応答時間を短縮します。熊本のサイトでも、関東や関西からのアクセスに対して数十〜数百ミリ秒単位で体感速度が改善します。

② Cloudflare 無料プランの機能と限界

Cloudflare の無料プランは、2026年時点で「帯域無制限」「DDoS対策」「SSL証明書」「Brotli圧縮」「HTTP/3対応」「自動Minify」など、有料プランに匹敵する機能が利用できます。中小企業サイトであれば、無料プランで9割の機能ニーズが満たせると考えて差し支えありません。有料プラン（Pro：月額20ドル〜）が必要になるのは、画像の自動WebP変換、より高度なセキュリティ、画像リサイズAPIといった追加機能を使いたい場合です。

③ Brotli圧縮・HTTP/3・自動Minifyの有効化手順

Cloudflareでサイトを登録した後、必ず有効化しておきたいのは、Speed 設定内の「自動Minify（HTML/CSS/JS）」「Brotli 圧縮」、Network設定内の「HTTP/3（QUIC）」の3つです。これらはチェックボックスを入れるだけで反映され、設定直後から効果が出ます。サイトの挙動に副作用が出るリスクは限定的で、万が一問題が起きても即座にオフにできます。

④ ブラウザキャッシュの適切な期限設定（Cache-Control）

ブラウザキャッシュは、一度ダウンロードした画像・CSS・JSを、次回アクセス時にローカル保存分から読み込ませる仕組みです。Cache-Control HTTPヘッダで期限を指定します。2026年の標準として、画像は1年（max-age=31536000）、CSS/JSはファイル名にハッシュを付けた上で1年、HTMLは無キャッシュまたは短期（1時間程度）というのが安全な設定です。Cloudflareの「Browser Cache TTL」設定で一括管理できます。

SECTION 09

WordPressサイトで90点を達成する最短ルート

CREVIAでご支援する熊本の中小企業様のサイトは、ほぼ全てWordPressで構築されています。そのためWordPress特有の最速ルートを整理しておきます。テーマ選定・必須プラグイン3つ・避けるべきプラグインの3点を押さえれば、多くの案件で70点→90点到達が可能です。

① テーマ選定（軽量テーマを選ぶ or 自社テーマを最適化）

WordPressテーマは、表示速度の基礎体力を決めます。GeneratePress、Astra、Blocksy などの軽量テーマは、標準状態で Lighthouse 90点前後のスコアを叩き出します。一方、日本語有料テーマや多機能テーマの中には、有効化しただけで30点台まで落ちる重いものも存在します。テーマの選定段階で失敗すると、あとから個別最適化で取り戻すのは困難です。

② 必須プラグイン3つ

WordPressで90点を目指す場合、最低限入れておきたいプラグインは以下の3つです。個別機能を持つプラグインをバラバラに入れるよりも、この3つに集約した方が、プラグイン同士の競合も起きにくくなります。

1. 1

   WebP自動変換プラグイン（EWWW Image Optimizer 等）

   既存画像を一括でWebP/AVIFに変換し、新規アップロード画像も自動で最適化します。無料プランで基本機能は十分です。画像最適化は最も投資対効果の高い領域なので、最初に入れるプラグインはこれが定番です。

2. 2

   キャッシュ系（WP Rocket または W3 Total Cache）

   ページキャッシュ、ブラウザキャッシュ、CSSインライン化、JS遅延読込を一元管理します。WP Rocketは有料（年49ドル）ですが初期設定が容易、W3 Total Cacheは無料ですが設定項目が多く初学者にはやや難しい傾向があります。

3. 3

   Cloudflare連携プラグイン（Cloudflare公式）

   WordPressとCloudflareを連携し、記事更新時にキャッシュを自動パージする機能を提供します。Cloudflareアカウント作成後、APIキーを貼り付けるだけで動作。更新してもキャッシュが古いままで「反映されない問題」を防げます。

③ 避けるべきプラグイン（多機能ビルダー系の罠）

逆に、表示速度を重視するサイトで積極的に避けたほうがよいのが、多機能ページビルダー系プラグインです。Elementor、Divi、WPBakery Page Builder などは編集の直感性と引き換えに、大量のJS/CSSを出力するため、Lighthouse の点数を30〜50点押し下げる要因になります。どうしても使う場合は、出力HTMLを最小化する設定と、不要モジュールの無効化を必ず行ってください。

④ 実例：70点→92点に改善したケース（CREVIA支援先・実データ）

CREVIAで運用支援させていただいている熊本市内のある小売店様のサイトは、ご相談時点でモバイルのLighthouseスコアが71点でした。主な原因は、ヒーロー画像がJPEG約1.2MBで配信されていたこと、多機能ビルダーが出力するCSSが500KB超だったこと、Google Analytics・タグマネージャ・広告タグがheadで同期読み込みされていたことでした。改善内容は、ヒーロー画像をAVIF+WebPに変換（1.2MB→120KB）、ビルダー由来の未使用CSSをパージ、サードパーティタグを defer 化、Cloudflare 無料プラン導入の4点のみ。結果、モバイルのLighthouseスコアは92点まで到達し、PageSpeed Insightsのフィールドデータ（CrUX）でもCore Web Vitalsが3指標全て合格になりました。作業工数は延べ15時間程度で、費用対効果の高い改善事例になりました。

SECTION 10

熊本の中小企業にとっての「速度 × 集客」の現実

Core Web Vitals と Lighthouse の話は、一見すると技術寄りの議論に見えます。ただ、熊本の中小企業様の経営現場に落とし込むと、速度改善は「スマホで店を選ぶ時代の、選ばれるか否かの分岐点」そのものです。本章では、熊本ローカルの文脈で速度の意味を整理します。

TSMC経済圏で急増するモバイル検索

2024年以降、熊本県菊陽町のTSMC半導体工場進出に伴って、菊陽町・合志市・大津町エリアには県外・海外から転入される方が増えています。こうした新しい住民層は、地元情報を得る手段の9割以上がスマホ検索です。「菊陽町 ランチ」「合志市 美容室」といった検索で上位表示されるためにも、そして検索結果からクリックされた後に離脱されないためにも、モバイル環境でのページ速度が集客の入り口条件になっています。

車社会・電波状況の悪い地域での速度体感

熊本は車社会で、お客様の多くは「移動中または到着直前の駐車場でスマホを見る」行動パターンを持ちます。このとき、電波状況は4G〜5Gが混在し、場所によっては3G相当の体感速度まで落ちます。都市部の光回線前提で設計されたサイトは、こうした電波状況では極端に遅く感じられ、お客様は即座に競合サイトへ流れます。速度改善は、都市圏以上に熊本のような地方で効いてくる投資です。

くまもと型応援補助金・IT導入補助金の活用余地

ホームページの改修・リニューアルにかかる費用は、くまもと型応援補助金や、国のIT導入補助金、小規模事業者持続化補助金の対象になるケースがあります。補助金は申請タイミングと書類要件があるため、「使えるかどうか」は案件ごとに判断が必要です。CREVIAでは、補助金活用を前提としたお見積もりや、申請書類のご用意にご要望に応じて対応しています。

制作会社選びで「速度を保証する会社」を選ぶ重要性

熊本にもホームページ制作を手がける会社は多数ありますが、納品時点でLighthouse 90点を数値で保証する制作会社は多くありません。見た目のデザイン性と表示速度はトレードオフではなく、どちらも両立できる設計技術があれば達成可能です。制作会社を選ぶ際は、初回打ち合わせの段階で「Lighthouseのスコアを何点以上で納品するか」を明示してくれるかどうかをチェックしてみてください。曖昧な回答しか返ってこない会社は、速度を重視していない可能性が高いです。CREVIAでは、ホームページ制作の納品時に Lighthouse 90点以上を目安として保証する方針を採っています。

SECTION 11

よくある質問

SUMMARY

まとめ｜速度は運用ではなく設計で決まる

本記事では、Core Web Vitals を改善し Lighthouse で90点以上を達成するための14の実装手順を整理しました。要点は3つに集約されます。

1. 1

   画像・JS・フォントの3点集中

   AVIF/WebP変換、不要JSの除去、フォントサブセット化——この3点で大半のサイトは90点に到達します。

2. 2

   CDN無料プラン＋適切なキャッシュ

   Cloudflare 無料プランで Brotli・HTTP/3・自動Minifyを有効化すれば、TTFBまで含めて改善します。

3. 3

   速度は設計段階で決まる

   重いテーマ・ビルダー・プラグインを選んだ時点で、後から90点に持ち上げるのは困難。最初の設計判断が全てを決めます。

表示速度の改善は、一度取り組めば終わりという作業ではありません。新規コンテンツを追加するたびに、プラグインを更新するたびに、数値が変動します。PageSpeed Insights を月次でチェックし、劣化の兆候を早期に捉える運用を定着させることが、長期的に安定した検索順位とAI引用機会を守る最善策です。

自社サイトのスコア診断から改善、その後の継続運用まで、CREVIAがご要望に応じて伴走可能です。Lighthouse 90点を保証するホームページ制作・リニューアル、または既存サイトの速度改善のご相談は、お気軽にお問い合わせください。