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

AFFINGER6は高速化を意識して設計されたテーマです。しかし、「本当に速いのか」「運用を続けても遅くならないのか」は、初期状態だけでは判断できません。

表示速度は、記事追加や広告設置などの運用環境によって変わります。トップページが速くても、個別記事でLCPが悪化するケースもあります。

だからこそ、初期状態やテーマを入れ替えただけの数値ではなく、段階ごとの数値も確認する必要があります。

本記事では、記事0本の初期状態、記事10本追加後、個別記事、広告追加後までを測定し、中央値で比較します。AFFINGER6の表示速度の特性と、運用後の変化量を検証します。

AFFINGER6の表示速度を検証する前提条件

まず、今回の検証条件をまとめます。

今回はAFFINGER6の素の状態の表示速度を検証しています。テーマそのものがどれくらい速いのかを確かめたかったからです。

AFFINGER6の表示速度検証でこの条件を採用した理由

テーマやサーバーの高速化機能をONにすれば、表示速度は確かに速くなります。

ですが、それでは「テーマそのものの性能」を正しく測れません。

高速化設定の影響が混ざると、どこまでがテーマの実力で、どこからが追加設定による効果なのかが分からなくなるからです。

ため

そのため本検証では、外部要因をできるだけ排除し、テーマ単体の土台となる表示性能を確認できる条件を採用しています。

なお、表示速度が実際の操作感や作業効率にどう影響するかは、下記の記事で検証しています。速度は数値だけでなく、体感とセットで見る必要があります。

あわせて読みたい

AFFINGER6は使いやすい？初期設定・記事作成・カスタマイズの負担を検証 「AFFINGER6は使いやすい」「慣れれば稼げる」。そんな声がある一方で、「設定が多すぎて難しい」「初心者にはきつい」という評価も見かけます。結局のところ、自分でも…

フェーズ0｜AFFINGER6は速い？記事0件の表示速度

本検証では、デフォルト（インストール直後）の速さを確認しています。

検証の前提条件は次のとおりです。

AFFINGER6表示速度の測定結果（中央値）

PCは大きな問題はありません。

ただし、モバイルではLCPが約4.8秒とやや長めです。

LCPとは、「ページの一番大きな要素が表示されるまでにかかる時間」です。

多くのページでは、ファーストビューの画像やメインビジュアルが対象になるため、「一番目立つ画像が表示されるまでの時間」と考えておけば概ね問題ありません。

ため

数字だけを見ると、PCは安定しているが、モバイルは少し重いという状態です。

AFFINGER6のLCP4.8秒の原因（LCP要素の確認）

LCPとして検出されたのは、テーマ標準の「no image」画像（343×343）でした。

画像そのものの読み込み時間は約190msと短く、画像自体が重いわけではありません。

では、LCPがなぜ4秒台だったのか？

原因は、画像が「表示されるまでの待ち時間」が長かったことです。読み込みはすぐ終わっているのに、実際に画面に表示されるまでに約1,940msかかっていました。

ため

つまり、遅かったのは画像データの重さではなく、「表示のタイミング」の問題だったということです。

ここから分かること

原因は、画像のサイズではありません。

画像データ自体は軽く、読み込みもすぐ終わっていました。

それでも遅くなったのは、ページの見た目を整えるための処理（CSSやスクリプトの読み込み）が終わるまで、画像の表示が待たれていた可能性があるからです。

ため

つまり、「画像が重いから遅い」のではなく、表示される順番や処理の流れが影響していたと考えられます。

AFFINGER6のCSS・JS構成の確認

DevToolsで読み込み状況を確認したところ、ページを開いた直後から、複数のCSSやJavaScriptが読み込まれていました。

たとえば、「jQuery系のスクリプト」「slickスクリプト」「moment.js」などが、初期状態の段階で読み込まれていました。

これらは、ページの見た目や動きを整えるためのファイルです。スライダーを動かしたり、アニメーションを表示したり、日付を整えて表示したりする役割があります。

つまり、画像そのものが重いのではなく、「ページの動きを作るためのファイル」がいくつも先に読み込まれていて、その処理が終わるまで画像の表示が少し待たされた可能性がある、ということです。

ため

その結果、画像の表示タイミングが少し後ろに回り、LCPが遅くなったと考えられます。

AFFINGER6初期JSの総転送量（Console集計）

DDevToolsを使い、ページを開いた直後に読み込まれるJavaScriptの合計サイズを確認しました。

合計は95,422バイト（約93KB・転送量ベース） でした。数字だけを見ると、特別に大きい容量ではありません。それにもかかわらず、モバイルLCPは 4.8秒 のままでした。

ここから分かるのは、原因は「ダウンロード量の多さ」そのものではない、ということです。

ため

読み込むデータ量がそこまで大きくないにもかかわらず遅いということは、問題は“読み込んだあと”にある可能性が高いと考えられます。

つまり、たくさんダウンロードしているから遅いのではなく、画面を表示するまでの内部処理に時間がかかっていると推測できます。

AFFINGER6の表示速度が遅くなる原因

PageSpeedのレポートを見ると、「表示をブロックしているリクエスト」という項目に、約4,150msの改善余地があると表示されていました。

これは、一部のファイルの読み込みや処理が終わるまで、画面の表示が待たされている可能性がある、という意味です。

つまり、データ量が多いから遅いのではなく、「先に終わらせないといけない処理」があるために、表示が後回しになっている状態と考えられます。

影響していた主なファイル

特に影響が大きかったのは、次の2つです。

これらは、ページの見た目を整えるために、最初に読み込まれるファイルです。文字のデザインやレイアウトを決めるため、表示よりも先に処理されます。

そのため、これらの読み込みや処理が終わるまで、画面の表示が一時的に待たされることがあります。

ため

つまり、画像が重いというよりも、「見た目を整える準備」に時間がかかっていた可能性が高い、ということです。

ここから分かること

今回LCPとして検出されたのは、小さな「no image」画像でした。

画像データ自体は軽く、読み込みもすぐ終わっています。つまり、画像が重いことが原因ではありません。

それにもかかわらず表示が遅れていることから、原因は画像ではなく、最初に読み込まれるCSSやフォントの処理にある可能性が高いと考えられます。

フォント変更でAFFINGER6表示速度は速くなるか（LCPの変化）

最初の測定では、モバイルLCPは4.8秒でした。

原因を確認すると、Google Fonts（外部フォント）が読み込まれていました。外部フォントは、別のサーバーからデータを取得するため、その分だけ表示までに待ち時間が発生します。

そこで、フォントを外部フォントから「游ゴシック（端末にあらかじめ入っているフォント）」に変更し、再度測定しました。

その結果、モバイルLCPは4.0秒まで改善しました。

約0.8秒の短縮です。

ため

つまり、表示遅れは画像ではなく、外部フォントの読み込みが影響していた可能性が高いと考えられます。

フェーズ0の基準値確定（AFFINGER6表示速度・記事0件）

最終的な数値は、次のとおりです。

LCPとして検出されたのは、テーマ標準の「no image」画像（343×343）でした。画像データ自体は軽く、サイズも大きくありません。

それにもかかわらず約4秒かかっていることから、原因は画像の重さではないと考えられます。

PageSpeedのレポートでは、「表示を待たせているファイルがある」と指摘されていました。つまり、最初に読み込まれるCSSやスクリプトの処理が終わるまで、画面の表示が待たされていた可能性があります。

言い換えれば、画像が重いのではなく、「ページを整える処理」が表示時間に影響していたということです。

このことから分かるのは、AFFINGER6の素の状態は極端に重い画像を使っているわけではないという点です。ただ、初期表示の段階で読み込まれるファイルが多いため、モバイルでは表示までに時間がかかりやすい傾向があります。

ため

つまり、問題は画像サイズそのものではなく、画面を表示する前の準備処理が多いことにあると考えられます。

フェーズ1｜記事10本追加後もAFFINGER6は速いか

フェーズ0では、記事が1本もない状態を測定しました。

しかし、実際のブログは記事が増えていきます。

そこで、記事を10本追加した状態で表示速度を測定しました。

なお、画像サイズや配置は、すべて固定しています。

つまり、記事を増やしただけでなく、画像やメディアも含めた「実際の運用に近い状態」で測定しています。

ため

表示速度は、記事数・画像枚数・メディアの有無によって変わります。だから、どれくらいの量を載せた状態なのかを明確にしています。

AFFINGER6表示速度の測定結果（5回測定・中央値）

記事を10本追加し、トップページを新着記事一覧の状態で測定しました。

5回測定し、中央値を採用しています。

モバイルLCPの中央値は7.7秒となり、フェーズ0（4.0秒）から約3.7秒の悪化していることが確認できました。

記事を10本追加しただけで、モバイルLCPは約2倍近くまで増加しています。

ため

これは、記事一覧ページで表示する要素が増えたことにより、画面が表示されるまでの処理が重くなった可能性があります。

あわせて、初期に読み込まれるCSSやスクリプトの影響が積み重なっていることも考えられます。

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

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

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

DOMは約69％増加しています。requestsも17件増えています。

記事を10本追加したことで、ページを構成する部品（HTML）や読み込むファイルが増えていることが分かります。

その結果、モバイルLCPは4.0秒から7.7秒へと悪化しました。

ため

この変化の背景には、DOMの増加やrequestsの増加が影響している可能性があります。

つまり、表示する内容が増えたことで、画面が表示されるまでにかかる処理が重くなったと考えられます。

LCP要素の特定（AFFINGER6記事10本状態）

PageSpeed Insightsの「LCPの内訳」タブを開いて、LCP要素を確認したところ、LCP要素は記事一覧のアイキャッチ画像（1536px）でした。

画像単体の読み込み時間は約440msです。極端に重い数値ではありません。

それにもかかわらず、モバイルLCPは7秒台でした。

※表示速度測定結果

内訳を見ると、初期表示を待たせているCSSやJavaScriptの存在が示されています。つまり、画像のダウンロードが遅いのではなく、表示前の処理が完了するまで待たされている状態と考えられます。

ため

言い換えれば、遅延の主な原因は画像サイズそのものではなく、初期表示をブロックしている構造にある可能性が高い、ということです。

AFFINGER6の積み上げ耐性（記事0→10本で表示速度はどう変わるか）

フェーズ0（記事0件）とフェーズ1（記事10本）を比較すると、モバイルの表示速度は明確に悪化しました。

記事を10本追加しただけで、DOMは大きく増加し、LCPも約2倍近くまで伸びました。

LCP要素として検出されたのは、記事一覧のアイキャッチ画像（1536px）です。

ただし、画像単体が極端に重いわけではありません。問題は、初期表示を待たせるCSSやJavaScriptが多い状態のまま、一覧ページの上部に要素が積み上がる構造にあると考えられます。

その結果、モバイルLCPは7秒台まで伸びました。

ため

なお、本検証では遅延読み込みや画像最適化などの調整は行っていません。

そのため、この数値は「何も手を加えていない状態で、記事が増えたときの基準値」として扱います。

フェーズ2｜実運用でAFFINGER6は速いか（個別記事）

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

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

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

ため

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

個別記事でのAFFINGER6表示速度測定結果（中央値）

トップページ（モバイルLCP 7.7秒）と比べると、個別記事では約5.2秒まで改善しています。

しかし、フェーズ0（4.0秒）と比べると、まだ悪化している状態です。

つまり、

という結果になりました。

ため

背景としては、アイキャッチにフルサイズ画像を使用していることに加え、初期表示を待たせるCSSやJavaScriptの影響が残っている可能性があります。

AFFINGER6のLCP要素の内訳（なぜ5秒台になるのか）

PageSpeed Insightsの「LCPの内訳」タブで確認したところ、LCPとして計測されていたのは、次の画像でした。

img width="1536" height="1024"
attachment-full size-full wp-post-image

つまり、フルサイズのアイキャッチ画像が「ページ内で最も遅く表示された大きな要素」として認識されている、ということです。

LCPの内訳

LCPの内訳は次の通りです。

注目すべきは、レンダリング遅延が約3秒発生している点です。

通信が極端に遅いわけではありません。画像データが異常に重いわけでもありません。時間を使っているのは、ブラウザが画面表示を終わらせるまでの待ち時間です。

ため

つまり、今回の5秒台という数値は、画像サイズそのものよりも、初期CSSやJavaScriptを含む描画構造の影響が大きいと考えられます。

なぜトップページではAFFINGER6は速く見えたのか

トップページでは、LCP要素が軽量なダミー画像になっていました。

/themes/affinger/images/no-img-l.png
（202×202）

サイズも小さく、データ量も軽いため、LCPは短く表示されていました。

つまり、「テーマ全体が軽い」というよりも、LCPの対象がたまたま軽い画像だった、ということです。

表示速度はテーマ全体の重さだけで決まるものではありません。ファーストビューで最も大きく表示される要素が何かによって、大きく左右されます。

ため

今回トップページで速く見えたのは、LCP対象が軽量画像だったことが主な理由と考えられます。

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

あわせて読みたい

AFFINGER6の値段14,800円は妥当なのか？有料テーマ相場と内包で検証 本記事では、AFFINGER6通常版（14,800円）を対象に価格の妥当性を検証します。上位版であるAFFINGER6 EX（26,800円）や専用プラグインは別商品として扱い、本検証には含…

フェーズ2の基準値（AFFINGER6表示速度・個別記事）

個別記事の測定結果は、次の通りです。

AFFINGER6は、フルサイズ画像をそのまま出力する構造のため、モバイル表示ではLCPが5秒台まで伸びました。

これはテーマが重たいというよりも、

という傾向が見られる設計だと考えられます。

画像の最適化（WebP化や縮小、圧縮など）を行えば、改善の余地はあります。

しかし、今回の検証では高速化設定は行っていません。あくまで「何も手を加えていない状態」での実運用に近い数値です。

ため

その基準で見ると、モバイルLCPは約5秒台。これが、AFFINGER6における「個別記事・フルサイズアイキャッチ使用時」の基準値といえます。

フェーズ3｜広告追加後もAFFINGER6は速いか

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

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

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

ため

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

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

AFFINGER6表示速度の測定結果（5回測定・中央値）

PC側は安定しており、大きな問題は見られませんでした。

一方で、モバイルはスコア80前後で推移。モバイルLCPの中央値は4.18秒となりました。

フェーズ2（5.16秒）と比べるとやや改善していますが、初期状態（4.0秒）と比べると、依然として高めの水準にあります。

つまり、

という状態です。

広告追加でAFFINGER6表示速度は遅くなるか（DOM・requests増加量）

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

DOMは増えていません。requestsも増加どころか減少しています。

つまり、今回の表示速度の変化は「広告を追加したことによる負荷増加」が主な原因とは考えにくい、ということです。

ため

モバイルLCPが4秒台で推移しているのは、広告が重いからでも、外部通信が急増したからでもありません。

画面が表示されるまでに待ち時間が発生しやすい設計そのものの影響だと考えられます。

AFFINGER6の広告耐性（表示速度・CLS評価）

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

今回の検証で見えたのは、AFFINGER6は「LCP対象の影響を受けやすい」という点です。

記事数が増え、上部にフルサイズ（1536px）の画像を配置すると、LCPは7秒台まで伸びました。一方で、軽量画像が対象になると、4秒前後まで改善しています。

つまり、AFFINGER6の表示速度は、テーマそのものの重さというよりも、「最初に何を大きく表示するか」に強く左右される傾向があります。

ため

もちろん、高速化プラグインの導入や圧縮設定などを行えば、改善の余地はあります。ただ、何も最適化していない初期状態では、モバイルLCPはやや高めに出やすい傾向が見られました。

そもそも広告を入れて収益化を目指す前提があるなら、テーマ自体が商材として戦えるかどうかも確認しておくべきです。その点は下記の記事で検証しています。

あわせて読みたい

AFFINGER6アフィリエイト稼ぎやすい？市場規模と商材力をデータ分析 「AFFINGER6アフィリエイトは本当に稼げるのか？」「稼ぎやすい案件なのか？」「知名度があるから売りやすいのでは？」 そう思っていませんか。 確かにAFFINGER6は知名…

総合評価｜AFFINGER6は速いテーマか？表示速度の特性

今回の検証では、初期状態から記事の積み上げ、フルサイズ画像の使用、広告設置まで、実際の運用を想定した段階的な測定を行いました。

その結果、次のことを確認できました。

つまり、AFFINGER6は「記事数が増えても安定するタイプ」というよりも、最初に何を表示するかによって表示速度が大きく変わるテーマだと分かりました。

表示速度はテーマの軽さそのものよりも、

といった要素に強く影響されます。

そのため、設計を工夫すれば改善の余地はあります。一方で、何も最適化していない初期状態では、モバイル表示はやや重めに出やすい傾向があります。

表示速度を見る際は、「最初のスコア」だけでなく、運用後にどれだけ数値が動くかまで確認することが重要です。

ため

この観点で評価すると、AFFINGER6は設計の影響を受けやすいテーマだといえます。

設定や最適化を前提に、使いこなしていくタイプのテーマだと考えられますね。

AFFINGER6表示速度検証で分かった事実

今回の検証から分かったのは、AFFINGER6は「初期が速いテーマ」というよりも、表示速度が初期表示の構造に大きく左右されるテーマであるということです。

つまり、条件を変えたときの数値の動きが比較的大きいという特徴が確認できました。

言い換えれば、「何を最初に表示するか」「どのように設計するか」によって、表示速度が大きく変わるテーマだといえます。

AFFINGER6表示速度で本当に見るべきは“運用後の変化量”

表示速度は、初期状態だけで測っても十分とはいえません。

理由は下記の通り。

WordPressテーマ（AFFINGER6）は使い続けるものです。

そのため、何もない状態の速さよりも、画像や広告が増えたときにどれだけ遅くならないかのほうが重要です。

ため

だからこそ見るべきなのは、記事・画像・広告などが増えたときに、どれだけ遅くなりにくいかという点です。

AFFINGER6は設計次第で表示速度が変わるテーマ

今回の検証で分かったのは、AFFINGER6には次のような傾向があるという点です。

言い換えると、AFFINGER6は「瞬間的な速さ」で評価するテーマではなく、初期表示の設計や画像設定によって数値が大きく動くテーマです。

画像の縮小、WebP化、遅延読み込み、高速化設定などを行えば、表示速度は速くなります。しかし、何も手を加えていない初期状態では、モバイル表示はやや高めに出やすい傾向があります。

ため

そのため、通常運用であっても、「最初に何を大きく表示するか」という設計次第で、表示速度は数秒単位で変わるテーマだといえます。

ちなみに、表示速度改善に時間を使うのか、コンテンツ制作に時間を使うのか。その選択はそのまま収益に跳ね返ります。時間を含めた収益目安は下記の記事で検証しています。

まとめ：AFFINGER6は表示速度が速いテーマか？

• 表示速度は、速ければ速いほど順位が上がり続けるものではありません。
• むしろ、極端に遅くなって評価を落とさないための“土台”と考えるのが現実的です。

AFFINGER6は、瞬間的なスコアが安定しているテーマというよりも、設計や最適化の影響を受けやすいテーマといえます。

初期状態のままでも致命的に遅いわけではありません。ただし、記事の積み上げや大きな画像の配置によって、モバイル表示は数秒単位で変動します。

そのため、画像サイズの最適化、遅延読み込みの活用、フォントやCSS設定の見直しといった調整を前提に運用することで、本来の性能を引き出せる設計といえるでしょう。

ため

表示速度を「何もしなくても安定するもの」と考えるか、「自分で整えていくもの」と考えるかその違いが、テーマ選びの判断軸になります。

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