| 対象サイト | 株式会社EME |
| 対象URL | https://www.eme.co.jp/ |
| 分析日 | 2026年4月11日 |
| 分析カテゴリ | 表示速度改善 ／ 画像・アセット最適化 |
| リソース種別 | 確認された形式・状況 | 最適化状況 |
|---|---|---|
| ナビゲーション画像 | hamburger.png（ハンバーガーメニューアイコン） | 要改善 |
| 製品画像 | PNG形式（vmini330_C2_130x138.png 等） | 要改善 |
| 事例・コンテンツ画像 | PNG形式（about01-3.png、example01.png 等） | 要改善 |
| 業界アイコン | PNG形式（1.png〜9.png）9点 | 要改善 |
| ロゴ | SVG形式（ft_logo.svg） | 良好 |
| WordPress JS・CSS | /wp/wp-content/ 配下のJS・CSSファイル群 | 要確認 |
| フォント | 外部フォント（Google Fonts等）の使用状況 未確認 | 要確認 |
ページ内で確認できる画像リソースのほぼ全てがPNG形式（.png拡張子）で配信されている。ロゴのみSVG形式で適切だが、製品画像・事例写真・業界アイコン・メガメニュー画像・デモ機/実験センターのバナー画像など多数の画像がPNGのまま配信されている。WebPはPNGと比較して平均26%、AVIFはさらに50%程度ファイルサイズを削減できる。
特に製品画像（about01-3.png・img01_2.png・about03_2.png等）はグラデーションや透明度を含む可能性があり、PNG→WebP変換の効果が大きい。すべての主要ブラウザでWebPに対応済み（2024年時点でシェア95%超）。
ページ内に製品画像4点・事例写真3点・業界アイコン9点・ABOUT画像3点・バナー画像3点以上が存在し、ページ初回ロード時にすべての画像が一括ダウンロードされている可能性がある。スクロールしないと表示されない画像（ビューポート外）まで初期ロードで読み込むと、不要な帯域を消費しLCP・FCPが悪化する。
HTML標準のloading="lazy"属性はすべての主要ブラウザで対応済みで、属性を追加するだけで実装できる。ファーストビューの画像（LCP候補）にはloading="eager"を設定し、それ以下の画像にloading="lazy"を適用するのがベストプラクティス。
モバイルナビゲーションのハンバーガーメニューアイコンが画像ファイル（hamburger.png）で実装されている。このようなシンプルなアイコンは、CSSのみで描画するか、SVGまたはフォントアイコン（Font Awesome等）を使用する方が望ましい。PNG画像は不要なHTTPリクエストを発生させるうえ、Retinaディスプレイ（高解像度デバイス）で画質が低下しやすい。
CSSの三本線（≡）はHTTPリクエストを発生させず描画できる。実装コストが低く、表示品質・パフォーマンスの両方で改善できる。
WordPressは複数のテーマCSS・プラグインCSS・JQueryライブラリ・プラグインJSを個別のファイルとして読み込む。これらがミニファイ（空白・コメント除去による圧縮）・結合されていない場合、多数のHTTPリクエストとファイルサイズ増大により、FCPとINPが悪化する。特に/wp/サブディレクトリ構成では標準のWordPress最適化がそのまま機能しないリスクがある。
WP Rocket・LiteSpeed Cache等の最適化プラグインで「CSSミニファイ・結合」「JSミニファイ・遅延読み込み」を有効にすることで、リクエスト数の削減とファイルサイズ縮小を同時に実現できる。
画像・CSS・JSリソースへのブラウザキャッシュ（Cache-Controlヘッダー）の設定が確認できなかった。キャッシュが設定されていない場合、再訪問ユーザーが毎回すべてのリソースをダウンロードし直すことになり、2回目以降のページ表示でも速度改善が得られない。BtoBサイトでは同一ユーザーが複数回訪問し製品を比較検討するため、再訪問時の表示速度は特に重要。
.htaccessまたは最適化プラグインで静的ファイル（画像・フォント・CSS・JS）に1年（31536000秒）のmax-ageを設定する。ファイル名にバージョン番号やハッシュを含めることでキャッシュバスティング（更新時の強制再取得）も合わせて設定する。
製品画像・事例画像がPC・モバイル問わず同サイズの画像を配信している可能性がある。例えばPC向けに2000px幅の画像を配信し、モバイル（375px幅）でも同じ画像を縮小表示するのは過剰なデータ転送となる。WordPressはsrcset属性を自動生成する機能があるが、テーマ・カスタム実装によっては機能していないケースがある。
WordPressメディアライブラリ経由でアップロードした画像はsrcsetが自動付与される。テーマのハードコード画像については手動でsrcset/sizesを追加するか、レスポンシブ対応の画像プラグインを活用する。
| No. | 対象項目 | 改善アクション | 期待効果 | 優先度 |
|---|---|---|---|---|
| 1 | WebP変換・配信 | WordPressプラグイン「Imagify」「ShortPixel」「EWWW Image Optimizer」のいずれかを導入する。既存画像を一括WebP変換し、自動的にWebP対応ブラウザにはWebP、非対応にはPNG/JPEGを配信する設定にする（フォールバック付き）。新規アップロード画像も自動WebP変換されるよう設定する。目安：PNG100KBをWebPで60KB以下に削減。 | 総画像転送量30〜50%削減。LCP・ページ全体の読み込み速度が大幅改善 | 高 |
| 2 | 遅延読み込み設定 | ファーストビュー以外の全画像に loading="lazy" 属性を追加する。WordPressのプラグイン（WP Rocket・BJ Lazy Load等）で一括設定可能。ファーストビュー画像（ヒーロー・上部製品画像）は loading="eager"（または属性なし）のままにし、LCPを妨げないようにする。また、全画像にfetchpriority="low"を付与してブラウザのプリロードスキャナーに優先度を伝える。 | 初期ページロード時のリクエスト数削減。FCP・LCPの短縮 | 高 |
| 3 | ハンバーガーアイコン置換 | hamburger.pngをCSSで描画したアイコンに置き換える。実装例（CSSのみ）：.hamburger span {
HTTPリクエストがゼロになり、Retinaでも鮮明に表示される。代替としてSVGインラインアイコンでも同様の効果が得られる。 |
不要HTTPリクエスト削減。高解像度デバイスでの表示品質向上 | 高 |
| 4 | CSS・JSミニファイ | WP Rocket・LiteSpeed Cache・W3 Total Cacheを使い以下を有効化する：① CSSのミニファイ・結合 ② JavaScriptのミニファイ ③ JSの遅延読み込み（defer）④ HTML圧縮（ホワイトスペース除去）。設定後は必ずページ表示を確認し、JS遅延でレイアウト崩れ・機能不全が発生していないかテストする。 | CSSファイルサイズ20〜40%削減。FCP・INP改善 | 中 |
| 5 | ブラウザキャッシュ設定 | .htaccessにCache-Controlヘッダーを追加し、静的ファイルのキャッシュ有効期限を設定する。目安：画像・フォント→1年（31536000秒）、CSS・JS→1ヶ月（2592000秒）。プラグインを使用する場合はWP Rocketの「ブラウザキャッシュ」機能またはW3 Total Cacheの「Browser Cache」タブで設定できる。 | 再訪問ユーザーの読み込み速度を大幅改善（リソース再取得ゼロ） | 中 |
| 6 | レスポンシブ画像（srcset） | WordPressのメディアライブラリ経由でアップロードした画像はsrcsetが自動付与されるが、テーマにハードコードされた画像には手動でsrcset・sizes属性を追加する。特にヒーロー画像・メガメニュー画像・デモ申込バナー等の大型画像について、モバイル用（480px・768px）・デスクトップ用（1200px）の複数サイズを用意しsrcsetで切り替える。 | モバイルでの不要な大容量画像転送を防止。モバイルLCP改善 | 低 |