WordPress のコア ウェブ バイタルの謎を解く

Core Web Vitals は、特に SEO とサイトのパフォーマンスがデジタル戦略にとって重要な場合に、サイトを最適化するための一連の必須指標を表しています。 それにもかかわらず、サイトの Core Web Vitals を改善しようとするときに、どの WordPress ツールと戦略が最も重要かを理解するのは難しい場合があります.

このセッションを視聴して、WordPress サイトの Core Web Vitals スコアを理解し、改善するためのベスト プラクティスとツールを詳しく見てみましょう。

スピーカー:

• WP Engine のプロダクト マネージャー、Alex Zuniga 氏
• Mark Davoli 氏、Amsive Digital の Web 開発ディレクター
• Vital Design の開発担当ディレクター、Matt Chase 氏
• Sanjucta Ghose 氏、WP Engine のシニア Web 開発者
• XWP フロントエンド エンジニアリング担当ディレクター、Mike Crantea 氏

転写:

ALEX ZUNIGA: こんにちは。WordPress のコア Web バイタルのわかりやすい解説へようこそ。 WP Engine のプロダクト マネージャー、Alex Zuniga です。 そして今日は、WordPress Web サイトの主要な Web Vitals の詳細について説明します。 Core Web Vitals は、SEO やサイト パフォーマンスのためにサイトを最適化することに関心がある場合、最適化するための必須の指標です。 しかし、どの WordPress ツールと戦略が最も影響力があるかを知るのは難しい場合があります。 このセッションに参加して、WordPress の Web バイタル スコアを改善するためにベスト プラクティスとツールがどのように役立つかを詳しく見てみましょう。

では早速、本セッションのパネリストをご紹介いたします。 まず、マイクに手渡し、簡単な自己紹介をさせていただきます。

マイク・クランテア: こんにちは、マイク・クランテアです。 私はスペインのカナリア諸島にいます。 私は XWP でフロントエンド エンジニアリングのディレクターを務めており、過去 17 年間勤務しています。 主にフロントエンド テクノロジーの分野で、私は Web パフォーマンスが大好きです。 そして、私はここにいることをうれしく思います。 おい。

アレックス・ズニガ: ありがとう、マイク。 次はマット・チェイスです。

MATT CHASE: 私は、ニューハンプシャー州ポーツマスにある Vital Design の開発ディレクターです。 私の仕事ではフロントエンドに重点が置かれています。 そのため、多くのライトハウスとコア ウェブ バイタル スコアを作成しています。

アレックス・ズニガ: 素晴らしい。 ありがとう、マット。 そしてマーク。

MARK DAVOLI: こんにちは、Amsive Digital の Web 開発担当ディレクター、Mark Davoli です。 SEO は当社にとって非常に重要であるため、当社のチームの Core Web Vital スペースに特化しています。 したがって、Core Web Vitals も同様です。 ここにいて幸せです。

アレックス・ズニガ: よろしくね。 そして最後にサンジュクタ。

サンジュクタ・ゴース: こんにちは。 私もWPエンジン出身です。 私は、WP Engine の Web サイトの保守を担当するチームの一員です。 そして、これには、WP Engine がそれらを取得したときに、Delicious Brains を提供したサイトが含まれます。 そして昨年のかなりの部分を、Delicious Brain サイトを Core Web Vitals 向けに最適化することに費やしました。 ですから、これは非常に興味深い会話になると思います。 ここにいて幸せです。

アレックス・ズニガ: ありがとう。 ありがとう。 パネリストの皆様、ようこそ。 そして、あなたが何を言わなければならないかを聞くのが待ちきれません。 そのため、Core Web Vitals に関しては、測定、管理、ツール、およびクライアントの期待によって、これらの質問を分類していきます。 では、皆さんにお聞きしたい最初の質問は、そもそも Core Web Vitals を気にする必要があるのはなぜですか? また、Core Web Vital の最適化にどの程度集中する必要がありますか?

MARK DAVOLI: よろしければ、お話しできます。 私にとって、ページ速度が速いことを確認することは非常に重要です。 そして、それが重要な理由は、最終結果のコンバージョンにあります。 右？ そのため、誰かが Web サイトにアクセスすると、読み込みに時間がかかるほど、サイトを離れてしまう可能性が高くなります。 また、ページ速度が速くないと、運が悪くなり、多くのビジネスを失う可能性があります. 特にeコマースストアでは。

サンジュクタ・ゴース：そうですね。 SEO にとっては非常に重要ですが、Core Web Vitals はサイトの知覚パフォーマンスの尺度であることも忘れてはなりません。 ユーザーがサイトをどのように認識しているか。 そして、ユーザーがあなたのサイトをレスポンシブでインタラクティブで安定していると認識していることに注意を向け続けることが非常に重要だと思います. これは、Core Web Vitals が測定するものです。 したがって、SEO スコアよりも、パフォーマンスに対するユーザーの認識が重要であると思います。 だからこそ、Core Web Vitals に焦点を当てる必要があります。

アレックス・ズニガ: もちろんです。 マット、あなたは-

MATT CHASE: ええ、基本的には、私が言おうとしていたことです。ええ、SEO の側面は素晴らしいです。 しかし、最終的には、これらのサイトを人々のためにコーディングします。 そして、私たちはそれらの人々に、可能な限り最速でスナッピーなサイトを持ってもらいたいと思っています. しかし、これは両方の世界に影響を与えます。 右？ つまり、これらの Core Web Vitals に合わせて調整すると、優れた UX を実現できます。 しかし、SEOチームを満足させる方法で、勝つのは必ずしも簡単なことではありません. だから、それは誰にとってもうまくいきます。

ALEX ZUNIGA: 以上のことから、重要であることはわかっています。 しかし、スコアを測定する最良の方法は何でしょうか?

MARK DAVOLI: 使用する以外に測定する方法の 1 つに、Google の Page Speed Insight Tool があります。これは、測定に使用するツールであるため、非常に重要です。 そうです、影響を与えたい場合は、そのツールを使用することが不可欠です。 Chrome DevTools にはブラウザ内の Lighthouse もあります。これは非常に重要です。 また、Search Console には、過去 28 日間の実際のユーザーの指標を監視するための優れたページ ユーザー エクスペリエンス ツールがあります。これは、長時間の監視に不可欠です。

サンジュクタ・ゴース：ええ。 したがって、Page Speed Insights は非常に優れたツールであると言えます。Core Web Vitals 自体が過去 28 日間の実際のユーザー データに基づいているという意味で、両方のリアルタイム データが得られるからです。 ただし、ラボのデータに基づくライトハウス レポートも表示できます。 Core Web Vitals は一定期間にわたって測定されるため、実際に改善が見られるまでには時間がかかるため、これは実際にすぐに改善できることです。

したがって、スコアを改善しようとしている場合、Lighthouse は優れたツールであると思います。 したがって、これらの機会をすぐに実行して、スコアがどのように改善されるかを確認できます。

アレックス・ズニガ: 素晴らしい。 ライトハウスの大きな叫び声のように聞こえます。 素晴らしい。 素晴らしい。

MIKE CRANTEA: このトピックに追加したいのは、実際のユーザー メトリクスのパフォーマンス データを追跡することで、本番環境に達したパフォーマンスの低下により迅速に対応できるようになったことです。 ラボ テストは、ステージングの際に役立ちます。 たとえば、伝播させたくない劣化があるとします。 しかし、本番環境では、驚きとなるようなことが常に発生します。 また、Search Console と Crux データベースの実際のユーザーの指標が表示されるまで数週間待つ代わりに、Web Vitals ライブラリを使用して自分で追跡することで、時代の先を行くことができます。

アレックス・ズニガ: 素晴らしい。 うん。 時々出てくる制作上のサプライズを常に先取りしなければなりません。 わかった。 では、測定の方にお答えいただきありがとうございます。 管理について調べてみましたが、Core Web Vitals に最も影響を与えるためにできることを 1 つか 2 つ挙げてください。

MATT CHASE: だから、私が思いつくのは、可能な限りのすべてのような遅延ロードだと思います。 そして、可能な限りすべてのロードを延期します。 それは私にとって、あなたがすぐに実行できるターンキーソリューションのようなものであり、すぐに改善が見られます. WP Rocketには、そのようなことを有効にするためにオンにできる非常に簡単なチェックボックスがたくさんあります.

マーク・ダヴォ​​リ: ええ。 私にとって重要な点は、アバブ ザ フォールド レンダリングと呼ばれるものです。 したがって、それができるだけ早くレンダリングされるようにします。 前述のように、可能な限り最高のスコアを得るために、画面外にあるものはすべて遅延して読み込みます。 そうは言っても、WP Rocketは遅延スクリプト機能に優れています. しかし、私たちはそれを GTM や Google の広告スクリプトなどに限定しようとする傾向があります。 そして、可能な限り最適化されていることを確認するために、ウェブサイトを強化するテーマの実際のコアアーキテクチャを改善することに本当に集中してください. したがって、そのようなパフォーマンスへの影響を与えるためにサードパーティのプラグインに依存しているわけではありません。

マット・チェイス: ああ、もちろん。 うん。 両端。

アレックス・ズニガ: わかった。 ガチャ。 明確にするために、あなたはWP Rocketと言いました。 それが遅延スクリプト機能ですか?

マーク・ダヴォ​​リ: はい。

アレックス・ズニガ: 素晴らしい。

MIKE CRANTEA: 十分な注目を集めていないものの 1 つは、キャッシングです。 ただし、サーバーの応答時間が速いからといって、高速なエクスペリエンスが保証されるわけではありません。 ただし、サーバーの応答が遅い場合は、エクスペリエンスが遅くなることが保証されています. そのため、利用可能なすべてのキャッシング レイヤー (ブラウザー キャッシング、オブジェクト キャッシング、ページ キャッシング) を利用し、それらをオンにして機能させることが、最初の適切なステップです。 あなたの基本を行います。 そして、フロントエンドの最適化まで作業を進めることができます。 頭の中にあるものを確認します。 などなど。

アレックス・ズニガ: すばらしい

サンジュクタ・ゴース：ええ。 また、画像の最適化も忘れてはいけないと思います。 最近の多くのウェブサイトは画像を多用する傾向があるため、これは非常に重要だと思います。 したがって、画像を圧縮し、CDN を介して提供してから、既に述べたように画像を遅延ロードすることが重要だと思います。 さらに重要なことは、レスポンシブ画像を提供することです。 画像タグまたは画像タグのソース セット属性を使用して、レスポンシブ画像を提供することができます。 Core Web Vitals はモバイル ファーストの測定値であるため、これが実際に多くの改善につながることがわかりました。 そのため、レスポンシブ画像を提供することが非常に重要です。 それは私たちが時々忘れてしまうものです。

だから私はイメージだと思います。 また、ビルドステップ中に CSS で JavaScript を最小化するなど、非常に単純なこともあります。 それも大いに役立つと思います。 やり方はとても簡単です。

マット・チェイス: ええ。 その件については、実際、あなたがそれを持ち出して以来、WordPress は一種のパッケージ化された webpack ビルド システムを配布しています。 彼らはそれを WordPress Scripts で呼び出すだけです。 そして、私たちの代理店は、独自の webpack システムを維持しようとして長い間苦労しました。 そして、約 8 か月ごとにノードの依存関係が変更され、ツールチェーン全体が壊れてしまいます。 しかし、WordPress はこれを維持してくれます。 そして、それは大きな利益になりました。

そこに含まれる webpack では、動的インポートを使用してメインの JavaScript バンドルを構築し始めました。 そのため、すべてを 1 つのメイン JavaScript パッケージにまとめるのではなく、実行時にノードの依存関係をインポートするようにしています。これにより、同じ種類の遅延スクリプトの読み込みを細かく調整できるようになりました。 特定の場合のみ。 私たちのブロックがページ上にあるときのように。

マーク・ダヴォ​​リ: ええ。 また、ウェブサイトで使用するプラグインを厳選することも非常に重要です。 サードパーティのプラグインをインストールすると、多くの予期しないブロートウェアを入手できます。 したがって、それらを非常に評判が良く、よく構築されたプラグインに限定してみてください。 そして、それらのプラグインがロードするものに注意してください。 サイトのパフォーマンスを制御するのに本当に役立ちます。 残念ながら、WordPress はバックエンドでの使用などを jQuery に大きく依存しています。 しかし、フロントエンドには必ずしも必要ではありません。 したがって、可能であれば、Web サイトのフロントエンドから jQuery のサポートを削除し、ネイティブの JavaScript に固執することで、パフォーマンスを大幅に向上させることができます。

アレックス・ズニガ: 素晴らしい。 私たちはすでにこの領域に浸っていると思います。 そして、あなたはいくつか言及しました。 しかし、ツールを使用して、もう少し掘り下げてみましょう。 Core Web Vital の最適化に使用したいツールは何ですか? また、どのようなユースケースに最適ですか? または、それらが適切ではないシナリオがいくつかありますか?

マット・チェイス: つまり、それは前に出てきました。 しかし、実際には Lighthouse ブラウザ内ツールは、すぐに結果が得られるので、私が本当に頼りにしているツールです。 右。 Core Web Vitals は優れていますが、その力は、時間をかけてまとめられた集計であるという事実にあります。 したがって、実際に何かを変更して数値の変化を確認することはできません。 Lighthouse と比較して、ブラウザーでは更新を行います。 ローカルの開発環境が表示され、Lighthouse テストを実行します。 そして、私のパフォーマンスが 15 ポイント跳ね上がったことをすぐに確認できます。 いいね。 それは正しいことでした。 それを本番環境にプッシュします。

アレックス・ズニガ: 素晴らしい。 他に使用したいツールはありますか？

MIKE CRANTEA: Chrome のローカル オーバーライド機能に大いに感謝したいと思います。 これを [パフォーマンス] タブと組み合わせることで、Web サイト内のアイテムの読み込み順序を変更することもできます。 そして、それがどれだけ影響を与えるか。 特定の変更を行うために努力する価値があるのか​​、それともそのままにして本当に影響を与える他のことに集中したいのかを知るために必要な監視を提供します.

MARK DAVOLI: サーバー アーキテクチャの監視も重要だと思います。 右。 そのため、世界最高の Core Web Vitals を持つことができますが、サーバーに異常なほどの負荷がかかり、気付かないうちに、最初のコンテンツ ペイントが劇的に低下し、他のほとんどすべてに影響を与えることに突然気付く可能性があります。 そのため、New Relic などのパフォーマンスを監視するためのツールを注意深く監視してください。 ウェブサイトを可能な限り高速にレンダリングするための適切なインフラストラクチャがあることを確認するためだけに注意を払うことが重要です.

MIKE CRANTEA: キャッシングをオンにして準備を整えておくと、このような場合に役立ちます。

MARK DAVOLI: そして CDN です。

マイク・クランテア: はい。 潜在的な災害を回避します。

アレックス・ズニガ: すばらしい。 わかりやすかったです。 そこで質問の一つ。 Core Web Vitals を最適化するための最適化プラグインは多数あります。 それを支援するためのWordPressプラグインの制限は何ですか? それとも本当にサイトを最適化しているのでしょうか? それとも、Google の測定値をだましている可能性がありますか? そして、おそらくそれは、プラグインに頼るよりも、プラグインを使用するか、作業を行う方が良いかという問題だと思います。

SANJUCTA GHOSE: プラグインは素晴らしいと思います。 たとえば、たとえばWP Rocketは素晴らしいです。 EWWW Image Optimizer をよく使用します。 そしてそれも素晴らしいと思います。 しかし、私はそれがすでに言われていると思います。 WP Rocket は、遅延 JavaScript 機能をオンにすると、奇妙なバグが発生するケースが見られたので、慎重に使用する必要があります。 ワンオフバグ。 そのため、プラグインを使用するよりも、場合によっては独自のソリューションを展開することをお勧めします。 開発の専門知識がある場合。

そのため、Delicious Brain サイトで行った最適化のほとんどは、プラグインを使用するのではなく、独自に開発しました。 とはいえ、プラグインは素晴らしい出発点だと思います。 したがって、始めたばかりの場合は、たとえば、ステージング サイトに WP Rocket をデプロイして、いろいろ試してみて問題が発生するかどうかを確認したいと思うかもしれません。 または、それが実際の改善をもたらす場合。 ですから、プラグインは慎重に使用する必要があると思います。 そして、プラグインが何をしているのか、バックグラウンドで何が起こっているのかを知る必要があります。 そして、それがあなたのサイトにどのように影響するか.

マット・チェイス: ええ。 ありがたいことに、最近のバージョンの WP Rocket は、少なくとも、危険なスイッチを非常に明確にラベル付けすることに長けていると思います。 私も何度もスクリプトの遅延に悩まされてきたので、CSS の最適化のように予期しないものでさえ、モデルが壊れていて、クラス名がそれらを可視化すると言ったものを取得できなかったのです。 . とても刺激的な一日でした。

しかし、ええ。 WP Rocket は、明らかに優れたコード インと優れたコード アウト以外に、私がよく使うものです。 右。 仕事をすることは、常にそれに取り組むための最良の方法です。 プラグインは物事を自動化できます。 しかし、実際にコードをスリムで意地悪なものにすることに代わるものはありません。

MIKE CRANTEA: ラボ タイプのプラグインとしてマークされているプラ​​グインがもう 1 つあります。 それがパフォーマンスラボです。 これは、WordPress パフォーマンス コア チームによって行われます。 恐ろしいことのように聞こえますが、これまでのすべてのテストで完全な安定性が得られました。 そして、それは本来あるべき姿と、その Performance Lab プラグインに仕上がった作業の質にとって非常に印象的でした。 ですから、試してみる価値があります。 いくつかのチェックボックス。 そして、そこにあるものはすべて安全です。 データベース スイッチについてはよくわかりません。 私がそれについて読んだとき、それはもっと物議を醸すものです。 うん。 そのボタンに触れないでください。 プラグイン内にSQLiteサポートなどを追加したように、これはいくつかの小さなWebサイトで確実に機能しています.

アレックス・ズニガ: 興味深いですね。

マーク・ダヴォ​​リ: ええ。 そして私にとって、WP Rocket は素晴らしいです。 私たちが行っていることのほとんどはネイティブに構築されているため、ほとんどのサイトでその使用を制限しています. しかし、Core WordPress には他にも多くの機能があり、適切に使用すれば適切に最適化されたサイトを実現できます。 Elementor などのサード パーティの代わりに Block Editor を使用すると、サイトが大幅に肥大化する可能性があります。 したがって、新しいネイティブ Gutenberg 型ブロック システムのように構築し、たとえばすべてのページで一度にすべてをロードするのではなく、必要に応じて実際にファイルをロードするとします。 現在、WordPress には遅延読み込み機能が組み込まれています。 そのため、それがどのように使用されているかを監視し、適切に使用するなど. そして、WP Rocket のようなツールを追加して、既存のものを強化します。 しかし、それだけに頼っているわけではありません。

特にうまく機能しないサイトを持っている場合は、そこにたどり着くのに役立ちます. しかし、前述のように、重要な CSS 生成と同様に、ボットがページで見たものに基づいて多くの仮定を行うため、これらのことには多くの問題が生じる可能性があります。 しかし、初期ビューをレンダリングしないものを予測することはできません。 したがって、前述のようにモデルがある場合、それらがポップアップしても、その可能性があることはわかりません。 そのための CSS を生成せず、適切にインライン化します。 たとえば、重要なフォントをプリロードしたり、スクロールせずに見える範囲でレンダリングしたりします。 繰り返しますが、それが鍵です。 本当に最も重要なこと。

SANJUCTA GHOSE: 重要な CSS の話題についてですが、私はただ飛び入りして、Addy Osmani が Critical という素晴らしいツールを持っていることを述べたいと思いました。 これをビルド プロセスに追加して、重要な CSS を生成できます。 それは素晴らしいです。 そして、それは非常に信頼できます。 あなたが重要なCSSについて言及したので、それを追加すると思いました。 断ってごめんなさい。

マイク・クランテア: 結構です。 重要な CSS の同じトピックについて、Jetpack チームは Jetpack Boost プラグインで何かをしようと努力しています。 これは、ページを iframe などでレンダリングすることにより、重要な CSS を生成する非常に興味深い方法です。 それが機能するときに提供する、それは素晴らしいソリューションです。 そうでない場合は、「ここでは機能しません」と表示されます。 一緒に移動してください。 何か他のものが必要です。 重要な CSS にたどり着くのは必ずしも容易ではありません。 一方、4、5 年前は、クリティカル CSS は超巨大でした。 とても助かりました。

ここ 2 ～ 3 年の HTTP/3 の進歩により、1 つの重要な CSS がブロックをレンダリングしても、100 キロバイト程度のインライン CSS を使用しても影響はほとんどありません。 4 ～ 5 年前に重要な CSS を使用していた Web サイトと同じくらい高速に動作する Web サイトを作成しています。 そのため、適切なサイズの CSS をサイト内に配置することを恐れないでください。 あなたはそれを取り除く必要はありません。 そして、超最適化されたウェブサイトを見てきました。

重要な CSS には 100 キロバイトのインライン CSS があります。 また、レンダー ブロッキング、jQuery、および使用されなかった他の 2 つのスクリプト。 ええ、そうです。 あなたはそれで目的を打ち負かしています。 5% タイプのアプローチを持続させるのに役立ちます。 しかし、それから始める場合は、最初のものを見てください。

アレックス・ズニガ: 素晴らしい。 素晴らしい。 私はそれらのすべてのツールだと思います。 それらの叫び声を聞くのは素晴らしいことです。 そして、それらの提案や推奨事項を聞くのは素晴らしいことです. そして、その種の多くが次の質問の周りに渦巻いています. Core Web Vitals を使用して WordPress で作業することのユニークな側面は何ですか? 他の技術スタックではなく、プラグインを介してこれを行う必要があるということですか? WordPressの方が簡単ですか？ 他に利用できるツールはありますか? 先ほど述べたように、皆さんは多くのツールを撃ち落としました。 WordPressの方が簡単ですか？ WordPressの方が難しいですか？ 皆さんは何を取りますか？

MATT CHASE: WordPress ならとても簡単だと思います。 それで、私たちは少し話しました–または、彼らが配布するWordPressスクリプトノードパッケージについて言及しました。これは、ボックス内の優れた種類のwebpackビルドシステムです. また、WordPress Create ブロックもあります。これは、WordPress ベースのサイトのカスタム ブロックをブートストラップする非常に迅速かつ簡単な方法です。 しかし、いわばグルーコードの多くが、あなたのために書かれているような方法で構築されています。 つまり、それはすでに賢いことです–マーク、あなたが言及したのは、それらのスクリプトをキューに入れるべきときにだけでした. したがって、ブロックがゲートからすぐにそれを行っているかどうかがわかります。 考える必要すらない。 したがって、WordPress を使用すると、そのような作業が非常に簡単になります。

マーク・ダヴォ​​リ: ええ、もちろんです。 しかもオープンソースです。 右？ したがって、ほとんど何でも変更できます。 そのため、クローズド システムで作業している場合、Core Web Vitals と WordPress を最適化するのははるかに困難です。 そして、Core Web Vitals が最初に発表されたとき、それはまだ実現していませんでした。 それははるかに挑戦的でした。 これらの機能の多くを追加することで、特にブロック エディターやブロック ベースのビルドなどを追加して、アセット、CSS ファイル、フォント ファイルなどを選択的に読み込む機能を本当に最適化することで、本当に長い道のりを歩んできました。 そうそう。 それは素晴らしかったです。

ALEX ZUNIGA: それはおそらく、クローズド システムとオープン ソースの違いです。 どうぞ、サンジュクタ。

サンジュクタ・ゴース：ええ。 うん。 WordPress専用のホスティングプロバイダーがたくさんあるからだと思います. そして、あなたが言ったように。 WordPress はオープンソースです。 そのため、WordPress サイトのホスティングに関して多くの最適化が行われています。 したがって、WordPress の上に構築している場合は、すでに多くのサポートが利用できると思います。つまり、車輪を再発明する必要はありません。 したがって、WordPress の上に構築して Core Web Vitals を最適化するのは、間違いなく簡単だと思います。

アレックス・ズニガ: 美しい。 そこで、これらのツールをどのように測定するか、コア Web バイタルを実際に強化するために何を使用するか、いくつかのツールについて話しました。 クライアントの期待について話しているとき、新しいプロジェクトのどの段階で、Core Web Vitals をビルドまたは戦略の一部として検討し始めますか? ベースのボイラープレート テンプレートのように開始するのは適切ですか? それとも、ストーリーの中でもう少し最適化するものですか? 皆さんは何をしますか？

マット・チェイス: ええ。 私にとっては、最適化されていないウェブサイトに対して行うことよりも、物事を構築する方法にすぎないと思います. それは最初からです。 そして、理想的には、コードのすべての行に含まれています。 私はそうしないようにしています。最適化された大規模なサイトを構築してから、後で戻って修正したくありません。 最初からできるだけ綺麗に書きたいと思います。 そして、通常、そのようにすると、最後に最後の最適化ジュースを少し絞り出す方が少し簡単です。

マーク・ダヴォ​​リ: ええ。 彼は絶対に正しい。 最初から構築を開始します。 つまり、終わりに近づくほど発生しないコンポーネントがあります。 ローンチが近づくまで、画像の最適化を通じて画像を実行するつもりはありません。 しかし、ビルド自体ではなく、時にはデザイン プロセスにおいても、コア Web バイタルを考慮に入れる場合、サイトがどのように設計されているかを考えることが重要です。 アーキテクチャ上、特定の設計を高速に実装することは、他の設計よりも難しいためです。 したがって、それを理解し、実装をより困難にする可能性があるものとそうでないものについて設計者を教育することは、非常に役立ちます。

マイク・クランテア: そして、制限を指示します。 ねえ、最大 x 台の電話しか持てません。 すべてのバリエーションで 25 をテーブルに持ち込むべきではありません。 これは、設計段階から役立ちます。 また、プロジェクトの期間中に発生するいくつかのタッチポイントがなくても、いくつかのことを簡単にやり遂げることができます. スプリントのように、クイズ プラグインをミックスに追加するための 7 つのリクエスト。 それがチェックされていない場合は、最後に少し見つかります。 したがって、私の推奨事項は、これを数スプリントごとに処理することです。 物事がどのように進化するかのステージングの自動測定を確認します。 最後にプッシュされたものはどうなりましたか? 物事は遅くなりましたか? プロジェクトの終了時に対応するのではなく、事前に是正措置を講じる必要がありますか?

サンジュクタ・ゴース：ええ。 同意します。 ポップアップ、広告バナー、またはそのようなものがあるべきかどうかなどの単純なことなので、デザイン段階から始めることが非常に重要です。 場合によっては、累積レイアウト スコアに大きな違いが生じることがあります。 そのため、何が起こるかを事前に知っておくことは良いことです。 ポップアップが表示されるか、バナーが表示されるかどうか。また、プロジェクトの終わりに向けてサプライズが発生することは望ましくありません。 そのため、設計段階からクライアントや利害関係者を関与させ、これが Core Web Vitals に影響を与える可能性があることを伝えて、十分な情報に基づいた決定を下せるようにすることが非常に重要だと思います。

MARK DAVOLI: これは立ち上げ後にも非常に役立ちます。なぜなら、サイトを公開したらすぐに、後でチャット ウィジェットなどを追加しようと思う場合があるからです。 それから突然、よじれがあります。 そして、これをどのように統合して最適化するかを考えなければなりません。 そのため、遅延スクリプト機能はほとんどの広告ピクセルをプッシュできますが、これは Core Web Vitals スコアを殺すのによくないことで有名です. しかし、クライアントが本当に望んでいることにとって重要なことであるため、何かを遅らせることができない場合があります。 そのため、できる限りバランスを取り、潜在的な影響を確実に伝えます。 そして、最終的な結果は、できるだけ早くそれを取得することです. 機能を犠牲にしなければならない場合もあります。 時々あなたはしません。 ただし、これらのコンバージョンを増やすために、できるだけ早く入手してください。

アレックス・ズニガ: すばらしい。 素晴らしい。 だから私は、より良い成分が最初からより良いウェブサイトを作るというようなことを聞​​いています. 最後に Core Web Vitals を平手打ちするだけというわけではありません。 最初にそのように考えたいのであれば、それは本当に生き方です。 うーん、すごい。 それでは最後の質問です。 Core Web Vitals に費やした時間の価値をクライアントに伝えるのに苦労したことはありますか? それは彼らが今まで押し返したことですか？ なぜその仕事をしているのか理解できないことがありますか？

マット・チェイス：実際に反対されたことはないと思います。 どちらかといえば、それは逆です。 通常、パフォーマンスが必要です。 Core Web Vitals が必要です。 実現させましょう。 常に反省しているわけではありませんが、トラッキング ピクセルと、それらがスコアを下げることで悪名高いことについて話しました。 しかし、誰も気にしません。 私たちは、ピクセル、ピクセル、ピクセル、ピクセルのようなものです。 そのため、トラッキングを追加するときは、その費用対効果を実際に比較検討する必要があります。トラッキングを追加して結果を得るほど単純ではないからです。 費用がかかるからです。

アレックス・ズニガ: 素晴らしい。

MIKE CRANTEA: パフォーマンスには忍耐力が欠けていると思います。 ですから、最初のスプリントの後、数スプリント続くパフォーマンス ワークを行いましょう。 いつ見られますか？ いつ見られますか？ 1 つの機能、1 つの機能、1 つの機能を増やすなど、反復的にリリースを計画することで、この作業がもたらす影響の信頼性が高まります。 そして、これがコンバージョンと変化につながるのを目にすればするほど、教育作業に多くの時間を費やすことなく、価値がより早く認識されます。

マーク・ダヴォ​​リ: ええ。 クライアントが理解するのが難しいことの 1 つは、実際のユーザー指標とラボ データの違いだと思います。 それらの多くは独自のテストなどを実行する可能性があるためです。 そして、完全に理解していません。 したがって、ページの起源の要約部分が洞察であることを彼らが理解するのを助けることは、実際にはGoogleがSEOランキングなどに影響を与えるために使用するものです. 彼らの多くは、そのスコアを探して最適化しているからです。 また、変更がどのように影響したかを完全に把握するには、本番環境で行われた変更を測定するのに 28 日かかることを理解してもらいます。

ALEX ZUNIGA: それは素晴らしい呼びかけです。 素晴らしいコールアウト。

マイク・クランテア: そして、最も紛らわしい指標の 1 つを指摘する必要があります。 対話性メトリック。 それらは不安定なことで有名です。 そして、スコアの変化のようにもっと恐れているタイプの人々にとっては、私たちが構築した新しい機能がウェブサイトを大幅に遅くしたようなものですか? そして、もう一度テストに合格すると、10 ポイント上がってから 10 ポイント下がるようなものです。 このバリエーションを説明するのは非常に時間がかかります。 一貫性のある数字が 1 つだけではないのはなぜですか? それは名前付けやキャッシュと同じくらい難しいことです。

アレックス・ズニガ: すごいね。 Core Web Vitals に関する皆様のご意見、ご感想をお寄せいただき、誠にありがとうございます。 それらをどのように使用するか、それらを測定するために何を使用するか、それらすべてに対する顧客の期待をどのように設定するか。 本当に勉強になりました。 パネリストがここでの時間を楽しんでくれたことを願っています。 皆様からのフィードバックをお待ちしております。 また、ここに参加した参加者にも素晴らしいフィードバックが得られたことを願っています。

それでは皆様、お忙しい中ありがとうございました。 さて、それは私たちのパネルでした。 パネリストの皆様、本当にありがとうございました。 このパネルにご参加いただきありがとうございます。 DE{CODE} の残りのセッションをご覧いただき、楽しい時間を過ごしていただければ幸いです。