フレームホール: PageSpeed 6.0 の抜け穴で簡単に満点を取れる

優れた Web 開発者なら誰でも、Google の PageSpeed Insights とオープン ソースの Lighthouse がバックグラウンドで使用されていることが、Web サイトの相対的なパフォーマンスを特定するのに役立つ最先端のツールであることを知っています。 また、この知覚速度を改善するためにどのような変更を加えることができるかについての重要な洞察も提供します。 PageSpeed は、Web 上の高速と低速の標準的な尺度になりました。

Google 自身が現在、各 Web サイトのこの PageSpeed スコアを追跡し、それを多くのインプットの 1 つとして使用して、誰が検索結果のトップに到達し、誰が 10 ページの煉獄に追放されているかを判断していることは害にはなりません.

達成不可能な 100 の完全なスコアに近づくことを期待して、このスコアを最適化および改善するためだけに、業界全体と何百万ドルもの資金がやり取りされています。最適化します。 これらの新しいメトリックは、Largest Contentful Paint (LCP)、Cumulative Layout Shift (CLS)、Total Blocking Time (TBT) です。 Google には、これらの新しい「Web Vitals」を説明する記事全体があり、測定方法の核心について詳しく説明しています。

この新しいリリースは、Web パフォーマンス業界がより多くのサービスを販売するためのまったく新しい機会です。Web サイトは、そのトップ スコアを追求するために新鮮で異なる変更を必要としているからです。 1 セント硬貨を費やす必要はありません。60 スコアの地獄の深みから 100 スコアの天国まですぐに行ける簡単な変更をお見せします。

TLDR: PageSpeed は、YouTube や広告などのサードパーティの埋め込みの速度への影響を考慮しなくなりました

要点だけを知りたいのであれば、答えは、Google の最新の変更により、Largest Contentful Paint に大きな重みが置かれているということです。 これは、Web サイトをロードするときに、画面に最大の要素が表示されるまでにかかる時間の測定値です。 これは、読み込み速度に対するユーザーの認識の適切なプロキシです。 問題は、そのコンテンツがスクロールせずに見える最大の要素として技術的に認定されている場合でも、Largest Contentful Paint が埋め込みコンテンツを考慮しないことです。

YouTube 動画や大規模な広告の埋め込みなど、サードパーティの埋め込みコンテンツのパフォーマンスへの影響が表面化しない理由を推測することなく、速度を向上させるために間違った変更を行うように人々を動機付け、Web を後退させると簡単に言えます。

たとえば、PageSpeed スコアがいかに重要になったかを考えると、それはばかげているように思えます。 ウェブサイトの元の低速バージョンを iframe するだけで、ウェブサイトの PageSpeed スコアを 60 から 100 に改善します。 結果を確認するための簡単なコマンドはここにありますが、以下を読んで、スコアを最適化しているユーザーが最終的なフレームホール ソリューションにどのように進んでいるかを確認してください。

 # Verify you have the new Lighthouse 6.0 installed npm install -g lighthouse # This one should have a score somewhere around 60 :( lighthouse https://webvitalsfail.b-cdn.net/ --view # Instantly to 100 lighthouse https://webvitalsfail.b-cdn.net/anything-100.html --view

キャットダンス v1 - リンク

これは、モバイル アプリ「Cat Dance」の典型的なプロモーション ページを表示するための簡単なサンプル Web サイトです。 話題の最新アプリを携帯電話にインストールすると、猫が踊る様子を示す超クールなアニメーション GIF が特徴です。 それでは、この Web サイトの Lighthouse 6.0 スコアを確認してみましょう。

うわー、パフォーマンス スコア 60 は、私たちのような成績優秀者にとってはつらいものです。 Google によると、この単純なサイトがどうしてこんなに遅いのでしょうか? このバージョンで導入された新しいメトリックの 1 つである "Largest Contentful Paint" に注目しましょう。

これは、アニメーション コンテンツにビデオを使用することを推奨し、Largest Contentful Paint 要素が踊る猫のアニメーション GIF であることを示しているため、非常に役立ちます。 それでは次に進みましょう:

キャットダンス v2 - リンク

このバージョンでは、アニメーション gif を、ネイティブの HTML5 Video Element を使用して再生される mp4 に置き換えます。 mp4 は文字通りアニメーション コンテンツ用に作成されており、同等のアニメーション gif よりもはるかに小さいため、これははるかに優れているはずです。

まあ、これは確かに正しい方向に進んでいます。 すばらしい踊る猫のアニメーションを mp4 に切り替えるだけで、14 ポイント向上しました。 LCP が 104.9 秒から 9.9 秒になったことは、確かに大幅な改善です。 しかし、私たちは 74 に満足していません。これは「C」グレードのようなもので、私たちは A+ 達成者のグループです。

LCP は、以前のアニメーション gif の代わりに意味のあるビデオによって生成されるようになりました。 しかし、エンコーディングやポスター画像などでうまく機能していない可能性があるので、次はそれで遊んでみましょう。

キャットダンス v3 - リンク

このバージョンでは、アニメーション化された猫のビデオに YouTube のみを使用します。 そうすれば、ビデオのエンコードに関連するものであれば、これを排除するのに役立ちます. 一般に、単純なビデオ エンコードが妨げになっている可能性があるため、この方法で得られるスコアを見てみましょう。

ちょっと待ってください、こいつらは天才です。彼らは私の PageSpeed スコアを 99 まで上げました。スコア 76 の原因は、ビデオ エンコードを本当に台無しにしたに違いありません。

ここで何か問題がありますか？ 以前のバージョンでは、踊る猫は常に画面上で最大の要素でした。 このテストのスクリーンショットを見ると、このバージョンでもビデオが同じサイズであることがわかります。 では、なぜ<h1>のテキストが最大の要素であると主張しているのでしょうか? その答えは、Largest Contentful Paint メトリックの Google の説明にあります。 このメトリックには、動画、画像、SVG などの最大の要素が含まれますが、IFRAMES は含まれません

待って、何？ これは正しくありません。 iframe が最大の要素であり、糖蜜のように読み込みが遅い場合、それは問題ではありません...カウントされません! したがって、iframe はパフォーマンスの魔法のブラック ホールのようなもので、遅い要素や大きな要素を埋め込むことができ、パフォーマンス スコアには影響しません。 とんでもない！ これを試してみましょう。

キャットダンス v4 - リンク

私たちの理論をテストするために、大きなアニメーション GIF とすべてを含む正確なバージョン 1 のサイトに戻ります。 変更は 1 つだけ行います。 アニメーション GIF を iframe にロードして、PageSpeed Score がどうなるか見てみましょう。

なんてこった...これで本当に解決策になるのでしょうか？ ウェブサイトの速度スコアの低下を引き起こしている問題を取り上げ、それらを iframe にスローしてから、BOOM を実行します。これ以上の問題はありません。 iframe にロードされたのと同じファイル、同じサイズであるため、ロード速度が実際に変わっているわけではないことがわかっているということです。 YouTube の埋め込みを使用したときと同じように、実際には速度はそれほど変わりませんでした。 iframe は、PageSpeed Score を打ち負かすための魔法のポータルにすぎません。

しかし、遅い要素をすべて iframe に移動しなければならないのは、ちょっと面倒なことです...

Cat Dance v5 - Framehole'd Link

Web サイトの速度をすぐに向上させる、より簡単な方法が必要です。 要素を選択的に iframe バージョンに置き換えなければならないことは、非常に複雑であり、長期的には価値がないかもしれません。 私たちは懸命に働くのではなく、賢く働く方法を知っています。

サイト全体を iframe に入れるとどうなるでしょうか? このようにして、ソリューションはサイトの実際のコードベースから分離されます。 この種のことをエッジまたは NGINX で行うこともでき、これを既存のコードへの影響から完全に切り離すことができます。

私たちの v5 は v1 のページであり、空のラッパーに iframe されています。 同じ大きなアニメーション gif、最適化なし。 そして今では 60 から 100 になりました。これは聖杯であり、実際の Web サイトに対して作業を行う必要はありません。

これはばかげている

これが今まで見た中で最大のスネーク オイルであり、根底にある速度が少しも変わらなかったのでこのスコアの変更を気にする開発者はいないと考えているなら、あなたはスネーク オイルの最前線にいると思います。しかし、人々が気にするかどうかについては非常に間違っています。

PageSpeed は Web パフォーマンスのゴールド スタンダードであることを忘れないでください。 Google は、このスコアを使用してアルゴリズムにフィードしています。 あなたの製品が PageSpeed スコアにどのように影響するかを知りたいと顧客から聞いたことがない場合は、十分な数の顧客と話をしていません。 彼らが気にかけているのは、Google が気にかけているからであり、スコアには何らかの意味があるはずです。 私がこれを説明するのにどれだけの言葉を要したかを見てください。あなたの製品がサイトの速度を低下させているのに対し、シンプルでわかりやすい PageSpeed スコアが間違っていることを顧客に伝え、あなたがどれほど間違っているかを宣言することを想像してみてください。

理由が何であれ、結局のところ、最も重要なコンテンツが Web サイトに表示されるまでの時間の計算から iframe を除外することを選択することは、まったく間違っています。

Web サイトの速度の指標として最大の要素の表示時間を使用することは、世界的に理にかなっています。 iframe に読み込まれた場合でも、速度の認識に影響を与えます。 また、埋め込みコンテンツを除外してスコアを進めることは、Web を高速化するという目標にとって有害で​​す。 埋め込みコンテンツは、読み込み時間が遅い原因である場合は特に、フリー パスを取得しません。

スコアリングがこれらの Web メトリクスで展開される場合、それらのアイテムの速度コストを完全に無視して、巨大な広告とサード パーティの埋め込みを備えたパッチワーク サイトに戻るように動機付けられている Web を求めています。 経営陣は可能な限り最高の PageSpeed Score を望んでいたため、この記事で述べたようにサイト全体の iframe を正確に実装する人がいることは間違いありません。

行動はスコアの付け方によって形作られる