画像の多い記事も快適に読めるか：EmDash の表示速度を条件をそろえて測る

画像の多いメディアでも、読者が待たずに読み始められるかは大切です。EmDash 1.2.0 のブログの雛形で、同じ文章と図版を使った記事を測定しました。今回の条件では、画像を軽くすると読み込み時の転送量が減りました。主要部分の表示時間の中央値も、約2.78秒から約2.55秒になりました。

ただし、表示時間には測定ごとのばらつきもありました。元の画像を使った記事では、3回のうち1回が約14.12秒でした。CMS の名前や一つの点数だけで速さを判断せず、どんな記事を、どの条件で測ったかと合わせて見ていきます。

同じ記事を使い、画像の形式と容量を変えて測った

検証日は2026年10月15日。EmDash 1.2.0、Astro 7.3.8 のブログの雛形を使いました。Node.js 向けに本番用のページを作り、手元のパソコンで動かしています。開発中のページをそのまま測ったものではありません。

記事の本文には図版を6点入れ、冒頭の画像にもそのうち1点を使いました。元の PNG 画像を使う記事と、同じ画像を横幅1,000ピクセルの WebP という軽量な形式へ変換した記事を用意しています。文章と配置は共通です。本文の6点がページに出ることと、各画像を取得できることを確かめてから測りました。画像の変換は今回の検証で事前に行った処理であり、EmDash が自動で行ったものではありません。

測定には Lighthouse 12.8.2 を使いました。スマートフォン向けの表示と、通信・処理速度を再現する既定の条件で、各ページを3回ずつ測っています。以下は、その中央値です。

転送量は減り、表示時間の中央値も短くなった

主要部分の表示時間には、LCP という指標を使います。最初の画面で大きく表示される画像や文章が、見えるまでの時間です。ページ全体の読み込みが終わる時間とは異なります。

容量は1 KBを1,000バイトとして丸めています。性能スコアの中央値は PNG の記事が95、WebP の記事が97でした。測定中の表示ずれを示す値は、どちらの記事も3回とも0でした。

記事の転送量には大きな差が出ましたが、主要部分の表示時間の中央値の差は約0.23秒でした。転送量の減少率が、そのまま表示時間の短縮率になるわけではありません。

各回の表示時間は、PNG の記事が約2.78秒、約14.12秒、約2.78秒でした。WebP の記事は3回とも約2.55〜2.56秒です。PNG の2回目が長くなった原因は特定していません。この差を除いて良い結果だけを選ばず、中央値と各回の値を合わせて残しています。

また、表の転送量は測定中に読み込まれたものです。読み込み記録では、各記事で図版6点のうち4ファイルを取得していました。本文のすべての画像を、記事の最後までスクロールして読み込んだ合計ではありません。記事一覧では、検証用の画像の取得はありませんでした。

記事の LCP の対象は冒頭の画像でした。画面の下にある画像を後から読み込む仕組みも含め、画像の容量と表示方法を合わせて確認する必要があります。

点数と一緒に、読者が見る記事の条件を確認する

今回の結果は、図版を載せた記事と一覧が、指定の条件でどう表示されたかを示すものです。EmDash を使えば、どのホームページも同じ点数になるという意味ではありません。

企業メディアでは、写真、動画、アクセス解析、問い合わせの案内なども載ります。今回の計測ページには、外部のアクセス解析と埋め込み動画を入れていません。通信距離、実際のスマートフォンの性能、多数の同時アクセスも再現していません。

WordPress と同じ記事を載せた比較も行っていません。この結果から、WordPress より何倍速いという説明はできません。

導入時には、実際に掲載する写真や図版と、使う予定の外部サービスを含めて測定します。軽いサンプルページだけでなく、画像の多い取材記事や記事一覧も確認することが大切です。

画像の準備と表示の仕組みを合わせて整える

今回、画像の準備を変えることで転送量を減らせました。日々の入稿で毎回担当者が迷わないよう、画像の大きさや形式、文章で伝える説明のルールを決めておくと運用しやすくなります。

制作時には、画面の幅に合うサイズを配信するか、最初に見える画像を優先するか、本文の下の画像を後から読み込むかを確認します。これらは、EmDash の画像の扱いと、ホームページ側の表示設定を合わせて考える部分です。

WordPress からの取り込みでは、画像が表示されても、元のサイズをそのまま配信していた例がありました。画像を取り込めたことと、軽く読めることは別に検証します。詳細は日本語記事の移行検証で紹介しています。

容量だけを減らして文字入りの図が読めなくなれば、本来の目的に合いません。スマートフォンで図の文字が読めるか、写真の必要な部分が見えるかも、実際の画面で確認します。

公開後も、代表的な記事を決めて測り続ける

表示速度は、制作が終わった日に一度測れば完了というものではありません。新しい案内や外部サービスを追加した後にも、同じページを同じ条件で測ると変化が分かります。

最初に、普通の解説記事、画像の多い記事、記事一覧を確認対象として決めます。点数だけでなく、主要部分の表示時間と転送量、実際の読みやすさを残します。公開後は、実際の読者の環境で得られるデータとも合わせて評価します。

EmDash の構成を活かすには、記事の中身と配信の仕方まで含めて作ることが重要です。まずは、自社で最も画像の多い記事を一本選び、納品前の確認対象に入れてください。

実際の原稿と画像を使って閲覧体験を確かめたい場合は、EmDashでつくるWebサイト制作からご相談ください。

参考（一次情報）

• 画像の管理（EmDash 公式）
• Lighthouse の性能スコア（Chrome 公式）
• 表示速度の測定：2026年10月15日、EmDash 1.2.0、Astro 7.3.8、Lighthouse 12.8.2。測定条件、各回の値、再現手順を制作ノートに保存。