Satoshi Nakamura
フォーラムへの返信
-
投稿
-
対馬様
大変お世話になっております。ご教示いただいたLightning公式サイト（工務店）のPageSpeed Insights分析結果、大変参考になりました。
私も添付画像のようにPSIを計測し、、私のサイトのPSIラボデータと比較したところ、LCPの数値やボトルネックの傾向が非常に似ていることが分かりました。
Lightning公式サイトのラボデータ（モバイル）:
パフォーマンススコア: 42 LCP: 20.4秒
主なボトルネック: 「レンダリングを妨げるリソースの除外」（7,260ミリ秒）
自社リソース（VK関連CSS/JS）とGoogle Fontsが多数指摘。私のサイトのラボデータ（モバイル）:
パフォーマンススコア: 55 LCP: 14.9秒
主なボトルネック: 「レンダリングを妨げるリソースの除外」（5,730ミリ秒）
自社リソース（VK関連CSS/JS）が多数指摘。この比較から、LightningテーマがPSIのラボ環境で不利に評価される傾向が、私のサイトでも同様に再現されていることが明確に理解できました。
そして、ラボデータが非常に悪いにもかかわらず、Lightning公式サイトのフィールドデータLCPが1.9秒と「良好」であるという事実は、私にとって大きな希望となりました。
昨晩はサーバー会社さんのエンジニアの方にご支援いただいて、htaccessの設定を変えてwebP配信問題は技術的に解決したにも関わらず想定した効果（LCP２〜３秒短縮）が全く出ず、手詰まり状態でした（ハイリスクな施策をやるのか否か）。
GoogleがSEO上でフィールドデータを重視しているという点も、改めて確認でき、大変安心いたしました。
対馬さんのご指摘と具体的なデータのおかげで、その特性と、実際の評価基準について深く理解することができました。貴重な情報とご助言をいただき、本当にありがとうございました。
完璧に「解決」しまして、今後もVKプロックパターン一択です。
Nakamuraしあわせ屋根屋様
貴重な情報ありがとうございます。//なおこれはLightningを使っているうちのお店のサイトではということで、「NPO法人フリースクール」のものではないです(^^;; //
今回の課題は「VK Block」です。「NPO法人フリースクール」ではありません。
VK Blockは大変な高機能でデザインも優れたプロダクトですが、それを実現するためのコード類（CSS、JS）がふんだんに盛り込まれており、表示スピードに課題がある、というのがこのトピックの本質、中核です。
具体的には、例えば検索結果に表示された「しあわせ屋根屋」という文字をクリックすると、画面が真っ白な状態が15秒間続くということです。これによって、ユーザーが「こんなに時間がかかるなら」と、検索結果に戻って別の屋根屋さんを探す、いわゆる「ユーザーの離脱」が起こります。
また、最初の画面表示に時間がかかることは、googleの検索エンジンの評価を著しく下げますので、検索順位の下降が起こるでしょう。また、googleの広告の入札価格にも影響します。
なので、しあわせ屋根屋殿がVK Blodkを導入したら、現在の「ホームページ経由でたくさんお仕事をいただいている」状況が一瞬にして瓦解するでしょう。
このVk Blockの課題は、専門的には「レンダリング（画像表示）を妨げるブロック」といいますが、通常はこうした現象を無力化する部品（プラグイン）が効力を発揮します。がしかし。WP fastest cacheというこの分野では最強の製品製品の「delay js」という強大な機能を持ってしても押さえ込めません。
したがって非常に「根が深い問題」なのです。
今回のケースは、Web制作者の一般的な対応策、画像の圧縮、次世代フォーマットの活用、CDNなどは「レンダリング（画像表示）を妨げるブロック」問題に対して全く効きません。VK Block製品自体の問題だからです。製品の何がボトルネックかを特定し、デバックする能力が必要なので、製品のコアな部分まで触れなくてなならず、VKの内部の方しかこの課題を解決することができません。
そうした中、VK Blockは膨大なユーザーがいる製品で、この最適化をやるとなると、広範囲な影響度分析、デザイン等の機能との両立、テストなどのプロセスとワークが必要なため、簡単には解決しない課題です。
VK BlockおよびVKブロックライブラリーは、デザインだけでなくユーザーの感情動線を考え抜いて作られた素晴らしい製品で、ドラック＆ドロップでサイトを簡単に変更できるなど、メンテナンスもしやすいという、ローテクのユーザーに優しい、初期の導入者にとっても優れた製品です。
しかし、しあわせ屋根屋殿のように、検索エンジン順位でシノギを削っているような会社さんは、手を出すと大火傷する製品ではないかと思います。逆にいうと、スピードの最適化を実装すると、めちゃくちゃすごい製品になるということです。仮に実装されたら、もうVK一択。VK最強。
瀬戸内様
ご丁寧なご意見、ありがとうございます。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万円支払うのであれば、石川様がご提案の他のテーマに乗り換えた方が得策であると考えております。
石川様
お忙しい中、ご丁寧なご返信、誠にありがとうございます。ベクトルの皆様におかれましても、日々多忙な業務にご尽力されていることと存じます。
現在のタスク状況、および多数のユーザー様を抱える製品の仕様変更に伴う表示崩れや動作不具合のリスク、さらにはテーマとカスタムブロックの機能分離という貴社製品のアーキテクチャ上の特性について、詳細にご説明いただき、深く理解いたしました。チューニングの限界についても承知いたしました。
当サイトのLCP（Largest Contentful Paint）が現在15秒という極めて高い数値を示しており、その内訳が貴社製品起因のJavaScript/CSSによるレンダリングブロックが約10秒、そしてWebP画像の配信不備が約3〜5秒という状況であるとを認識しております。GoogleのCore Web Vitals基準ではLCP 4.0秒超が「不良 (Poor)」と評価され、検索エンジンからの評価に直接的な影響を及ぼすため、このパフォーマンス改善は喫緊の課題となっております。
貴社製品の持つ優れた機能性やブロックエディターとの高い親和性には、日頃より大変助けられております。また選択したブロックライブラリ・NPOのデザイン、メッセージ、構成、ユーザー感情動線設計といったテンプレートは素晴らしく、特に団体立ち上げ時には銀行開設などにサイトが必要でしたし、助成金の申請にも大助かりでした。私ども団体の初動をしっかりと支えていただいたことを、改めて感謝申し上げます。
しかしながら、ご提案いただきました通り、現状のパフォーマンス課題を鑑み、他テーマ・プラグインへの乗り換えも真剣に検討する必要があると感じております。
貴重なご意見をいただき、誠にありがとうございました。
なお、webPの配信問題に関しては、サーバー側との連携が完了した時点で、ご報告をして（皆様に共有させていただいて）、このスレッドを閉じさせていただこうと思っております。
Nakamrua瀬戸内様
コメント有難うございます。ご指摘いただいたことは、すでに実施していう範疇であると認識しています。
私の記載内容（＝自分で試したこと、実際の症状）、石川様のコメント、私から対馬様への返信をご一読いただけると幸いです。さて、瀬戸内様の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秒もかかり離脱する可能性もあることから、その利用目的に反する『深刻な問題』であることを付言いたします。
対馬様
貴重なアドバイス有難うございます。アイキャッチ画像が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石川様（社長？）のご発言はそれを踏まえてのことと認識しております。つまり、自身でっきる範疇を超えているのです。
ご参考まで。
石川様、お世話になっております。
ご返答いただきありがとうございました。「具体的に弊社テーマ・プラグインでできそうな事がありましたらその旨ご連絡くださいませ」とのお言葉を受け、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パフォーマンスの改善のため、何卒ご検討のほどよろしくお願い申し上げます。
石川様
お世話になってます。ご回答ありがとうございます。”クエリループ”ですね？右側の管理画面に、表示項目数があったので、２→４できました。
お陰様で、問題解決できました。その上また一つ勉強になりました。ガイダンスに感謝申し上げます。
Nakamura石川様
お世話になってます。お忙しい中ご回答ありがとうございます。// “ヒーローエリアの下の「NEWS」は” どうやって表示させていますか？ //
ツリーを見ると「投稿テンプレート」と記載があります。
これで回答になっているでしょうか？Nakamura
瀬戸内様
大変お世話になってます。ご回答ありがとうございます。いただいたコードはどこに貼り付ければいいでしょうか？
全体の共通設定と考えて、外観>カスタマイズ>サイドバーを見てみましたが、カスタムCSSやHTML入力などのフィールドがなかったため、恐縮ですが、お尋ねしております。ご検討いただけると幸いです。
Nakamura石川様
お世話になってます。お忙しい中ご回答いただきありがとうございます。文章内で、CTAボタン（決済ページへ誘導）を、HTMLで作成しました。
そのCTAボタンを削除したところ、正常な表示になりました。（解決しました）お手を煩わせてしまい恐縮です。また改めて感謝申し上げます。
Nakamura
