00:06
7月10日、月曜日ですね。
中国は朝9時33分になりました。
今日からまた月曜日で頑張っていきたいところですけども、
東京は今日晴れててですね、いい感じの天気になりそうです。
ちょっと蒸し暑くなりそうですけど、
その代わりやっぱり九州の方とか、まだまだ西日本の方は、
だいぶ前線の影響があるので、
同じ日本でもこんなに差が出るんかっていう感じですね。
本当皆さん、自然災害には気をつけていただければと思いますし、
暑くなってきてるので、熱中症対策もしていただければなと思います。
おはようございます。ひめみの大きい坂くわはるです。
では、本日も作発を始めていきたいと思います。
本日はですね、ちょっと短い記事にはなるんですけど、
Time to First Byte- What it is and How to Make Improvementsと、
パフォーマンスですね、システムパフォーマンス、
DTFBと言われる一つの指標があるんですけど、
それについてのお話ですね。
Core Web Vitalっていう指標があって、
これすごく有名なものなんですけど、
皆さんもご存知かもしれないですけど、これの一つですね。
DTFBについてフォーカスをされた記事が、
今年の5月31日に出筆されていますので、
これをちょっと読んでいきたいなと思っております。
本日の参加者が、あ、ゆめ子さんですね。
おはようございます。ご参加いただきありがとうございます。
見えてないですけど、弊社のスーさんですね。
ご参加ありがとうございます。
じゃあ、今からだらだらと読んでいこうと思っています。
あとこの記事、後ほどツイートしますので、
皆さんのほうでも見ていただければと思います。
じゃあ、いきましょう。
Time to First Byte、DTFBっていうのは、
ブラウザーがサーバーに接続して、
データをダウンロードするまでの時間を示す指標になります。
サイト全体のDTFBのタイミングを追跡することで、
パフォーマンスに悪影響を及ぼすサーバーの速度低下や問題っていうのを
検出できます。
DTFBはコアウェブバイタルではないかもしれませんが、
あれ、入ってなかったっけ?
それは誰でもが追跡すべき重要なサイトパフォーマンス指標になります。
DTFBが悪いということは、
サーバーが十分に迅速に応答していないということを意味しており、
ページ読み込みプロセス全体にパフォーマンスの問題が連鎖する可能性というのがあります。
その時間は単に迷惑なだけでなく、
訪問者の離脱だったり、
競合他社のチェックに直接つながる影響もあったりします。
このガイドでは、タイムトゥーファーストバイトの測定方法、
重要な理由、改善方法など、
タイムトゥーファーストバイトの指標について知っておくべきことを
すべてお伝えしたいと思います。
この知識を身につければ、訪問者のために
きびきびとしたサイト体験を生み出す準備というのが整います。
はい。
なので、テーブルコンテンツは8個くらいありますね。
8個あるんですけど、割と1個1個は短いんで、
スパーっと読めるんじゃないかなと思います。
じゃあ最初、まず1つ目ですね。
What does DTFB measure?
DTFBって何を計測してるの?という話からですね。
DTFBは、訪問者がリンクをクリックするか、
キーボードのEnterキーを押してから、
03:00
そのページの最初のバイトがダウンロードされるまでの時間を測定します。
文字通り、ファーストバイトですね。
ほとんどの人にとって、このプロセスっていうのは
うまくいけば瞬時に感じられるでしょうけど、
舞台裏ではいくつかのことが起こっています。
ページのDTFBは、以下のすべてのタスクの合計になりますよ、
1、2、3、4、5個あります。
1つ目はリダイレクト時間です。
URLが301や302などで移動された場合など、
URLリダイレクトの解決にかかる時間がスタートですね。
2つ目にサービスワーカーの起動時間です。
すべてのケースに当てはまりませんけど、
サービスワーカーのAPIはブラウザで実行され、
サーバーから返される前、または後に
リクエストを変更できるという点で、
プロキシサーバーに似てますけどね。
もしサービスワーカーを使っていれば、
この時間も継続されます。
続いて3つ目、DNS Lookupですね。
DNS Lookupは何たら.comのようなURLに使用する単語を
ブラウザが正しいウェブページをダウンロードするために
使用できるIPアドレスに変換をします。
4つ目、コネクションですね。
接続とTLSのネゴシエーションです。
ブラウザとサーバーが接続を形成し、
データを送信できるようになるまでの時間ですね。
ラスト5つ目、リクエストですね。
ブラウザがサーバーにデータを要求し、
サーバーがそれを送り返すプロセスです。
TTFBは最初のバイトが送信された時点で
計測を終了します。
以上、この5つの項目の合計時間が
TTFBになります。
TTFBは人々があなたのサイトにアクセスするときに
多くの要因に基づいて
大きく異なる可能性があることに
注意する必要があります。
サーバーから遠ければ遠いほど、
データが物理的に届くまでに
時間がかかります。
このため、シドニーとロンドンでは
TTFBの時間が大きく異なり、
あなたのページでの体験が
大きく異なる可能性もあります。
物理的にサーバーが近い方は
それは良いよねってのは
もちろんその通りだと思いますね。
余談ですけど、先日赤前さんの
勉強会に参加したことがあってですね。
その登壇者の一人が
自分の部屋の電球を
ボタンポチッと
一発で
消せるようにしていると。
僕からすると歩いていいよって思ったりするんですけど
面倒くさかったり、夜寝る直前とかって
トーンから出たくないので
アプリから自分の部屋の電球を消したい
それはわかりますけど
ただその人がおっしゃってたのは
そのボタンを押して
インターネットを通っていって
最終的に自分の部屋の電球を消すのに
わざわざ電波とか電信が
世界中回るのがアホらしい
確かに。
部屋の電球を消すぐらいなんで
本当に数歩歩けばいい距離を
わざわざインターネットを回してから
電球を消すみたいな、意味わからんことしてて
これ物理的にサーバーチューかければいいじゃん
みたいな話をしたんですけど、まあいいや
余談です。続いて
なぜTTFBを改善すべきでしょうか
っていう話です。TTFBは
ページスピードのバックボーンになります。
06:00
TTFBが良ければ
読み込み時間が短縮されるとは限りませんけど
悪ければサイトが遅く感じられ
人々は遅いサイトとは好みません
これは正しいですね。
Googleの調査によると
1秒追加されただけでも
直記率が劇的に増加する可能性があります。
読者の印象に残るページを
作るにはTTFBを可能な限り
早くする必要というのがあります。
確かに人が遅く感じる
色位置って300ミリ秒じゃなかったっけ
ですね。で、
引っかかりがないように感じる最速の速度
っていうのが確か90ミリ秒じゃなかったっけ
90か80ミリ秒らへんらしいですね。
この辺から
人がちょっと遅く感じるかなっていう
色位置らしいです。100とか
200、200とかいくともうちょっと
引っかかってるなって感触らしくてですね。
東京とかでよく使われるスイカ
スイカがだいたい
どの端末でも90から100
ミリセックぐらいで処理が
終わるような機構になってるらしくて
とても速いし、これはほんと世界的に
評価されてるシステムであるんですけど
これが
200とかいくとちょっと
引っかかるらしいです。人間の感覚的には。
というので、なかなかすごい話をしてるな
と思いました。余談ですけど
1秒追加されただけだと
1秒で1000ミリ秒なんでそりゃ確かに
もう遅いと感じられるし
直起ですね。変えられる可能性は全然
高くなると思いますね。
で、遅いサイトっていうのは
直起率を上げるだけでなく
Googleのサイトランキングにも影響してきます。
Googleは検索エンジンが
ページ体験をランキング要因として
考慮することを明言しております。
サイトの体験の良し悪しというのは
いくつかの要素にもちろん基づいて
判断されますが、そのうちの一つが
Core Web Vital、TTFBに
部分的に依存する一連の
パフォーマンス指標になります。
例えば、Large Contentful Paintですね
LCPっていうのはCore Web Vitalの
一つで、ページの折り返し部分より
上にある最もデータ量の
多い要素を読み込むのに
かかる時間っていうのを測定します。
ページがサーバーからデータをダウンロード
するのに時間がかかる。つまり
TTFBが遅い場合、LCPの
スコアも一緒に悪くなります。
Googleはこれをネガティブなページ体験
シグナルとみなして、検索順位を
下げてしまいますと。まあ下げる可能性が
ありますよって話ですね。
はい、なので結局読み込み早いに
越したことはやっぱないって話ですね。
では続きまして、What is the good
to TTFBです。
よいじゃTTFBなんぞやってお話ですけど
TTFBに関しては
早いに越したことはもちろんありません。
ほとんどのページでは
TTFBは800ミリ秒以下を
目指すべきです。800ミリ秒を
超えるとロード時間が著しく遅くなる
可能性っていうのがあるらしいですね。
一応TTFBの上のグラフ
画像が貼られていて、
goodは800ミリ秒までですね。
needs improvementですね。改善が必要だよ
っていうのが1800ミリ秒らしいです。
でもそれ以降はもうpureだそうですね。
まあ1.8秒もかかってたら
多分もうみんな離れるんじゃないですか。
と思いますので。
サイト上の
すべてのページでTTFBってのは別に
異なります。これらの
スコアは訪問者の場所に
09:00
大きく依存するということを覚えておいてください。
このため定期的に異なる
ロケーションでサイトのページを
テストし、800ミリ秒で
ベンチマークを下回るページを見つける
ということが重要です。詳細はちょっと
口述しますという話でした。
では続いて
4 ways to implement TTFBと
TTFBを改善する
方法のお話に入りたいと思います。
TTFBを下げるには
最初のバイトがロードされる
までのプロセスを1つ以上
ミリ秒単位で短縮する必要
というのがありますね。そのための方法のいくつかを
紹介するというので、まず1つ目
ですけど、1つ目はホスティング
またはサーバーをアップグレードしましょう。
なるほど。物理的にスペック
を上げろと。このステップは
TTFBを顕著に改善するために
できる最も重要なことです。
より良いホスティングやサーバーに
投資することで、接続時間をスピードアップし
ブラウザーへのデータ転送を
より迅速に行うことができるようになります。
場合によってはサーバーをアップグレード
するだけで良いこともあります。
金で殴ると。メモリーや
CPUの制限によってパフォーマンスが
低下している場合はアップグレードを
行うことでTTFBを改善することが
できます。またホスティング
プロバイダーを変更した方が適切な
場合というのもあります。しかし
ホスティングプロバイダーが優れている理由は
必ずしも明らかではありません。
さまざまなホスティングオプションを
評価する際には、以下の点を
考慮する必要がありますので、3点
挙げられておりますね。
1つは専用サーバーを
提供する。2つ目
CPU、メモリ、GPUの
スペックが競合他社より優れていること。
3つ目、サイト訪問者の
所在地に近いサーバーを所有すること
だそうですね。はい。
では続いて2つ目ですね。
ユーザーコンテンツデリバリーネットワーク
CDNを使えと。CDN
っていうのはグローバルに分散された
サーバーネットワークにコンテンツを
キャッシュしておくことができるため、
TTFBを改善することができます。
より多くのサーバーにアクセスすることで
より迅速に訪問者にサービスを
提供することができるはずです。
訪問者へのサーバーへの
物理的な近さはデータがブラウザに届くまでの
時間にもちろん影響しますからね。
またCDNっていうのは自動的な
配信にも役立つよっていう話をしてて
そうなんか理由的なものを3つ
挙げられてますね。1つ目は
個人サーバーが処理するリクエストの
数を減らし負荷を軽減します。
2つ目はファイルサイズを縮小し
より高速な転送を実現します。
最後、サーバー設定を最適化し
高速化というのを実現します。
まあまあこれなんか色々
設定次第な感じはしますけど
少なくともCDNを使えば速くすることが
できるよっていうのはその通りだなと思いましたね。
続いて4つの方法
3つ目ですね。DNSルックアップ
時間の短縮をしましょう。
DNSルックアップっていうのは
コンピューターが使用するURLをコンピューターが
使用するIPアドレスに変換するため
ページ読み込みプロセスの不可欠な部分になります。
サーバーが最初の1バイトの
データをブラウザに送り返す前に
このチェックを行う必要というのがあります。
このためDNSルックアップ処理を
最適化することでTTFBの
時間を短縮することができますよと。
DNSのルックアップ時間を
12:00
短縮する方法にはいかのような方法があると。
あくまで参考程度ですけど
合計4つですね。1つ目が
DNSレコードに長期のTTLレコードを持たせ
DNSを少なくとも24時間
キャッシュできるようにすると。
DNS自体もキャッシュするとですね。
2つ目にDNSプリフェッチを
使用してページ読み込みの
潜在的な遅延というのを減らしましょうと。
3つ目、ページのリダイレクトを
削除しましょうと。
ラスト、フォントやCSSファイルなど
よく使われるいわゆる性的な
ファイルというのをキャッシュしましょうと。
その通りですね。
毎回毎回全部手続き的に読みに
いったらそれは遅くなりますからね。
じゃあラスト、4つ目です。
4つ目は
常にサーバー側でレンダリングされた
HTMLをデフォルトにしましょうと。
サーバーやキャッシュの設定を
調整することは、このリストの他の
オプションよりもはるかに複雑です。
しかし、最良のTTFBの結果を
得るためには、できるだけ早く
データを送信できるようにサーバーを
最適化するという必要があります。
サーバーをより早く反応させる
一つの方法は、サーバーサイドレンダリング
を使用することです。
サーバーサイドレンダリングとは、
ページがサーバー上でレンダリングされ、
ブラウザに全体が送信されるということを
意味します。頻繁に更新される
ページではSSRを活用して
事前にページをレンダリングし
一定時間キャッシュし、ブラウザが
要求したときに素早くページを送信
するというのができます。
この辺に関しては、Next.jsのレンダリング
モードがあって、こちらの
Next.jsパフォーマンスガイドというのが
参考なので、見てみてください。
クライアント側の話ですね。
余談ですけど、
Next.jsは確か
プリレンダリングの概念が入ってきたので、
どこのページをサーバー側にするか
みたいなところですね。あとはサーバーサイド
コンポーネント
というのがあるので、リアクトサーバー
コンポーネントというのがあるので、今コンポーネント
単位でどこをサーバー側で処理するか
みたいなのまで設定できるようになったもんね。
全部をサーバーサイドレンダリングするっていうのは
また違う気がするんですけどね。
その辺は別の話が始まるのでやめます。
では続いて
How to test and track your site's
TTFB scores ですね。
サイトのTTFBスコアをテストし、ちゃんと
追跡してみましょうという、そういう方法を
見ましょうということですね。
TTFBをテストする最も簡単な方法
っていうのは、無料のCore Web Vitals
チェッカーになります。
それ用の、ちゃんとリンクも張られてますね。
Core Web Vitals Checkerっていうサイトが
あります。そこに単純に
URLとかぶち投げて
計測してもらう。そうすると
チェックできるので見てみてください。
これはですね、Googleが出した
PageSpeed Insightsっていうサイトがあります。
こちらもパフォーマンス計測でよく使われるものですね。
これと同様に、私たちのツールが
Googleが非
iOSデバイス上の
Chromeブラウザーから収集する
CRUXデータに依存しています。
今のにこのCRUXの読み方は
わかんないので僕そのまま読みますけど。
このデータベースっていうのは
人々の大規模なサブセットで
構成されており、合理的に
計画の1回限りのチェックを可能にします。
しかし長期的なソリューションとしては
理想的ではありません。
15:01
PageSpeed Insightsや
Web Vitals Checkerのようなツールの
問題点っていうのがいくつかあって、
それ以下の通りです。合計
5つぐらいが挙げられています。
あくまで参考データです。
一つ目に全ての人からデータを得ている
というわけではないです。Chrome以外の
ブラウザーやiOSの人を除きます。
あとはインターネット設備やデバイスの
種類の違いを考慮していません。
なるほどね。あくまで参考値ですね。
3つ目に
テストのスケジューリングや
パフォーマンスのトラッキングもできません。
4つ目に
トラフィックの少ない小規模のサイトのデータもありません。
最後、毎日更新はされません。
CRUXは毎月更新は
されますけどってことですね。
一応今の自分たちの
サイトがどうなのかっていうのは
測ることはもちろんできるんですけど、あくまで
参考値ですよって話でしたね。
またこれは他のサイトとかの比較も
してくれるんで、そういう意味での参考としては
割かし
精度の高い参考値ではあるとは思いますけどね。
とはいえ、鵜呑みにするのは危険だな
っていうところでした。
より良い解決策というのは
TTFBのようなパフォーマンス指標をテストし
追跡するために
カリブレプラットフォームっていうのを使用することです。
急に宣伝が来たな。
カリブレっていうのを使用すれば、全てのページで
手動でテストを実行し
データをプロットして継続的な傾向を
確認する必要がないためです。
時間と労力を節約できますし
その代わりにカリブレを使用することで
全てのページで自動的に
ルーチンテストというのをスケジュールすることができ
素早く問題を発見し
あなたの努力がどのようにサイトパフォーマンスの
向上に繋がったかっていうのを確認することができます。
えー、こんなのあるんですね。
いくらなんだろう。
一応15日間
フリートライアルがあるらしいですね。
一応ですね
グラフでバーっと見れる感じになってるんで
これ後で参考として画像が貼られてるので見てみてください。
さらにですね
様々な場所、インターネット接続
またはデバイスの種類に模倣して
各テストをカスタマイズできるため
全ての訪問者に対して
サイトのパフォーマンスを確認することができるようになります。
これによって理想的な条件だけでなく
あらゆる条件下で
サイトが優れたパフォーマンスを発揮できるようになります。
一応15日間の無料トライアルで
サイトのパフォーマンスをチェックできるので
見てみてください。
管理画面で細かく見れるようになってるっぽいし
見やすいですねやっぱり。
グラフ系だから見やすいかもしれないですけど
というのがあるので見てみていただければと思いますね。
最後に
最も重要なパフォーマンス指標をサポートというところで
サイトのTFBに関する
ヘルプを探したらば
最も重要なパフォーマンス指標の改善にも
関心する必要がありますよと。
以下のガイドを使用して
Core Web Vitalsの全てにわたって
サイトのパフォーマンスを顕著に向上させる方法
というのは見てみてください。
例えば総ブロッキング時間だったりとか
累積レイアウトシフト
コンテンツペイント
次のペイントへのインタラクション
インタラクションネクストペイント
最近はこの指標が結構重要指摘されている
これも結構重要だなと思いますので
この辺についても
それぞれ一個一個記事を書かれていて
そのリンクも貼られているので
興味があればそれも読んでみてください。
18:01
というところで今日の朝勝はこれで締めたいと思います。
改めまして今日の参加者は
赤神さんとケンジさんと
ひめ子さんと
オノオさんと
ご参加いただきありがとうございました。
月曜日ですね。
また今日から一週間頑張っていけたらと思います。
今日も一時頑張っていけたらなと思います。
終了します。
お疲れ様でした。
