CONTENT
ここから
第17章では、配送ステータス、追跡番号、発送完了メール、送料計算など、商品を届けるための配送管理を整理しました。
この章からは、第6部として、ECを売れやすくするための設計に入ります。
まず扱うのは、表示速度です。
ECサイトでは、見た目がきれいでも、表示が遅いと購入者は離脱します。
特にスマホでは、数秒の遅れがそのまま機会損失につながります。
ページが遅い
↓
商品を見る前に離脱
↓
カートに入らない
↓
決済まで進まない
Next.jsでECを作る大きなメリットのひとつは、速いページを作りやすいことです。
ただし、Next.jsを使えば自動的に速くなるわけではありません。
速くするための設計が必要です。
攻略本風に言えば、第18章は**「ECの移動速度を上げる強化ステージ」**です。
18.1 ECで速度が売上に影響する理由
ECでは、ページの表示速度が購入体験に直結します。
購入者は、商品を見たいだけです。
ページがなかなか開かないと、次のように感じます。
このサイト、大丈夫かな
商品を見るのが面倒だな
他の店で買おうかな
特に影響が大きいのは、次のページです。
・トップページ
・商品一覧ページ
・商品詳細ページ
・カートページ
・購入ボタン周辺
トップページが遅いと、そもそも商品までたどり着きません。
商品一覧が遅いと、比較する前に離脱します。
商品詳細が遅いと、購入判断が止まります。
カートが遅いと、決済前に不安になります。
トップページ：
入口
商品一覧：
比較
商品詳細：
購入判断
カート：
決済前の確認
つまり、ECの速度は単なる技術問題ではありません。
購入者の不安を減らし、購入までの流れを止めないための設計です。
高速ECで目指すべき状態は、次の通りです。
・商品一覧がすぐ表示される
・商品画像が自然に読み込まれる
・購入ボタンがすぐ押せる
・余計なアニメーションで待たせない
・スマホでも軽く動く
速いECは、購入者に余計なことを考えさせません。
商品を見る、選ぶ、買う。
この流れを邪魔しないことが大切です。
18.2 静的化できるページを見極める
Next.jsで高速ECを作るとき、最初に考えるべきことは、静的化できるページは静的化することです。
静的化とは、簡単に言うと、あらかじめページを作っておくことです。
アクセスされてから毎回作る
→ 遅くなりやすい
事前に作っておく
→ 速く表示しやすい
ECで静的化しやすいページは、次のようなものです。
・トップページ
・商品一覧ページ
・商品詳細ページ
・カテゴリページ
・初めての方向けページ
・ギフトページ
・FAQページ
・特定商取引法ページ
・プライバシーポリシー
これらのページは、アクセスのたびに毎回データを大きく変える必要がありません。
たとえば、商品詳細ページは、価格や在庫の変更がなければ同じ内容を表示できます。
商品名
商品説明
画像
価格
配送案内
FAQ
これらは頻繁には変わらない
反対に、静的化しにくいページもあります。
・カートページ
・注文確認ページ
・決済処理ページ
・管理画面
・ログイン後のマイページ
・注文履歴ページ
これらはユーザーごとに内容が変わります。
そのため、毎回サーバー側で確認する必要があります。
考え方はシンプルです。
誰が見ても同じ内容
→ 静的化しやすい
見る人によって変わる内容
→ 動的処理が必要
ECでは、すべてを動的に作る必要はありません。
多くのページは静的化できます。
静的にできるページ：
できるだけ静的化
動的にするページ：
本当に必要なところだけ
この見極めが、高速ECの最初の攻略ポイントです。
18.3 動的処理を最小限にする
動的処理とは、アクセスされたタイミングでサーバーがデータを確認し、ページや処理を作ることです。
ECでは、動的処理が必要な場面があります。
・カートの中身を確認する
・在庫を確認する
・決済金額を計算する
・Squareの決済リンクを作る
・注文ステータスを確認する
・管理画面を表示する
これらは、正確性が必要です。
そのため、無理に静的化してはいけません。
ただし、動的処理を増やしすぎると、表示が遅くなりやすくなります。
すべてのページで毎回DBを読む
↓
サーバー処理が増える
↓
表示が遅くなる
動的処理を最小限にする考え方は、次の通りです。
商品を見せる部分：
できるだけ静的化する
購入に関わる部分：
サーバー側で正確に処理する
たとえば、商品詳細ページでは、商品説明や画像は静的に表示できます。
しかし、購入ボタンを押した後の金額計算はサーバー側で行います。
商品詳細ページ：
速く見せる
購入ボタン押下後：
サーバーで価格・在庫・送料を確認する
この分け方が重要です。
表示は速く
決済は正確に
ECでは、速度だけを優先してはいけません。
金額や在庫は、必ず安全に確認します。
高速化の基本は、速くしてよい部分と正確に処理すべき部分を分けることです。
18.4 商品一覧のキャッシュ設計
商品一覧ページは、ECでよく見られるページです。
そのため、商品一覧が遅いと、EC全体が重く感じられます。
商品一覧で表示する情報は、主に次の通りです。
・商品名
・商品画像
・価格
・簡単な説明
・在庫表示
・カテゴリ
・おすすめ表示
これらの情報は、毎秒変わるものではありません。
そのため、キャッシュと相性が良いです。
キャッシュとは、一度取得したデータや作ったページを、しばらく再利用する仕組みです。
毎回DBから取得する
→ 負荷が増える
一度作った内容を再利用する
→ 速く表示しやすい
商品一覧のキャッシュ設計では、次のように考えます。
商品情報があまり変わらない
→ 長めにキャッシュ
価格や在庫がよく変わる
→ 更新時に再検証
販売停止や売り切れが多い
→ 管理画面から更新後に再検証
キャッシュで注意したいのは、古い情報が表示される可能性です。
たとえば、在庫切れの商品が、しばらく「在庫あり」のまま表示されることがあります。
在庫が0になった
↓
キャッシュが残っている
↓
商品一覧では在庫ありに見える
このズレを防ぐには、商品情報を変更したタイミングで再検証します。
商品を更新
↓
商品一覧のキャッシュを更新
↓
新しい一覧を表示
商品一覧で特に再検証したいタイミングは、次の通りです。
・商品を公開した
・商品を非公開にした
・価格を変更した
・在庫が0になった
・おすすめ商品を変更した
・並び順を変更した
商品一覧は、速さと正確さのバランスが大切です。
速く表示したい
でも、古い情報は見せたくない
そのため、管理画面で商品を変更したら、商品一覧も更新する設計にします。
18.5 商品詳細の再検証設計
商品詳細ページは、購入判断に直結するページです。
ここが遅いと、購入ボタンを押す前に離脱されます。
商品詳細ページには、次のような情報があります。
・商品名
・価格
・画像
・説明文
・在庫表示
・配送案内
・購入ボタン
・関連商品
商品詳細ページも、基本的には静的化しやすいページです。
ただし、価格や在庫、公開状態が変わることがあります。
そのため、商品詳細ページでは再検証が重要になります。
再検証とは、古いページを新しい内容に作り直すことです。
古い商品ページ
↓
商品情報を変更
↓
再検証
↓
新しい商品ページ
再検証が必要なタイミングは、次の通りです。
・価格を変更した
・商品説明を変更した
・画像を変更した
・在庫が0になった
・公開状態を変更した
・スラッグを変更した
特に注意したいのは、価格変更です。
商品ページに古い価格が表示されていると、購入者とのトラブルになります。
表示価格：5,400円
決済価格：6,000円
購入者：
表示と違う
このようなズレを防ぐため、価格変更後は必ず商品詳細ページを更新します。
価格変更
↓
DB更新
↓
商品詳細ページを再検証
↓
新しい価格を表示
ただし、万が一古い価格が表示されていても、決済金額はサーバー側で計算します。
商品ページの表示：
参考情報
決済前の金額計算：
サーバー側で確定
つまり、商品詳細ページでは次の2段構えにします。
1. 再検証で表示情報を新しくする
2. 決済時にサーバー側で価格を再確認する
高速化と安全性を両立するには、この考え方が必要です。
18.6 画像最適化
ECでページが重くなる原因の多くは、画像です。
商品画像は必要です。
しかし、大きすぎる画像をそのまま表示すると、ページが遅くなります。
高画質な画像
↓
ファイルサイズが大きい
↓
読み込みが遅い
↓
購入者が待たされる
画像最適化で考えることは、次の通りです。
・必要なサイズで表示する
・必要以上に大きな画像を使わない
・画像形式を適切にする
・表示されるタイミングに合わせて読み込む
・代替テキストを設定する
商品一覧では、小さめの画像で十分です。
商品詳細では、少し大きな画像が必要です。
商品一覧：
小さく軽い画像
商品詳細：
大きめで見やすい画像
すべての場所で同じ巨大画像を使うのは避けます。
悪い例：
商品一覧でも4000pxの画像を読み込む
よい例：
商品一覧には表示サイズに合った画像を使う
Next.jsでは、画像最適化を行うための仕組みがあります。
ただし、どの画像でも無条件に軽くなるわけではありません。
元画像が重すぎたり、外部画像の設定が不適切だったりすると、効果が出にくくなります。
画像管理でおすすめのルールは、次の通りです。
・商品一覧用の画像比率をそろえる
・商品詳細用の画像を用意する
・ファイルサイズの上限を決める
・画像名を分かりやすくする
・altテキストを入れる
altテキストの例です。
悪い例：
image
よい例：
クラシック節ギフトセットの外箱と商品内容
画像は、ECの魅力を伝える武器です。
しかし、重すぎる画像は、購入体験の邪魔になります。
きれいに見せる
＋
速く表示する
この両方を目指します。
18.7 フォント最適化
フォントも、表示速度に影響します。
デザインにこだわると、複数のWebフォントを使いたくなります。
しかし、フォントを増やしすぎると、読み込みが重くなります。
フォントが多い
↓
読み込みが増える
↓
文字表示が遅れる
↓
ページが重く感じる
ECで大切なのは、読みやすさです。
特に商品名、価格、購入ボタン、配送案内は、すぐ読める必要があります。
商品名
価格
在庫表示
購入ボタン
送料
配送予定
フォント最適化の基本は、次の通りです。
・使うフォントを絞る
・太さを増やしすぎない
・不要な言語セットを読み込まない
・ローカルフォントも検討する
・文字が遅れて表示されないようにする
よくある失敗は、フォントの種類と太さを増やしすぎることです。
悪い例：
明朝体
ゴシック体
英字用フォント
見出し用フォント
本文用フォント
価格用フォント
太さも複数
よい例：
見出し用
本文用
必要な太さだけ
最初のECでは、フォントは1〜2種類に絞るのがおすすめです。
本文：
読みやすいゴシック体
ブランド感を出したい見出し：
必要な箇所だけ別フォント
フォントは、ブランドの印象を作ります。
しかし、購入体験を遅くしてまで増やす必要はありません。
デザイン性
＋
読み込み速度
＋
読みやすさ
この3つのバランスを取ります。
18.8 JavaScriptを減らす
ECサイトでは、JavaScriptを増やしすぎるとページが重くなります。
JavaScriptは、ブラウザ上で動くプログラムです。
便利ですが、増えすぎると読み込みや処理に時間がかかります。
JavaScriptが多い
↓
読み込みが増える
↓
ブラウザで処理が必要
↓
スマホで重くなる
ECでJavaScriptが必要な場面はあります。
・カート操作
・数量変更
・モーダル表示
・画像スライダー
・フォーム入力
・管理画面の操作
しかし、すべての表示にJavaScriptが必要なわけではありません。
商品名、価格、説明文、画像は、最初からHTMLとして表示できます。
JavaScriptなしでも表示できるもの：
商品名
価格
商品説明
配送案内
FAQ
JavaScriptを減らす考え方は、次の通りです。
読むだけの部分：
サーバー側で表示する
操作が必要な部分：
クライアント側で動かす
たとえば、商品詳細ページ全体をClient Componentにする必要はありません。
商品説明：
Server Component
購入数量の変更：
Client Component
カート追加ボタン：
Client Component
このように分けることで、必要な部分だけJavaScriptを使えます。
避けたい設計は、ページ全体をなんとなくClient Componentにすることです。
悪い例：
商品詳細ページ全体を'use client'にする
よい例：
操作が必要な部品だけClient Componentにする
JavaScriptを減らすと、特にスマホで軽くなります。
高速ECでは、見せるだけの部分をできるだけ軽く作ることが重要です。
18.9 Client Componentを増やしすぎない
Next.js App Routerでは、Server ComponentとClient Componentを使い分けます。
初心者がつまずきやすいのは、なんでも'use client'にしてしまうことです。
'use client'を付けると、そのコンポーネントはブラウザ側で動くClient Componentになります。
Client Componentが悪いわけではありません。
ただし、増やしすぎるとJavaScriptが増え、ページが重くなります。
Client Componentが多い
↓
ブラウザに送るJavaScriptが増える
↓
読み込みと処理が重くなる
Server Componentに向いているものは、次の通りです。
・商品名の表示
・商品説明の表示
・価格の表示
・カテゴリ一覧
・FAQ
・記事コンテンツ
・静的な画像表示
Client Componentに向いているものは、次の通りです。
・カートに追加するボタン
・数量変更
・開閉メニュー
・モーダル
・フォーム入力
・お気に入りボタン
・管理画面の一部操作
商品詳細ページの構成例です。
商品詳細ページ
├─ 商品名：Server Component
├─ 商品画像：Server Component
├─ 商品説明：Server Component
├─ 配送案内：Server Component
└─ 購入操作：Client Component
このように、操作が必要な部分だけをClient Componentにします。
コードの考え方です。
type ProductDetailPageProps = {
params: {
slug: string;
};
};
/**
* 役割: 商品詳細ページ全体を表示する
* 入力: 商品スラッグ
* 出力: 商品情報と購入操作を含むページ
*/
export default async function ProductDetailPage(
props: ProductDetailPageProps
) {
const product = await getProductBySlug(props.params.slug);
return (
<main>
<h1>{product.name}</h1>
<p>{product.description}</p>
<p>{product.price}円</p>
<AddToCartArea productId={product.id} />
</main>
);
}
AddToCartAreaだけをClient Componentにします。
'use client';
type AddToCartAreaProps = {
productId: string;
};
/**
* 役割: 商品をカートに追加する操作部分を表示する
* 入力: 商品ID
* 出力: カート追加ボタン
*/
export default function AddToCartArea(props: AddToCartAreaProps) {
return (
<button type="button">
カートに追加する
</button>
);
}
このように分けると、ページ全体を軽く保ちやすくなります。
Client Componentは、必要な場所だけに使う。
これがApp Routerで高速ECを作る基本です。
18.10 Lighthouseで改善点を確認する
最後に、作ったECが本当に速いか確認します。
そこで使えるのがLighthouseです。
Lighthouseは、Webページの品質を確認するためのチェックツールです。
主に次のような項目を確認できます。
・表示速度
・アクセシビリティ
・SEO
・ベストプラクティス
Chromeの開発者ツールから使えます。
Chromeでページを開く
↓
開発者ツールを開く
↓
Lighthouseを選ぶ
↓
検証を実行する
ECで特に見たいのは、次の項目です。
・ページの表示が遅くないか
・画像が重すぎないか
・不要なJavaScriptが多くないか
・文字が読みやすいか
・SEOの基本が整っているか
Lighthouseのスコアだけを追いかけすぎる必要はありません。
大切なのは、購入者にとって使いやすいかどうかです。
スコアが高い
でも購入しにくい
→ よくない
スコアも良く
購入導線も分かりやすい
→ よい
Lighthouseでよく出る改善項目には、次のようなものがあります。
・画像サイズが大きい
・不要なJavaScriptが多い
・フォント読み込みが重い
・初期表示に時間がかかる
・ボタンやリンクが分かりにくい
・メタ情報が不足している
改善するときは、一度に全部直そうとしなくて大丈夫です。
優先順位をつけます。
1. 画像を軽くする
2. Client Componentを減らす
3. 不要なライブラリを外す
4. フォントを整理する
5. キャッシュと再検証を見直す
商品ページ、トップページ、商品一覧ページは必ず確認します。
確認すべきページ：
トップページ
商品一覧ページ
商品詳細ページ
カートページ
決済前ページ
Lighthouseは、答えを出してくれる道具ではありません。
どこを改善すべきかを見つけるための地図です。
Lighthouse
↓
問題点を見つける
↓
優先順位を決める
↓
改善する
↓
もう一度測る
高速化は、一度やって終わりではありません。
商品が増えたとき、画像を追加したとき、機能を増やしたときに、また確認します。
第18章のまとめ
Next.jsで高速ECを作るには、ただNext.jsを使うだけでは不十分です。
どのページを静的化するか、どこを動的にするか、画像やフォントをどう扱うかを設計する必要があります。
この章で覚えておきたいポイントは、次の通りです。
1. ECでは表示速度が購入体験に直結する
2. 誰が見ても同じページは静的化しやすい
3. カートや決済など正確性が必要な処理は動的にする
4. 商品一覧はキャッシュと再検証を設計する
5. 商品詳細は価格変更や在庫変更時に再検証する
6. 画像は見た目と軽さのバランスを取る
7. フォントは増やしすぎない
8. JavaScriptは必要な部分だけに使う
9. Client Componentをページ全体に広げすぎない
10. Lighthouseで改善点を確認する
高速ECの基本は、次の一言にまとめられます。
表示は速く、決済は正確に。
商品を見せる部分はできるだけ軽くします。
一方で、価格、在庫、送料、決済金額はサーバー側で正確に確認します。
このバランスが取れると、Next.jsの強みを活かした高速ECになります。
第19章では、速く表示するだけでなく、検索から見つけてもらうためのSEOに強いECページを作っていきます。