00:05
はい、今日はですね、昨日の夜、関西CTO ミートアップっていう勉強会がありまして、こちらにパネルディスカッションとして、一応動画させていただいたので、
今ですね、大阪の南場で配信をしております。はい、おはようございます。イメージのkeethこと熊原です。では、本日も朝活を始めていきたいと思います。
本日はですね、State of Jays 2022の続きを読もうと思っていたんですけど、ちょっと面白い記事を見つけてしまったので、
一本挟んでしまって申し訳ないですけど、今日は、Our top Core Web Vitals recommendations for 2023ということで、
はい、まあ、皆さんごよたしというか、ご存じだと思います。Core Web Vitalsの2020年版、これがいいだろうみたいな記事が書かれていたので、それを読みたくなったので、読んでいきたいと思います。早速では行きましょう。
2023年にCore Web Vitalsのパフォーマンスを向上させるために、Chrome DevRelチームが最も効果的だと考えているベストプラクティスを集めました。
長年にわたって、Googleはウェブ開発者に対しパフォーマンスを向上させる方法について多くの推奨事項を提示してきました。
これらの推奨事項はそれぞれ個別に多くのサイトのパフォーマンスを改善する可能性がありますが、推奨事項の完全なセットは確かに圧倒的であり、
現実的には一人の人間やサイトがそのすべてに従うことは不可能になります。
ウェブパフォーマンスが本業でない限り、どの推奨事項があなたのサイトに最大の影響をもたらすかというのはおそらく明らかではないでしょう。
例えば、重要なCSSを実装すると読み込みパフォーマンスが向上するという記事を読んだことがあるかもしれませんし、
画像を最適化することが重要だという話も聞いたことがあるかもしれません。
しかし、その両方に取り組む時間がない場合、どちらを選べきかどのように判断すればよいでしょうか。
クロームチームでは昨年1年間この問いに答えようとしてきました。
ユーザーのパフォーマンスを向上させるために開発者に提供できる最も重要な推奨事項は何でしょうかというところです。
確かにね、自分たちで軸があったりとか方針があったりとか、
最初からこれが課題だみたいなところがはっきり見えているんだったらそれに対するアクションを取るといいんですけど、項目のアクションを取ればいいんですけど、
そうじゃないのであればどうやって考えればいいかというのは確かに難しいですね。
この質問に適切に答えるためには推奨事項の技術的なメリットだけではなく、
開発者が実際にその推奨事項を採用できる可能性に影響を与える人的もしくは組織的な要因も考慮する必要があります。
つまり理論的には大きな影響を与える推奨事項であったとしても、現実にはそれを実施するための時間やリソースを持つサイトというのはほとんどないでしょう。
同様にいくつかの推奨事項は非常に重要になりますけど、ほとんどのウェブサイトは既にこれらのプラクティスを実践しています。
つまり私たちはウェブパフォーマンスに関する推奨事項のトップリストに焦点を当てたいと考えました。
確かにそうですね。
最近そもそも実装するフレームワークだったり、SaaSのシステムとかサービスだったりが、
そもそもウェブパフォーマンスに割と考慮した実装になってたりとか、その辺吉田にやってくれてたりするので、
03:03
実は意外とその推奨事項のいくつかは既に実践を知らぬ間にやってたりする可能性が多いんですよね。
実生活に最も大きな影響を与えると思われる推奨事項というところで、
トップリストに焦点を当てたいというのはそのトップリストが3つあって、
1つが実世界に最も大きな影響を与えると思われる推奨事項で、
2つ目がほとんどのサイトに関連し適用できる推奨事項、
3つ目がほとんどの開発者が現実的に実施可能な推奨事項、この3つに焦点を当てたいと思います。
この1年間私たちはパフォーマンスに関する推奨事項の全セットの監査と、
上記の3つの基準に対する各セットの評価、
訂正的および定量的両方ありますと、これに多くの時間を費やしてきました。
この記事ではCore Web Vitalsの各メトリクスのパフォーマンスを向上させるための
最も重要な推奨事項というのを解説します。
ウェブパフォーマンスの初心者、または何が最大の効果をもたらすかというのを判断している場合、
これらの推奨事項が出発点として最適であると私たちは考えています。
というのが一応冒頭のお話でした。
ここから一つ一つの推奨事項にガーッと入っていくわけですけど、
まず一つ目は、ご存知というかみんな大好き、
LCPですね、Largest Contentful Paintですね、ところから行きたいと思います。
最初の推奨事項は不可パフォーマンスの指標であるLargest Contentful Paint、LCPについてになります。
3つのCore Web Vitalsの指標のうち、LCPは最も多くのサイトが苦労しているもので、
現在Web上の全サイトの約半数しか推奨基準を満たさないので、そこから始めましょうと。
この人たちは勝手に分析したりとか、もしかしたらお願いしたりとか相談をして、
調査させてもらったみたいなのがあるかもしれないですけど、
全世界の実に半分ぐらいしか、Googleが推奨している値をクリアしていないんですね。
これ結構意外ですね。
では実際の中身に入っていきます。
LCPリソースがHTMLリソースから検出可能であることをまず確認しますというところからでした。
2022のWeb Almanac by HTTP Archiveというものがあるんですね。
そういうサイト記事があるんですけど、そこによるとモバイルページの72%はLCP要素として画像を使用しており、
ほとんどのサイトでLCPを最適化するには、これらの画像を素早く読み込む必要があることを意味しています。
多くの開発者にとって、画像の読み込みにかかる時間は課題の一つに過ぎないということは明らかではないでしょう。
HTTP Archiveのデータによると、多くのサイトはこの部分で詰まることが示唆されています。
早くWebP対応してくれとか、画像のフォーマットありますよね。
それをAppleがSafari対応してくれたらいいなと思いますけどね。
実際、LCP要素が画像であったページのうち、39%の画像はHTMLドキュメントのソースから発見できないソースURLを持っていました。
つまり、これらのURLは標準的なHTML特性、いわゆるイメージタグのソースイコール補強記みたいなところか、
06:01
もしくはリンクレールイコールプリロードのHREFイコールなんちゃらみたいなものですね。
こういうもので発見できないため、ブラウザーはそれらを素早く発見し、すぐに読み込みを開始することができるんですよ。
画像の読み込みを開始する前に、CSSやJavaScriptのファイルが完全にダウンロードされ解析され処理されるのを
ページが待つ必要があるんだったら、それはすでに遅すぎるかもしれません。
HTMLの解析した後って、CSSとJSでまず抽象項分岐を作って、そこをさらに解析してってやるんですけど、
そこの順番がCSSが終わったら次にJSっていって、それぞれがちゃんとブロックするんですよね、処理自体を。
だから本当に遅いんですよね、それらを待ってしまうと。
なのでここはできればそういうことをしないようにやりたい。
さっきのリンクでリコールプリロードってあるんで、プリロードで事前に先読み的に読み込めるんだったら読み込みたいですよね。
こういう細かいテクニックとか、あとはレイジローディングとかもありますけど、
とにかく初期レンダリングのスピードを速くするってのはすごく大事なことだと思うので、
画像の扱いはこの先も僕らはずっと向き合い続けなきゃいけない課題だよなってずっと思ってますね。
続いて、CSSまたはJavaScriptファイルが完全にダウンロードされ、解析され、
処理されるのを待ってからイメージの見込みを開始する必要がある場合は遅すぎる場合があります。
一般的なルールとして、LCP要素がイメージの場合、画像の場合ですね。
画像のURLっていうのは常にHTMLソースから検出可能である必要があります。
それを可能にするヒントをいくつかあげます。
いくつかあるんですけど、これはチェックというかリスト項目になって大きく3つありますが、
1つはソースまたはソースセットですね。
SRCセット属性を持つ要素を使用してイメージをロードします。
レンダリングにJavaScriptを必要とするデータ-ソースみたいなような非標準の属性は使用しないでください。
9%のページではデータ-ソースの背後にLCPイメージが隠されています。
これ使わないで基本的にはソースまたはソースセット属性を使用してイメージをロードしてください。
クライアント側レンダリング、クライアント側レンダリングに翻訳されるんですね。
CSRのことですけど、よりもサーバーサイドレンダリングですね。
SSRを優先します。
SSRというのはHTMLソースにページ全体のマークアップ、イメージを含むものが存在することを意味しています。
CSRソリューションではイメージを検出する前にJavaScriptを実行する必要があるので、
どちらかというとSSRの方が画像処理をするときはやっぱり早いよという話をしていますね。
それはもちろん、そもそもSSRの方が早いのは皆さんご存知だと思います。
思い処理とか計算とかもバックエンドに分投げることができるので、そりゃそうだよねって感じですね。
続いて、外部CSSまたはJSファイルからイメージを参照する必要がある場合でもタグを使用してHTMLソースを含めることができます。
はぁ?どういうことだ?
インラインスタイルで参照されるイメージというのはブラウザのプリロードスキャナーでは検出できないため、
HTMLソースで検出されても他のリソースのロード時に検出がブロックされる可能性があるため、
このような場合はプリロードは役に立ちます。
あぁ、そういうことね。
やっぱりなんだかんだプリロードは大事だよなと思いますね。
続いて、LCPイメージに検出可能性の問題があるかどうかというのを理解するのに役立つライトハウスのバージョンですね。
09:07
今10.0らしいです。2023年1月に10.0が出たと。
このバージョンで新しい関数をリリースする予定ですと。
そうなんや。
あとで僕見てみますけど、ライトハウスの更新ブログまだ読んでないので、
たぶんGoogle出してるっぽいので、それはちょっと見てみたいと思います。
で、LCPリソースがHTMLソースから検出可能であることを保証することは測定可能な改善につながる可能性があり、
リソースに優先順位をつける追加の機能を開放することにつながります。
これは次の推奨事項になりますということですね。
ではでは次の推奨事項に行きましょう。
確かにね、特にCSSから画像を読み込む場合も全然あるので、
その場合ってやっぱり重くなりますよね。
普通にHTMLの解析をして、そこのプリロードから先に画像を取れるんだったら、
そっちの方が絶対早いはずなので、これは本当にその通りだなと思いました。
では続いて、じゃあ続いていきましょう。
続いてはLCPリソースが優先されることを確認しますという章ですね。
LCPリソースをHTMLソースから確実に検出できるようにすることは、
LCPリソースの読み込みを早期に開始できるようにするための重要な最初のステップになりますが、
別の重要なステップは、そのリソースの読み込みが優先され、
急に入らないようにすることです。
他の重要でないリソースとかを急に入れないようにするということですね。
例えばそのLCP画像がその標準の、HTML標準のIMGですね、
イメージタグを使用してHTMLソースに存在する場合だとしても、
ドキュメントのヘッド内ですね、ヘッドタグ内のイメージタグの前に
複数のスクリプトタグがページに含まれている場合、そんなことがあります。
この場合は画像リソースの読み込みが開始されるまでしばらくお待ちくださいみたいなことになるので、
あんまりよろしくないなということですね。
この問題を解決する最も簡単な方法は、
LCP画像をロードするイメージタグとか、リンクタグに新しいフェッチプライオリティ範囲というものがあります。
この属性、別の記事でも読んだんですけど、すごく大事だと思うので、
リンクタグのフェッチプライオリティという属性ですね。
これを範囲にして最優先に読み込んでいるという設定は、
どのリソースが最も優先度が高いかというのを、
僕らがすでに先にHTMLに書いておいて、
ブラウザの解析処理に教えることができるんですよ。
ということをやると、ブラウザに提供することでより早くできますよということですね。
これによってスクリプトが完了するのを待つのではなくて、
ブラウザが早期にロードするように指示されることになりますのでということでした。
続いて、冒頭の方に出てきましたウェブでアルマナックというやつですね。
によると対象となるページの0.03%のみがこの新しいAPIを利用しています。
多分まだ皆さん意外と知らないんじゃないですかね。
リンクタグのフェッチプライオリティイコールっていうローとかはいとかって設定できるんですけど、
多分このAPIそのものを皆さんが認知できないって気がするので。
これはウェブ上のほとんどのサイトが、
わずかな作業でLCPを改善できる可能性が十分にあることというのまでそう意味していますと。
本当に想像通りですね。
12:00
フェッチプライオリティ属性は現在Chromiumベースのブラウザでのみサポートされていますというところなんですよ。
なので残念ながらSafariが対応しないので、
Appleの特にiPhone Safariがこれを使えないのがちょっと苦しいんですねって感じがしますけど。
このAPIは他のブラウザでは無視されるため、
前進的な拡張機能であるということなので、
開発者はぶっちゃけ今すぐ使用して使うことができますよと。
別にこれを入れて何かエラーになったりとかHTMLの解析止まったりとか、
サイトが表示されないみたいなことは別にないわけですよね。
単純に無視されるだけなので、今すぐ入れても全然問題ないよということでした。
Chromium以外のブラウザの場合は、
LCPリソースが他のリソースより優先されるように設定をする唯一の方法というのは、
ドキュメントの前半で参照することです。
要は順番を変えるしかないということですね。
ドキュメントのヘッドタグに多数のスクリプトタグがあるサイトの例を再度使用すると、
LCPリソースがそれらのスクリプトリソースより優先されるようにしたい場合は、
リンクれるイコールプリロードを追加することになります。
このタグをこれらのスクリプトの前に配置するか、
これらのスクリプトをボディのイメージの下に移動することができます。
これらはスクリプトタグのことですね。
スクリプトタグをボディのイメージタグがあったり、その下に移動するということですね。
本当にやりたければ、ボディタグの終了タグの直前にスクリプトタグを書くというのは古典的ですけれども、
これでも何らかの効果はあるので、一つの手だなと思います。
これを機能しますけれども、フェッチプライオリティ属性というのを使用するよりも、
人間口角的ではないので、他のブラウザーがすぐにサポートを追加することも願っていますということでした。
案にAppleと言っている気がしますけど。
Appleは基本アプリの会社だったので、
ウェブにどれだけ真摯に向き合ってくれるかというのは、いまだに会議的にはあるんですけれども、
サファリ16がどれだけ早くいろんなものを対応してくれたりするのかというのが気になります。
続いていきましょう。
LCPリソースの優先順位付けのもう一つの重要な側面というものは、ローディングイコールレイジーですね。
いわゆるレイジーローディングですけど。
という属性を追加するなど、優先順位を下げる原因となるようなことをしないようにすること。
しないようにすることなんですね。
現在全世界のページの10%が実際にLCPイメージにローディングイコールレイジーを設定しています。
全ての画像に無差別に遅延読み込みの動作を適用する画像最適化ソリューションには注意してください。
それらがその動作をオーバーライドする方法を提供する場合は、必ずそれをLCPイメージに使用してください。
どの画像がLCPになるかわからない場合は、ヒューリスティックを使用して妥当な方法を選択してみてください。
ヒューリスティックというのがあるんですね。
重要でないリソースを延期するということは、LCPリソースの相対的な優先順位を効果的に高めるもう一つの方法になります。
例えばユーザーインターフェイスを強化していないスクリプトですね。
いわゆる分析スクリプトとかソーシャルウィジェットなど解析的ですね。
リターゲティングタグとかそういう言語のスクリプトだと思いますけど。
15:01
こういうものはロードイベントが発生するまで安全に延期できます。
これによってネットワークの他の重要なリソースですね。
LCPリソースなどと競合しなくなります。
その待機幅としてですね。
要約すると次のベストプラクティスに従って、
LCPリソースが早い段階で優先的に埋め込まれるようにする必要がありますよというので、
大きく3つありますね。
一つはですね、LCP画像のイメージタグにフェッチプライオリティハイを追加しますと。
フェッチプライオリティでイコールハイというのを指定する。
要は優先度高いですよということを指定しますと。
で、LCPリソースがリンクれるイコールプリロードタグというのを介して
ロードされている場合は特に心配する必要はないですよということですね。
あとは、LCP画像のイメージタグにローディングレイジーですね。
レイジーローディングの設定をしないでくださいというのが2つ目になりますと。
これを行うと画像の優先順位が下がり、読み込みの開始が遅れてしまうのでということですね。
でもそれがLCPイメージであるんだったらですね、
LCPじゃないんだったら別にいいんですよ。
文字通り支援読み込みしてくればいいですよということですね。
もし可能であれば重要でないリソースを延期するということですね。
今言った通りですね、ドキュメントの末尾に移動するとか、
画像またはiFrameのネイティブチェーン読み込みというのを使用するとか、
JavaScriptを介して非同期に読み込ますとかというふうに、
重要じゃない画像についてはとにかく後回しにするという設定をすることですね。
まとめるとその3つをやるといいんじゃないのということでした。
以上で多分LCPの話は終わりかな。
続いてCLSの話に行きたいけど、
ちょっと先にTTFBが入っているTTFBに行こうかなと思います。
これを読んだらちょっと今日の朝勝は終了になるかなと思いますので、
じゃあ読んでいきましょう。
CDNを使用してドキュメントとリソースのTTFBを最適化するというのが次ですね。
前の2つの推奨事項ですね。
つまりLCPリソースを早期に発見して優先順位をつけて、
すぐに読み込みを開始できるようにすることに重点を置いています。
このパズルの最後のピースというのは、
最初のドキュメントのレスポンスもできるだけ早く到着するようにすることです。
ブラウザは最初のHTMLドキュメントのレスポンスの最初のバイトを受信するまで
サブリソースの読み込みを開始することができず、
これが早くなればなるほど他のすべてが早く開始されるようになります。
この時間はTime to First Byte、TTFBと呼ばれて、
そのTTFBを減らす最良の方法というのは以下の通りです。
主に2つありますね。
1つ目はできるだけユーザーの地理的に近くにコンテンツを配信する。
2つ目はコンテンツをキャッシュして、
最近リクエストされたコンテンツを素早く提供できるようにする。
この2つを実践する最善の方法というのはCDNを使用することです。
CDNというのは世界中に散らばるエッジサーバーにリソースを配信するため、
ユーザーまでの電線移動の距離が短くなります。物理的にですね。
またCDNというのは通常、きめ細やかなキャッシュ制御を備えていて、
サイトのニーズに応じてカスタマイズや最適化もできますよと。
多くの会社は静的資産ですね、リソースをホストするために
CDNを使用することに精通していますけど、
18:00
CDNは動的に生成されたものであっても、
実はHTML文書を提供してキャッシュすることもできますよと。
ウェブアルマナックによると、
HTML文書のリクエストのうち、CDNから提供されたのはわずか29%だと。
意外と少ないですね。もっと高いと思ってましたけど。
皆さんガンガンにCDNを使っているなと思っていたんですよね。
これはサイトがさらなるコスト削減を要求する大きな機会があるということを意味しています。
意外とみんな当たり前と思っていることを、
実は全世界できていないことがたくさんあるんですね。
これ全然エンジニア食いぶちたくさんあるじゃないですかね。
仕事全然取れますね。
フリーランスの人、この辺数字見ると皆さん意外と仕事ありますよ。
CDNを設定するためのヒントをいくつか紹介していきたいと思います。
これは大きく3つですね。
1つ目はコンテンツがキャッシュされる時間を増やすことを検討する。
例えばコンテンツが常に新鮮である、新しいものであるかというのを結構皆さんチェックしますけど、
実際それ本当に重要なんでしょうかというところですね。
それとも数分間だけ古くてもいいんじゃないかとか。
アップデートの更新タイミングを考慮すると、
そんなに頻度高く更新しなくても良いのであれば、
多少新しくなかったとしても、
今のコンテンツを早く早くユーザーに返してあげることの方が大事なんじゃないかというお話ですね。
これちょっとビジネス的なお話ですね。
2つ目はコンテンツを無期限にキャッシュして、
更新があったときにキャッシュを削除するということを検討します。
キャッシュの更新タイミングとか削除タイミング、いわゆるキャッシュ戦略と言われるやつですけど、
これはちょっと扱いがむずいですよね。
更新するタイミングとか処理を決めたとしても、
実際に全CDNとかをフラッティングして処理をしていかないといけないんですけど、
いわゆる浸透率という言葉を使ったら怒られるんですけど、
新しいキャッシュがちゃんと適用されるかというところの時間とかタイムラグもあったりするので、
ここは結構むずいんですよね。
でもできるんだったら絶対にした方がいいと思います。
3つ目、オリジンサーバーで実行されているダイナミックロジックというのを
エッジサーバーに移動できないかを検討する。
最近のCDNには結構こういう機能が入ってきたよということですね。
ダイナミックロジックですね。
その場でいきなりポンと処理する何かがあるのであれば、
それもCDNの方に移していくということですね。
最近そういうCDNマラソンの進化でいうと、
やっぱりどう考えてもクラウドフレアD1が出てきたというのが
やっぱり昨年の超絶なインパクトでしたね。
CDNのエッジサーバーでノードJSが動かすことができて、
いわゆるその場でアプリケーションが動くんですね。
さらにそこでSQLライトが動くので、
その場でデータベースも動いてノードJSも動くというので、
本当にエッジサーバーでガチの小さなアプリケーションを動かすことができるようになったというので、
これが今のところCDNの最強の機能なんじゃないかと思います。
他のCDNがどこまでサポートするかは分からないし、
他のCDNはやらない気がするんですよね。
ここまでのドラスティックなことをやるってかなり勇気がいるし、
リソースも使うのでなかなかの意思決定が当たると思います。
でも赤マイとかファストリーとか、
あとAWSのクラウドフロントとかはあんまりやらない気が個人的にはしてますけどね。
21:03
エッジサーバーでデータベースが動くのはさすがにと。
ノードJSが動くのは全然やると。今もできてると思いますけど。
まずは余談でした。
一般にエッジから直接コンテンツを提供できるようになれば、
オリジンサーバーへの移動を回避できるのであれば、
パフォーマンスはすごく有利になります。
またオリジンサーバーに戻る必要がある場合だとしても、
CDNは一般により迅速に処理できるように最適化されるので、
何にせよ利点があるので、
もし使ってないお客さんとかサイトがあるんだったら、
まずCDNを入れるというだけで、
TTFBが一気に解決しますよということですね。
タイムでファーストバイトが解決するので、
やってみてくださいというところでした。
今日は全部終わらなかったんですけど、
この辺であさかさ終了したいと思います。
今日はプテラドさんとボウさん、
ご参加いただき大変ありがとうございました。
明日もこの記事ずっと続きますので、
読んでいきたいと思いますし、
パフォーマンス周りは僕らウェブエンジニアとの
重要な観点の一つになりますので、
これはしっかり追っていきたいんですけど、
このベストプラクティスや何にしても、
トップコアウェブバイトのレコメンデーションを
Googleの中の人が言ってくれているのはすごくありがたいので、
ぜひ引き続き勉強しつつ、
自分たちの実生活と実社会の仕事にも
取り組んでいきたいと思いますので、頑張っていきましょう。
明日はCLSから入ります。
コミュネイティブレイアウトシフトですね。
そのところから入っていきたいと思いますので、
今日もよろしくお楽しみください。
では土曜日ですね。
ゆっくり休んでいただいて、
明日も休みなので、
のんびりしていただければなと思います。
では終了したいと思います。
お疲れ様でした。
