SWELLは本当に速い?初期状態と実運用で表示速度を実測検証

当記事にはアフィリエイトリンクが含まれる場合がありますが、評価は特定の商品やサービスの購入を促すことを目的としたものではなく、コンテンツの内容にも一切関与していません。
こんな疑問を解決します
  • 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回目平均
PC9998999910099
PC LCP0.81.10.80.90.80.88
モバイル819492888287.4
モバイル LCP4.53.02.93.84.43.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回目平均
PC100100100100100100
PC LCP0.20.30.30.30.30.28
モバイル100100100989899.2
モバイル LCP1.11.21.21.21.21.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回目平均
PC100100100100100100
PC LCP0.30.40.30.50.50.4
モバイル989898989898
モバイル LCP1.21.21.61.61.61.44

フェーズ0(記事0本)のモバイルLCPは1.2秒でした。それに対して今回は1.44秒

約0.2秒の増加です。

わずかに遅くなっていますが、依然として2秒未満を維持しています。

なぜ遅くならないのか

一覧ページでは、複数のアイキャッチ画像を読み込みます。

それでも遅くならなかったことから、画像の読み込み方法や表示の順番がうまく設計されている可能性があります。

ため

つまり、「SWELL自体が記事が増えても表示速度が遅くなりにくい設計をしている」と考えられます。

記事追加でSWELL表示速度は遅くなるか(DOM・リクエスト増加量)

DOM・・・ページ全体のパーツ数
requests・・・ページを表示するためにファイルを取りに行った回数

記事0件と10件の状態で、記事0件と10件の状態でDOMおよびリクエスト数を比べました。

フェーズ0フェーズ1変化量
DOM187320+133
requests3339+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回目平均
PC100100100100100100
PC LCP0.30.40.30.50.50.4
モバイル989898989898
モバイル LCP1.21.21.61.61.61.44

DOMは大きく増えました。

これは、記事数や装飾が増えればページの構成要素も増えるため、ある意味で自然な動きです。

それでも、モバイルのLCPは2秒未満を維持しており、表示速度が遅くなることはありませんでした。

ここから言えるのは、SWELLは記事や画像などのLCP要素が増えても、重くなる設計をしていないということです。

ため

今回の検証でも、DOMは増加しましたが、LCPは大きく悪化していません。つまり、運用を続けても遅くなりにくいテーマだと考えられます。

したがって、「最初は速いけど、記事が増えたら一気に重くなる」というテーマではありません。

フェーズ2|実運用でSWELLは速いか(個別記事)

フェーズ2では、トップページではなく、実際に読まれる「個別記事」で表示速度を測定します。

なぜなら、検索から訪れる読者の多くはトップページではなく、個別記事に直接アクセスするからです。実運用に近い数値を見るためには、個別記事での測定が現実的だと判断しました。

検証の前提条件は以下の通りです。

前提条件
アイキャッチ

あり(1536×1024px)

記事本文

7,097文字

画像枚数

1枚

レイアウト

個別記事レイアウト

テーマ側高速化設定

OFF

サーバー側高速化設定

OFF

ため

トップページは軽く見えても、個別記事で重くなるテーマもあります。そのため本フェーズでは、「実際に読者が開くページで、どれだけ安定しているか」を確認します。

個別記事でのSWELL表示速度測定結果(中央値)

項目31回目2回目3回目4回目5回目平均
PC100100100100100100
PC LCP0.50.50.50.50.50.5
モバイル989999979998.4
モバイル LCP2.01.81.82.01.81.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秒

項目31回目2回目3回目4回目5回目平均
PC100100100100100100
PC LCP0.50.50.50.50.50.5
モバイル989999979998.4
モバイル LCP2.01.81.82.01.81.88

ここで分かること

1536pxのフルサイズ画像をアイキャッチに設定しても、モバイルのLCPは約2秒前後で安定しています。

「大きな画像=重い」と思いがちですが、実際には画面サイズに合わせた大きさで読み込まれています。つまり、必要以上に大きなデータをそのまま表示しているわけではありません。

さらに、画像は読み込み後すぐに画面に表示されており、表示までの待ち時間も小さく抑えられています。

ため

そのため、フルサイズ画像を使っても、表示速度が大きく遅くなることはありませんでした。

つまり、大きな画像を使っても重たくなる設計ではない、ことが分かります。

テーマの価値は、運用を重ねたときに表示速度がどう変化するかで判断すべきです。価格に対して妥当かどうかは下記の記事でまとめています。

フェーズ3|告追加後もSWELLは速いか

フェーズ3では、実際のブログ運用環境に合わせ、広告を設置した状態で測定を行います。

前提条件
記事数

10記事

フォント

游ゴシック

サイドバー広告

1枠

トップ下広告

2枠

広告サイズ

300×250

テーマ側高速化設定

OFF

サーバー側高速化設定

OFF

CDN

未使用

測定回数

5回(中央値)

これまでのフェーズでは、「テーマ単体の速さ」と「個別記事での表示速度」を確認してきました。

つまり、余計な要素をできるだけ入れない状態での土台の速さを見てきたということです。

ため

フェーズ3では、そこに広告を設置した場合、表示速度がどれだけ変化するのかを確認します。

実際の運用に近い状態で、どの程度影響が出るのかを見たいからです。

広告追加後のSWELL表示速度測定結果(中央値)

スクロールできます
項目1回目2回目3回目4回目5回目平均
PC100100100100100100
PC LCP0.40.40.40.50.50.44
モバイル989999989898.4
モバイル LCP1.61.81.81.61.61.68

広告を3枠設置しても、モバイルLCPは約1.7秒で安定しています。

フェーズ2(広告なし)の1.88秒と比べても、大きな悪化は確認できませんでした。

ため

広告を追加しても表示速度が極端に遅くなる設計ではない、ことが分かります。

広告追加でSWELL表示速度は遅くなるか(DOM・requests増加量)

記事10本の状態(フェーズ1)と、広告3枠を追加した状態(フェーズ3)を比較しました。

フェーズ1フェーズ3変化量
DOM320319ほぼ変化なし
requests3941+2

DOMはほぼ変化なし。requestsは+2件の増加にとどまっています。

つまり、広告を追加しても、ページを構成するパーツが増えたり、読み込むデータ量が増加してたりしているわけではありません。

ため

そのため、広告を3枠追加した程度では、ページが急に重くなるような変化は見られませんでした。

SWELLの広告耐性(表示速度・CLS評価)

広告を3枠設置した状態の測定結果は、次の通りです。

結果
PCスコア100フェーズ1とほぼ変化なし
PC LCP0.44秒フェーズ1とほぼ変化なし
モバイルスコア98.4フェーズ1とほぼ変化なし
モバイル LCP1.68フェーズ1より+0.24秒増加
DOM320フェーズ1とほぼ変化なし
requests41フェーズ1より+2件増加
スクロールできます
項目1回目2回目3回目4回目5回目平均
PC100100100100100100
PC LCP0.40.40.40.50.50.44
モバイル989999989898.4
モバイル LCP1.61.81.81.61.61.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は表示速度が速いテーマか?

SWELLの表示速度検証まとめ
  • 記事を10本追加しても、モバイルLCPの増加は約0.4秒にとどまった
  • フルサイズ(1536px)画像を使用しても、モバイルLCPは約2秒前後で安定した
  • 広告を3枠追加しても、表示速度の大きな悪化は確認されなかった
  • DOMは増加しても、requestsの増加は限定的だった
  • 初期の速さよりも「運用後の変化量が小さいこと」が強みといえる
  • 表示速度は、速ければ速いほど順位が上がり続けるものではありません。
  • むしろ、極端に遅くなって評価を落とさないための“土台”と考えるのが現実的です。

SWELLは、瞬間的に速いだけでなく、運用を続けても遅くなりにくいテーマです。

記事が増えても表示速度を気にして立ち止まる必要がありません。表示速度の改善や高速化に時間を取られず、コンテンツ作成に集中できます。

ため

つまり、表示速度に足を引っ張られない環境が手に入るということです。

あとは、実際の仕様やサポート体制も確認しながら、SWELLが自分に合うかどうかを判断してみてください。

\ ここまで整理した前提をもとに、公式情報も確認しておきましょう /

リンク先:https://swell-theme.com/

SWELL関連記事

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

コメント

コメントする

CAPTCHA


目次