サーバーの応答速度が致命的に遅いです。

PageSpeed Insights が求めるのは、0.6 秒以内です。対して、BizH さんのサイトは、5.4 秒かかっています。まずは、サーバーの応答速度を 0.6 秒以内にすることだけに集中するのがいいと思います。

なぜこれだけ遅いのかは外部からは分かりません。WordPress のデバッグモードを有効にし、PHP エラーが出ていないかなどの調査が必要に思えます。

参考：WordPress でのデバッグ

● 相談 1

LCP の参考情報として、Google のエンジニアさんによる説明が最も参考になります。

Largest Contentful Paint を最適化する

また、Cocoon 設定 > 高速化で HTML・CSS・JavaScript を縮小するのが効果的です。ただし、縮小はサーバーの応答速度を速くするものではなく、サーバーが応答した後の速度を速くするものです。

● 相談 2

兎にも角にも、サーバーの応答速度が遅いです。

iframe で、Excel画面を表示している　→　iframeの画面貼り込みを控える

少なくとも、投下資本利益率（ROIC: Return on Invested Capital）のページでは、 Excel の <iframe> は遅延読み込みされています。そのため、このページでは気にする必要はありません。

※ Chrome では、4G 以上の高速回線の時に <iframe> に loading="lazy" 属性がある場合、その <iframe> が画面内に入ってくる 2500px 手前で <iframe> を読み込みます。つまり、最初に見える範囲から下に 2500px スクロールした範囲に <iframe> がなければ LCP が悪くなることはありません。

※ <iframe> の読み込みは、サーバーの応答速度には関係ありません。

過大な DOM サイズの回避で例に上がっている、CTAボックス内のCTAメッセージの記述を止める

DOM サイズは、お気になさる必要はありません。

無駄でかつレスポンスを悪化させるプラグインを停止または変更する　→（洗い出しは調査中）

これはサーバーの応答速度に関係がありますので、お調べになるのがいいと思います。

サーバーはConoHa WINGなのでサーバー自体は悪くなさそうですね。

投稿者:: @bizh

↑

❶iframe で、Excel画面を表示している　→　iframeの画面貼り込みを控える

❷過大な DOM サイズの回避で例に上がっている、CTAボックス内のCTAメッセージの記述を止める

❸無駄でかつレスポンスを悪化させるプラグインを停止または変更する　→（洗い出しは調査中）

どれもここまでサーバーが遅くなる原因としてはちょっと考えられないですね。

サーバがこれだけ遅い原因として、同じレンタルスペース内で他にもサイト運営を行っていてそこの負荷が高いとか？
他に何かサーバー負荷が高い原因とか思い当たる節はありますでしょうか？

ConoHaコントロールパネルの「サーバー管理」→「契約情報」→「リソース」の「CPUやメモリ」のリソース状態はどのようになっていますでしょうか。

Akira様 わいひら様

相談1・2へのコメント、調査のやり方のアドバイスありがとうございます。

私自身が問題ではと考えていた❶❷❸ではなく、真因が他にあるとのご指摘があり、それが分かっただけでも安堵しています。

これからひとつひとつ、確認していって、原因追及・課題解決につなげて、少しでもパフォーマンスを挙げていきたいと思います。

まず、私が説明できる点から、解明していきたいと思います（実はお恥ずかしいことをさらすことにもなります）。

１．ConoHaのリソース

添付ファイルに、CPUの付加状況を貼り付けます。100%を振り切ることが度々あります。特に記事をuploadした直後にかなりの頻度で 503 Service Unavailable が出て、よく再ログインをしていました。

メモリについては、ほぼ1%で、たまに2%になる程度です。

２．同じレンタルスペース内で他にもサイト運営を行っていてそこの負荷が高いとか？

同じレンタルサーバ内には、以下4つのドメインが設定されています。

1)nanakorobi-yaoki.com
2)uscma.jp
3)management-accounting.biz 
4)uscma.conohawing.com

4)は、サーバ契約時に作成しましたが、何も触っていません。ドメイン名を任意で使用したかったので、ConoHaの契約キャンペーンで、４）以外に任意のドメイン名をひとつ追加サービス（登録料ずっと無料）があったので、そこで３）を設定し、問題が起っているのは３）です。

１）と２）は、追加で有償でドメイン（1年限り、自動更新なし）を取得して、つらつらと書き綴っていましたが、自動更新なしの設定を忘れてしまい、気が付いたときには、失効しておりました。中古ドメインを買い直そうとしたら、残念ながら、他の買い手に先を越されてしまっていました。

どちらも、本当に大したデータ量ではないのですが、ぞれぞれ1年程度は手を入れて、40記事、100記事程度uploadしており、データ消去する前に書いたドラフトだけでもどうにかサルベージできないかなと考えて、やり方が分からずそのまま放置していました。

３．WordPress のデバッグモードを有効にし、PHP エラー調査

これは、ご提示いただいたURL記事を参考に、実行し、結果がでましたら、またこちらにご相談させてください。

４．Cocoon 設定 > 高速化で HTML・CSS・JavaScript を縮小する

こちらは、Akira様の説明通り、サーバ応答後のものであるということを理解しつつ、現状を共有させてください。

WEXAL ON

>基本設定
ステータス 最適化完了
前回最適化処理時間
最適化モード スタンダード
自動最適化 ON

>Webコンテンツ最適化
画像最適化 ONF
画像圧縮レベル 80
CSS最適化 ON
JavaScript最適化 ON

>ファーストビュー最適化
LazyLoad(画像) 無効
LazyLoad(CSS・JavaScript) 無効

いろいろと面倒な事例を持ち込み恐縮です。次は上記「３．WordPress のデバッグモードを有効にし、PHP エラー調査」を進めてまいります。

よろしくお願いいたします。

投稿者:: @bizh

↑

１．ConoHaのリソース

これを見る限りではずっと負荷が高い状態というわけではないんですね。
それでもサイトを開いてもやっぱり表示が遅いです。
「プラグインの全停止」などは試して見られたんでしたっけ？

投稿者:: @bizh

↑

同じレンタルサーバ内には、以下4つのドメインが設定されています。

1)nanakorobi-yaoki.com
2)uscma.jp
3)management-accounting.biz 
4)uscma.conohawing.com

4)は、サーバ契約時に作成しましたが、何も触っていません。ドメイン名を任意で使用したかったので、ConoHaの契約キャンペーンで、４）以外に任意のドメイン名をひとつ追加サービス（登録料ずっと無料）があったので、そこで３）を設定し、問題が起っているのは３）です。

１）と２）は、追加で有償でドメイン（1年限り、自動更新なし）を取得して、つらつらと書き綴っていましたが、自動更新なしの設定を忘れてしまい、気が付いたときには、失効しておりました。中古ドメインを買い直そうとしたら、残念ながら、他の買い手に先を越されてしまっていました。

どちらも、本当に大したデータ量ではないのですが、ぞれぞれ1年程度は手を入れて、40記事、100記事程度uploadしており、データ消去する前に書いたドラフトだけでもどうにかサルベージできないかなと考えて、やり方が分からずそのまま放置していました。

だとしたら同スペースの別サイトが問題という感じでもなさそうですね…。

投稿者:: @bizh

↑

いろいろと面倒な事例を持ち込み恐縮です。次は上記「３．WordPress のデバッグモードを有効にし、PHP エラー調査」を進めてまいります。

だとしたらやっぱりこれが知りたいところかもしれません。

わいひら様

コメントありがとうございます。

「プラグインの全停止」を試しましたが、速度は変わりませんでした。。。

「WordPress のデバッグモードを有効にし、PHP エラー調査」を実行すべく、事前準備中です。

なにしろ、コーディングや基盤・テクニカルなことは初心者なので、どこから手を付けるかを思案中です。

進展が出てきましたら、この場で引き続きご相談させて頂きたく。

宜しくお願い致します。

いつもお世話になっております。

まずは真因究明ということで、デバックモードに切り替えて、エラー内容を確認使用する手前で難関にぶち当たりました。

いくつかのURLも参照して、ルートディレクトリ直下の wp-config.php に、

/**
* 開発者へ: WordPress デバッグモード
*
* この値を true にすると、開発中に注意 (notice) を表示します。
* テーマおよびプラグインの開発者には、その開発環境においてこの WP_DEBUG を使用することを強く推奨します。
*/
define('WP_DEBUG', false);

という箇所があるから、引数 false を true に変えて、デバックモードを走らせましょうというやり方はいくつも検索で引っかかったのですが、そもそも、本サイトの wp-config.php は英語で上記のような日本語版ではなく（それは本課題から外れていると思いますが）、いくつかの例証とは config内の記述が異なり、本質である 'WP_DEBUG' は、Win-PCなので、Ctrl+Fを使って検索をかけても、テキスト目視でも、このデバックに絡むコードを探し当てることはできませんでした。

セキュリティに絡むデータが含まれているので、ここで configファイルの内容を公開することはできないと推察するのですが、

❶もっと基本に立ち返り、configファイル内の記述を洗い直した方が良い
❷記述がないのなら、デバックに関するコードを書き加えればよい
❸ちょっと初心者過ぎるので、自習すべきURLを教えて頂いてから自分で対処した方が良い

のいずれが次の妙手となり得るでしょうか？

❷の場合は、 config 内のどこが適切な箇所になりますでしょうか。いろいろと参照した結果、

/* That's all, stop editing! Happy publishing. */
/** Absolute path to the WordPress directory. */

の上あたりかなと考えております。

よろしくお願いいたします。

@bizh さん

再度、参考リンクを貼り付けます。

WordPress でのデバッグ

デバッグのための wp-config.php 例 にご質問の答えが書かれています。

❷の場合は、 config 内のどこが適切な箇所になりますでしょうか。いろいろと参照した結果、～

おっしゃるとおりです。

手軽に確認する方法としてQuery Monitorプラグインを使用するとエラー若しくは警告が出ている場合は添付画像の矢印部分何かしら表示されます。
https://ja.wordpress.org/plugins/query-monitor/

エラー・警告・通知などがある場合、該当メニューをクリックするとメッセージ一覧が表示されます。

Akira 様　わいひら様

年度末繁忙期につき、レスポンスが遅れて申し訳ありません。

Akira様にご提示いただいた デバックモードのURLはいの一番に参照させて頂いておりましたが、改めて閲覧して、コードを挿入して使用することをやっと理解できました。一読では頭に次工程が思い浮かばなかったようです。

わいひら様にプラグイン使用法をご教授頂きましたので、まずはそちらでエラー内容を確認させて頂きました。

結果として、1 Notice, 17 Deprecated, 合計18 PHPエラーが検出されました。

<Notice>

メッセージ
file_get_contents(): Read of 8192 bytes failed with errno=21 Is a directory

場所
wp-includes/functions.php:6620
file_get_contents()
wp-includes/functions.php:6620
get_file_data()
wp-content/plugins/conoha-wing-plugin/conoha-wing-plugin.php:33

コンポーネント
WordPress Core

→調べたところ、「ファイルではなくディレクトリをfile関数で読み込もうとしたエラー」ということらしいです

<Deprecated>
プラグイン: aurora-heatmap で４つ
プラグイン: ewww-image-optimizer　で２つ
プラグイン: wordfence　で11

という結果でした。プラグイン全停止チェック実行の際にスピードに差分がでなかったので、プラグインにPHPエラーというのは驚きでした。

aurora-heatmapは、あくまで便利ツールなので、不使用にするのは簡単なのですが、ewww-image-optimizerとwordfenceは、画像圧縮とセキュリティ関連なので、何かしら対策を打ちたいです。

優先順位は、ewww-image-optimizer　として、wordfence　については数が多すぎるので、代替プラグインを探すしかないかなと思っています。

大変お手数ですが、この手がかりから、次の打ち手のアドバイスをいただくことはできますか？

下記添付の一覧情報の「場所」には[+] が展開されて、場所情報の詳細が記述されています。そちらもお見せした方がよろしいですか？

丸投げ状態になりどうもスミマセン。

宜しくお願い致します。

画面貼り付けははみ出し、添付ファイルは文字化け、で重ねてすみませんでした。

下記に、画面貼り付け情報をテキストで再度ご提示いたします。

注意 file_get_contents(): Read of 8192 bytes failed with errno=21 Is a directory 1
wp-includes/functions.php:6620
WordPress Core
非推奨 Return type of Aurora_Heatmap_Options::offsetExists($offset) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice 1
wp-content/plugins/aurora-heatmap/class-aurora-heatmap-options.php:105
プラグイン: aurora-heatmap
非推奨 Return type of Aurora_Heatmap_Options::offsetGet($offset) should either be compatible with ArrayAccess::offsetGet(mixed $offset): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice 1
wp-content/plugins/aurora-heatmap/class-aurora-heatmap-options.php:115
プラグイン: aurora-heatmap
非推奨 Return type of Aurora_Heatmap_Options::offsetSet($offset, $value) should either be compatible with ArrayAccess::offsetSet(mixed $offset, mixed $value): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice 1
wp-content/plugins/aurora-heatmap/class-aurora-heatmap-options.php:125
プラグイン: aurora-heatmap
非推奨 Return type of Aurora_Heatmap_Options::offsetUnset($offset) should either be compatible with ArrayAccess::offsetUnset(mixed $offset): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice 1
wp-content/plugins/aurora-heatmap/class-aurora-heatmap-options.php:136
プラグイン: aurora-heatmap
非推奨 strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated 1
wp-includes/functions.php:7022
プラグイン: ewww-image-optimizer
非推奨 str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated 1
wp-includes/functions.php:2162
プラグイン: ewww-image-optimizer
非推奨 Return type of Requests_Cookie_Jar::offsetExists($key) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice 1
wp-includes/Requests/Cookie/Jar.php:63
プラグイン: wordfence
非推奨 Return type of Requests_Cookie_Jar::offsetGet($key) should either be compatible with ArrayAccess::offsetGet(mixed $offset): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice 1
wp-includes/Requests/Cookie/Jar.php:73
プラグイン: wordfence
非推奨 Return type of Requests_Cookie_Jar::offsetSet($key, $value) should either be compatible with ArrayAccess::offsetSet(mixed $offset, mixed $value): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice 1
wp-includes/Requests/Cookie/Jar.php:89
プラグイン: wordfence
非推奨 Return type of Requests_Cookie_Jar::offsetUnset($key) should either be compatible with ArrayAccess::offsetUnset(mixed $offset): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice 1
wp-includes/Requests/Cookie/Jar.php:102
プラグイン: wordfence
非推奨 Return type of Requests_Cookie_Jar::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice 1
wp-includes/Requests/Cookie/Jar.php:111
プラグイン: wordfence
非推奨 http_build_query(): Passing null to parameter #2 ($numeric_prefix) of type string is deprecated 1
wp-includes/Requests/Transport/cURL.php:345
プラグイン: wordfence
非推奨 Return type of Requests_Utility_CaseInsensitiveDictionary::offsetExists($key) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice 1
wp-includes/Requests/Utility/CaseInsensitiveDictionary.php:40
プラグイン: wordfence
非推奨 Return type of Requests_Utility_CaseInsensitiveDictionary::offsetGet($key) should either be compatible with ArrayAccess::offsetGet(mixed $offset): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice 1
wp-includes/Requests/Utility/CaseInsensitiveDictionary.php:51
プラグイン: wordfence
非推奨 Return type of Requests_Utility_CaseInsensitiveDictionary::offsetSet($key, $value) should either be compatible with ArrayAccess::offsetSet(mixed $offset, mixed $value): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice 1
wp-includes/Requests/Utility/CaseInsensitiveDictionary.php:68
プラグイン: wordfence
非推奨 Return type of Requests_Utility_CaseInsensitiveDictionary::offsetUnset($key) should either be compatible with ArrayAccess::offsetUnset(mixed $offset): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice 1
wp-includes/Requests/Utility/CaseInsensitiveDictionary.php:82
プラグイン: wordfence
非推奨 Return type of Requests_Utility_CaseInsensitiveDictionary::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice 1
wp-includes/Requests/Utility/CaseInsensitiveDictionary.php:91
プラグイン: wordfence

度々申し訳ございません。

上記、Query MonitorのPHPエラーは、ダッシュボード画面によるものでした。同プラグインの使用法を思い違いしておりました。

当該最初のお問合せさせて頂きましたページ「投下資本利益率（ROIC: Return on Invested Capital）」につきましては、下記の通り、1 Notice, 1 Deprecation でした。

注意 file_get_contents(): Read of 8192 bytes failed with errno=21 Is a directory 1
wp-includes/functions.php:6620
file_get_contents()
wp-includes/functions.php:6620
get_file_data()
wp-content/plugins/conoha-wing-plugin/conoha-wing-plugin.php:33
WordPress Core
非推奨 uasort(): Returning bool from comparison function is deprecated, return an integer less than, equal to, or greater than zero 1
wp-includes/category-template.php:916
uasort()
wp-includes/category-template.php:916
wp_generate_tag_cloud()
wp-includes/category-template.php:767
wp_tag_cloud()
wp-includes/widgets/class-wp-widget-tag-cloud.php:74
WP_Widget_Tag_Cloud->widget()
wp-includes/class-wp-widget.php:394
WP_Widget->display_callback()
wp-includes/widgets.php:835
dynamic_sidebar('sidebar')
wp-content/themes/cocoon-master/sidebar.php:18
load_template('wp-content/themes/cocoon-master/sidebar.php')
wp-includes/template.php:718
locate_template()
wp-includes/general-template.php:136
get_sidebar()
wp-content/themes/cocoon-master/footer.php:11
load_template('wp-content/themes/cocoon-master/footer.php')
wp-includes/template.php:718
locate_template()
wp-includes/general-template.php:92
get_footer()
wp-content/themes/cocoon-master/single.php:20
WordPress Core

上記Query Monitorの該当ページのログは添付ファイルの通りです。

宜しくお願い致します。

@bizh さん

それらの Notice や Deprecated でサーバーの応答速度がものすごく遅くなるとは考えにくいです。

添付画像の「遅いクエリー」には何が書かれているでしょうか？

出力されているメッセージは、Notice（通知）、Deprecated（非推奨）程度のものなので、Error（エラー）、Warning（警告）、が出ているわけではないのでサーバーの速度的な問題になるものはなさそうです。

遅いクエリも通常環境で結構出ることがあるので、もしそれが問題でなかったら一度ConoHa WINGサーバーの方に「なぜ自分の入っているサーバーはこんなに遅いの？」と問い合わせした方が手っ取り早いかもしれません。

@akira 様

確認作業ありがとうございました。

とりあえず、表示されているものがLCP遅延の原因ではない可能性が高いことが分かり少し安心しました。

さて、遅いクエリーとして1件検出されておりますので、そちらを下記に表示いたします。

宜しくお願い致します。

クエリー 
SELECT ID, sum_count, post_title, post_author, post_date, post_modified, post_status, post_type, comment_count
FROM (
SELECT terms_accesses.post_id, SUM(terms_accesses.count) AS sum_count, terms_accesses.term_taxonomy_id, terms_accesses.taxonomy
FROM ( #カテゴリーとアクセステーブルを内部結合してグルーピングし並び替えた結果
SELECT wp_cocoon_accesses.post_id, wp_cocoon_accesses.count, wp_term_relationships.term_taxonomy_id, wp_term_taxonomy.taxonomy
FROM wp_term_relationships
INNER JOIN wp_cocoon_accesses
ON wp_term_relationships.object_id = wp_cocoon_accesses.post_id
INNER JOIN wp_term_taxonomy
ON wp_term_relationships.term_taxonomy_id = wp_term_taxonomy.term_taxonomy_id
WHERE wp_cocoon_accesses.post_type = 'post'
AND wp_cocoon_accesses.date BETWEEN '2022-03-27'
AND '2023-03-27'
AND wp_term_relationships.term_taxonomy_id NOT IN (14,48,7,8,5,18,42,15)
AND wp_term_taxonomy.taxonomy = 'category' #WHERE句
GROUP BY wp_cocoon_accesses.id ) AS terms_accesses #カテゴリーとアクセステーブルを内部結合した仮の名前
GROUP BY terms_accesses.post_id
ORDER BY sum_count DESC ) AS ranks_posts
INNER JOIN wp_posts
ON ranks_posts.post_id = wp_posts.id
WHERE post_status = 'publish'
AND post_type = 'post'
ORDER BY sum_count DESC
LIMIT 5

呼び出し元
get_access_ranking_records()
wp-content/themes/cocoon-master/lib/page-access/access-func.php:484
generate_popular_entries_tag()
wp-content/themes/cocoon-master/lib/html-forms.php:1016
PopularEntryWidgetItem->widget()
wp-content/themes/cocoon-master/lib/widgets/popular-entries.php:108
WP_Widget->display_callback()
wp-includes/class-wp-widget.php:394
dynamic_sidebar('sidebar')
wp-includes/widgets.php:835
load_template('wp-content/themes/cocoon-master/sidebar.php')
wp-includes/template.php:783
locate_template()
wp-includes/template.php:718
get_sidebar()
wp-includes/general-template.php:136
load_template('wp-content/themes/cocoon-master/footer.php')
wp-includes/template.php:783
locate_template()
wp-includes/template.php:718
get_footer()
wp-includes/general-template.php:92

コンポーネント
親テーマ

行
5

時刻
0.2721

@yhira 様

運営に問い合わせるというのは想定外でした。

早速、ConoHa WINGサーバー側に問い合わせることに致します。

宜しくお願い致します。

いつもお世話になっております。

ConoHaへ問合せいたしましたが、私の説明が悪いせいでしょうが、下記のようなご返答で、原因追及はできませんでした。なにか、確実に回答をいただけるコツや聞き出すためのお作法みたいなものが必要なのでしょうか？

ずばり、LCPのことをお伝えしたのですが。。。

おそれいりますが、Webサイトの表示速度やGoogle Search Console
などの外部サイトとの連携情報につきましては構築いただいてい
るWebサイトのご運用状況により多岐に渡りますため、当窓口の
サポート外となります。

おそれいりますが、インターネット上の情報などをご参考にして
いただき問題の切り分けを実施いただきますようお願い致します。

ご要望に沿えず申し訳ございません。

投稿者:: @bizh

↑

さて、遅いクエリーとして1件検出されておりますので、そちらを下記に表示いたします。

このクエリが原因だと仮定するならCocoon設定→「アクセス集計」のアクセス解析を無効にするとどうなりますでしょうか

投稿者:: @bizh

↑

ConoHaへ問合せいたしましたが、私の説明が悪いせいでしょうが、下記のようなご返答で、原因追及はできませんでした。なにか、確実に回答をいただけるコツや聞き出すためのお作法みたいなものが必要なのでしょうか？

ずばり、LCPのことをお伝えしたのですが。。。

何と質問したかはわからないので詳しくはわかりません。
ただPageSpeed Insightsのことを持ち出して質問したのであれば悪手だったかもしれません。
PageSpeed Insightsは外部ツールなので当然サーバーのサポート範囲には含まれません。
質問するのだとしたら純粋に「あなたのところのサーバーの応答速度がめちゃくちゃ遅いんですけど原因として考えられるものは何かありますか？もしかしてサーバーでトラブルみたいなことは起きていますか？」みたいなことを丁寧に聞けばもしかしたら答えてくれるのかもしれません。
サポートの良いサーバーだとこれで答えてくれるケースもあります。

ただConoHa WINGがどうかと言うとそこまでしてくれるかはちょっとわからないです。

@yhira 様

ご対応ありがとうございます。

❶ Cocoon設定→「アクセス集計」

該当ページについて、Query Monitorで測定した結果、6.18秒→5.79秒に改善しました。

❷ ConoHa WING

問合せお作法についてアドバイス頂きありがとうございます。改めて、シンプルな形で再度問い合わせたいと思います。

投稿者:: @bizh

↑

該当ページについて、Query Monitorで測定した結果、6.18秒→5.79秒に改善しました。

そこまで速くなってませんね。
しばらく時間を置いて様子を見て計測しても、これくらいの差であれば直接的な原因ではないかもしれません。

@yhira 様

ご確認ありがとうございます。

先のアドバイスを参考に、再度、ConoHaに問い合わせた結果、下記のような回答を得ました。

まあ、”一時的”な状況ではございませんが、特に問題なかったといわれれば、それ以上、この線での追及は難しいようです。

お問い合わせいただき、まことにありがとうございます。
ConoHa お客様センターです。

お問い合わせの件につきましてご案内致します。

ご申告の事象につきまして、確認致しましたところ、ホスト
サーバーや弊社ネットワークにおいて、ご申告の事象に繋がる
ような不具合や異常を示すアラートの検知はございませんでした。

ConoHa WINGは共用サーバーのサービスとなっておりますため、
同ホスト内の他のお客様のご利用状況等により一時的にご申告の
事象が発生している可能性はございます。

また、お客様のコンテンツの運用や設定状況によっては、サイト
の動作が不安定となるケースもございますので、対象のWordPress
の設定状況などご確認いただき、必要に応じて設定をご調整いただ
きますようお願い致します。

何卒ご確認の程よろしくお願い致します。

投稿者:: @bizh

↑

ConoHa WINGは共用サーバーのサービスとなっておりますため、
同ホスト内の他のお客様のご利用状況等により一時的にご申告の
事象が発生している可能性はございます。

「レンタルサーバー同居人」調べると結構な数のサイトが出てきますね。
http://tobira.sakura.ne.jp/doukyo/
共用サーバーであれば十分同居人が重いということが原因としてあるかもしれません。
たださすがに全体的に重いと苦情が来るので放置はしてないとは思いますが。

Bingで「ip: 118.27.95.84」で検索してもある程度同居人を調べられます。

ただ一番可能性があるのは自分の環境だと思うので、一度プラグインを全部無効にして、加えてWordPressテーマもWordPress公式テーマにしてPageSpeed Insightsで速度に変わりがないか調べておく必要あるかと思います。
添付画像よりかは何秒か早くなればプラグインかテーマが原因ですし、変わらなければサーバー・サーバー設定が怪しいという切り分けができるかと。

www80.conoha.ne.jp 118.27.95.84の同居サイトですけど数えたら678以上あるんですね。
http://tobira.sakura.ne.jp/doukyo/
出力されているものだけでもこれだけあるので、結構入っているもんだなぁと。
※レンタルサーバー同居人検索の正確性までは調べてないのでご了承ください

ちなみにCocoonはCocoonサイトだけしか出力されませんでした。

僕のブログのnelog.jp (150.230.194.151)だと91サイトが出力されました。
サーバーによって収容人数もあると思うのでそれぞれなのかもしれませんが。出力されてないものもあると思うので参考程度に。

僕が9年前くらいに取得したサーバーのサイトだと350ぐらいでした。
そのサーバーの対応性能と運用方針によって適切な収容人数も変わってくるのかもしれませんね。

@yhira 様

お手数をお掛けしております。共用サーバ収容数の調査方法などご教授頂き感謝します。結構数があるのですね。びっくりしました。

PageSpeed Insight の件ですが、条件を変えて真因究明しようと、まずは大枠で❶現状、❷テーマCocoon、プラグイン無し、❸テーマTwenty Twenty-Three、プラグイン有り、❹テーマTwenty Twenty-Three、プラグイン無し　で差分抽出してみました。

なお、キャッシュ等のせいなのか、私には PageSpeed Insight の「実際のユーザーの環境で評価する」の箇所の表示内容が不変だったため、調査結果の画像貼り付けは、「パフォーマンスの問題を診断する」の部分になります。

以下、見にくいかもしれませんが、一度ご確認いただきたく。宜しくお願い致します。

❶現状

❷テーマCocoon、プラグイン無し　の結果になります。

❸テーマTwenty Twenty-Three、プラグイン有り　の結果になります。

一番早くなりました。

❹テーマTwenty Twenty-Three、プラグイン無し　の結果になります。

プラグイン有りより若干遅くなります。

もし、標題LCPの問題にテーマが関係するなら、併せてご確認させて頂きたい件があります。

LCP問題は、2年以上前からの現象なのですが、2023/2月に別件（Warningが出てログインできない状態です）にて、ご対応頂き、github から修正版をdownload した際、添付の様に、Cocoon親テーマが２つ並ぶ現象になりました。バージョンの古い方を手動で削除すると、新しい方が残っていても、Cocoonテーマが当たらなくなるので、そのまま2つ並立させています。なお、その後のCocoonバージョンアップはそのまま更新されています。

現状は、バージョン: 2.5.6　と、バージョン: 2.5.8.3　になっています。

直接関係がないなら、この件は別にトピックを立てて改めて相談いたします。自分の中の懸念点として追記しました。

添付画像です。

@bizh さん

「テーマCocoon」での計測は、子テーマでの計測でしょうか？親テーマを有効にした場合の計測結果はどうなるでしょうか？

また、子テーマでテンプレートファイルのカスタマイズはされているでしょうか？

「実際のユーザーの環境で評価する」の箇所の表示内容が不変だった

ユーザーがサイトに訪問した時のこれまでのデータのため、すぐには変わらないと思います。

Cocoon親テーマが２つ並ぶ現象

CSS が縮小されているため、どちらの親テーマが適用されているのかが分かりません。

WordPress 管理画面で上手くいかない場合は、サーバーのファイルマネージャーや FTP ソフトをお使いになり、使っていない親テーマを削除すればいいかもしれません。

@akira 様

色々と確認いただきありがとうございます。

１）PageSpeed Insight「実際のユーザーの環境で評価する」

仕様が分かり安心しました。

２）Cocoon親テーマが２つ並ぶ現象

ConoHaのファイルマネージャーを使用して、旧バージョンの親テーマが削除できました。

３）CSS縮小化

今後も見て頂くことがある可能性を考え、HTML/CSS/JavaScript縮小化をOFFしました

４）子テーマでテンプレートファイルのカスタマイズ

追加CSSにて、下記のようなカスタマイズをさせて頂いております。

/* グローバルナビゲーションサブキャプション色 */
.navi .sub-caption {
  color: #fff;
}
/*標準ボタン装飾をCocoonボタンと統一*/
a.wp-block-button__link {
  border: 2px solid transparent;
  border-radius: 10px;
  box-shadow: 0px 5px 5px -2px rgba(240, 235, 232, .2);
  color: #fff;
  cursor: pointer;
  display: inline-block;
  font-size: 14px;
  font-weight: bold;
  line-height: normal;
  padding: 7px 13px;
  position: relative;
  text-align: center;
  text-decoration: none;
  transition: all 0.3s ease-in-out;
}

a.wp-block-button__link:hover {
 box-shadow: 0 -3px 2px 0px rgba(221, 221, 221, .2), 0 -5px 5px -2px rgba(221, 221, 221, 1) inset;
 filter: brightness(115%);
 opacity: 1;
}
.header-container,
.main,
.sidebar,
.footer {
  background-color: #ffffff;
}

５）親テーマを有効にした場合の計測結果

先程提示したものは、子テーマによるものです。

先に一覧を表示します。

➡投下資本利益率（ROIC: Return on Invested Capital）

●「最初のサーバー応答時間を速くしてください」
Cocoon子テーマ/プラグイン有り：5.86s
Cocoon子テーマ/プラグイン無し：5.03s
Cocoon親テーマ/プラグイン有り：5.15s
Cocoon親テーマ/プラグイン無し：4.45s
Twenty Twenty-Three/プラグイン有り：-
Twenty Twenty-Three/プラグイン無し：-

●「Cocoon親テーマ/プラグイン有り」は下記のとおりです。

●「Cocoon親テーマ/プラグイン無し」は下記のとおりです。

併せて、状況がさらに悪化してサーバー応答が悪くなっています。2023年3月30日にWordPress6.2がリリースされ、更新した後、ダッシュボード内で特定の挙動をすると、「502 Bad Gateway」が出るようになりました。これがLCP問題と同様に、共用サーバの問題か、当方の設定の問題か不明なため追記させて頂きました。

トリガー例）

❶ダッシュボード＞投稿一覧＞記事をテキスト検索 or カテゴリ/タグで絞込
❷ダッシュボード＞更新＞「メンテナンスリリースとセキュリティリリースのみの自動更新に切り替えます。」をクリック

❶については、投稿一覧画面を1枚ずつ前後させれば、過去記事のメンテができるので回避策はあるのですが、ページ送りに任意の数字を入力して該当ページに飛ぼうとすると、「502 Bad Gateway」が出るので、ひとつひとつの挙動の確認中です。

上記、LCP問題と同根の課題ではないならば、切り分けて別トピックにて改めて問合せさせて頂きます。

「WordPress 6.2」は、日本時間3/29(水)リリース予定

のトピックをただいま確認しました。

6.2へのバージョンアップ自体の確認事項はほかにも複数ありますので、上記コメントは、あくまでLCP問題に関連する場合のみ、ご返信いただければ幸いです。LCPに無関係ならば捨ておいていただき、別途質問させて頂きます。

すみませんでした。

BizHさん

502の件ですが。

新しいトピックが立たないようですので、こちらに書いてしまいます。
（この後、しばらく離席してしまうと思うので）

WEXALが有効なようです。

これを一旦無効化すると、状況は変わりますでしょうか。

BizHさん

もう1つ、502の件について。

WEXAL無効化で変わらない場合。

PHPのバージョンを下げてみてください。
（現在、8.1系のようですので、8.0系や7.4系にしてみる）

それで変わるかどうか、ご確認いただければと。

投稿者:: @bizh

↑

●「Cocoon親テーマ/プラグイン有り」は下記のとおりです。

ということは子テーマのカスタマイズに原因があるように感じます。
CSSの変更でサーバーの応答時間が遅くなることはちょっと考えにくいので、functions.phpのようなPHPのカスタマイズはされていないのでしょうか？

www80.conoha.ne.jp 118.27.95.84の同居サイトにCocoonのサイトがあったのでPageSpeed Insightsで確認してみたら結構良い結果でした。
だとしたらサーバーの影響ということも考えづらく、やっぱりCocoonの子テーマのカスタマイズが原因のように感じます。

とはいえ環境情報を見ても子テーマはカスタマイズされてないっぽいんですよね…。

投稿者:: @bizh

↑

----------------------------------------------
子テーマ名：Cocoon Child
バージョン：1.1.1
style.cssサイズ：718バイト
functions.phpサイズ：203バイト
----------------------------------------------

mk2さんが書かれていることを試しても変わらない場合は、子テーマの最新バージョンは1.1.3なのでこれに変更するとどうでしょうか？
https://github.com/xserver-inc/cocoon-child

手順としてはこちらです。

1. 1.1.1でstyle.cssのCSSを全てコピーして控えておく
2. 1.1.3にアップデートする
3. 1.1.3のstyle.cssに控えておいたCSSを貼り付ける

@mk2_mk2 様

アドバイスありがとうございます。

「502 Bad Gateway」の回避のため、まず

１）「WEXAL無効化」を実施後、添付のようなエラーメッセージが出てしまいました。

そこで、

２）「PHPのバージョンを下げる」を実施し、8.1→8.0　に変更した所、無事、502はでなくなりました。

別課題をここで解決に導いて頂きありがとうございました。