オウンドメディアの記事が増えると、ホームページは重くなるのか。EmDash 1.2.0 の検証用サイトに日本語の記事を 10 本と 300 本入れ、本番と同じ作り方で表示速度とページの重さを測りました。記事ページの速さはほぼ変わらず、差が出たのは一覧の作り方と写真でした。
この記事の目次
オウンドメディアを始めるとき、「記事が増えたらホームページが重くなるのでは」という心配がよく出てきます。EmDash は速いと聞くけれど、それは記事が少ないうちだけではないか、という疑問です。
そこで、EmDash の検証用サイトに日本語の記事を 10 本入れた状態と 300 本入れた状態を作り、同じ条件で測り比べました。結論を先に書くと、記事が 30 倍になっても、記事ページを表示する速さはほぼ変わりませんでした。 差が出たのは、一覧ページをどう作るかと、写真の重さです。この記事では、その数字と、この計測では分からないことを順に書きます。
何を、どの版で、どうやって測ったか
- EmDash 1.2.0（2026年10月15日時点の最新）。公式の作成コマンドで作ったブログテンプレートを、デザインも含めてそのまま使いました。
- 本番と同じ作り方で起動しました。開発用のサーバーではなく、公開用に組み立てた（ビルドした）サイトを Node.js（サーバー用のプログラム実行環境）で動かしています。
- 記事は日本語のダミーです。1 本あたり本文約 2,350 字、見出し 7 つ、アイキャッチと本文中の写真が 1 枚ずつ（約 1600×1000 と 1200×800 ピクセル）。カテゴリ 5 つ、タグ 12 個に振り分けました。10 本と 300 本で、記事の中身は同じ作り方です。
- 測ったものは 3 つです。 1. ページを作って返すまでの時間（各ページ 50 回の中央値） 2. 10 人が同時にアクセスし続けたとき、1 秒に何ページ返せるか（10 秒間） 3. Google の無料の計測ツール Lighthouse による点数と、ページの重さ（転送量）。スマートフォンと低速の回線を想定した標準の設定で、各 3 回の中央値
計測はすべて同じ Mac（Apple M5 Pro）の中で行いました。インターネットを通っていないので、数字は「サーバーがページを作る速さ」をほぼそのまま表します。計測に使ったスクリプトと結果は、再現できる形で残しています。
記事が 30 倍になっても、ページを作る時間はほぼ同じだった
ページを作って返すまでの時間は、次のとおりです。単位はミリ秒（1,000 分の 1 秒）です。
記事ページは 4.7 ミリ秒から 5.4 ミリ秒、トップページは 4.5 ミリ秒から 5.5 ミリ秒でした。人が感じ取れる差ではありません。
速さが保たれる理由は、ページの作り方にあります。EmDash は、訪問者が来るたびに、その記事 1 本だけをデータベースから読み出してページを作ります。記事ページ 1 枚を作るのに使ったデータベースへの問い合わせは、10 本のときも 300 本のときも 4 回でした（EmDash が応答に付けている計測情報で確認）。記事が何本あっても、読み出す量は変わりません。
記事一覧も、新しい順に 20 本ずつページを分けて表示する作りになっています。並べ替えと切り出しはデータベースの中で行われ、300 本すべてを読み込むことはしません（公式ドキュメントにも、そう書かれています）。一覧は 4.7 ミリ秒から 7.5 ミリ秒に増えました。このとき並べていた件数は、10 本のときは 10 本、300 本のときは 20 本です。
もう一つ、記事を足すたびにサイト全体を作り直す必要もありません。公開した記事は、次のアクセスから表示されます。サイトの組み立て（ビルド）は 10 本でも 300 本でも数秒で終わり、記事数とは関係がありませんでした。
同時に 10 人がアクセスし続ける試験でも、記事ページは 1 秒あたり約 340 ページ（10 本）と約 290 ページ（300 本）を返し、エラーは 0 件でした。
遅くなったのは「全記事を 1 ページに並べた」ときだけ
比較のため、テンプレートには無い「全記事を 1 ページに並べる一覧」を検証用に足しました。ページ分けをせず、全記事の写真付きカードを並べる作りです。
このページだけは、はっきり遅くなりました。
- ページを作る時間は 3.6 ミリ秒から 35.4 ミリ秒に、約 10 倍
- ページそのもの（HTML）の大きさは約 39KB から約 600KB に
- 同時アクセスの試験では、1 秒あたり約 590 ページから約 30 ページに
- Lighthouse の点数は 98 点から 72 点に下がり、主な内容が表示されるまでの時間（LCP）は 2.3 秒から 5.2 秒に延びました
Google は LCP の目安を「2.5 秒以内」としています。全件を 1 ページに並べると、300 本の時点でこの目安を超えました。
つまり、記事が増えて遅くなるかどうかを決めるのは、CMS（ホームページの更新システム）の種類だけではなく、一覧ページをページ分けしているかどうかです。EmDash の標準テンプレートはページ分けされていますが、デザインを作り込むときに「全部を 1 ページに」と決めると、この遅さを自分で招くことになります。
各ページの Lighthouse の結果（点数と LCP、3 回の中央値）は次のとおりです。
ページ | 記事 10 本 | 記事 300 本 |
|---|---|---|
トップページ | 98 点・2.3 秒 | 98 点・2.3 秒 |
記事一覧（20 本ずつ） | 99 点・2.0 秒 | 99 点・2.1 秒 |
記事ページ | 97 点・2.4 秒 | 97 点・2.4 秒 |
全記事を 1 ページに | 98 点・2.3 秒 | 72 点・5.2 秒 |
ページの重さを決めていたのは、写真とフォントと外部のタグ
記事数よりも大きく効いていたのは、ページに何が載っているかです。記事ページ 1 枚の重さは約 360KB で、内訳は写真が約 165KB、文字の書体を読み込むフォントが約 98KB、HTML が約 52KB でした。JavaScript（画面を動かすためのプログラム）は、検索窓のための約 6KB が 1 本だけです。
参考に、このサイト（nowever.co、EmDash 0.30 系、Cloudflare 上で運用）の EmDashラボ一覧ページも、同じ Lighthouse で 1 回測りました。点数は 100 点、LCP は 1.8 秒です。重さは約 860KB あり、そのうち日本語のフォントが約 460KB、JavaScript が約 240KB でした。JavaScript は 4 本とも、アクセス解析などの外部のスクリプトと、Cloudflare が自動で差し込むスクリプトで、サイト自身のものはありませんでした。
トップページは点数 97 点、LCP 2.3 秒でしたが、重さは約 6MB あり、そのうち背景の動画が約 4.6MB です。
なお、同じ日の別の時間帯に同じ設定で測った回では、一覧 67 点、トップ 62 点でした（柱の記事に記録）。1 回ずつの点数は大きく揺れるので、比べるときは点数より重さの内訳を見ます。
ここから言えるのは、ホームページの重さの多くは、写真や動画、日本語フォント、後から足すタグの選び方で決まるということです。CMS を EmDash にしても、写真を大きいまま載せたり、解析タグを何本も足したりすれば、ページは重くなります。
正直に書くと、この計測で分からないこと
- ローカルでの計測です。 実際の訪問者は、インターネットを通って Cloudflare の基盤からページを受け取ります。その経路の時間は、この数字に含まれていません。Cloudflare 上では、作ったページを各地に一時保存して返す仕組み（Workers Cache）や、データベースの読み出しを手前にためる仕組み（オブジェクトキャッシュ）も使えますが、今回はどちらも測っていません。アクセスが急に増えたときの仕組みと費用は、アクセスが急に増えたときの記事で扱っています。
- HTML は圧縮されずに送られていました。 今回の Node.js の構成では、サーバーが HTML を圧縮しませんでした。全記事を並べたページの約 600KB は、圧縮すれば約 38KB になる計算です（試算で、実測ではありません）。Lighthouse の点数が大きく下がった一因はここにあります。
- 写真は元の大きさのまま配信されていました。 Node.js とパソコン内への保存という構成では、画面の幅に合わせて写真を縮小する処理が効かず、スマートフォンにも元の写真が送られました。公式ドキュメントでは、Cloudflare 上では写真が自動で縮小されるとしていますが、今回は確かめていません。また、Cloudflare Images の無料プランで縮小できるのは月 5,000 件（写真と大きさの組み合わせ）までで、超えると新しい縮小は失敗します。写真の多いメディアでは、件数か有料プランを見込んでおく必要があります。
- 先頭の写真の読み込みが後回しになる設定でした。 ブログテンプレートの記事ページでは、アイキャッチ写真が「画面に入ってから読み込む」設定になっていて、LCP は 2.4 秒と目安ぎりぎりでした。公式ドキュメントは、ページ先頭の写真には優先して読み込む指定を付けるよう勧めています。デザインを作るときに直せる部分です。
- WordPress との比較はしていません。 同じ条件の WordPress の環境を用意していないため、「WordPress より何倍速い」とは言えません。WordPress でも、キャッシュの設定やテーマ次第で速いサイトは作れます。
- 300 本までです。 3,000 本や 1 万本では測っていません。記事ページの作り方から考えると大きくは変わらないはずですが、確かめてはいません。
記事を増やす前に、確かめておきたいこと
今回の結果から、オウンドメディアを始める前に確かめておくとよい点をまとめます。CMS を選ぶときだけでなく、デザインを発注するときにも使えます。
- 一覧ページはページ分けされているか。 全記事を 1 ページに並べる作りは、記事が増えるほど遅くなります。
- 写真は表示する大きさに合わせて縮小されるか。 公開する環境で、スマートフォンに送られる写真の大きさを確認します。
- ページ先頭の写真は優先して読み込まれるか。 LCP の目安 2.5 秒に直接効きます。
- 解析タグや外部のスクリプトは、本当に必要な分だけか。 今回のサイトでは、JavaScript の重さはほぼすべて後から足したものでした。
- 日本語フォントの読み込み方は決まっているか。 書体の選び方で、数百 KB 単位で重さが変わります。
記事の本数が増えても、EmDash で作ったページの速さは保たれます。その速さを保てるかどうかは、一覧の作り方と、写真やタグの扱いにかかっています。今のホームページや、これから作るメディアの設計が気になる場合は、EmDashでつくるWebサイト制作からご相談ください。
参考（一次情報）
- Querying Content（EmDash 公式ドキュメント：一覧の並べ替えとページ分けはデータベースで行われる）https://docs.emdashcms.com/guides/querying-content/
- Media Library（EmDash 公式ドキュメント：先頭の写真に priority を付ける）https://docs.emdashcms.com/guides/media-library/
- Deploy to Cloudflare（EmDash 公式ドキュメント：画像の縮小、Workers Cache、無料枠）https://docs.emdashcms.com/deployment/cloudflare/
- Object Cache（EmDash 公式ドキュメント）https://docs.emdashcms.com/deployment/object-cache/
- Web Vitals（Google、LCP の目安 2.5 秒）https://web.dev/articles/vitals
- Lighthouse のスロットリング設定（Google、スマートフォン想定の標準設定）https://github.com/GoogleChrome/lighthouse/blob/main/docs/throttling.md
- 検証に使ったダミー記事の生成スクリプト、計測スクリプト、計測結果（2026年10月15日、EmDash 1.2.0）は、社内リポジトリに保存しています（再現可能）。
