売上アップ、コンバージョン率の改善を検討する際、「ページ表示速度の改善」や「アクセシビリティ対応」は施策候補としてがりやすいテーマ。ページ読み込み時間が1秒から3秒に増加すると、直帰率が約32%上昇するという説（Google/SOASTA Research, 2017）、ECサイトの平均コンバージョン率が2〜4%程度で速度改善による微小なコンバージョン率の変動が売り上げに直接影する――。こんなことも良く見聞きしますよね。また、2024年に施行された改正障害者差別解消法で合理的配慮が必要になったため、アクセシビリティの重要性が高まった……なので改善を進めている、ということもよく聞きます。
しかし、実際には誤った、または正しくない改善の手法が選択されているケースが少なくありません。ECの現場で働く筆者がよく見受ける誤解や誤った対処法を技術的に整理し、本質的な改善へのアプローチをお伝えします。
パフォーマンス改善の誤解と正しい考え方
誤解① PageSpeed Insightsのスコアが上げれば、ユーザー体験も改善される
「スコアが90を超えたので改善完了」――。こう判断するのは早計かもしれません。
PageSpeed Insights（PSI）はGoogleが提供するウェブパフォーマンス診断ツールですが、そのスコアはラボ環境（開発環境でシミュレーション）での結果です。実際のユーザーの回線環境・デバイス・行動パターンを完全に反映したデータではありません。
長らくこのラボデータでの指標が注目されてきましたが、PSIでもフィールドデータ（ユーザーがそれぞれのデバイスや回線環境で体験した生の記録）と呼ばれるデータが「実際のユーザーの環境で評価する」という表現で上部に表示されるようになったため、実際の環境とシミュレーション結果というのがわかりやすくなっています。
しばらくPSIを見ていなかった方は、ぜひ確認してみてください。各データの特長は次の通りです。
| データ種別 | 内容 | 特性 |
| ラボデータ （例：Lighthouse） | 制御された環境での計測 | 再現性が高いが、実環境との乖離あり |
| フィールドデータ （例：CrUX） | 実際のユーザーから収集した統計値 | 実態を反映しているが、収集に時間を要する（アクセスの少ないサイトではデータが存在しない） |
スコア改善だけを目標に施策を優先すると、フィールドデータ上のユーザー体験が改善されない、あるいは別の問題が悪化するケースもあります。スコアは診断の入口であり、目標値ではありません。
改善の判断軸として置く上でわかりやすい指標の1つは、Googleが定義するCore Web Vitals（CWV）の3指標です。
| 指標 | 意味 | 良好の閾値 |
| LCP（Largest Contentful Paint） | 主要コンテンツの表示完了時間 | 2.5秒以内 |
| INP（Interaction to Next Paint） | インタラクションへの応答性 | 200ミリ秒以内 |
| CLS（Cumulative Layout Shift） | レイアウトのズレの累積度 | 0.1以下 |
これらはGoogle検索のランキング要因にも組み込まれており、改善へのリソースも社内で検討しやすい項目でしょうか。
通販新聞社が発表した第83回通販通信教育売上高ランキング上位300社のうち、月間トラフィックが10万以上の日本国内サイトを対象とした結果をまとめた2025年の記事を見ると、多くのサイトがCWVの改善に力を入れていることがわかります。
誤解② 画像を軽くすれば、速度は改善される
画像最適化はパフォーマンス改善の代表的な施策です。ただし、それだけでは不十分なケースが多いのが実情です。
ページが「ユーザーに表示されるまでの一連の流れ」は、複数のフェーズに分解できます。ページが表示されるまでの「5つのステップ」は次の通り。
- DNS 解決 → 接続確立（TCP または QUIC） → TLS ハンドシェイク（ネットワーク起因の遅延）
- 例えると：お店の住所を確認して、鍵を開ける
- 何が遅延の原因か：サーバーとの距離が遠い、接続設定が複雑
- TTFB（Time to First Byte）：サーバーが最初の1バイトを返すまでの時間
- 例えると：注文してから料理が出てくるまでの時間
- 何が遅延の原因か：サーバーのスペック不足、データベースの処理待ち
- レンダーブロッキングリソースの処理：HTML解析を止めるCSS・同期JSの読み込み
- 例えると：看板を立てる前に、重い荷物を片付ける
- 何が遅延の原因か：不要なCSSや古いJavaScriptが道を塞いでいる
- 画像・フォント・動画の読み込み：LCPに直結するリソース
- 例えると：写真やポスターを壁に貼る
- 何が遅延の原因か：画像サイズが大きすぎる、動画の読み込みが重い
- JavaScriptの実行：メインスレッドを占有し、INPを悪化させる主因になりやすい
- 例えると：店員さんが注文を処理する（計算）
- 何が遅延の原因か：プログラムが複雑すぎて、スマホの頭脳がパンクする
たとえば画像をWebPに変換しても、TTFBが1.5秒かかっていればLCPの改善幅は限定的です。むしろJavaScriptバンドルサイズの削減・不要なサードパーティスクリプトの排除・サーバーキャッシュの最適化が、体感速度の改善に大きく寄与するケースも少なくありません。
また、現代の通信速度では、画像やCSS、JSファイルの少々のサイズの軽減よりも、クライアント側（ユーザーの端末側）で行われるJavaScirptの計算量を減らす方がユーザー体験は大きく向上するケースも多いです。
※WebPやAVIFなどの次世代画像フォーマットを利用すると、ラボデータのスコアは上がりますが、それが本当にパフォーマンスの改善になっているかは別の問題です。
改善施策を選択する前に、ボトルネックがどのフェーズにあるかを計測・特定することが先決です。WebPの利用においては、下記に興味深い投稿があります。
これは有用な検証記事。
・WebPは言うほど良くない
・AVIFが性能が最も良さそう
エンコード時間の長さはAVIFのデメリットであるものの、画質×容量のコスパが良いですね。
画像圧縮するベストな方法（2025）https://t.co/7YTEEJQoW5— 池田 泰延 (@clockmaker) December 17, 2025
筆者もWebPとJPGを比べた際に、WebPがJPGに劣るケースに遭遇したことがあります。しかしながら、ECサイトを運営しているとモールやASP側の自動変換が適用されるケースも多く、画質やパフォーマンスの理想だけを求めた運用が可能かは別の問題でもあります。
パフォーマンス改善で押さえておくべき設計原則
計測 → 仮説 → 実装 → 検証のサイクルを回すことが重要です。感覚や「なんとなく重い」という印象ではなく、データを起点に改善サイクルを構築しましょう。
初めて改善サイクルを構築する方は、具体的な数値の確認方法として、次のようなツールでまずは確認してみてはいかがでしょうか。。
- Google Search Console の「ウェブに関する主な指標」レポート：フィールドデータに基づくページ単位のCWV状況を確認できます
- Chrome DevTools の Network・Performance パネル：ウォーターフォールチャートで各フェーズのボトルネックを特定できます
- WebPageTest（webpagetest.org）：地域・回線速度・デバイスを指定した詳細な計測が可能です
Chrome DevTools の Network・Performanceパネルからは、パフォーマンスデータをダウンロードできます。
→ https://developer.chrome.com/docs/devtools/performance/save-trace?hl=ja
現代であれば、このデータをAIに渡すことで、内容の分析・改善を簡単に行うことができます。まずはこちらを試していただくのをお勧めします。
※計測はシークレットモードでChromeの拡張機能を無効にして行ってください
アクセシビリティ改善の誤解と正しい考え方
誤解① アクセシビリティオーバーレイを導入すれば対応完了
「ボタンを1つ設置するだけで対応できる」というキャッチコピーに魅力を感じる担当者は多いかもしれません。しかし、この判断には注意が必要です。
アクセシビリティオーバーレイとは、JavaScriptを1行埋め込むだけで「文字サイズ変更」「色調調整」「読み上げ補助」などの機能をページに追加するサードパーティツールの総称です。国際的なアクセシビリティ専門家コミュニティからの批判が根強く、主な問題点は次の通りです。
- HTML構造上の問題は解決しない：
<button>ではなく<div>で実装されたクリッカブル要素は、スクリーンリーダーから「クリックできない要素」として認識されます。オーバーレイがこれを動的に修正しようとしても、完全な対応には限界があります。目が見える人は「ここはボタンだ」と分かりますが、目が見えない人が使う「音声読み上げソフト（スクリーンリーダー）」は、「これはただの壁（div）です」と伝えてしまいます。 - 既存の支援技術との競合：スクリーンリーダー（NVDA・VoiceOverなど）はすでにOSレベルで動作しており、オーバーレイがそれを上書きしようとすることで逆に操作性が低下するケースが報告されています。つまり、ユーザーは普段使い慣れた「自分の設定」で操作したいのに、Webサイト側のツールがそれを勝手に上書きして操作を邪魔してしまい、逆に動けなくなる（操作不能になる）ケースがあるのです。
- WCAGへの準拠とは別物：Web Content Accessibility Guidelines（WCAG）への準拠は、マークアップ・コントラスト比・キーボード操作性・フォームラベルなど、実装レベルの要件を含んでいます。オーバーレイには「看板の文字を大きくする」くらいのことしかできません。「階段（キーボードで操作できない場所）をスロープにする」といった、建物自体の構造を作り直すことはできないのです。
オーバーレイを導入することで「何もしないよりはよい」という場面も多いですが、「アクセシビリティ対応済み」と評価できる根拠にはなりません。
誤解② アクセシビリティ対応は、障害者向けの法令対応に過ぎない
日本では2024年4月の改正障害者差別解消法により、民間事業者にも「合理的配慮の提供」が義務化されました。ただし、アクセシビリティ改善の価値を「法令対応コスト」として捉えると、施策の優先度を正しく評価できません。
アクセシビリティ改善が恩恵をもたらす対象は、障害者に限定されないからです。
| 対象ユーザー | 関連するアクセシビリティ改善の例 |
| スクリーンリーダー利用者 | 適切なaltテキスト、aria-label、見出し構造 |
| 高齢ユーザー | 十分なコントラスト比（WCAG AA: 4.5:1以上）、大きなタップターゲット |
| モバイルユーザー | フォーカス管理、タッチターゲットサイズの確保 |
| 低回線速度の環境 | 代替テキストによるコンテンツ取得、段階的な読み込み設計 |
| 一時的な障壁を持つユーザー（片手操作・まぶしい環境など） | 操作の簡素化、色以外の情報伝達 |
これはカーブカット効果として知られる概念です。歩道の縁石カットが車いす利用者だけでなく、ベビーカー・自転車・高齢者の移動を助けるように、バリアフリー設計は特定集団だけでなく社会全体の利便性を底上げします。
ECサイトにおいても同様で、アクセシビリティ対応のための適切なHTML構造（見出し階層・リスト・ラベル）はクローラーによるコンテンツ理解にも寄与するため、SEOとの相乗効果も期待できます。
アクセシビリティ改善で押さえておくべき設計原則
WCAG 2.1が定める4原則「知覚可能・操作可能・理解可能・堅牢」を基軸に実装を評価することが出発点です。
ECサイトにおいて優先度が高い確認項目を以下に示します。
- フォームのラベル設計：
<label for="">が各入力フィールドに正しく紐づいているか - キーボード操作性：Tab キーのみで主要操作（商品選択・カート追加・決済）が完結するか
- コントラスト比：本文テキストが背景に対して4.5:1以上を確保しているか（Chrome DevTools の Accessibilityパネルで確認可能）
- 画像の代替テキスト：商品画像のalt属性に意味のある説明が記述されているか
- エラーメッセージの明瞭さ：フォームエラーが色だけでなくテキストで伝達されているか
モールやASPによる対応が必要な項目も多くありますが、コントラスト比やalt属性と言った項目は、日常の運用業務内でも改善を見込める項目です。
過去の記事では、すでに7年前にAmazonはアクセシビリティ対応していたことが解説されています。
改善を始める前に確認すべきこと
パフォーマンス・アクセシビリティはどちらも、「計測なき改善は改善ではない」という原則が当てはまります。
施策を実施する前に、現状の数値をベースラインとして記録しておくことが重要です。改善後の効果を定量的に評価できなければ、次の施策への投資判断ができません。
パフォーマンス：今週できる一歩
Google Search Consoleの「ウェブに関する主な指標」で、自サイトのフィールドデータを確認してみてください。「改善が必要」と判定されているページがあれば、Chrome DevTools の Performanceレポートを取得し、LCPの原因リソースを特定するところから始められます。
アクセシビリティ：今週できる一歩
自サイトのトップページ・商品ページ・カートページを、マウスを使わずキーボード（Tab / Enter / Space）だけで操作してみてください。フォーカスが見えない・操作が詰まる・順序がおかしい——そうした障壁が発見された箇所が、最初の改善対象です。
数値やスコアの「見た目の改善」を目標にするのではなく、実際のユーザーが何を体験しているかを起点に設計を見直すことが、本質的な改善のコツです。
- この記事のキーワード
バックナンバー
この記事の筆者
筆者の人気記事
