[ 解決済 ] NPO法人 フリースクールのパフォーマンス（PSIモバイル-LCP）
[ 解決済 ] NPO法人 フリースクールのパフォーマンス（PSIモバイル-LCP）
- このトピックには19件の返信、5人の参加者があり、最後に
により7時間、 26分前に更新されました。
-
投稿
-
■ WordPress のバージョン
WordPress 6.8.1■ テーマ・プラグインは全て最新版で確認してください。
確認しました。■ テーマの種類
Lightning ( G3 )■ テーマのバージョン
Lightning ( G3 )■ スキンの種類
Origin III■ プラグインの種類・バージョン
以下、最新version・Lightning G3 Pro Unit
・VK All in One Expansion Unit
・VK Block Patterns
・WP Fastest Cache
・EWWW Image Optimizer (有効化済み、WebP変換設定済み)
・Google Site Kit (Google Analyticsの連携エラーはありますが、reCAPTCHAやGoogle Fontsの読み込みは行われています)■ 期待する動作
主要ページでのモバイルでのパフォーマンス向上：LCPを2.5秒にしたい。■ 自分で試した事
・他のプラグインは外して、LightningテーマのCSS最適化（高速化）設定のテスト（パフォーマンスは逆に低下）
・WP Fastest Cacheの「Delay JS」の有効化。JavaScriptの縮小・統合も全て有効。（他有効化済み、HTML/CSS/JSの縮小・統合、Gzip、ブラウザキャッシュ、レンダリングブロックJSソースの除外、Googleフォントの非同期読み込み、Delay JSは全て有効化済み)）。
・EWWW Image Optimizer (有効化済み、WebP変換設定済み)→サーバー会社がWebPとして処理していないため、対応を依頼中。
・Google Fontsにはfont-display: swap !important;を、外観>カスタマイズ＞追加CSSで強制適用済み（画像のないテキストのみのページではLCPが2.4秒に改善）。■ 症状が発生するブラウザ
safari,chrome■ 実際の症状
【PSIレポートで指摘されている主な問題（モバイル版トップページ）】PSIのLCP（最大コンテンツの描画）は現在約15秒で、そのうち「レンダリング遅延」が約10.4秒を占めています。
特に「レンダリングを妨げるリソースの除外」として、以下のJavaScript/CSSファイルが指摘されており、合計で約5.99秒の短縮が可能と表示されています。・自社ドメインのJavaScript/CSS:
その他、emjs.js や h5x4.css といったファイル群（合計約3秒のレンダリングブロック）
・第三者スクリプト:
Google reCAPTCHA関連のJavaScript (/recaptcha/api.js?render=… など) （約0.75秒のレンダリングブロック）
また、「使用していないJavaScriptの削減」（約305KB削減可能）や「使用していないCSSの削減」（約96KB削減可能）も指摘されており、特にreCAPTCHA関連のJSが約280KBも未使用とされています。【質問事項】
WP Fastest Cacheの「Delay JS」が有効にも関わらず、上記のような自社ドメインのJavaScript/CSSやreCAPTCHA関連のJavaScriptがレンダリングをブロックしている状況が続いております。これらのファイルがレンダリングをブロックし続ける原因として、どのような可能性が考えられますでしょうか？
LightningテーマやVK Blocksの特性上、WP Fastest CacheのDelay JSではこれらのファイルを完全に遅延させることが難しいのでしょうか？
もしそうである場合、これらのレンダリングブロックを解消し、モバイルLCPをさらに改善するための具体的な対策（例: VK Blocksの設定見直し、他のプラグインとの連携、コードレベルでの最適化など）について、アドバイスをいただけますと幸いです。
お忙しいところ恐縮ですが、ご教示いただけますようお願い申し上げます。
該当URL : https://*********※該当URLはフォーラムライセンスが有効のユーザーにのみ表示されます
お世話になっております。ベクトルの石川でございます。
弊社のテーマ・プラグインの高速化については今後の検討課題とさせていただきます。
現時点での具体的な改善対策につきましては、
現状優先度の高い実装タスクが多いため、お急ぎの場合は別途高速化専門の制作者・業者様にご相談の上、具体的に弊社テーマ・プラグインでできそうな事がありましたらその旨ご連絡くださいませ。その上で対応できそうな内容であれば対応させていただきます。よろしくお願いいたします。
石川様、お世話になっております。
ご返答いただきありがとうございました。「具体的に弊社テーマ・プラグインでできそうな事がありましたらその旨ご連絡くださいませ」とのお言葉を受け、PageSpeed Insights (PSI) の詳細な診断結果から、貴社テーマ・プラグインに関連すると思われるレンダリングブロックの原因を特定し、いくつかの技術的な改善提案をまとめましたので、ご回答させていただきます。
【現在の状況の再確認】
モバイルLCPが約15秒と非常に高く、そのうち「レンダリング遅延」が約10秒を占めています。
WP Fastest CacheのHTML/CSS/JS縮小・統合、Gzip、Delay JSなど、可能な限りの最適化は全て有効にしております。
LightningテーマのCSS最適化は無効化しています。
【PSIレポートで特定された貴社テーマ・プラグイン関連の主なレンダリングブロックリソース】
PSIの「レンダリングを妨げるリソースの除外」セクションにて、以下のファイルが継続的に指摘されており、これらがLCPのレンダリング遅延の主要因であると判断しております。https://minnano-piano.org/wp-content/plugins/lightning-g3-pro-unit/inc/vk-blocks/build/js/emjs.js (または類似のファイル名)
その他、vk-blocks/build/パスに含まれる複数の.jsおよび.cssファイル
これらのファイルは、スライダーがあるページだけでなく、スライダーがないページでも共通してレンダリングをブロックしており、サイト全体のモバイルLCPに悪影響を与えていると推測されます。
【ユーザーとSEOへの影響（LCPの重要性）】
現在のモバイルLCP約15秒という数値は、ユーザーにとって非常に長い待ち時間となり、ページの離脱率を高めるなど、ユーザー体験を著しく損ねる状況です。また、Googleは2021年以降、このLCPを含むCore Web Vitals（コアウェブバイタル）を検索ランキングの重要な要因の一つとしています。 LCPが基準値（2.5秒）を大きく超えることで、たとえ他のSEO対策が優れていても、検索順位において不利になる可能性があり、結果として潜在的なユーザーへのリーチが阻害されるという不利益を被っております。
これらの貴社テーマ・プラグインに関連するファイルがレンダリングをブロックし続けることは、私だけに留まらず、貴社製品を利用の全てのユーザー様が、ユーザー様の顧客体験の悪化とSEO上の深刻な不利益を直接的に被ることを意味し、貴社製品の品質に対する信頼にも関わる問題であると認識しております。
【貴社テーマ・プラグインで検討可能な具体的な改善提案】
WP Fastest Cacheのような外部最適化プラグインでは対応しきれない部分があるため、貴社テーマ・プラグインの内部ロジックで対応可能な以下の点について、ご検討いただけないでしょうか。クリティカルCSSの最適化:
ページの初期描画（ファーストペイント）に必要なCSS（クリティカルCSS）のみを自動的に抽出し、HTMLの<head>内にインラインで埋め込む機能、またはそのための仕組みを提供すること。これにより、外部CSSファイルの読み込みを待たずに、ページの主要部分がすぐに表示されるようになります。
残りのCSSは非同期で遅延読み込みさせることで、レンダリングブロックを大幅に削減できます。
JavaScript/CSSの条件付き読み込みの強化（Tree Shaking/Code Splitting）:
現在開いているページで実際に使用されているVK Blocksのブロックや機能に限定して、必要なJavaScriptとCSSのみを読み込むようにする仕組みを強化すること。
例えば、スライダーブロックが使われていないページではスライダー関連のJS/CSSを読み込まない、といった厳密な条件付き読み込みです。
また、大きなJS/CSSファイルを、より小さな機能単位に「コード分割（Code Splitting）」し、必要な時に必要なものだけを読み込むようにすることも有効です。
JavaScriptのより厳密な非同期/遅延読み込みの制御:
WP Fastest Cacheのような外部プラグインに依存せず、テーマ・プラグイン側でJavaScriptをenqueueする際に、より確実にasyncまたはdefer属性を付与するロジックを強化すること。
特に、初期描画に必須ではないJavaScript（例: スクロール時に発動するアニメーションなど）は、徹底的に遅延読み込みさせることで、メインスレッドのブロック時間を短縮できます。
これらの提案は、貴社テーマ・プラグインの構造を熟知されている開発チームであれば、より効果的に実装できる可能性があると考えております。
お忙しいところ恐縮ですが、これらの提案について、貴社テーマ・プラグインで対応可能かどうか、または他に推奨されるアプローチがございましたら、ご教示いただけますと幸いです。
当該貴社製品のすべてのユーザー様の顧客体験の向上とSEOパフォーマンスの改善のため、何卒ご検討のほどよろしくお願い申し上げます。
> お忙しいところ恐縮ですが、これらの提案について、貴社テーマ・プラグインで対応可能かどうか、または他に推奨されるアプローチがございましたら、ご教示いただけますと幸いです。
表示速度の改善については前向きに検討させていただきますが、
スライダーの件や分割読み込みなども、できていないにはできていないなりの理由があって現在の仕様になっています。
現段階でテーマ・プラグインで対応可能な部分を改めて調査するのにも工数が必要なため、前向きに検討・改善したい
とは思いますが、先述の通り現状溜まっているタスクがありますので、
今すぐに対応・調査する事もできない
ので、弊社の対応時期や具体的なアプローチ・回答は現段階ではできません。
何卒ご理解のほどよろしくお願いいたします。
横から失礼します。
ご自身でできることもまだあるのではないかと思います。
パッと思いつくものでは、
スライダーをやめる、
アニメーションをやめる、
WebP画像を使用する、
スマホ用の画像 (ダウンロードされたものをそのままお使いなのでしたら、幅が748pxあります。スマホならもっと小さくても問題ありません) をリサイズする、など。
また、PSIは計測した機器や場所にも依存しますし、多くの方が誤解されています。ページスピードの専門家の方がお書きになった以下の記事が勉強になりますので、ぜひ読んでみてください。
まだありますかねー。
サーバー側での設定を見直す、
CDNを利用する、私が思いつくのはこれくらいです。
また、トップページでも Contact Form 7 関連の CSS・JS が読み込まれているように思います。
ベクトルさんがご用意くださっている「Contact Form 7 アセットファイル最適化」をご確認ください。
私も横から失礼します。
アイキャッチ画像の写真が .png になっているので、
これも速度に影響しているように思います。高速化をまったく行っていない私の作業用サイトで、
「NPO法人 フリースクール_トップページ」のパターンを試したところ、
LCP が 7.5秒 でした。ご参考まで。対馬様
貴重なアドバイス有難うございます。アイキャッチ画像がPNGである点、ごもっともです。しかし、当サイトでは既にEWWW Image Optimizerプラグインを導入し、全ての画像をWebP形式に変換済みです。
現在のLCP（Largest Contentful Paint）が極めて高い主な要因は、変換されたWebP画像をブラウザのAcceptヘッダーに応じたコンテンツネゴシエーションで適切に配信できていない、サーバーサイドの問題にあると、PageSpeed Insightsの詳細診断およびブラウザ開発者ツールでの詳細なLCPブレイクダウン（特に「読み込み遅延」）から特定しております。またサーバー側に対応を依頼しております。これは私の先の記述にあるとおりです。
（参考：始まり）確認方法：開発者ツール「Network」タブで、実際に配信されている画像の「Type」がimage/jpegやimage/pngであることを確認。さらに各画像リソースの「Headers」タブを検査。ブラウザからの「Request Headers」にはAccept: image/webpが含まれているにもかかわらず、サーバーからの「Response Headers」はContent-Type: image/jpegやimage/pngを示していました。このブラウザ要求とサーバー応答のミスマッチが、WebPファイルがサーバー上に存在しながらも、サーバー側のコンテンツネゴシエーションが機能していないことを明確に示しています。（参考：終わり）
貴テストサイトのLCP 7.5秒は、環境要因（サーバー応答時間、キャッシュ設定、その他プラグインの有無など）によって変動し得ると理解しておりますが、GoogleのCore Web Vitals基準ではLCP 4.0秒超で「不良 (Poor)」と評価され、検索エンジンからの評価に悪影響を及ぼすと想定されます。
当サイトでは、VK Blocks起因のJavaScriptファイル（emjs.js、h5x5.jsなど）やCSSファイルによるレンダリングブロック（約10秒）と、WebP配信の不備（約3〜5秒）という二つの主要なボトルネックが重なっており、これがLCP 15秒という数値に直結しております。
引き続き、WebP配信問題に関してはサーバー側と連携して最適化を進めて参ります。
しかし、テーマ・プラグイン側の問題は、VK blockが製品として最適化し、その実装を行わない限り（＝バージョンアップ）解決したい問題であり、VK石川様（社長？）のご発言はそれを踏まえてのことと認識しております。つまり、自身でっきる範疇を超えているのです。
ご参考まで。
お世話になっております。ベクトルの石川でございます。
前の返信にて前向きに検討・改善したい
とは思いますが、先述の通り現状溜まっているタスクがありますので、
今すぐに対応・調査する事もできない
と回答しましたが、
弊社製品は利用ユーザーが非常に多く、仕様変更により表示くずれや読み込み順変更による動作不具合が発生する可能性も高いので、実際のところ調査・調整には期間がかかります。また、弊社テーマは、テーマを変更した時にコンテンツが編集不可能になったりしないように、
他のテーマと違ってテーマと独自のカスタムブロックなどの機能部分は分離しています。
そういった構造上の違いもあるためカスタムブロック内包型のテーマに比べるとチューニングしてもある程度限界があります。Satoshi Nakamura 様のコメントの記載具合を見ると、
おそらくご希望の期間に弊社製品の改善をするのは難しいと感じています。他のテーマ・プラグインへの乗り換えなどもご検討ください。
瀬戸内様
コメント有難うございます。ご指摘いただいたことは、すでに実施していう範疇であると認識しています。
私の記載内容（＝自分で試したこと、実際の症状）、石川様のコメント、私から対馬様への返信をご一読いただけると幸いです。さて、瀬戸内様のPSIに関する記述に関してコメントさせていただきます。
ご指摘の通り、PageSpeed Insights (PSI) のラボデータは計測環境に依存し変動しますが、GoogleがSEOのランキング要因として重視するのは、実際のユーザー体験を反映するCore Web Vitals（特にLCP）のフィールドデータです。
LCPが4.0秒を超えると「不良 (Poor)」と評価され、これは検索エンジンからの評価に直接的な悪影響を及ぼし、検索順位の低下という不利益に繋がります。 ラボデータが変動しても、フィールドデータが不良であれば、その影響は避けられません。
また、ご提示の記事、拝見しました。PageSpeed Insights (PSI) のラボスコアが秒数と直接一致しない点、また測定環境による変動性がある点は理解しております。GoogleがSEOで最終的に評価するのは、実際のユーザー体験に基づくCore Web Vitals (CrUXデータ) であるという点も、その通りです。
しかし、LCPが7.5秒や15秒といったCore Web Vitalsの「不良 (Poor)」基準（4.0秒超）を大きく逸脱する数値である場合、これは単なるラボスコアの変動に留まらず、実際のユーザー体験が著しく損なわれていることを明確に示唆します。 このようなLCPは、必然的にPSIの総合パフォーマンススコアを大幅に低下させ、CrUXデータにおいても「不良」と評価され、検索ランキングに直接的な不利益を及ぼすという認識は変わりません。
また、記事が例示する「ラボスコアが低くてもフィールドデータが良好なケース」は、高度に最適化された大規模サイトに多く見られるものであり、LCPが基準値を大幅に超過している当サイトの現状とは文脈が異なります。PSIスコアは最適化度合いの総合指標であり、Core Web Vitalsの基準からかけ離れたLCPは、SEO上の致命的なボトルネックであるという事実は揺るぎません。
いずれにしても、対馬様の純然たるテスト環境であってもLCPが7.5秒であり、不良 (Poor)」基準（4.0秒超）を大きく逸脱する数値であり、それは私が示したエビデンスがものがたるとおり『VK Block自体の問題』です。
サイトで集客や製品販売を行う目的のユーザーは、検索順位に影響したり、ユーザーが検索結果からサイトを開こうとしても7.5秒から15秒もかかり離脱する可能性もあることから、その利用目的に反する『深刻な問題』であることを付言いたします。
石川様
お忙しい中、ご丁寧なご返信、誠にありがとうございます。ベクトルの皆様におかれましても、日々多忙な業務にご尽力されていることと存じます。
現在のタスク状況、および多数のユーザー様を抱える製品の仕様変更に伴う表示崩れや動作不具合のリスク、さらにはテーマとカスタムブロックの機能分離という貴社製品のアーキテクチャ上の特性について、詳細にご説明いただき、深く理解いたしました。チューニングの限界についても承知いたしました。
当サイトのLCP（Largest Contentful Paint）が現在15秒という極めて高い数値を示しており、その内訳が貴社製品起因のJavaScript/CSSによるレンダリングブロックが約10秒、そしてWebP画像の配信不備が約3〜5秒という状況であるとを認識しております。GoogleのCore Web Vitals基準ではLCP 4.0秒超が「不良 (Poor)」と評価され、検索エンジンからの評価に直接的な影響を及ぼすため、このパフォーマンス改善は喫緊の課題となっております。
貴社製品の持つ優れた機能性やブロックエディターとの高い親和性には、日頃より大変助けられております。また選択したブロックライブラリ・NPOのデザイン、メッセージ、構成、ユーザー感情動線設計といったテンプレートは素晴らしく、特に団体立ち上げ時には銀行開設などにサイトが必要でしたし、助成金の申請にも大助かりでした。私ども団体の初動をしっかりと支えていただいたことを、改めて感謝申し上げます。
しかしながら、ご提案いただきました通り、現状のパフォーマンス課題を鑑み、他テーマ・プラグインへの乗り換えも真剣に検討する必要があると感じております。
貴重なご意見をいただき、誠にありがとうございました。
なお、webPの配信問題に関しては、サーバー側との連携が完了した時点で、ご報告をして（皆様に共有させていただいて）、このスレッドを閉じさせていただこうと思っております。
Nakamruaすでに実施していう範疇である
ソースを見る限り、少なくとも以下２点は実施されていないように思いますが、いかがでしょうか。
一度サイトスピードの専門家に相談されてみてはいかがでしょうか。
そこまでスピードにこだわりを持っておられるのでしたら、ブロックパターンを利用なさらず、ご自身でコンテンツの中身にも工夫されるとよいと思います。ただ、どうやら聴き入れていただける (＆見直しをかけられる) 意思が感じられないため、以降コメントを控えます。
瀬戸内様
ご丁寧なご意見、ありがとうございます。Contact Form 7のアセット最適化やCDNの利用、サイトスピード専門家への相談といった一般的な高速化策につきましては、いずれも重要な視点として認識しております。
また、ブロックパターンを利用せずコンテンツを工夫すべきというご提案も承知いたしました。
しかしながら、現在LCPを著しく引き上げている要因は、『VK Blocksの特定のJavaScript/CSSファイルによるレンダリングブロック（約10秒）』と、『サーバー側のWebP配信問題（約3〜5秒）』であると、開発者ツールでの詳細なLCPブレイクダウンおよびHTTPヘッダー分析により明確に特定しております。
WebP配信についてはCDNでの解決も検討いたしましたが、まずは既存のサーバー環境で根本的な対応をリクエストする方が合理的であると判断しております。（＊詳細は「根拠」を参照ください。）
これらの根源的なボトルネックの解消こそが、Core Web Vitalsの「不良 (Poor)」評価から脱却するための最優先事項であると考えております。貴殿が『聴き入れていただける意思が感じられない』と言及をされた点については、私どもとしては、具体的なデータに基づき、最も影響の大きい箇所から改善を試みている最中であることをご理解いただければ幸いです。
引き続き、改善に向けて尽力して参ります。貴重なご意見、重ねて感謝申し上げます。
＊「根拠」
1.CF7のアセットの最適化。検討をいたしましたが、LCPへの直接的な影響は限定的であると判断しました。主な根拠としては、現在のLCP15秒のうち、約10秒がVK Blocks起因のレンダリングブロックJS/CSSによるもので、CF7のアセットは、その10秒の一部を構成する可能性はありますが、VK Blocksの巨大な影響に比べると寄与度は小さく優先順位は低いと考えました。
2.WebP配信に関する解決法。CDN vs.既存のサーバー環境での根本的な対応リクエスト
以下の点が、CDN導入を考慮した上で、既存サーバーでの対応を優先する方が合理的であると判断した主な根拠です。
①コスト効率:
既存サーバーでの対応: 既存のレンタルサーバー契約の範囲内で解決できるため、追加費用が発生しません。 サーバー側で.htaccessのルール追加や設定変更を行うだけであれば、現在のホスティング費用に含まれる範囲です。CDNの導入: CDNは通常、月額費用やデータ転送量に応じた費用が発生します。 小規模サイトであっても、年間数千円〜数万円の追加コストがかかることが一般的です。WebP配信のためだけにCDNを導入するのは、費用対効果の観点から見て、まず既存リソースで解決できないかを試すのが合理的であると考えました。
②アーキテクチャの複雑性:
既存サーバーでの対応: 既存のサーバー設定を変更するだけであり、サイトのアーキテクチャに新たなレイヤーを追加する必要がありません。シンプルに問題の根本を解決できます。③CDNの導入: CDNを導入すると、DNS設定の変更、CDN側のキャッシュルールや最適化設定の管理、オリジンサーバーとの連携など、サイトの構成が一段と複雑になります。 これにより、将来的なデバッグやメンテナンスの手間が増える可能性があります。特定のWebP配信問題のためだけに、この複雑性を増すのは得策ではない場合があります。
④問題の根本的解決:
Xサーバーでの対応: サーバー側でコンテンツネゴシエーションが正しく機能するようになれば、それはホスティング環境自体のWebP配信能力が向上したことを意味します。これは根本的な解決です。⑤CDNの導入: CDNはWebP配信を「肩代わり」してくれますが、Xサーバー側のWebP配信設定が不適切な状態はそのまま残ります。CDNがダウンしたり、サービスを変更したりする際には、再び同じ問題に直面する可能性があります。
⑥責任範囲の明確化:
WebPの適切な配信は、画像変換プラグイン（EWWW）とウェブサーバー（Xサーバー）の連携によって実現されるべき機能です。既存のホスティングサービスがこの機能を提供できないのであれば、まずはそのサービス提供者（Xサーバー）に改善を求めるのが筋であり、彼らの責任範囲内での対応を期待するのが合理的です。これらの理由から、まずは既存のサーバー環境で問題の根本的な解決を試み、それが困難であると判断された場合に、費用や複雑性を考慮した上でCDNの導入を検討するというステップが合理的であると判断しております。
3.高速化業者
VK Blocks起因のレンダリングブロック解消として、具体的には、ファイルの非同期読み込みやクリティカルCSSのインライン化などを行います。適切な技術的アプローチを適用できれば、LCP（該当部分10秒）という時間を大幅に短縮できる可能性があります。しかし、VK Blocksの複雑性や、どの程度までコードに手を入れるかによって、その効果の度合いや難易度は変わり、成果が不明確です。
そうした中で、10〜20万円支払うのであれば、石川様がご提案の他のテーマに乗り換えた方が得策であると考えております。
- このトピックに返信するにはログインが必要です。
