- SWELLは本当に速いのか?
- ブログを運営していく中で遅くなったりしないか?
- 表示速度が原因でSEO評価が落ちないか?
AFFINGER6は高速化を意識して設計されたテーマです。しかし、「本当に速いのか」「運用を続けても遅くならないのか」は、初期状態だけでは判断できません。
表示速度は、記事追加や広告設置などの運用環境によって変わります。トップページが速くても、個別記事でLCPが悪化するケースもあります。
だからこそ、初期状態やテーマを入れ替えただけの数値ではなく、段階ごとの数値も確認する必要があります。
本記事では、記事0本の初期状態、記事10本追加後、個別記事、広告追加後までを測定し、中央値で比較します。SWELLの表示速度の特性と、運用後の変化量を検証します。
この記事を書いた人

税理士簿財&日商簿記1級受験生。簿記2級・FP2級・MOS・JADA上級心理カウンセラー資格を保有。将来的には、公認会計士資格の取得を目指しており、その後は慶應義塾大学法学部通信課程への進学、さらに予備試験・司法試験への挑戦も視野に入れています。
会計・簿記・FPの「数字と構造の視点」と、認知心理学・行動心理学による「人が迷い、止まり、動けなくなる理由」を組み合わせて、“選び方の構造”と“判断基準の作り方”を設計しています。
WordPressテーマを、「有名かどうか」「性能が高いか」ではなく、迷わず使えるか、続けられるか、詰んだときに戻れるか、経験がムダにならないか。こうした“実際に続くかどうか”の視点で整理しているのが特徴です。
売るためのレビューではなく、「自分で判断できるようになるための材料」をまとめています。
SWELLの表示速度を検証する前提条件
まず、今回の検証条件をまとめます。
今回はSWELLの素の状態の表示速度を検証しています。テーマそのものがどれくらい速いのかを確かめたかったからです。
- サーバー
-
エックスサーバー
- 高速化機能
-
OFF
- キャッシュ
-
未使用
- CDN
-
未使用
- テーマの高層化
-
未使用
- 採用数値
-
中央値(※たまたま速かった・遅かった回を除くため)
- 測定ツール
-
PageSpeed Insights
- その他
-
ページの中身の量(DOM)や読み込み数(requests)も確認。
SWELL表示速度検証でこの条件を採用した理由
テーマやサーバーの高速化機能をONにすれば、表示速度は確かに速くなります。
ですが、それでは「テーマそのものの性能」を正しく測れません。
高速化設定の影響が混ざると、どこまでがテーマの実力で、どこからが追加設定による効果なのかが分からなくなるからです。
ためそのため本検証では、外部要因をできるだけ排除し、テーマ単体の土台となる表示性能を確認できる条件を採用しています。
なお、表示速度が実際の操作感や作業効率にどう影響するかは、下記の記事で検証しています。速度は数値だけでなく、体感とセットで見る必要があります。

フェーズ0|SWELLは速い?記事0件の表示速度
本検証では、デフォルト(インストール直後)の速さを確認しています。
検証の前提条件は次のとおりです。
- 記事数
-
0
- 画像
-
なし
- 広告
-
なし
- テーマ高速化
-
すべてOFF
- サーバー高速化
-
すべてOFF
- CDN
-
未使用
- 採用値
-
中央値
- 測定ツール
-
PageSpeed Insights
SWELL表示速度の測定結果(中央値)

| 項目 | 1回目 | 2回目 | 3回目 | 4回目 | 5回目 | 平均 |
|---|---|---|---|---|---|---|
| PC | 99 | 98 | 99 | 99 | 100 | 99 |
| PC LCP | 0.8 | 1.1 | 0.8 | 0.9 | 0.8 | 0.88 |
| モバイル | 81 | 94 | 92 | 88 | 82 | 87.4 |
| モバイル LCP | 4.5 | 3.0 | 2.9 | 3.8 | 4.4 | 3.72 |
PCはほぼ満点に近い安定した数値です。
一方、モバイルでは、LCPが約3.7秒となりました。
LCPとは、「ページの一番大きな要素が表示されるまでにかかる時間」です。
多くのページでは、ファーストビューの画像やメインビジュアルが対象になるため、「一番目立つ画像が表示されるまでの時間」と考えておけば概ね問題ありません。
ためSWELLのモバイルLCP3.7秒は極端に遅い数値ではありませんが、やや時間がかかっています。
SWELLのLCP3~4秒台の原因を特定(LCP要素の検証)
最初の測定では、モバイルのLCPは3~4秒台でした。
「テーマが遅いのか?」と思い、DevToolsで原因を確認したところ、ページの一番大きな表示部分として読み込まれていたのは、外部配信の 1600×1200px画像(picsum.photos) であることが分かりました。
この画像はトップページのメインビジュアルおよび記事スライダー内で使われていました。


LCPが遅かった原因
1600pxクラスの画像は、スマホで見るには明らかに大きすぎます。
しかも外部から読み込む画像だったため、表示されるまでに時間がかかっていました。
その結果、LCPが3~4秒台まで伸びていました。
対処
そこで、メインビジュアルを削除し、記事スライダーをOFFにして、再度測定しました。
すると、モバイルLCPは1.2秒まで改善しました。

ここから分かること
最初に遅くなっていた原因は、テーマそのものではありません。
画面の一番上に置いた「大きな画像」が原因でした。
ためこのようにLCPは、テーマの速さそのものではなく、最初に大きく表示される部分が何かで決まります。
フェーズ0の基準値確定(SWELL表示速度・記事0件)
最終的な数値は、次のとおりです。
- PC LCP
-
0.3秒
- モバイルLCP
-
1.2秒
- 測定回数
-
5回
- 採用数値
-
中央値(PageSpeedは、測るたびに多少ブレるため、一番速かった回や一番遅かった回は使っていません。)
| 項目 | 1回目 | 2回目 | 3回目 | 4回目 | 5回目 | 平均 |
|---|---|---|---|---|---|---|
| PC | 100 | 100 | 100 | 100 | 100 | 100 |
| PC LCP | 0.2 | 0.3 | 0.3 | 0.3 | 0.3 | 0.28 |
| モバイル | 100 | 100 | 100 | 98 | 98 | 99.2 |
| モバイル LCP | 1.1 | 1.2 | 1.2 | 1.2 | 1.2 | 1.18 |
初回測定では、モバイルLCPは3.8秒でした。
しかし、その原因は画面の一番上に表示されていた大きな画像にありました。
LCPの対象を修正し、もう一度測定したところ、最終的な基準値は1.2秒になりました。
ここから分かること
SWELLの素の状態は、少なくとも初期設定のままでも良好な数値を示しています。
LCPはテーマの「重さ」そのものよりも、ファーストビューに何を配置するかによって大きく変動します。大きな画像やスライダーを置けば数値は悪化し、シンプルな構成なら安定します。
ためつまり、LCPはテーマの重さというより、「最初にどんな画像やデザインを置くか」に大きく左右されます。そのため、テーマだけが原因で遅くなるとは言えません。
検証結果を見るかぎり、SWELLは遅いテーマではありません。初期設定のままでも大きく数値が崩れることはないので、軽量化されているテーマだと考えてよさそうです。
フェーズ1|記事10本追加後もSWELLの表示速度は速いか
フェーズ0では、記事が1本もない状態を測定しました。
しかし、実際のブログは記事が増えていきます。
そこで、記事を10本追加した状態で表示速度を測定しました。
- 記事数
-
10
- アイキャッチ
-
10枚
- 画像
-
40枚
- MP3動画
-
6本
- 広告
-
なし
- テーマ高速化
-
すべてOFF
- サーバー高速化
-
すべてOFF
- CDN
-
未使用
- 採用値
-
中央値
- 測定ツール
-
PageSpeed Insights
なお、画像サイズや配置は、すべて固定しています。
つまり、記事を増やしただけでなく、画像やメディアも含めた「実際の運用に近い状態」で測定しています。
ため表示速度は、記事数・画像枚数・メディアの有無によって変わります。だから、どれくらいの量を載せた状態なのかを明確にしています。
SWELL表示速度の測定結果(5回測定・中央値)
記事を10本追加し、トップページを新着記事一覧の状態で測定しました。
5回測定し、中央値を採用しています。
| 項目 | 1回目 | 2回目 | 3回目 | 4回目 | 5回目 | 平均 |
|---|---|---|---|---|---|---|
| PC | 100 | 100 | 100 | 100 | 100 | 100 |
| PC LCP | 0.3 | 0.4 | 0.3 | 0.5 | 0.5 | 0.4 |
| モバイル | 98 | 98 | 98 | 98 | 98 | 98 |
| モバイル LCP | 1.2 | 1.2 | 1.6 | 1.6 | 1.6 | 1.44 |
フェーズ0(記事0本)のモバイルLCPは1.2秒でした。それに対して今回は1.44秒。
約0.2秒の増加です。
わずかに遅くなっていますが、依然として2秒未満を維持しています。
なぜ遅くならないのか
一覧ページでは、複数のアイキャッチ画像を読み込みます。
それでも遅くならなかったことから、画像の読み込み方法や表示の順番がうまく設計されている可能性があります。
ためつまり、「SWELL自体が記事が増えても表示速度が遅くなりにくい設計をしている」と考えられます。
記事追加でSWELL表示速度は遅くなるか(DOM・リクエスト増加量)
記事0件と10件の状態で、記事0件と10件の状態でDOMおよびリクエスト数を比べました。
| フェーズ0 | フェーズ1 | 変化量 | |
|---|---|---|---|
| DOM | 187 | 320 | +133 |
| requests | 33 | 39 | +6 |
DOMは187 → 320に増え、約71%増加しました。
記事が増えれば、ページの中身(HTMLの量)が増えるのは当然のことです。
一方で、requestsは33 → 39。
増えたのは 6件だけ でした。
ここから分かること
一覧ページでは、複数の記事ブロックを表示します。それでも、外部との通信は大きく増えていません。
つまり、記事が増えても無駄な読み込みが急増する構造ではないと考えられます。
ため画像の読み込みや、スクリプトの設計がうまく機能している可能性があります。
SWELLの積み上げ耐性(記事0→10本で表示速度はどう変わるか)
記事を0本から10本に増やした結果は、次の通りです。
- PC LCP
-
+0.2秒
- モバイルLCP
-
+0.4秒
- requests
-
+6
- DOM
-
+133
| 項目 | 1回目 | 2回目 | 3回目 | 4回目 | 5回目 | 平均 |
|---|---|---|---|---|---|---|
| PC | 100 | 100 | 100 | 100 | 100 | 100 |
| PC LCP | 0.3 | 0.4 | 0.3 | 0.5 | 0.5 | 0.4 |
| モバイル | 98 | 98 | 98 | 98 | 98 | 98 |
| モバイル LCP | 1.2 | 1.2 | 1.6 | 1.6 | 1.6 | 1.44 |
DOMは大きく増えました。
これは、記事数や装飾が増えればページの構成要素も増えるため、ある意味で自然な動きです。
それでも、モバイルのLCPは2秒未満を維持しており、表示速度が遅くなることはありませんでした。
ここから言えるのは、SWELLは記事や画像などのLCP要素が増えても、重くなる設計をしていないということです。
ため今回の検証でも、DOMは増加しましたが、LCPは大きく悪化していません。つまり、運用を続けても遅くなりにくいテーマだと考えられます。
したがって、「最初は速いけど、記事が増えたら一気に重くなる」というテーマではありません。
フェーズ2|実運用でSWELLは速いか(個別記事)
フェーズ2では、トップページではなく、実際に読まれる「個別記事」で表示速度を測定します。
なぜなら、検索から訪れる読者の多くはトップページではなく、個別記事に直接アクセスするからです。実運用に近い数値を見るためには、個別記事での測定が現実的だと判断しました。
検証の前提条件は以下の通りです。
- アイキャッチ
-
あり(1536×1024px)
- 記事本文
-
7,097文字
- 画像枚数
-
1枚
- レイアウト
-
個別記事レイアウト
- テーマ側高速化設定
-
OFF
- サーバー側高速化設定
-
OFF
ためトップページは軽く見えても、個別記事で重くなるテーマもあります。そのため本フェーズでは、「実際に読者が開くページで、どれだけ安定しているか」を確認します。
個別記事でのSWELL表示速度測定結果(中央値)
| 項目3 | 1回目 | 2回目 | 3回目 | 4回目 | 5回目 | 平均 |
|---|---|---|---|---|---|---|
| PC | 100 | 100 | 100 | 100 | 100 | 100 |
| PC LCP | 0.5 | 0.5 | 0.5 | 0.5 | 0.5 | 0.5 |
| モバイル | 98 | 99 | 99 | 97 | 99 | 98.4 |
| モバイル LCP | 2.0 | 1.8 | 1.8 | 2.0 | 1.8 | 1.88 |
モバイルLCPは 1.88秒。
フルサイズの大きなアイキャッチ画像を使っているにもかかわらず、2秒未満に収まっています。
これは、
- 画像が適切に読み込まれている
- 描画処理が詰まっていない
- 初期表示が安定している
ことを示しています。
ため一覧ページだけでなく、実際に読者が開く「個別記事」でも、表示速度は大きく落ちていません。
画像を追加しても極端に重くなる様子はなく、コンテンツを増やしても急に遅くなりにくい設計だと考えられます。
SWELLのLCP要素の内訳(なぜ2秒台になるのか)
PageSpeed Insightsの「LCPの内訳」タブを開いて確認しました。
すると、LCP要素として検出されていたのは次の画像でした。

img width="1536" height="1024"
class="p-articleThumb__img"
sizes="(min-width: 960px) 960px, 100vw"一見すると「1536pxのフルサイズ画像」をそのまま読み込んでいるように見えます。
ですが実際は、画面サイズに合わせた大きさで読み込まれていました。つまり、必要以上に大きな画像をそのまま表示しているわけではありません。
さらに、画像が読み込まれてから表示されるまでの待ち時間もほとんどなく、画像を読み込んだらすぐ画面に表示されています。
ためその結果、モバイル環境でもLCPは約1.9秒に収まっていました。
フェーズ2の評価|SWELL表示速度は速いか
個別記事の測定結果は、次の通りです。
- PC スコア
-
100
- PC LCP
-
0.5秒
- モバイルスコア
-
98
- モバイル LCP
-
1.88秒
| 項目3 | 1回目 | 2回目 | 3回目 | 4回目 | 5回目 | 平均 |
|---|---|---|---|---|---|---|
| PC | 100 | 100 | 100 | 100 | 100 | 100 |
| PC LCP | 0.5 | 0.5 | 0.5 | 0.5 | 0.5 | 0.5 |
| モバイル | 98 | 99 | 99 | 97 | 99 | 98.4 |
| モバイル LCP | 2.0 | 1.8 | 1.8 | 2.0 | 1.8 | 1.88 |
ここで分かること
1536pxのフルサイズ画像をアイキャッチに設定しても、モバイルのLCPは約2秒前後で安定しています。
「大きな画像=重い」と思いがちですが、実際には画面サイズに合わせた大きさで読み込まれています。つまり、必要以上に大きなデータをそのまま表示しているわけではありません。
さらに、画像は読み込み後すぐに画面に表示されており、表示までの待ち時間も小さく抑えられています。
ためそのため、フルサイズ画像を使っても、表示速度が大きく遅くなることはありませんでした。
つまり、大きな画像を使っても重たくなる設計ではない、ことが分かります。
テーマの価値は、運用を重ねたときに表示速度がどう変化するかで判断すべきです。価格に対して妥当かどうかは下記の記事でまとめています。

フェーズ3|告追加後もSWELLは速いか
フェーズ3では、実際のブログ運用環境に合わせ、広告を設置した状態で測定を行います。
- 記事数
-
10記事
- フォント
-
游ゴシック
- サイドバー広告
-
1枠
- トップ下広告
-
2枠
- 広告サイズ
-
300×250
- テーマ側高速化設定
-
OFF
- サーバー側高速化設定
-
OFF
- CDN
-
未使用
- 測定回数
-
5回(中央値)
これまでのフェーズでは、「テーマ単体の速さ」と「個別記事での表示速度」を確認してきました。
つまり、余計な要素をできるだけ入れない状態での土台の速さを見てきたということです。
ためフェーズ3では、そこに広告を設置した場合、表示速度がどれだけ変化するのかを確認します。
実際の運用に近い状態で、どの程度影響が出るのかを見たいからです。
広告追加後のSWELL表示速度測定結果(中央値)
| 項目 | 1回目 | 2回目 | 3回目 | 4回目 | 5回目 | 平均 |
|---|---|---|---|---|---|---|
| PC | 100 | 100 | 100 | 100 | 100 | 100 |
| PC LCP | 0.4 | 0.4 | 0.4 | 0.5 | 0.5 | 0.44 |
| モバイル | 98 | 99 | 99 | 98 | 98 | 98.4 |
| モバイル LCP | 1.6 | 1.8 | 1.8 | 1.6 | 1.6 | 1.68 |
広告を3枠設置しても、モバイルLCPは約1.7秒で安定しています。
フェーズ2(広告なし)の1.88秒と比べても、大きな悪化は確認できませんでした。
ため広告を追加しても表示速度が極端に遅くなる設計ではない、ことが分かります。
広告追加でSWELL表示速度は遅くなるか(DOM・requests増加量)
記事10本の状態(フェーズ1)と、広告3枠を追加した状態(フェーズ3)を比較しました。
| フェーズ1 | フェーズ3 | 変化量 | |
|---|---|---|---|
| DOM | 320 | 319 | ほぼ変化なし |
| requests | 39 | 41 | +2 |
DOMはほぼ変化なし。requestsは+2件の増加にとどまっています。
つまり、広告を追加しても、ページを構成するパーツが増えたり、読み込むデータ量が増加してたりしているわけではありません。
ためそのため、広告を3枠追加した程度では、ページが急に重くなるような変化は見られませんでした。
SWELLの広告耐性(表示速度・CLS評価)
広告を3枠設置した状態の測定結果は、次の通りです。
| PCスコア | 100 | フェーズ1とほぼ変化なし |
| PC LCP | 0.44秒 | フェーズ1とほぼ変化なし |
| モバイルスコア | 98.4 | フェーズ1とほぼ変化なし |
| モバイル LCP | 1.68 | フェーズ1より+0.24秒増加 |
| DOM | 320 | フェーズ1とほぼ変化なし |
| requests | 41 | フェーズ1より+2件増加 |
| 項目 | 1回目 | 2回目 | 3回目 | 4回目 | 5回目 | 平均 |
|---|---|---|---|---|---|---|
| PC | 100 | 100 | 100 | 100 | 100 | 100 |
| PC LCP | 0.4 | 0.4 | 0.4 | 0.5 | 0.5 | 0.44 |
| モバイル | 98 | 99 | 99 | 98 | 98 | 98.4 |
| モバイル LCP | 1.6 | 1.8 | 1.8 | 1.6 | 1.6 | 1.68 |
広告を3枠設置しても、モバイルのLCPは約1.7秒で安定しています。
広告なしの状態(フェーズ2:1.88秒)と比べても、大きく遅くなっている様子はありませんでした。
ためつまり、この条件では、広告を追加しても表示速度への影響は小さく、全体として安定していると考えられます。
そもそも広告を入れて収益化を目指す前提があるなら、テーマ自体が商材として戦えるかどうかも確認しておくべきです。その点は下記の記事で検証しています。

総合評価|SWELLは速いテーマか?表示速度の特性
今回の検証では、初期状態から記事の積み上げ、フルサイズ画像の使用、広告設置まで、実際の運用を想定した段階的な測定を行いました。
その結果、次のことを確認できました。
- 記事を増やしても、表示速度は大きく崩れない
- フルサイズ画像を使っても、モバイルLCPは約2秒前後に収まる
- 広告を追加しても、致命的な劣化は起きない
つまり、SWELLは「最初だけ速いテーマ」ではなく、条件が増えても安定しやすい設計だと考えられます。
表示速度は、初期の数値そのものよりも、運用を続けたときにどう変化するかのほうが重要です。
ためその点において、SWELLは実際のブログ運営でも遅くなりにくいテーマだと評価できます。
SWELL表示速度検証で分かった事実
今回の検証から分かったのは、SWELLは「初期が速いテーマ」ではなく、記事や広告を追加しても遅くなりにくい「安定性が高いテーマ」ということです。
- 記事を10本追加しても、モバイルLCPの増加は約0.4秒
- フルサイズ画像を使用しても、約2秒前後に収まる
- 広告を3枠追加しても、大きな悪化は見られない
つまり、条件を増やしても、表示速度が大きく悪化することはありませんでした。
記事を増やしたり広告を入れたりしても、速度が遅くなることが見られなかった、ということです。
SWELL表示速度で本当に見るべきは“運用後の変化量”
表示速度は初期状態で測るだけでは不十分です。
理由は下記の通り。
- 記事数が増えていくから
- 画像数も増えていくから
- 広告も入るから
WordPressテーマ(SWELL)は使い続けるものです。
そのため、何もない状態の速さよりも、画像や広告が増えたときにどれだけ遅くならないかのほうが重要です。
ためだからこそ見るべきなのは、記事・画像・広告などが増えたときに、どれだけ遅くなりにくいかという点です。
SWELLは運用後も表示速度が遅くなりにくいテーマ
その点で、SWELLは“瞬間的な速さ”ではなく、運営を続けても遅くなりにくい設計であることが分かりました。
言い換えると、表示速度が安定しており、急に重くなりにくいということです。
もちろん、プラグインを過剰に入れたり、動画や大容量ファイルを大量に設置すれば重くなります。
ためしかし、通常の運用範囲であれば、表示速度が極端に遅くなる構造ではないといえます。
重要なのはここです。
表示速度の改善に時間を使うのか、コンテンツ制作に時間を使うのか。その選択は、そのまま収益効率に跳ね返ります。
時間を含めた回収目安は、下記の記事で検証しています。
まとめ|SWELLは表示速度が速いテーマか?
- 記事を10本追加しても、モバイルLCPの増加は約0.4秒にとどまった
- フルサイズ(1536px)画像を使用しても、モバイルLCPは約2秒前後で安定した
- 広告を3枠追加しても、表示速度の大きな悪化は確認されなかった
- DOMは増加しても、requestsの増加は限定的だった
- 初期の速さよりも「運用後の変化量が小さいこと」が強みといえる
- 表示速度は、速ければ速いほど順位が上がり続けるものではありません。
- むしろ、極端に遅くなって評価を落とさないための“土台”と考えるのが現実的です。
SWELLは、瞬間的に速いだけでなく、運用を続けても遅くなりにくいテーマです。
記事が増えても表示速度を気にして立ち止まる必要がありません。表示速度の改善や高速化に時間を取られず、コンテンツ作成に集中できます。
ためつまり、表示速度に足を引っ張られない環境が手に入るということです。
あとは、実際の仕様やサポート体制も確認しながら、SWELLが自分に合うかどうかを判断してみてください。
\ ここまで整理した前提をもとに、公式情報も確認しておきましょう /
SWELL関連記事
-
SWELLの値段17,600円は妥当なのか?有料テーマ相場と内包物で検証
-
SWELLはなぜ高い?選んでも大丈夫なのかを検証【会計×FP視点】
-
SWELLのコスパは本当に良い?費用対効果を作業時間ベースで検証
-
SWELLは稼げる?元は取れるのか|回収目安と12か月ROIを検証【会計・FP視点】
-
SWELLは得する?損する?値段以上の価値があるのかをNPVで検証
-
【案件検証】SWELLアフィリエイトは稼ぎやすい?市場規模と商材力をデータ分析
-
SWELLは本当に使いやすい?初期設定・書きやすさ・サポートまで検証
-
【数値検証】SWELLアフィリエイトは本当に稼げる?収益化ラインと12か月累計利益を試算






コメント