Core Web Vitalsを改善するときに実際にweb制作会社がやったこと

「Core Web Vitalsのスコアが悪くて、なかなか検索順位が上がらない…」
「ページの読み込みが遅くて、離脱率ばかり上がってしまう…」

こうした悩みを抱えていませんか？本記事では、以下の内容を 実際の数値変化 とともにご紹介します。

• Core Web Vitalsとは何か（LCP・INP・CLSの基本）
• PageSpeed Insightsなどを使った計測方法
• クーシーが自社サイトで行った具体的な改善施策

「どこから手をつければいいのか分からない」
「制作会社に相談すべきか迷っている」

という方は、この記事を読みながら、自社サイトでもすぐに試せる改善のヒントを見つけてみてください。

Core Web Vitalsとは？

Core Web Vitals（コアウェブバイタル）とは、Webサイトのユーザー体験（UX）を数値で評価するための指標です。

Googleは、ユーザーがページを利用する際の快適さを測るうえで特に重要な要素として、次の3つをCore Web Vitalsとして定義しています。

簡単に言えば、「ページが速く表示されるか」「クリックしたらすぐ反応するか」「画面がガタガタしないか」という、ユーザーが当たり前に期待する3つの体験を数値化した指標です。

以下で、それぞれの指標をもう少し詳しく見ていきましょう。

LCP（Largest Contentful Paint）：ページの読み込み速度

LCPとは、ページ内で最も大きなコンテンツ（画像・動画・大きなテキストブロックなど）が表示されるまでの時間を測る指標です。主に、ファーストビュー（ページを開いたときに最初に見える範囲）内に表示されるコンテンツが対象になります。

たとえば、トップページのメインビジュアルや、記事のアイキャッチ画像がこれに該当することが多いです。

LCPの数値が悪いとどうなる？

ユーザーは「ページがなかなか表示されない…」と感じ、表示が完了する前にページを離脱してしまう可能性が高まります。そのため、LCPはユーザーの第一印象を左右する重要な指標として位置付けられています。

INP（Interaction to Next Paint）：操作への反応性

INPとは、ユーザーがアクション（クリック・タップ・キー入力など）を起こしたときに、ブラウザがその動作に応答するまでの待機時間を測る指標です。

※スクロールやマウスの移動などは対象外です。あくまで「操作に対する反応速度」が評価されます。

INPの数値が悪いとどうなる？

たとえば以下のようなケースが起きます。

• ハンバーガーメニュー（≡）をタップしても、すぐにメニューが開かない
• チェックボックスをクリックしても、チェックが入るまでにワンテンポ遅れる
• フォームの送信ボタンを押しても、画面が反応しない

こうした「もっさり感」はユーザーにストレスを与え、操作を途中でやめてしまう原因になります。INPはこのような操作の快適さを評価する指標であり、操作性の良し悪しを判断する重要な要素です。

INPについてさらに詳しく知りたい方は、以下の記事も参考にしてみてください。

Core Web Vitalsの新指標「INP」とは？FIDとの違いや計測方法を解説

CLS（Cumulative Layout Shift）：視覚的な安定性

CLSとは、ページの読み込み中にコンテンツが予期せずズレる（レイアウトが崩れる）度合いを測定する指標です。

CLSの数値が悪いとどうなる？

よくある例として、以下のようなケースがあります。

• 読み込み中は表示されていなかった広告バナーが、あとから挿入される
• その結果、コンテンツ全体が下に押し出されて、意図しないリンクやボタンをうっかりクリックしてしまう

「読もうとしていた文章が急にズレた！」
「違うボタンを押してしまった！」

という体験は、ユーザーにとって非常に不快です。Googleもこれを好ましくないUXとして評価するため、CLSを改善することは視覚的に安定した、信頼できるページ体験を提供するために欠かせません。

3つの指標のまとめ

これら3つの指標を総合的に改善していくことが、Core Web Vitals対策の基本です。Core Web Vitalsは単なる技術指標ではなく、ユーザー体験の質を高め、その結果としてSEO評価の向上を目指すための考え方だと認識しておきましょう。

Core Web VitalsはSEOに影響を与えるのか

結論から言うと、Core Web Vitalsは検索順位に影響する可能性があります。

Googleは、Core Web Vitalsを「ページエクスペリエンス」を評価するための指標として正式に採用しており、検索順位にも影響する可能性があることを公式に明言しています。

ただし、Core Web Vitalsは検索順位を単独で決める指標ではありません。

Googleの検索順位は、コンテンツの質・関連性・被リンクなど、数多くの要因で決まります。Core Web Vitalsは、その中の1つです。とはいえ、同じような品質・関連性を持つページが並んだ場合に、ユーザー体験の良し悪しが順位判断の”差分”を生む要素として機能することがあります。

実際の検索結果では、一定水準以上のコンテンツが多数存在するため、こうした差分が影響するケースは少なくありません。

SEO以外にもメリットがある

Core Web Vitalsの改善は、SEOのためだけの施策ではありません。表示速度や操作性、視覚的な安定性の向上は、以下のような効果にもつながります。

• 離脱率の低下（ページを最後まで見てもらいやすくなる）
• サイト内回遊性の向上（次のページも見てもらいやすくなる）
• コンバージョン率（CVR）の改善（お問い合わせや購入につながりやすくなる）

こうしたユーザー行動の改善は、結果として検索エンジンからの評価にも好影響を与える可能性があります。つまり、Core Web Vitalsは「これだけ対策すれば順位が上がる指標」ではないものの、検索結果で選ばれやすいページを作るための土台として、無視できない重要な要素だといえるでしょう。

Core Web Vitalsを計測してみよう

Core Web Vitalsを改善するには、まず現状の数値を計測することが第一歩です。

ここでは、代表的な3つのツールと、それぞれの特徴・使いどころを紹介します。

PageSpeed Insights ― まずはここから始めよう

PageSpeed Insightsは、Googleが提供する無料の表示速度計測・分析ツールです。

こちらのURLにアクセスし、計測したいページのURLを入力するだけで、Core Web Vitalsを含む各種指標を簡単に確認できます。

PageSpeed Insightsの最大の強み：フィールドデータとラボデータの両方を確認できること

PageSpeed Insightsには、2種類のデータが表示されます。

• フィールドデータ

  実際にサイトを訪問したユーザーの端末で収集されたデータ（＝本当のユーザー体験の数値）

• ラボデータ

  計測ツールがシミュレーションで算出したデータ（＝テスト環境での数値）

「自分のPCでは速く表示されるのに、ユーザーのスマホでは遅い」ということはよくあります。フィールドデータを見ることで、実際のユーザーが体験しているパフォーマンスを把握できるのがこのツールの大きな利点です。

また、スコアは 「数字と色（緑・黄・赤）」 で表示されるため、専門知識がない人にも一瞬で現状が伝わります。クライアントや上司に改善の成果を報告する際の「見せるためのツール」としても活用されています。

Lighthouse ― 公開前のチェックに最適

Lighthouseは、Chromeの開発者ツール（DevTools）から利用できる計測ツールです。PageSpeed Insightsと同様に、表示速度やCore Web Vitals関連の指標を測定できます。

使い方

1. Chromeで計測したいページを開く
2. 右クリック →「検証」（または F12キー）で開発者ツールを開く
3. 上部タブから「Lighthouse」を選択
4. 「Analyze page load」をクリックして計測開始

Lighthouseの最大の強み：公開前のページや、制作途中の開発環境でも計測できることです。

本番公開前に数値を確認し、あらかじめ改善しておきたい場合に適しています。

現場では「一回測って終わり」ではなく、「直しては測り、直しては測り」を10回、20回と繰り返すのが基本です。手軽にスコアを測れるため、開発中のパフォーマンスチェックにはかなり重宝されています。

Google Search Console ― サイト全体の傾向を把握する

Google Search Consoleは、Google検索におけるサイトのパフォーマンスを監視・管理・改善するための無料ツールです。

検索キーワードの状況やインデックスの状態、SEO上の問題点などを確認できます。利用には、サイトの登録と所有権の確認が必要です。

Google Search Consoleの最大の強み：「ページ単位」でなく「テンプレート単位」の問題を発見できること

Core Web Vitalsレポートでは、個別URLではなく、「特定のテンプレートやページタイプに共通する問題」を把握できるのが特徴です。

たとえば、数万ページある大規模サイトで1ページずつ計測するのは現実的ではありません。Google Search Consoleを使えば、「同じテンプレートを使っているページ群」がまとめて低評価になっていないかを見極めることができます。

計測した数値を改善するために実際にやってみたこと

Core Web Vitalsを計測すると、問題点が数値として見える化され、改善策が具体的に見えてきます。

ここからは、実際にクーシーが自社サイトで行った改善の事例をご紹介します。

以下は、実際にクーシーのWebサイトのトップページをPageSpeed Insightsで計測した結果をもとに、どのような改善策を実施したかの記録です。

改善の前に：プロが設定する「3つの前提条件」

計測結果を元に改善を始める際、私たちはまず以下の前提条件を整理します。ここを明確にしないまま進めると、「作業した割にスコアが変わらない」といった迷走に陥りやすいからです。

前提①「モバイル」の数値を優先する

PageSpeed Insightsでは「モバイル」と「デスクトップ」の2つの結果が出ますが、プロはモバイルの数値を最優先で見ます。

その理由は2つあります。

• Googleの評価軸が「モバイルファースト」であること

  Googleは、モバイル版のページを基準にサイトを評価しています。

• モバイル環境のほうがストレスを感じやすいこと

  スマホは通信速度や処理能力がPCより低いため、パフォーマンスの問題が顕著に表れます。

モバイルで合格点が出れば、デスクトップは自然とクリアしていることがほとんどです。

前提②「フィールドデータ」をゴールに据える

計測ツールには、2種類のデータがあります。

• ラボデータ

  その場でシミュレーションした計測値（テスト環境の数値）

• フィールドデータ

  実際のユーザー環境で収集された統計データ

本当に改善したいのは、Googleの評価対象となる「フィールドデータ」 です。ラボデータで100点を取ることが目的ではなく、「実際のユーザー体験が改善されているか」を最終的なゴールに設定します。

前提③ 改善の「費用対効果」を見極める

すべての項目を100点にする必要はありません。

たとえば、「数ミリ秒の改善のために、サイトのデザインや機能を大幅に削る」のは本末転倒です。ビジネス上の目的（お問い合わせ数や売上）を損なわず、「最小の工数で最大の効果が出る項目」から着手するのが前提になります。

具体的には、Webフォントの読み込みの見直しや画像の最適化など、比較的手軽に取り組めて効果の大きい施策から優先的に進めるのがおすすめです。

改善例01：LCP ― ファイルの読み込み速度を改善（SP 6.2秒→1.5秒、PC 2.2秒→1.1秒に短縮）

サイトの読み込み速度で真っ先に問題として出てくるのが、画像・動画・JavaScript・CSS・フォントなどのファイルの読み込み速度です。これらはLCPのスコアに直接関わってきます。LCPの理想値は2.5秒以内とされています。クーシーのWebサイトでは、リニューアル前と後で以下のように改善されました。

この数値を実現するために行った対策を、1つずつご紹介します。

① 画像を次世代フォーマット（WebP・AVIF）、動画をWebMに変換

WebPとは？
WebPは、Googleが開発した、Webサイトでの表示に特化した次世代の画像フォーマットです。従来のPNGやJPGよりも圧縮率が高く、それでいて高画質を保てるのが特徴です。PNGやJPGからWebPに変換しても、見た目の劣化はほぼありません。

AVIFとは？
AVIFは「AV1 Image File Format」の略で、2019年にリリースされた次世代画像フォーマットです。WebPよりもさらに高い圧縮率を持ち、WebPを超える存在になるのではと言われています。クーシーでもAVIF形式の画像を扱っています。

AVIFとWebP、どう使い分ける？
基本的には「両方を併用する」のが現在のWeb制作のベストですが、リソースに応じて以下の基準で選んでみてください。

AVIFが向いているケース

• 「とにかく表示速度」を最優先したい場合（画像枚数が多いECサイト、LCPの改善が急務なサイトなど）
• リッチなグラデーション画像が多い場合（WebPで発生しやすい「マッハバンド」＝色の階調の段差がAVIFでは抑えられます）

WebPが向いているケース

• 大量の画像をリアルタイムで変換・配信するなど、運用コスト・速度を優先したい場合（AVIFはサーバー負荷が高くなりすぎることがあります）
• 極端に古いOSやブラウザ（iOS 15以前など）にも対応する必要がある場合（WebPのほうがブラウザ対応が幅広い）

WebMとは？
画像だけでなく、動画にも高画質で圧縮率が高いフォーマットがあります。それがWebMです。2010年ごろからGoogleが提供しており、従来のMP4と比べてファイルサイズを大幅に削減できます。画像をWebP（またはAVIF）、動画をWebMに変換してサイトにアップし直すだけでも、LCPのスコアは改善します。

② Webフォントの削減とウェイトの整理

最近のWebサイトではWebフォント（GoogleフォントやAdobe Fontsなど）を使用するのが主流ですが、特に日本語フォントはテキストデータが非常に多いため、ファイル容量が重いという問題があります。

Webフォントの容量は、サイトの読み込み速度に大きく影響します。そのため、以下の対策が重要です。

• 使わないフォントは読み込まないようにする
• ウェイト（太さ）を必要最小限に絞る（※）

※たとえば「Regular」「Bold」「Light」など、ウェイトが3種類あれば、それだけでフォントファイルを3つ読み込んでいることになります。

また、デザインの段階でWebフォントの使用数を限定しておくなど、デザイナーとの事前のすり合わせも必要です。クーシーでは、Webフォントの使用は最大3個までというルールを設けています。デザイン上で3個以上使用されている場合は、個数を減らすのか、デザイン通りに進めるのか、作業者間ですり合わせを行っています。

③ CSS・JavaScriptの圧縮と不要コードの削除

ブラウザがページを表示するとき、HTMLだけでなく、CSSファイルやJavaScriptファイルも読み込みます。ファイルの数が多ければ多いほど、読み込みに時間がかかり、表示速度が遅くなります。

具体的な対策としては以下の通りです。

• CSSやJavaScriptのファイルを圧縮（ミニファイ）する：コード内の空白・改行・コメントなどを削除して容量を軽くする
• 複数のファイルを統合（バンドル）する：リクエスト数を減らして読み込み回数を減らす
• 不要なコードを削除する：使っていないCSSルールやJavaScript関数を取り除く

とにかくファイル容量を軽く、読み込ませるファイル数は少なくするのがポイントです。

④ 遅延読み込み（Lazy Load）でファーストビュー以外の画像を後読み

画像の読み込みを、ページの初回ロード時ではなく、ユーザーがスクロールして画像の近くまで来たタイミングで読み込むようにする手法です。これにより、最初に読み込むデータ量が減り、ページの表示速度が上がります。

実装方法

• imgタグに loading="lazy" を設定する（最もシンプルな方法）
• Lazy Load系のJavaScriptライブラリを使って実装する

注意点
ファーストビュー（ページを開いて最初に見える範囲）に表示される画像には遅延読み込みを設定してはいけません。ファーストビューの画像を遅延読み込みにすると、表示が遅れてCLSのスコアに悪影響が出る可能性があります。

⑤ ヒーローエリアを「最初は静的表示」→あとから動的化

多くのサイトでは、トップページのメインビジュアル（ヒーローエリア）にスライダーやアニメーションを使っています。しかし、初回からスライダーやアニメーション付きで表示すると、JavaScriptの初期化処理が画面の描画をブロックし、LCPが遅くなってしまいます。

この問題に対しては、以下のような対応が効果的です。

• 初回表示時は、1枚目のメインビジュアル画像を静的（動かない状態）で表示する
• ページの描画が完了した後に、スライダー（Swiperなど）を初期化する
• ローディング演出は維持したまま、スライダー化を後ろにずらす

これにより、画像自体の読み込みは変えずに「描画されるまでの待ち時間」だけを短縮でき、LCPの大幅な改善につながります。

⑥ クリティカルCSSを分離し、ヒーロー周りを先に描画

クリティカルCSSとは？

ページを開いた瞬間に最初に見える範囲（ファーストビュー）を描画するために、「最低限これだけは必要」というCSSのことです。

なぜこれが重要？CSSが大量にある場合、ブラウザはすべてのCSSの読み込みが完了するまで画面の描画を始めません。ファーストビューに関係ないCSS（ページ下部のスタイルやフッターの装飾など）の読み込みを待っている間、ユーザーは白い画面を見続けることになります。

対策

• ヒーローエリアに必要なCSSだけを、クリティカルCSSとしてHTMLの <head> に直接記述して先に読み込む
• それ以外のCSSは通常通り後から読み込む
• 初回表示時は装飾・アニメーションを抑え、後から有効化する

この対応により、「ヒーロー画像は表示されているのに、文字やレイアウトがなかなか出ない」といった状態を防ぐことができます。

⑦ 初期表示時は重い装飾・アニメーションを無効化

以下のようなCSSプロパティは、見た目は良いものの描画コスト（ブラウザの処理負荷）が高く、LCPを悪化させやすい要素です。

• backdrop-filter（背景のぼかし効果）
• box-shadow（ボックスの影）
• :has() を使った状態依存スタイル
• 複雑な疑似要素（背景画像を使ったものなど）

対策
初回表示時はこれらを無効化し、ヒーローエリアの描画が完了してから有効化するようにします。
これにより、「初回描画を軽くしつつ、見た目のクオリティも維持する」というバランスを取ることができます。

⑧ LCP画像の優先度を明示的に指定

LCP画像とは、そのページを開いたときに画面内で最も大きな面積を占めている画像のことです。多くの場合、トップページのメインビジュアルや記事のアイキャッチ画像がこれに該当します。

Googleは「この大きな画像が表示された瞬間」を、ユーザーが「ページが表示された」と感じる重要な指標として評価しています。

LCP対象の画像には、以下の属性を指定します。

• loading="eager"：この画像は遅延読み込みせず、すぐに読み込む
• fetchpriority="high"：この画像の読み込みを最優先にする
• width / height を明示：ブラウザが表示スペースを事前に確保できるようにする

<!-- LCP画像の記述例 -->
<img src="hero.webp" 
     loading="eager" 
     fetchpriority="high" 
     width="1200" 
     height="600" 
     alt="メインビジュアル">
        

これによりブラウザに「この画像を最優先で描画してほしい」と伝えることができ、LCPの安定化につながります。

改善例02：INP ― 操作の「もっさり感」を解消する

INPの理想値は200ミリ秒（0.2秒）以下が望ましいです。INPのスコアが改善されると、フォーム送信やボタンのクリック時のストレスが減り、結果としてCVR（コンバージョン率）の向上にもつながる可能性があります。

① 不要なJavaScriptを読み込まない・必要なものは遅延読み込み

ページ内で使われていないJavaScriptが読み込まれると、それだけでブラウザの処理が重くなり、ユーザー操作への応答が遅れます。

対策

• 不要なJavaScriptは遅延読み込みにし、必要な箇所だけ実行するように優先度をつける
• 使っていないアナリティクスタグ、広告スクリプト、古いウィジェットなどは思い切って削除する

② 画像やCSSの最適化

LCPの改善と共通する部分も多いですが、画像のフォーマット変換（WebP化）やCSSの圧縮・不要コード削除は、INPの改善にも効果があります。ファイルの読み込み速度が遅いと、ブラウザのリソースが読み込み処理に占有されてしまい、ユーザーの操作に対する応答まで遅延することがあるためです。

③ 重いアニメーションを減らし、操作時のモタつきを解消

複雑な動きが多いサイトでは、ユーザーが操作したときに反応が遅れることがあります。

対策

• なるべく軽いCSSアニメーションで実装する（JavaScriptによるアニメーションよりもブラウザ負荷が低い）
• 高度な表現が必要な場合はCanvas APIを使って、メインスレッドの負荷を抑える

④ 入力後にまとめてエラー判定し、入力中のストレスを減らす

フォームなどで、1文字入力するたびにリアルタイムでバリデーション（入力チェック）を走らせると、処理が頻繁に発生して動作が重くなります。

対策
バリデーションのタイミングを、「入力中」ではなく「入力欄からフォーカスが外れたとき（blur）」や「送信ボタンを押したとき」に変更し、処理の回数を減らして動作を軽くします。

⑤ 初期ロード時にすべてのJavaScriptを実行しない

スライダーやアニメーションなどのJavaScriptを、ページ読み込み直後にすべて実行すると、INPが悪化します。

対策

• 初回描画に不要なJSは requestAnimationFrame や setTimeout で実行タイミングを後ろにずらす
• 表示に必要な処理と、装飾用の処理を分離する

こうすることで、ユーザー操作に対する反応速度を改善できます。

改善例03：CLS ― 画面の「ガタつき」を抑える

CLSは読み込み速度ではなくレイアウトの安定性に関する指標なので、LCPやINPとはまた違ったアプローチが必要です。

① 画像・動画にwidth/heightを指定して高さズレを防ぐ

CLSスコア低下の原因の代表的なものが、画像の高さが確保されていないために、読み込み時に画面表示がガクッとズレる現象です。画像や動画が読み込まれる前に、ブラウザがその要素の表示スペースを確保できるよう、width と height 属性を必ず指定しましょう。

<!-- 良い例 -->
<img src="photo.webp" width="800" height="600" alt="写真">

<!-- 悪い例（widthとheightがない） -->
<img src="photo.webp" alt="写真">
        

この問題は、PageSpeed Insights上にもはっきりと注意が表示されるのでわかりやすいです。

② aspect-ratioでコンテンツの高さを担保する

画像や動画のアスペクト比（縦横比）をCSSで事前に指定しておくと、コンテンツが読み込まれる前でもブラウザが表示スペースを正しく確保できます。

/* CSSでアスペクト比を指定する例 */
img {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
}
        

aspect-ratio はiframeにも使えるので、YouTubeやGoogleマップなどの埋め込みコンテンツの表示崩れも改善できます。

③ Webフォントと代替フォントを似たものに揃えてCLS悪化を防ぐ

Webフォントの読み込みには時間がかかるため、読み込みが完了するまでの間は代替フォント（システムフォント）で表示されます。このとき、Webフォントとフォールバックフォントの文字サイズ（高さや幅）が大きく異なると、フォントが切り替わった瞬間にテキストの高さが変わり、レイアウトがズレます。

対策

• 使用するWebフォントと、font-family で指定する代替フォントを高さや幅が似たフォントにする
• スコア改善で一番理想的なのはWebフォントを使用しないことですが、デザイン上の理由でそうもいかない場合はこの方法が有効です

④ アニメーションはtransformで実装し、再描画によるレイアウト崩れを防ぐ

CSSアニメーションで要素を動かす際に、margin、top、bottom、left、right などのプロパティを変更すると、ブラウザがレイアウトの再計算（リフロー）を行います。このリフローが発生すると、ページ内の他の要素の位置もズレてしまい、CLSに悪影響を与えます。

対策

• アニメーションは transform（translateX、translateY、scale など）や opacity で実装する。これらはリフローを発生させないため、レイアウトに影響しません。
• JavaScriptでのアニメーションもロードに時間がかかり、描画が間に合わないことがあるため、なるべくCSSアニメーションで対応するのが望ましいです

/* 悪い例：marginを使ったアニメーション（リフローが発生） */
.element {
  transition: margin-top 0.3s;
}
.element:hover {
  margin-top: -10px;
}

/* 良い例：transformを使ったアニメーション（リフローが発生しない） */
.element {
  transition: transform 0.3s;
}
.element:hover {
  transform: translateY(-10px);
}
        

CLSの改善例は、以下の記事でもご紹介しています。

【CLS改善】CLSスコアがスライダーで低下！原因と改善方法

⑤ 初期表示とアニメーション状態を分離

特にアニメーションを実装している部分で、ページのロード時に高さが崩れることがあります。

対策
初期表示時に高さ・レイアウトをCSSで固定しておき、JavaScript実行後にのみアニメーションや状態変化を適用するようにします。

こうすることで、JavaScriptの読み込みが完了する前のタイミングで発生するレイアウト崩れを防ぎ、CLSの悪化を防止できます。

まとめ

Core Web Vitalsは、単なるSEOの技術指標ではなく、Webサイトの品質向上やビジネス成果を高めるための指標です。Googleの順位を上げる「だけ」のためのものではありません。

表示の速さ、操作感、安定した画面表示は、ユーザーにとっては「当たり前」になりつつありますが、実際の改善作業は細かなチューニングの積み重ねです。画像フォーマットの見直し、Webフォントの削減、CSS/JavaScriptの最適化、レイアウト崩れを防ぐ実装…こうした小さな工夫の連続が、結果としてCore Web Vitalsのスコアを改善し、何より「このサイト、使いやすいな」というユーザーの信頼につながります。

正直に言うと、Core Web Vitalsの数値を追うのは、時に「終わりのない微調整」のように感じることもあります。ブラウザの仕組みが変わったり、スマホの性能が変わったりするたびに、新しい課題が出てくるからです。

それでも、苦労してコードを書き換えたあとにスコアが改善されたときは、何度経験してもやっぱり嬉しいものです。それは単にテストでいい点を取ったからではなく、「これで、サイトを見てくれる人が少し快適になったはずだ」と思えるからです。

クーシーでは、自社サイトでのCore Web Vitals改善の知見をもとに、お客さまのWebサイトでもLCP・INP・CLSの改善や表示速度の最適化を支援しています。

「自社サイトのCore Web Vitalsを改善したい」「どの施策から始めればいいか相談したい」という方は、ぜひ一度お問い合わせください。サイトの現状を診断したうえで、具体的な改善プランをご提案いたします。

よくある質問

Q1. Core Web Vitalsを改善すると、必ず検索順位は上がりますか？

検索順位は、コンテンツの質や被リンクなど多くの要因で決まります。Core Web Vitalsはその中の1つですが、ユーザー体験の向上につながるため、中長期的にはSEOにも良い影響が期待できます。「Core Web Vitalsだけ改善すれば確実に順位が上がる」というものではないことを理解しておきましょう。

Q2. Core Web Vitalsのうち、まずどの指標から改善すべきですか？

多くのサイトでは、まずLCP（表示速度）とCLS（レイアウトの安定性）から着手するケースが多いです。画像の最適化やwidth/heightの指定など、比較的取り組みやすい施策が多いためです。INPはJavaScriptの最適化やアニメーションの見直しが必要になるため、計測結果を見ながら優先順位を決めるとよいでしょう。

Q3. 自分でできるCore Web Vitals改善と、制作会社に頼んだほうがよい部分の違いは？

自分でできることの例

• 画像のフォーマット変更（WebPへの変換）
• Lazy Loadの導入（CMSのプラグインで対応できることも多い）
• 不要なプラグインやウィジェットの削除

制作会社に頼んだほうがよいことの例

• CSS/JavaScriptの統合・削減・最適化
• Webフォントの設計と読み込み戦略の見直し
• レイアウト崩れを防ぐ実装（aspect-ratio、transform、クリティカルCSSなど）
• サイト全体のパフォーマンス設計

技術的な実装が絡む部分は、制作会社の知見があると安全かつ効率的に進められます。