00:07
はい、みなさんこんにちは。 keethことくわはらです。
本日もやっていきましょう。 keethのエンジニア雑談チャンネルです。
この番組ではウェブ業界に関することや、エンジニアリング、いろんな技術についての雑談などの情報を発信していきたいと思います。
で、今日はですけども、昨日リアクトのロードマップを見ていて、結構面白かったし良かったなと思うので、今日も別のやつを見ていきたいなとちょっと思ったんですね。
で、フロントエンド周りのロードマップを別に見てもいいんですけど、せっかくなので別のものとか、自分が興味ある違う部位などとかの方もいいのかなと思ったりはしてましたね。
自分のその関心ところというか、所属しているグループとかから確認すると、フロントエンドのディベロッパーロードマップの方が面白いのかもしれないですけど、
ノードJSも実は興味あったりはするし、CITDとかDevOps周りだったりとか、その辺は別に完全に興味ないわけでは全然ないですし、なんなら好きな方ですしとか、
あとはパフォーマンスチューニングとかもすごく好きなので、その辺のものがないのかなと思ったんですけど、フロントエンドパフォーマンスっていうようなものもあったりして、あとAWSもあるんですよね。
その辺がちょっと面白そうなんで、ちょっと見てみたい感はありますけど、フロントエンドパフォーマンスベストプラクティスっていうというようなものからいきたいと思います。
これはもはやロードマップじゃない気はしますけどね、ベストプラクティスというところで見ていきたいと思います。
ここではフロントエンドロードマップとJavaScriptロードマップの2つのカテゴライズですね、ざっくりで分かれていて、ハイプライオリティ、ミディアムプライオリティ、ロープライオリティの3種で分けていると。
じゃあハイプライオリティからですね。ミニマイズナンバーオブアイフレームズですと。まずアイフレームの数減らせってところですね。
あとミニファイドCSSですね。リムーブ、コメンツ、ホワイトスペースとかを消して、CSSをミニファイしましょうと。
これCSSってことはJavaScriptをミニファイするような、たぶん後出てくると思いますけど。
3つ目、CSSファイルのノンブロッキングですと。ノンブロッキングでCSSファイルを読み込めとか。
あとインラインザクリティカルCSS、アバブザフォールドCSSと言ってます。あとはアボイドザエンベディテッド、もしくはインラインCSSと言ってます。
私なんかCSS周りのところがっつり書いているんで、そこが結構重いって言ってるんですかね。なんかやっぱり画像の方が重いイメージ結構あるんですけど。
CSSの方なんだ。埋め込みのCSSの数、それは減ればもちろんいいと思いますし、基本的にはミニファイとかバンドルもすると思うんですけど、まあまあとはいえですけどね。
続いて、アナライズスタイルシートコンプレキシティってやつを押してくださいと。
複雑なソースタイルシートをとりあえずアナライズ分析してくれと言ってます。まあそのまま数減らしたりとか重複したCSSのスタイリングとかその辺を減らせばいいってことかな。
で続いてコンプレスヨイメージズもしくはキープザイメージカウントローと言ってますね。はいはいはい。やっぱり画像ですよね。
まあ圧縮してくれと。もしくは画像の数を減らしてくれと。まあそれはおっしゃる通りですしね。
03:01
画像が少なければ少ないほうが絶対それは早いに決まってるんで。はい続いてチューズイヤイメージフォーマットアップルプリセッティですね。
まあまあ最適化をしろってことですね画像の。まあ最近だとwebとかあったりするのでまあそういうものを使ったりすると早いですよとかでそういう話ですね。
画像フォーマットの最適化はもう今ロンテンドーほぼ必須のお話ですね。続いてはミニファイユアジャバスクリプト。まあそりゃそうだよね。
XSでもミニファイしましたけどジャバスクリプトもやっぱりミニファイしましょうと。これはもうほぼデファクトだし今のバンドルツール使った開発環境だとは普通にすると思うんで。
当然ちゃ当然ですけどちゃんと言語交わしているってことですね。はいじゃあ続いてノンブロッキングジャバスクリプト。
ユーズエーシンクもしくはディファーを使いなさいと。はいエーシンクとディファーの使い方若干違ったりするんですね。
まあ非同期に読み込むところありますけど。あるのでまあこの辺はちゃんと理解をして使いましょうってことですね。
納指でエーシンクとかディファーをつければいいってわけじゃ全然なかったりするので。
続いてユーズhttpsオンユアウェブサイトというので。
httpsだけのサイトって言ってるのかわからないですけど君のウェブサイトにhttpsでSSLか使ってくださいねってことですね。
はい。なんかそのほうが速いのかどうなんですかね。
単純にネットワークのスピード感で言ったらhttpsじゃないほうが速い気はしますけど現実界としてhttps使わないのはまずありえないと思うので。
まあなんかちょっと僕はこの辺ちょっと理解しないけどそのほうが速いのか。
はい。はいまあ続いてキープやページウェイト。
1500kbですね。はいはい。
IDEAで500kbって言ってます。はい。
まあ可能なら500kbに抑えろって言ってますけど。
サイズが1900kbですね。
全部圧縮したりいろんなものをミニファイしたりした結果っていうところですね。
1500kbなんだ。
サイト全体のサイズについて1500kbってちゃんと数字を明確されてるのは見たことなかった。
まあそんな感じなんですね。
なんか一個一個のページ単位についてどれぐらいサイズとか
それぞれのインストールするとか
インポートするライブラリとかのツールがどれぐらいのサイズみたいなのを結構気にしたことがありますけど
ウェブサイト全体をこれぐらいのサイズに抑えろってのは見たことなかったですね。
はい。分かりました。
続いてキープやページロードタイム3セカンドなので
まあそりゃそうですね。
君のウェブサイトとかページが3秒以内にまずロードされて連打リクしてくださいと言ってますね。
まあこれはもういろんなところで語られてますけども
多分3秒はこれもっともっと縮まっていくと思います。
はい。まあでも3秒でもだいぶ早くなりましたけどね。
とはいえ3秒経つとユーザーは離れてしまっているっていう結果で
Googleが言ってますよね。
それは仕方ないという感じ。
じゃあ続いてキープザタイムというファーストバイトを1.3セカンドですね。
はいはいはいはい。
ファーストバイト1.3秒多分逆に言うと遅いと思うんですよね。
何もないまま真っ白なページ1秒見なきゃいけないってなると
多分ユーザー待機かなり少なるので
ファーストバイト1.3秒以下。
まあこれはそうだよなって感じですね。
続いてミニマイズHTTPリクエストと。
まあまあそれもそうですよね。
HTTPリクエスト数が増えれば増えるほど
ネットワークとのIOとかサーバーとのやり取りが増えるので
それは遅いので数を減らしてくださいと。
続いてサーブファイルfrom the same protocolだと。
まあまあまあまあ。
プロトコルは同じにした方がいいのもそれは当然ですよねって感じです。
06:00
サーバーの容量とかスペックによりますけど
できるんだったら同じサーバー内でガンってやった方がいいと思います。
まあ現代ではそういうことなかなかそういう現状はないと思いますので
まあなるべく数は減らした方がいいよってことですね。
続いてアボイドリクエスティングアンリーチャブルファイルですね。
リーチャブルファイルですか。
まあ要は404の数を減らせと。
これはなんかまあパフォーマンス関係なく
ハイクオリティだと思いますけど
まあまあパフォーマンスにも影響するのでってことですね。
404ならばそもそも読み込まなくていいはずなんで
その分のネットワークIOを減らした方がもちろんいいよねって感じですね。
はいでは続いてセットHTTPキャッシュヘッダーズプロパリーですね。
キャッシュもねうまいこと使っていきたいというのはもちろんありますね。
HTTPの方ですけど。
でラスト。
GZIPもしくはBLOTILのコンプレッションいつイネーブルにしてくださいよってことですね。
まあコンプレッサーできるのはもちろんやった方がいいのでこの辺ですね。
はいというのでフロントエンドパフォーマンスのハイプライオリティは
今の以上ザーッと並べていたものですけど
まあなんかよく言われているものがザーッと言われてた感じですね。
でパフォーマンスツールズとしてまあ使うものという何があるかって話ですけど
まあページスピードインサイツっていうサイトがあって
まあそれを使うのが一つと。
まあまあ結構皆さん使ってるものですね。
あとはライトハウスとかウェブページテストとか。
あのChromeのDevToolsの中にまあ一応ライトハウス組み込まれてます。
それ使うとか。
はいあとはバンドルフォビアですね。
を使って実際どれぐらいバンドルされてますかっていうのをこう見たりすると。
まあライブラリーがそれぞれサイズどれぐらいですかとか
そのライブラリーのGZIPしたときのバンドルサイズとかの比較をしてくるんで
バンドルフォビアも結構いいと思います。
であとはSquash.appはちょっと僕初めて聞きました。
そんなやつがあったんですね。
まあこの辺を使ってとにかく自分たちのサイトを計測しろというところですね。
はいまあとにかく計測からパフォーマンスは始まるので
それはその通りだっていう感じはしました。
では続いてミディアムプライオリティですね。
ミディアムはざっとまた見ていきますと
ミニファイトHTMLですね。
リムーブコメントとかホワイトスペースとか
まあキー消してって
HTMLもミニファイトしてくださいと。
まあこれもさっき言った通りバンドルツールを最近使うのがデファクトなので
ほっといても勝手にやってくれるでしょうというところですね。
で続いてユーズコンテンツデリバリーネットワーク
はいまあCDNで使ってねっていうので
まあキャッシュする方が早いのでそれはそうですよねって感じです。
CDNはハイプライオリティじゃないんですね。
逆にいうのを思いました。
これ入れるでしょうと思ったんですけど
まあマストかって言われたらそれはもちろんマストじゃないんですけど
そのサーバーへのアクセス数がすごい高いとか
だったら絶対ロードバランスまで捌ききれなかったりするし
そもそもデータをキャッシュできたりとか
コンテンツの更新がないんだったら
CDNで返した方が絶対早いので
そのほうがいいと思うんですけどね。
ミディアムなの。
で続いて
そらそうだろ
まあビットマップよりもね
ベクトルイメージの方がいいんじゃないって話してますけど
いやいや果たしてどうなんて感じはしますけどね。
まあそもそも画像を減らせっていう話からスタートはしてますからね。
続いて
はいはいアスペクトレイズ用ですね。
画像のハイトとウィッツですね
横幅と縦幅をちゃんとセットしましょうねってことです。
しないと無条件で
オリジナルサイズがあんとインストールするのでってことですね。
はいでは続いて
09:01
まあベース64イメージはそら避けた方がいいと思いますね。
確か普通の画像をベース64にしたら
確か1.3倍ぐらいのサイズになるんですよね。
なので
テキストで扱えるからそれは便利っちゃ便利なんですけど
その代わり重くなるし
遅くなるってのは確かにそうなので
避けられるならベース64イメージは避けた方がいいって話ですね。
では続いて
遅延ローディングしろってことだと思うんですけど
まあまあそうですね
イメージが自分たちが今見ている画面の外にいるんであればって感じですね。
はーいでは続いて
画像サイズをちゃんとディスプレイサイズに最適化するとか
ピッとさせるってことですね。
はい。
まあそれもその通りだって感じはしますね。
最近でも画像サイズの指定とかも結構細かくできるようになったりするんですよね。
イメージグループだっけ?
なんかそういう特殊なタグありましたよね。
それを使うともうちょっと柔軟に画像サイズを指定して読み込みすることができるので
まあその分
そういうサイズ用の画像をちゃんと用意しなきゃいけないってのはもちろんありますけど
まあパフォーマンス最適化のためには最適な画像の種類とか
サイズをいくつか用意しておくってのは全然いい話だと思ってるので
はいそんな感じですね。
あざわざモバイルに超巨大なサイズのファイルを読ませて
でそれを画面の中でリサイズイメージとかをして表示するぐらいだったら
最初から小さいサイズ読み込むのが早いに決まってますからね。
では続いて
アボイドマルチプルインラインJavaScriptスニペッツ
まあそうねって感じです。
これはまあその通りだと思うし
皆さん普通の開発環境だとバンドルするので
この辺は意識しなくてもまあ大丈夫と思うんですけど
だいたいあの解析タグですね。
リターゲティングタグとかアナリティクス系のタグですね。
あの辺はまさしくそのままインラインで埋め込んだりするので
結果あれの数が多いとめちゃくちゃ遅くなるので
まあこの辺の数もできれば減らせるなら減らした方がいいよと
そういう話です。
でまあそのためになんか最近出てきた
パーティータウンっていう
まあちょっとしかメジャーバージョン1じゃなかった気がしますけど
とかあるので
パーティータウンというライブラリーは今後結構注目を浴びると
個人的には思ったりしてます。
はいでは続いて
Keep your dependencies up to date
はいはいはい
依存性ライブラリーのちゃんと更新とか見直しをしてねってことですね。
はい
まあこれは多分セキュアな話とか
その辺の話が出てくると思うんですけど
ちゃんと最適化したライブラリーも常に進化し続けるはずなんで
最新のものを使う方がまあいいんじゃないのっていう
多分そういう話だと思いますね。
その中にパフォーマンスの改善も入ってくる可能性はあると思いますのでね。
まあこれはなんか言われなくてもやると思います。
続いて
Check for performance problems in your JavaScript files
ってことですね。
まあこれさっきの計測するのと結局同じな気がしますけど
ちゃんとあなたのJavaScriptファイルのパフォーマンスの問題を
ちゃんとチェックしましょうねっていうことですね。
まあパフォーマンス問題見ていくと必ず
見るとは思いますので
意識しなくてもこの辺もできる気はしますけど
まあ一応明記したってことですね。
では続いて
Service workers for cachingとかパフォーマンス heavy tasksと言ってますね。
だいぶ抽象度の高い書き方してますけど
そりゃそうだろうって感じはしますが
まあサービスワーカーを使うのは本当にいい話だと思いますね。
これも
キャッシュ周りのところでサービスワーカーとかに頼れるんだったら
全然頼った方がいいと思いますので。
まあこれはCDNと結構似てる話だと思いますけど
12:02
でもこっちの方はマストじゃないなっていう感じがしましたね。
あとはまあheavy tasksっていうのは
多分タスクそのものをちょっと分解するとか
絶対したほうがいいと思いますね。
処理自体をどうか、何かして分割できないかって
そういう話だと思います。
はいでは続いて
Cookie size should be less than 4096 bytesだって言ってますね。
クッキーに4MBの何かが保存するって
そうそうない気がしますけどね。
そこまで行くんだったら
ローカルストレージ使うとか
インデックスDB使うとかそっちだと思いますが
クッキーにそんなデカいの読み込ませるのは
ちょっと違う気がしますね。
パフォーマンス以前の話な気がしました。
はいでは続いて
Mediumはラストですね。
Keep the cookie count less than 20と。
クッキーに20も保存します?
何かサイトとかあるんだ。
ちょっと驚きです。
僕でも最大でも8個とかやったことありますけど
8ですら多くねっていうか
そこまで行くんだったら
やっぱりローカルストレージとかの方に
使うべきでしょうと思ったりしましたね。
何をそんな保存するんだろう。
まあとりあえず20個以下に抑えてくださいと言ってます。
逆にクッキーとのやりとりで
そんなパフォーマンス遅いんですかね。
あんまりそのクッキーに
たくさん情報を保存したことがないので
クッキーの保存とかそこのやり取りの
パフォーマンスの解析とか
調査をしたことがなかったので
クッキーって遅いんですかね。
わかんないけど。
はい以上今のがMedium Priorityです。
じゃあラストLow Priorityですね。
Preload URLs where possibleってことですね。
あーはいはいはいはい
Preloadできるものは読んでくださいと。
いや先読みできるんだったら
これ俺High Priorityだったんですけど
Lowなんですね。
Low PriorityでPreload URLsですね。
続いて
Concatenate CSS into a single fileってことですかね。
コンカレンス
でもRじゃなくてTだもんな。
連結するつなぐっていう英単語だそうですね。
CSSファイルを一つのファイルに連結しろと。
多分これもさっきのバンドルするので
結局あんまり意識しなくて勝手にやるとは思いますけど
とはいえCSSファイルいくつかで
分割することはよくある話ですので
それをちゃんと最後ビルドするときに
バンドルしねって話かなな気がしましたね。
要は画面上でCSSファイルを何度も何度も
種類ごとに読み込みをするっていうのは
結局遅くなるので
一発でポンと読み込めたらいいよねってことだとは思うんですけど
ファイルの話だよな。
多分シングルファイルって書いてるからね。
はい、そんな感じです。
続いてRemove unused CSSですね。
これは文字通り
使ってないCSSは削除しなさいと。
これはJavaScriptの関数とか変数も一緒ですね。
使ってないものはちゃんとチェックして削除しましょう。
どうやってチェックするかなんですけど
ツールもいっぱいあるんですけど
実はChromeのDevToolsで
CSS使ってないものっていうのが実は
数字で見れたはずなんですよ。
このサイトどれくらいCSSで
使ってないものあるか確か見れたはずなんで
Chromeで全然見れるとは思いますけど
画面まで行って初めて見るくらいだったら
開発の段階で見たいと思うので
なんかその辺のライブラリある気はしますけどね。
ESLintとかで見れたらいいんですけどね。
あとStyleNitとかかな。
ちょっとその辺やったことないので
なんか気にはなります。
続いてUse WoW2 Font Formatを使えと。
フォントの話についに出てくるんですね。
っていうのでWoW2っていうフォントフォーマットがあるので
それを使ってくださいと。
と言ってます。
これもプリコネクトできるんだったら
そりゃした方がいいねって。
15:00
そりゃおっしゃる通りですね。
ものによってはサーバーの中に置いといて
ネットワーク通信じゃなくて
自社のサーバー内だけ閉じれた方が
早いとはもちろん思うんですけど
まあ今は普通にCDNとか
外部のフォントのデリバリーサービスがあるので
その辺に読み込みをしに行くっていうのは
よくある話なんで。
ここがね、そういう新しいフォントフォーマット
使ってくれたら別にいいんですけどね。
Keep the web font size under 300KBと。
フォントサイズを300KB以下に抑えるということですね。
フォントサイズも確かに
僕あんま比較したことなかったですね。
そんな300KBのフォントサイズどうなんだろうね。
まあサイズが小さければ
実際に残したことはないし
フォントの種類をどれだけ読み込むかによる気はしますので
あとすごい特殊なフォントを使うんだったら
確かにサイズが結構デカくなっちゃったりするので
どこまで自分のサイトのビジュアルとか装飾に対して
フォントをどこまで重視するかというのは気はしますけど
でもフォントって基本的には
読みやすさの方を重視した方が絶対にいいと思ったりするので
そのサイトデザインとかのコンセプトと
要相談って感じですね。
続いて
Prevent FlashはInvisible Textと言ってますね。
フラッシュは死んでるのあれですけど
多分そのフラッシュの話じゃない気がしますね。
あとはInvisible Textの読めないテキストみたいなところで
話ですけど
ちょっとごめんなさい。
僕があんまりこれ書いてる意味が
意図が読めてないので割愛します。
ラスト
Keep an eye on the size of dependencies
サイズのディペンデンシーズにちゃんと目を向けろと
向け続けろと言ってます。
これは要はさっきの
チェックしてくださいって話と結局
同じな気がしますので
そのまま皆さん意識せずやってると思いますけどね。
というので
あとはMore Resourcesってことで
フレームワークスペシフィックガイドとか
レコメンデーションタスクもしくはガイドみたいのがあるので
その辺を見てみてくださいと。
リンクも貼ってますので
興味ある方は見てみてくださいということでした。
結構
今まで当たり前にやってきたことを
ただ当たり前に愚直にやれっていう感じは
すごくしましたけど
やっぱりパフォーマンスってのは
とにかく計測せよってところに尽きると思うので
しっかり自分たちの作っているサイズとかの
チェックをし続けてくださいねってことだと思います。
はい。今回はこんなところで終わっていきたいと思います。
いつも聞いてくださり本当にありがとうございます。
ではまた次回の収録でお会いしましょう。
バイバイ。
