SEO 対策モバイルの基礎知識と要点10選|まず押さえるポイント

2024年時点で検索はモバイル経由が過半となり、GoogleはCore Web Vitalsの指標をINPに刷新しました⁷。ページ体験の質は検索での成功に寄与し、収益にも影響しうるため⁶⁸、モバイルを起点にした最適化が重要です。スマホ回線のレイテンシと端末CPUの制約は、同じ実装でもデスクトップより誤差が大きく、遅延は直帰・離脱を増やしやすくなります⁸。モバイルファーストインデックスではスマホ版の内容が評価対象であるため、技術選定・配信・計測のいずれもモバイル起点に再設計が必要です。本稿では、CTO・エンジニアリーダーが短期間で成果を出すための基礎と要点10選を、コード・数値・運用手順で提示します。

モバイルSEOの基礎指標と技術仕様

前提を明確化し、誤った最適化を避けます。特にINP・LCP・CLSの3指標は実装判断の評価軸として運用に組み込みます¹³⁵。

前提条件と環境

対象: SSR/SSGを含むモダンWeb（Next.js, Nuxt, Astro等）。計測はラボ（Lighthouse/PSI）とRUM（web-vitals）を併用。配信はHTTP/2以上、Brotli、モバイル優先のキャッシュ制御。

仕様/指標	モバイル要点	閾値/推奨
クロール	Googlebot Smartphone（モバイルUA）	スマホ版とPC版の内容同一
LCP	最大描画要素（画像/テキスト）	2.5s以下が良好、4.0s超は要改善¹
INP	全体入力応答（タップ/キー）	≤200ms良好、200–500ms要改善³⁴
CLS	レイアウトシフト蓄積	≤0.10良好、0.10–0.25要改善⁵
配信	HTTP/2/3 + Brotli + CDN/Edge	TTFB 200ms台を目標
画像	AVIF/WebP優先、明示的サイズ	適切なsrcset/sizesとpreload⁹

要点10選：実装の勘所とコード

1. LCP最適化（ヒーロー画像/テキストの即時描画）

ヒーロー画像はpreloadし、明示サイズとモダンフォーマットで配信。SSRで初期HTMLに含め、クライアントJS依存を避けます¹。

import dynamic from 'next/dynamic';
import Head from 'next/head';
const HeroImage = dynamic(() => import(’../components/HeroImage’), { ssr: true });
export default function Page() {
return (
<>
<Head>
<meta name=“viewport” content=“width=device-width, initial-scale=1” />
<link rel=“preload” as=“image” href=“/hero.avif” imagesrcset=“/hero.avif 1x, /hero@2x.avif 2x” imagesizes=“100vw” />
</Head>
<HeroImage priority />
</>
);
}

計測ではLCP対象を固定化し、遅延読み込み・カルーセル初期化による遅延を避けます¹。

2. INP改善（JS削減と即応性）

リスナの最小化、長タスク分割、優先度制御（scheduler.postTask等）。レガシーポリフィルの除去で送信JSを削減³。

import React, {useTransition} from 'react';
export function Filter({apply}) {
const [pending, start] = useTransition();
return (
<button
aria-busy={pending}
onClick={() => start(() => apply())}
>
絞り込み
</button>
);
}

長タスクが残る場合はWeb Worker移送を検討します³。

3. CLSゼロ化（寸法とフォント）

画像・広告枠は必ず幅高を宣言し、フォントは可変幅差を抑えるdisplay: optional/ swap + size-adjustを活用⁵。

import React from 'react';
export function Img(props) {
return <img loading=“eager” decoding=“async” width={1200} height={600} alt="" {…props} />;
}

4. モバイルファーストインデックスの整合

スマホ版もPC版と同一の主コンテンツ・構造化データ・リンクを保持。レンダリング差分を削除し、robots/Canonicalを統一。

5. 画像パイプライン（AVIF/WebP, responsive）

ビルド時に多形式・多解像度を生成してキャッシュ親和性を高めます⁹。

import fs from 'node:fs/promises';
import sharp from 'sharp';
async function buildResponsive(src, outBase) {
try {
await Promise.all([
sharp(src).avif({quality: 50}).toFile(${outBase}-800.avif),
sharp(src).webp({quality: 60}).toFile(${outBase}-800.webp),
sharp(src).jpeg({quality: 70}).toFile(${outBase}-800.jpg)
]);
} catch (err) {
console.error(‘Image build failed’, err);
process.exitCode = 1;
}
}
buildResponsive(‘public/hero.jpg’, ‘public/hero’);

6. JS分割と遅延（module/nomodule廃止、動的import）

ヒーロー以外のウィジェットは遅延。エッジでの早期フラッシュ回避のためSSRとハイドレーション優先度を設計します。

import React, {Suspense} from 'react';
const ProductList = React.lazy(() => import(’./ProductList’));
export function Page() {
return (
<Suspense fallback={<div role=“status” aria-live=“polite”>Loading…</div>}>
<ProductList />
</Suspense>
);
}

7. サーバー・配信（TTFB短縮）

HTTP/2/3、Brotli、TLS 1.3、CDNのEdge TTLとstale-while-revalidate。SSRはキャッシュキーにクエリを含めすぎない設計。

8. PWA/Service Workerで再訪体験を底上げ

初回はネットワーク優先、2回目以降はStale-While-Revalidateで画像・フォントを即時表示。

/* eslint-disable no-restricted-globals */
import {precacheAndRoute} from 'workbox-precaching';
import {registerRoute} from 'workbox-routing';
import {StaleWhileRevalidate} from 'workbox-strategies';
try {
// @ts-ignore
precacheAndRoute(self.__WB_MANIFEST || []);
registerRoute(
({request}) => request.destination === ‘image’,
new StaleWhileRevalidate({cacheName: ‘images-v1’})
);
} catch (e) {
console.error(‘SW init failed’, e);
}

9. フォールバックUXとアセットのアクセシビリティ

オフライン時や低帯域時の代替UIを用意し、ARIAと視認性を両立。CLSを防ぎつつ読みやすさを担保します。

10. 計測とRUM・CIの常設

RUMで実ユーザーのVitalを収集、PRごとにLighthouse CIで回帰をブロック。閾値はモバイル値で運用。

import {onLCP, onINP, onCLS} from 'web-vitals/attribution';
try {
onLCP(({value, attribution}) => {
navigator.sendBeacon(‘/vitals’, JSON.stringify({metric: ‘LCP’, value, target: attribution?.element}));
});
onINP(({value, attribution}) => {
navigator.sendBeacon(‘/vitals’, JSON.stringify({metric: ‘INP’, value, event: attribution?.eventType}));
});
onCLS(({value}) => {
navigator.sendBeacon(‘/vitals’, JSON.stringify({metric: ‘CLS’, value}));
});
} catch (e) {
console.error(‘web-vitals init failed’, e);
}

計測・ベンチマークとCIの実運用

手元のラボ値と実ユーザーのRUM値の両輪で意思決定します。ここでは、Lighthouse（モバイルプリセット）での改善例を提示します。

指標	Before	After	改善要因
LCP	3.8s	1.9s	ヒーロー画像preload+AVIF
INP	380ms	180ms	JS分割/遅延+長タスク分割
CLS	0.18	0.05	画像寸法宣言+フォント最適化
TTFB	800ms	220ms	CDN+Brotli+SSRキャッシュ
JS実行	2.4s	0.9s	動的import/不要ライブラリ削除
転送量	2.8MB	1.2MB	画像圧縮+HTTP/2

CIへの組み込み例（プログラマティックLHCI）。PRでしきい値を超えたら失敗させます。

import {writeFile} from 'node:fs/promises';
import lhci from '@lhci/cli/src/index.js';
try {
const {lhr} = await lhci.openLocalBrowserAndRunLighthouse(‘https://m.example.com’, {preset: ‘mobile’});
await writeFile(‘lhr.json’, JSON.stringify(lhr));
const lcp = lhr.audits[‘largest-contentful-paint’].numericValue;
if (lcp > 2500) throw new Error(LCP regression: ${lcp});
console.log(‘LCP’, lcp);
} catch (e) {
console.error(‘LHCI run failed’, e);
process.exit(1);
}

RUMはBigQuery/Logに集約し、国/端末/ネットワーク別にセグメント。予算（Performance Budget）をJSONで宣言し、PRごとに差分を検証すると運用が安定します。

事業インパクトと導入計画（ROI/期間）

モバイル高速化は検索流入とCV双方に効きます。例として、月間セッション10万、CVR 2.0%、平均注文額8,000円のECで、LCP 3.8→1.9s・INP 380→180msに改善しCVRが2.3%へ上昇した場合、月+240万円の売上増となります。投資300万円・維持月20万円なら、回収は2か月弱。Google/Deloitteの公開分析（小売・旅行）でも、速度短縮によるCV改善の相関が示されています⁸。

導入期間の目安:

現状診断（1週）: ラボ/ログを整備し、LCP要素と長タスク特定。RUM収集の実装。
優先実装（2–3週）: 画像パイプライン、preload、JS分割、CDN設定、フォント最適化。
安定化（1週）: CIしきい値運用、RUMダッシュボード、A/BでCV影響を検証。

リスク: 広告・計測タグの遅延、画像CDNの変換遅延、キャッシュキー爆発。対策としてタグ遅延読込のサンドボックス化、ビルド時変換の採用、キャッシュポリシーの合意（Varyの最小化）を行います。

補助ツール（任意）

Blurプレースホルダー生成でファーストインプレッションを向上。

import sys
from PIL import Image, ImageFilter
def blur_placeholder(src, dst):
try:
with Image.open(src) as im:
im = im.resize((32, 32), Image.LANCZOS).filter(ImageFilter.GaussianBlur(1.2))
im.save(dst, format=‘JPEG’, quality=30)
except Exception as e:
print(f’placeholder failed: {e}’, file=sys.stderr)
raise
if name == ‘main’:
blur_placeholder(‘public/hero.jpg’, ‘public/hero-blur.jpg’)

まとめ：まず押さえて進めるために

モバイルSEOは「測る→直す→運用する」の反復です。最初にCore Web Vitalsのボトルネック（LCP要素・長タスク・レイアウトずれ）を特定し、ヒーロー画像のpreload/AVIF化、JS分割、寸法宣言とフォント最適化を実行。RUMで実ユーザーの数値を常時監視し、CIにしきい値を組み込めば、リリースのたびに品質が積み上がります。貴社のトップページはLCP 2.5s以下、INP 200ms以下、CLS 0.1以下を達成できていますか¹³⁵。今日から計測の配線と優先3施策（画像・JS・TTFB）に着手し、2–4週間での体感改善と収益効果の検証を進めましょう⁶⁸。

参考文献

Largest Contentful Paint (LCP) – web.dev. https://web.dev/articles/lcp
Interaction to Next Paint (INP) – web.dev. https://web.dev/inp
INP thresholds and guidance – web.dev (INP page, thresholds section). https://web.dev/inp/#:~:text=,are%20greater%20than%20500%20milliseconds
Optimize Cumulative Layout Shift (CLS) – web.dev. https://web.dev/articles/optimize-cls
The role of page experience in creating helpful content – Google Search Central Blog (Apr 2023). https://developers.google.com/search/blog/2023/04/page-experience-in-search
Introducing INP to Core Web Vitals – Google Search Central Blog (May 2023). https://developers.google.com/search/blog/2023/05/introducing-inp
How speeding up your mobile site can improve your bottom line – Think with Google (2020). https://www.thinkwithgoogle.com/intl/en-emea/marketing-strategies/app-and-mobile/mobile-page-speed-data/
AVIF updates in 2023 – web.dev. https://web.dev/articles/avif-updates-2023

SEO 対策 モバイルの基礎知識と要点10選|まず押さえるポイント

**モバイルSEOの基礎指標と技術仕様**

**前提条件と環境**

**要点10選：実装の勘所とコード**