| 対象サイト | 株式会社EME |
| 対象URL | https://www.eme.co.jp/ |
| 分析日 | 2026年4月11日 |
| 分析カテゴリ | 表示速度改善 ／ Core Web Vitals |
| 指標 | 概要 | Good（目標値） | Needs Improvement | Poor |
|---|---|---|---|---|
| LCP | 最大コンテンツ描画（読み込み速度） | ≤ 2.5秒 | 2.5〜4.0秒 | > 4.0秒 |
| INP | インタラクションの応答速度 | ≤ 200ms | 200〜500ms | > 500ms |
| CLS | 累積レイアウトシフト（視覚安定性） | ≤ 0.1 | 0.1〜0.25 | > 0.25 |
| TTFB | サーバー応答速度（補助指標） | ≤ 800ms | 800ms〜1.8秒 | > 1.8秒 |
| FCP | 初回コンテンツ描画（補助指標） | ≤ 1.8秒 | 1.8〜3.0秒 | > 3.0秒 |
LCP（Largest Contentful Paint）の対象要素はファーストビューの最大コンテンツ（通常はヒーロー画像またはH1テキスト）となる。本サイトではヒーローセクションに複数の画像（バナー・製品写真等）が使われており、これらがPNG形式で配信されている可能性が高い（/wp/wp-content/uploads/ パス配下の画像）。PNG画像は非可逆圧縮に対応しておらず、WebPと比較してファイルサイズが30〜50%大きくなる傾向があり、LCP悪化の主要因となる。
Googleの目標値はLCP ≤ 2.5秒。WordPressサイトで画像最適化未対応の場合、モバイルで4秒を超えるケースも多い。LCPはCore Web VitalsのうちSEOランキングへの影響が最も直接的な指標。
ページ内の画像（製品写真・業界アイコン・事例写真）のHTMLソースにwidth/height属性が明示されていない場合、画像読み込み完了後にレイアウトが突然ズレる「レイアウトシフト」が発生しCLSスコアを悪化させる。また、スライダー・カルーセル形式のコンテンツはアニメーション中にレイアウトシフトを引き起こしやすく、特にモバイルでのCLS悪化要因となる。
CLS目標値は ≤ 0.1。画像にwidth/height属性を付与することでブラウザが事前に表示領域を確保でき、レイアウトシフトを防止できる。これはコード変更のみで対応可能な低コスト施策。
WordPressは標準でjQuery・複数のCSSファイル・プラグイン由来のJSを<head>内で読み込むため、レンダリングブロックが発生しFCP（初回コンテンツ描画）を遅延させる。本サイトは/wp/サブディレクトリ構成のため、標準のWordPress最適化設定が適用されていない可能性がある。また、サーバー側のページキャッシュが設定されていない場合、WordPressのPHP処理がリクエストのたびに実行されTTFBが高くなる（目標 ≤ 800ms）。
TTFBが800msを超えるとFCP・LCP両方に連鎖して悪影響を及ぼす。サーバーサイドキャッシュの導入がすべての速度指標改善の基礎となる。
ナビゲーション（ハンバーガーメニュー・メガメニュー）やアニメーション・スライダーがJavaScriptで動作しており、メインスレッドの処理負荷が高い場合にINP（インタラクション応答速度）が悪化する。特にモバイル端末はCPU性能が低く、未最適化のJSがあるとタップ→反応まで500ms以上かかるケースが発生する。INPはFIDに代わり2024年3月からCore Web Vitalsの正式指標となり、SEOランキングに直接影響する。
使用していないJSの遅延読み込み（defer/async属性）と、不要なプラグインの削減がINP改善の基本対策。
ファーストビューの最大画像（LCP要素となるヒーロー画像・バナー）が <link rel="preload"> で事前読み込み指定されていない場合、ブラウザがHTMLを解析してから画像のダウンロードを開始するため、LCPが大幅に遅延する。特に本サイトのようなWordPressテーマでは、ヒーロー画像がCSSのbackground-imageで設定されているケースもあり、その場合ブラウザが最後に発見する画像リソースとなりLCPがさらに悪化する。
<head>内に <link rel="preload" as="image" href="ヒーロー画像URL"> を追加するだけでLCPを0.5〜1秒短縮できる場合がある。実装コストが低く効果が大きい施策の一つ。
画像・CSS・JSのURLがすべてwww.eme.co.jpドメインから直接配信されており、CDN（Content Delivery Network）経由での配信が確認できない。CDNが未使用の場合、東京以外のリージョン（例：大阪・名古屋・地方）からのアクセスでTTFBが増加し、グローバルユーザーには顕著な遅延が生じる。
WordPressに対応したCDNとしてはCloudflare（無料プランあり）が最もコストパフォーマンスが高く、設定変更のみで静的アセットのキャッシュ配信が可能。まずCDNなしで他の施策を実施し、それでもTTFBが高い場合に検討する。
| No. | 対象指標 | 改善アクション | 期待効果 | 優先度 |
|---|---|---|---|---|
| 1 | TTFB・全指標 | サーバーサイドキャッシュを導入する。WordPressプラグイン「WP Rocket」（有料・最も効果的）または「W3 Total Cache」「LiteSpeed Cache」（無料）を導入し、ページキャッシュ・ブラウザキャッシュ・Gzip/Brotli圧縮を一括設定する。これにより毎回のPHP処理をスキップしTTFBを大幅に短縮できる。 目標：TTFB ≤ 800ms |
TTFB・FCP・LCPすべての指標が連動して改善。最も費用対効果の高い施策 | 高 |
| 2 | LCP | 全画像をWebP形式に変換して配信する。WordPressプラグイン「Imagify」「ShortPixel」「EWWW Image Optimizer」のいずれかを導入し、既存PNG/JPEGをWebPに一括変換する（ファイルサイズ約30〜50%削減）。<picture>要素またはsrcset属性でWebP非対応ブラウザへのJPEGフォールバックも合わせて設定する。 目標：LCP ≤ 2.5秒 |
LCPの大幅改善。ページ全体の読み込み速度向上 | 高 |
| 3 | CLS | 全<img>タグにwidth・height属性を明示的に付与する。WordPressはバージョン5.5以降、メディアライブラリからの画像挿入時にwidth/heightを自動付与するが、テーマ・カスタムコードで追加した画像は手動設定が必要。特にファーストビュー・製品セクション・業界アイコンの画像サイズを優先的に設定する。 目標：CLS ≤ 0.1 |
CLSの改善。ページロード中の視覚的安定性向上 | 高 |
| 4 | LCP | LCP要素（ヒーロー画像）のpreloadを<head>内に追加する。<link rel="preload" as="image" href="ヒーロー画像のURL" fetchpriority="high">
LCP画像への loading="lazy" 属性がある場合は削除し、loading="eager"（または属性なし）に変更する。ファーストビュー以外の画像にはloading="lazy"を適用して帯域幅を節約する。 |
ヒーロー画像の発見・読み込みタイミングが早まりLCPが0.5〜1秒改善 | 中 |
| 5 | INP・FCP | レンダリングブロックJavaScriptを最適化する。①不要なプラグインの無効化・削除 ②必須でないJSスクリプトにdefer属性を付与 ③jQueryを軽量代替またはネイティブJSへ段階的に移行 ④WP RocketまたはW3 Total Cacheの「JS遅延読み込み」機能を活用する。Google Tag Managerを使用している場合はタグの整理・不要タグ削除も効果的。 | FCP・INPの改善。モバイルでのインタラクション応答速度向上 | 中 |
| 6 | TTFB・全指標 | Cloudflare（無料プラン）を導入してCDN配信と追加キャッシュを設定する。NameサーバーをCloudflareに変更するだけで、画像・CSS・JSの静的アセットがエッジサーバーから配信され、国内全域からのTTFBが短縮される。Cloudflare無料プランでもDDoS保護・HTTPSの自動対応・圧縮も付帯する。 | 全国・全デバイスからのTTFB短縮。サーバー負荷軽減 | 低 |