00:03
7月11日火曜日ですね。
時刻は朝9時34分になりました。
連日暑い日が続きますけど、
今日から何か3日間ぐらい?
何か割と猛暑日が続くらしくて、
熱中症、また日射病、
皆さんに気を付けていただければなと思います。
本当に暑いらしいのでね、もう
遠慮せず、
エアコンつけるなり、涼しい部屋に行くなり
していただければなと思います。
はい、おはようございます。
ひめみのおきぃすことくわはらです。
では、本日も朝活を始めていきたいなと思います。
本日は、昨日に引き続きましてですね、
昨日読んだ記事、
Time to First Byteですね。
ETFBの話です。
まあ、いわゆるサイトのパフォーマンスとか、
周りの解説記事があったんですけど、
それの他の記事のリンク、
4つぐらいリンクがありまして、
トータルブロッキングタイムとか、
カミュレイティブレイアウトシフトとか、
ラジェストコンテンツルペイント、
あとはインタラクショントゥネクストペイント、
この4つですね、の記事のリンクがあって、
いわゆるパフォーマンス周り、
GoogleのCore Web Vitalsに付属している、
各指標なんですけど、
そこの記事のリンクもあったので、
これを機に一挙にパフォーマンス周り、
全部勉強しちゃおうというところで、
続けて読んでいこうというところですね。
今日は、トータルブロッキングタイム、
Short and Sweet Guide for Happiness Users
という記事を読んでいこうと思います。
よりハッピーなユーザーのための、
いわゆる簡潔でスイートなガイドですよと。
スイートって言い方は、
日本ではあんまり馴染みないかもしれないですけどね。
甘いガイドって言われてもあるんですけど、
いわゆる優しいガイドってことですね。
その記事を今日読んでいこうと思っております。
本日の参加者ですけども、
ケンジさんと赤神さんですね。
いつもご参加いただきありがとうございます。
今からダラダラって読んでいきたいと思います。
点滅にはおよそ100から400ミリ秒ぐらいかかります。
これは高速ではありますが、
レンダリング中のウェブページとやり取りする際に、
多くの人が許容する時間の2倍から8倍ぐらいかかる、
というふうに言われています。
50ミリ秒を超えると訪問者はページが反応しないと感じ、
全体的なユーザーエクスペリエンスに影響を与えます。
好む反応感を減らすには、
TBT、いわゆるトータルブロッキングタイム、
という指標を改善する必要があります。
TBTはブラウザのメインスレッドが長いタスク、
いわゆる50ミリ秒以上のタスクによって
ブロックされる時間を追跡しています。
長いタスクっていうのは、
メインスレッドをロックし、ユーザーの入力を遅らせます。
このトータルブロッキングタイムガイドに従うことで、
どのように修正を実装し、
改善に向けて結果を追跡するかを学ぶことができます。
経験豊富な開発者であれば、
より多くの修正が可能ですけど、
初心者の方でもこのガイドに従うことで、
サイトのスピードとユーザーエクスペリエンスに
有意義な影響を与えることもできます、
というのが冒頭の話でした。
ではここから本題に入っていきたいと思います。
今回はテーブルオブコンテンツ7個ありますけど、
多分教授に読み終わると思いますので、
早速いきましょうか。
まず、What is Total Blocking Time?
トータルブロッキングタイムって何ぞやってるところからですけど、
略してTBTですね。
TBTは実行中の時計のように計算がされます。
1つのタスクが50ミリ秒の指揮位置を超えると、
そのタスクが最終的に完了するまで時計が動き続けます。
03:03
トータルブロッキングタイムとは、
ファーストコンテントフルペイントから
インタラクティブタイムまでの間に発生する、
これらの長いタスク、
それぞれの最初の50ミリ秒を差し引いたものの合計になります。
例えば、以下の2つのタスクリストを見てみましょう。
タスクリストがテーブルでバーッと表示されてますね。
タスク1、2、3、4、5みたいなやつがタスクとテーブル一致ですね。
テーブル2の方はタスク1、2で止まってますけど、
それぞれが、例えば、
40ミリ秒、60ミリ秒、50ミリ秒みたいな感じで、
一個一個のタスク自体にそれぐらい時間がかかってます。
タスクリストの1の方はトータルタイムが280ミリ秒ぐらいかかりました、合計で。
トータルのブロッキングタイムは40ミリ秒ぐらいかかりました。
タスクリスト2の方は、
リスト1はタスクが5個に分かれてます。
リスト2はタスク2個に分かれてるんですけど、
タスクの数自体は少ないのに、
タスクリスト2はリスト1と同じようにトータルタイムが280ミリ秒かかってます。
そして、トータルブロッキングタイムに関しては、
タスク1の4倍以上の180ミリ秒ぐらいかかってます。
こんなようなタスク、リストがあったのもとりあえずしましょう。
この場合ですけど、
どちらのタスクリストも処理時間自体は同じ280ミリ秒でした。
しかし、タスクリスト1には5つの短いタスクがあるため、
TBT自体はかなり低いと。
一方で、タスクリスト2の2つの長いタスクっていうのは、
50ミリ秒の敷地を超えて多くの時間を費やすため、
TBTっていうのは比較的高いと。
はい、こちらが180ミリ秒ですよね。
なので、単純にタスクの数が多いと時間がかかるとは、
もちろん限らないよっていう一つの例。
さっき言ったTBT50ミリ秒っていう敷地を超えるかどうかって結構重要だった話ですね。
はい、では続いて、
なぜTBTの短縮を気にする必要があるんでしょうかっていう話ですけど、
ページのTBTを減らすってことは非常に重要です。
なぜならTBTが計測する長いタスクっていうのは、
ユーザーの入力を遅延させ、
ページがオートしないように感じさせてしまうからです。
まさしくブロッキングですね。
ページのメインスレッドっていうのは、
一度に一つのタスクしか処理できないので、
特に長いタスクというのはユーザーの入力を含む他の全てっていうのを遅らせます。
TBTが短ければ短いほど、
あなたのページは訪問者により反応しやすくなりますと。
大体JSで動かすんですよね。
JSがシングルスレッドの言語なので、
JSの処理速度を超えるのは結構しんどいという感じですね。
なので結局一度に一つのタスクしか処理はできないというところです。
なのでなるべく早くするにしたことはないんですけどね。
これがブラウザーがマルチで動いてくれるんだったら
話はまた変わるんでしょうけど、
まあまあそうはいかんよって感じですね。
なのでとにかく早くしないとユーザーは
反応が悪かったり反応がなかったりすると離れちゃう、
チョッキーしちゃいますよねっていうところでした。
タイムブロッキングタイムの敷地の話がさっきあったんですけど、
一応グッドと言われるものはやっぱり300ミリ秒で反応をですね、
全ての入れ替えを返してあげると。
ニーズインポータント、インプルーブメントですね。
改善が必要だよって言われる敷地が600ミリ秒ですと。
あとそれ以降、PUAですね。
600ミリ秒以降がもう完全に遅いと。
06:02
これはもう改善するしかないねっていうような敷地だそうですね。
良いTBTスコアってのは300ミリ秒以下で、
全てのトップページの最初の目標と考えてください。
とにかく300ミリ秒を最初のレンダリングでみんな目指してねってことでした。
あと昨日にも出てきましたカリブレとかライトハウスのようなツールを使って
ページのTBTとかも確認してみてください。
このデータを使ってサイトへの変更がページのTBTとか、
その他のユーザー重視の指標をどのように改善または低下させるかっていうのを追跡してみましょうと。
ライトハウスは皆さん簡単に使えますし、
Google使ってれば、Chrome使ってれば開発者ツールにありますからね。
あくまであれも参考値として見ていただくので全然いいと思います。
必ずしも正解というか、あの数値が全て物語っているとは限らないのでね。
では続いて、How to Reduce Total Blocking Timeです。
トータルブロッキングタイムを短縮する方法というセクションに今から入っていきたいと思います。
まぁいくつかに分かれてそうですね。
TBTを改善する方法というのはいくつかありますが、
全てが複雑なものではありません。
以下に改善のための最良の方法と、それが成功させるためのヒントというのを紹介していきたいと思います。
一つ目ですけど、まずやっぱオプティマイズ・ザ・ページ・イズ・ジャバスクリプトですね。
ページのJavaScriptそのものを最適化していきましょうと。
JavaScriptというのはメインスレッドの速度低下の最大の原因の一つです。
JavaScriptのファイルサイズだったり実行時間を減らすことでTBTの数値を改善するということができます。
これを達成するためのいくつかの方法がありますよというので、
1、2、3、4、5、6個ありますね。
長いので3つずつに区切りましょうかね。
一つ目、コード分割、コードスプリッティングと遅延ロードの実装ですね。
コード分割によってJavaScriptをより小さく管理しやすいバンドルに分割することができます。
優先順位の低いバンドルを後で遅延ロードするようにして、
最初はページのコンテンツを表示するのに必要なバンドルだけをリクエストするようにしましょうと。
コード分割と遅延ロードの実装についてはバンドルサイズの最適化ガイドというのがありますので、
そちらを見てみてくださいというので別のリンクがありますよと。
2つ目に、先ほども出ましたJavaScriptの量を減らすというのが2つ目です。
JavaScriptのコードというのはすぐに必要以上に非大化してしまいます。
しっかり調査監督を行って削除できるものを確認したり、
CSSベースのソリューションに変更したり、
ビルトインの代替品に置き換えたりしましょうと。
結構最近のライブラリーでツリーシェイキング対応しているライブラリーたくさんあると思いますし、
あとはWebpackとかBeatを使っている皆さんもいらっしゃると思いますけど、
そこでツリーシェイキングの機能を結構バンドラーが持ってますので、
そこで対応して必要なものだけを読み込んで、
そうじゃないものは削除しますみたいな機能が入っているものを選ぶのが全然いいんじゃないかなと思ったりします。
いわゆる昔のローダッシュみたいに、
とりあえず全部もあるとダウンロードしインストールしてしまうみたいなやつをすると、
使ってないローダッシュのそれぞれの関数も全部バンドルされてしまうので、
そういうのやめましょうとかですね。
ちなみに余談ですけど、ローダッシュではなくてレメダってやつが弊社で今使われているもので、
レメダはツリーシェイキング対象からやってくれるので、
09:01
インポートアフターでやっても必要なものだけをそのファイルごとで切り分けてくれるので、
この辺便利だとちょっと思いましたね。
はい、などなどです。
まああとはWebpackとあとBeatもあるんかな。
ちょっとBeat僕まだちゃんと触ってないんですけど、
いわゆるアナライザーがあるので、
アナライザーで1回バンドルした結果のバンドル.jsのファイルをわーっと可視化してくれるんですよね。
グラフで可視化してくれるので、
それを見て、このファイルでかいな、このバンドルでかいなっていうところを一個一個削除していくといいと思いますね。
はい、余談でした。
続いて改善方法3つ目ですけども、バンドルフォビアですね。
バンドルフォビアっていうのを使って、バンドルサイズを四角化し大きなものを削減するのに役立てましょう。
久しく聞きましたね、バンドルフォビアですね。
こんなものがあったのでこれを使いましょうと。
あとはですね、最小化されたコードを使いましょうと。
クロージャーコンパイラーとかTarsarのようなツールを使って、
コードから空白とか冗長な部分を取り除くことでJavaScriptのファイルの読み込みを効率化しましょう。
これはまあ、いわゆるこういうものを使わなくても皆さんやってそうな気がしますけど、
いわゆるミニファイしてしまえばわかりやすいんじゃないかなと思います。
もちろんミニファイだけではなくて、そこからさらに冗長なものとかもあると思うんですけど、
よく使われるミニファイでも全然いいと思います。
とにかく読み込みするサイズ容量を減らすと。
これはネットワークレベルの話になりますけど、
でもこれによって結局ブロックしまうんですよね。
読み込み自体はどうやったってブロッキングされてしまうので、ここを改善しましょう。
もちろんAsyncとかDefferとかつけて遅延ローディングすることもできるのかないですけど、
メインとして書かなきゃいけないコンテンツを担当するJavaScriptファイルっていうのは絶対ブロックして読み込まないといけないので、
サイズが小さければ小さいに越したことはないって話ですね。
続いて、4つ目はビルドを分割しましょう。
1つはJavaScriptをES6としてよりモダンなブラウザーに提供し、
もう1つはES5として古いブラウザーに提供します。
より少ないロードでES6のスピードのリテインを活用し、古いブラウザーを使っている顧客を置き去りにしません。
ちゃんと対応するのは対応しますけど、
ES6とES5で書いているようなモダンブラウザー用と古いブラウザー用がもしあるんだったら、
それ自体をもうガツンと分けてビルドをしてしまいましょうってことですね。
ここは難しい問題ですね。
あと時間の問題で古いブラウザーの対応しないってサイトで言っちゃってもいい気はしますけどね。
ここは時間の問題だと思います。
では続いて5つ目ですね。
JavaScriptをバンドルしましょうと。
ビルドをしたら次はバンドルもしましょうって話ですね。
複数のJavaScriptファイルを一緒にコンパイルするためにバンドラーを使用します。
バンドルによってファイルがマージされ、冗長性が取り除かれるためロード時間が短縮されます。
WebpackとかParcelのようなツールを使って始めてみましょうと。
僕はちなみにParcelはちょっと怪異的というか設定がなさすぎるので、
本当に本番環境とかの運用に耐えるのかっていうのはちょっと僕はあんまり自信ないというか、
まあ少し怪異的ですね。
なので今はやっぱWebpackとBeatが主流なんじゃないですかねと勝手に思っています。
他にもいっぱいバンドラツールあるのでその辺また情報を調べていただければと思います。
ではラスト6つ目ですね。
HTTP2とかHTTP3またはSPDYですね。
スピーディーの略ですね。
12:00
でリソースを提供してみましょうっていう本当にネットワークレベルの話ですね。
あとQuickってのもあると思いますけど。
HTTP1.1よりモダンな転送プロトコルに切り替えることで、
より多くのリソースを並行してダウンロードできるようになります。
その結果より多くのリソースをより早くダウンロードできるようになりますよと。
その変更方法についてはサープスタッドっていう記事があるのでそこを見てみてくださいと。
HTTP2プロトコルオンナタラカンチャーっていう別の記事のリンクがあるので。
これ一般HTTP2に切り替えるための記事っぽいですね。
リンク見る限りですけど。
HTTP2も僕もちゃんと勉強できてないのでね。
社内のエンジニアに怒られたので、
ちゃんと勉強してくださいって怒られたのでどっかでやろうと思います。
できれば朝方でやりたいですけど、できなかったら私が所属する夢見の
なんだっけ?
ウィークリーデイジャバスクリプトじゃないわ。
フロントエンドの勉強会を毎週木曜日、昼の13時からYouTubeで配信してるので
そこで見ていただくといいかもしれない。
そこでもやろうかなと思ってます。
もう今フロントエンドの勉強会とはいえ、
フロントエンドでもネットワーク周りだったりとか、
ウェブアセンブリーだったりとか、
引きの要件周りもいい加減勉強しなきゃいけないなっていうのも
待ったなしだと僕は思っているので、
その辺を勉強していきたいなと思ってます。
余談はさておき。
じゃあ続いていきましょう。
How to reduce throttle blocking timeですね。
DBTの減少のための一つ目の手法として、
まずはJavaScriptの最適化をしましょう。
というのが今の6つの方法でした。
続いて2つ目ですけど、
2つ目はサードパーティースクリプトによる監査ですね。
Auditって書いてあるので、
Auditを監査と訳すのはどうなのかっていうのはちょっとありつつ、
一旦監査で今回訳しますけど、
サードパーティーのスクリプトの監査をしましょう。
サードパーティーのスクリプトというのは、
ウェブページにとって重要ではないタスクで、
メインスレッドを詰まらせることで、
スピード測定基準というのをすぐに破壊してしまいます。
これらのスクリプトを削除し、
すぐに読み込む必要のあるものを優先しましょう。
ここに関してもいくつか項目が分かれていて、
合計5つ分かれているので、
それもちょっと読んでいこうと思いますが、
まず1つ目ですね。
Use smaller third-party libraryですね。
より小さなサードパーティーライブラリを使いましょう。
全てのライブラリが同じように作られているわけではありません。
バンドルフォビアのようなツールを使って、
ライブラリの依存関係というのをしっかりスキャンをして、
より軽量な代替品を見つけてみましょう。
単純にNPMのダウンロード数とか、
GitHubのリポジトリを見て、
イシューの数とかスター数を見て、
多分選ばれていると思うんですけど、
同じような機能で、
スター数とか少ないかもしれないですけど、
より小さい代替品、
自分たちが求める機能の代替があるんだったら、
それに切り替えるのも1つですね。
続いて2つ目ですけど、
2つ目は重要ではないスクリプトをあえて遅延させましょう、
という話ですね。
ページのコンテンツに影響を与えないようなスクリプトというのは、
すぐに読み込む必要というのはありません。
クリティカルではないスクリプトを遅延ロードで遅延させ、
処理中のタスクが少ないときにロードできるようにしましょう。
要は遅延ローディングしましょうということですね。
続いて3つ目。
ファサードを使いましょうと言っています。
15:00
ファサードというのは静的な要素で、
訪問者を騙すことで、
何かが実際よりも早く読み込まれたというふうに思わせるものです。
ファサードは実際のサードパーティーのコンテンツよりも、
読み込みがはるかに簡単で、
ユーザーエクスペリエンスに影響を与えないので、
ウィンウィンです。
キャリバーの、
これキャリバーと読むんですね。
ずっとキャリブレって言うんだけど、
キャリバーと読むらしいですね。
キャリバーのウェブサイトでは、
特にライブチャットのためにファサードを使用しています。
私たちのライブチャットローダーファサードというのは、
GitHubで無料で公開されており、
ヘルプスカウト、インターコム、ドリフト、
メッセンジャー、ユーザーライク、
というのを模倣していますよと言っています。
ちょっとファサードと言っているのは、
いわゆるレイヤーとか、
設計周りのファサード層の話をしているのかどうか
ちょっと分からないんですけど、
おそらくそうと思うんですけど、
どういうことを、
このJavaScriptにおけるファサードって
どういうことを言っているのかちょっと分かりづらいので、
一応ファサード自体のリンクも貼られているので、
後ほどこの記事にまたツイートするので、
皆さんの方で見ていただければと思います。
では続いていきましょう。
4つ目ですね。
不要なスクリプトを取り除きましょうと言っています。
キャリバーのようなツールを使って、
どのようなサードパーティーのスクリプトが
ウェブページの速度を低下させているか
というのを確認しましょう。
何があるか分かったら、
ページの高速化のために何を削除または修正できるか
というのをチームの関係者と話し合って
決めてくださいということです。
不要なものは削除するはその通りですね。
ラスト5つ目ですね。
新しい読み込みテクニックを試しましょうと。
例えばPartyTownというライブラリですね。
これ去年僕も聞いたんですけど、
すごく注目しています。
こういうものではサードパーティーを
ウェブワーカーにロードすることで
メインスレッドをブロックすることがなくなります。
というので、
次世代の読み込みテクニックとかツールライブラリ
とかで生まれてきているので、
そういうのもしっかり調べて使っていきましょう
ということですね。
ちょっとうろ覚えというか、
ざっくり聞いた話だけで喋っちゃうんで、
正確性は無視しますけど、
PartyTownと言っているのは、
例えばスクリプトの中で、
いわゆる計測タグとかですね、
ビジネス要件で必要な、
ウェブアナリティクスともそうですし、
ターゲティングタグとか、
いろんな計測タグがあるんですけど、
そういうのって完全にロックされるんですよね。
読み込むときに必ずJSが
動いている瞬間の時間帯というのは
完全にブラウザブロックされちゃうんですよね。
結果、
そういうビジネス要件が大きい
ECサイトとかウェブサイトだと、
最初初期ローディングが結構読み込み
1秒か2秒くらいかかるみたいなサイトも
結構あるんですね。
よくよく見てみると、
本体のアプリケーション自体は
高速に読み込まれているんですけど、
そういう計測タグのJavaScriptの
実行タイムで遅くなっているみたいに
全然あるんですよね。
そういうのをバックグラウンドで
実行してくれたりする、
いわゆるウェブワーカーにぶん投げる
みたいなことをしてくれるのが
このPartyTownです。
確か。
なので、
コンテンツ自体は早く読み込んでくれます。
でも、ちゃんと裏で
そういう計測タグというのを
走らせてくれますよというので、
問題はその計測タグが
裏で走らせた結果、
本当に計測できているかどうかという
その1つの疑問はあったりしますけど、
ただ読み込みの速度が遅くて
ユーザーが直記されるんだったら
計測するはずのデータ自体が
取れなくなるので、
それは意味ないよねって話になるんですよ。
18:00
なので、
まずは1ページぐらいとかの読み込みとか、
初期のデータのところの正確性を
ちょっと度外視じゃないですけど、
ぼやかしてやるんだったら
いいんじゃないかなと思います。
僕はビジネス要件の話なので
あれですけど、
でもPartyTownというのは
そういうことをやってくれるので、
システムとしては
すごく素晴らしいツールだと思ってますので、
興味あったら見てみてください。
画像がペッて貼られていて、
キャリバーとかのサイトで
ツールを使ったらこんな感じで
計測ができて、
こんな感じでモニタリングだったり
グラフ化しますよっていうのが
参考例として貼られてるんで
見てみてください。
じゃあ続いて、
今のが2つ目。
AuditThirdPartyScriptですね。
じゃあ続いて3つ目ですけども、
3つ目はReduceMainThreadWorkですね。
文字通り、
メインスレッドの量を減らしましょうと。
最初の2つのステップを踏んでいけば
メインスレッドの仕事を減らすために
必要な作業の多くってのは
既に終わっているはずです。
しかしメインスレッドを
高速に保つために
もっとできることがあります。
ここではメインスレッドを
大きなタスクから解放するための
より高度なヒントを
いくつか紹介していきたいと思います。
今回は3つですね。
1つ目ですけど、
WebWorkerやServiceWorkerを使いましょうと。
本当にこれは高度なテクニックですね。
WebWorkerやServiceWorkerを使うことで
集中的なタスクを別の
UIブロックをしないスレッドに
移すことができます。
続いて2つ目。
レイアウトのスラッシングを減らしましょう。
スラッシングっていうのは
JavaScriptファイルの強豪が原因で
ページが何度も再描画とか
再フローを繰り返すことで
発生してしまいます。
リフローだったり
再描画を余儀なくされるような
一般的な問題に注意しながら
JavaScriptコードを監査することで
レイアウトのスラッシングっていうのを
減らしていきましょう。
それでは3つ目ですね。
アニメーションやエフェクトには
JavaScriptを使いましょう。
可能であればJavaScriptのアニメーションを
CSSに変換するのが
ベストプラクティスです。
CSSアニメーションが効率的で
アニメーション可能なプロパティにのみ
適用されているということを
確認してください。
これまた難しいですよね。
ユーザーの操作とか
何かしらユーザーの挙動に応じて
させたいアニメーションって
絶対あると思うんですよね。
っていうのを細かく設定できたり
発火させるタイミングっていうのを
こちらでコントロールするとしたら
結局JavaScriptにさせられない
みたいなのが正直あって
ここがまた悩ましいところです。
とはいえ
CSSに移せるんだったら
それは早いですよ。
絶対に早いと思います。
だから難しいのは
最近のCore Web Vitalsっていうのは
初期レンダリングだけが
強化するんじゃなくなったんですよね。
レンダリング後の操作性が
どんだけ重いか軽いかっていうところも
強化点に変わってきてるんで
それ次第でまたSEOの順位が
変わってきたりするので
一概にアニメーションを全部
CSSに分投げればいいっていうと
そうではない気もしていますので
まあ難しいところですね。
とはいえ
CSSで書くのと
JavaScriptのライブラリを使うのって
絶対CSSのほうが
結果的に軽いのは
目に見えてるとは思いますので
そこを検討してください
っていう話でした。
というところで
いろいろしゃべりましたけど
ラストですね。
まとめに入りたいと思います。
合計ブロック時間を追跡して
最適化のパフォーマンスを
21:00
良く確認しましょう
という話でした。
長期的なサイトスピードの
向上のためには
手っ取り早く修正して
立ち去ることは
良い解決策ではありません。
これらの最適化を行った後は
その結果をちゃんと追跡し
さらに高速化するための
次のステップに進む方法
っていうのを
確認する必要があります。
CALIBURを使えば
複数のドメインで
ページスピードの指標
っていうのを追跡し
時間の経過とともに
パフォーマンスが
どのように変化するかを
確認することができます。
また
サードパーティーのトラッキングや
パフォーマンスバジェットのような
気の利いたツールにアクセスをし
トータルブロッキングタイムのような
指標を常に把握することもできます。
以上CALIBURでも
15日間無料で
全ての機能を使えるので
興味ある人は
15日間で
このTBTをチューンアップして
CALIBURの
ページスピードモニタリングツールを
使うことで
どれだけ簡単に
TBTをチューンアップできるか
というのを
試してみてください。
ということで
この記事が締められておりました。
TBT一回自分で
ライトハウスとかを使って
手続き的に
一個一個
自分の手でやってみて
やっぱり時間かかるし
この辺自動化したり
落下になった時に
CALIBURっていうのを
試してみて
会社として
お金を使うかどうか
っていうのを
検討していただくのが
まずはいいと思うので
一回ちょっと僕は
逆説的かもしれないですけど
いきなりツールに
頼るんではなくて
一回TBTを改善で
どういうことを
するのかっていうのを
把握する上で
手続き的にやってみるのを
僕はお勧めしますね。
というところで
以上で
終わりたいと思います。
まあなかなか
こっちの方が
より開発者に
特化するというか
直接的に
僕らが何かするっていうのが
分かりやすい
手順なので
前回読んだ
TTFBよりも
TBTの方が
より入りやすい
と思いました。
パフォーマンス改善の
項目についてはですね。
まあ一回
試していただければ
いいと思います。
結局は最終的に
ユーザーに
どう届けるか
っていうところを
担う僕らが
ここはしっかり
担保しなきゃいけないので
フロントエンジニアとしては
このTBTとか
昨日読んだTTFBも
しっかり追っていければな
と思っております。
ではそんな感じで
今日の朝方
終了していきたいと思います。
本日参加者は
改めまして
赤神さんと
あと見えてないけど
スーさんですね。
ご参加いただいて
ありがとうございました。
明日はですね
また同じように
パフォーマンス改善系の
記事を読んでいきたい
んですけど
毎回読み方
合ってるか自信ないんですけど
カミュレイティブ
レイアウトシフトですね。
日本語に訳すると
累積レイアウトシフトですけど
の記事を
読んでいきたいと思ってますので
興味ある方
来てみてください。
あともう2日間ですね
パフォーマンス改善の
記事読んでいきたい
と思いますので
興味あれば
一緒に勉強していきましょう。
じゃあ火曜日ですね。
またあの暑さが
本当にひどくなってきてますので
体調管理だけ
気をつけていただければ
なと思います。
じゃあ終了したいと思います。
お疲れ様でした。
