00:03
はい、12月3日土曜日ですね。四国浅くじを回りました。 本日は待ちに待ったPWAナイトカンファレンス2022の開催日ですね。
はい、まあそれがあるんですけど、僕が今日司会をするので、もし興味があれば来てみてください。はいおはようございます。
ひめめのkeethことくわはらです。では本日も朝活を始めていきたいと思います。 ちょっとだいぶ遅れてしまいました。
まさかの16分ですね今。 まあちょっと寝坊してバタバタしてたんですけども。はい、まあなのでちょっと後ろ出しになりますけど、今日はやっていきたいと思います。
ではですね本日はタイトルがあります通りですけども、keethに 投稿されている、2月14日ですね今年。
投稿されていたWebフロントエンドパフォーマンスチューニング70選という記事ですね。 だーっと読んでいこうかなと思っています。はい、なかなか素晴らしい記事で、全部はまだ読み切ってなかったので、これを機にガッと読んでいこうかなと思っております。
まあフロントエンド周りのところですけど、パフォーマンスのやっぱり僕は最近関心がすごい強いので、この記事を読んでちょっと勉強させていただこうかなと思う次第です。
はい、というわけでではでは早速入っていきたいとおもいますが、タツヤ汗川さんですね。おはようございます。ご参加いただきありがとうございます。
今日も記事のタイトルにある記事をだらだら読んでいく感じです。 では行きましょう。こんにちはNkosukeです。近年Webフロントエンドではサイトのパフォーマンスの重要性がすごく高まっていますと。
例えばGoogleはCore Web Vitalsというパフォーマンスの指標を検索結果のランキング要因にも組み込んだという話ですね。
まあでもどちらかというとこれは初期レンダリングのスピードに関する指標だった記憶がありますね。
分かりやすいもので言うと、算数のかけ算みたいなものですよね。かけ算って最初は多分皆さん丸暗記すると思うんですけど、結局あれといえば足し合わせることを一発でスパッとやるっていうだけの話にすぎないっていう話なんですけど、
そのかけ算の使い方だったりとか有用性みたいなのは後から理解するんですよね。
最初からそのかけ算の有用性とかどういう原理みたいなところをしっかり理解して使っている小学生ってほぼほぼいないと思うんですよね。
まあいらっしゃる方もいると思いますけど、まああれと同じで、まずはわからないけど覚えておくとか使ってみて、その後になるほどねっていうのが理解できるというのはよくある話なので、パフォーマンスも同じことなんだろうなと思いました。
更新情報ですね。9月12日に更新情報がありまして、5つ追加されています。
ツリーシェイキングを意識して書くっていうのと、トランスファイル後のコードを意識して書く、あとはリダイレクトを避ける、画像を使わずhtml、cssでアイコンを表示する、
最後、beforeやafterの擬似要素を使って不要なドムを作らないみたいな、5つの別の擬似が入ってますね。
まあでもこれ、タイトル見るだけで確かにそうねみたいな、なるほどって思うものばっかりなので、本当大事だなと思いますね。
一番最初のツリーシェイキングを意識して書くって意外と難しいんですよね、意識するのっていうのは。
でもこれ本当に大事な観点なので、さすがだなってとこです。これらの記事も別で読みたいかなと思いますけど。
はい、では行きましょう。注意事項ですね。一口にフロントエンドといっても、サーバーサイドレンダリングとかスタティックサイドジェネレーティングですかね、
03:00
サーバー側も関わっていくこともあるので、バックエンド寄りの話も混じっているのですけど、それは足からということですね。
わかりやすくするためにカテゴリ分けはしてますけど、微妙なカテゴリ分けのものもあるので、そこも足からです。
中には具体的なハウツーというよりも、いわゆる考え方的なものを混じっているかもしれません。それも足からです。
あとはですね、環境によって必ずしもパフォーマンスが改善されるとは限らないので、それも足からです。
あくまでパフォーマンスの観点なので、他の観点では最適とはならないというものもあるかもしれません。
というので、そこも足からです。例えばインデックスDBを紹介していますけど、
サファリ15で脆弱性が見つかっていますとか、速くするためだけの観点でこの記事が書いていますよということですね。
紹介するものには特定のブラウザーでしかサポートされていないものもありますけど、そこも足からです。
さっしかたないですよね、なかなかブラウザー統一はならないので。はい、というところでした。
要は前提がかなりいっぱいありましたけど、この辺の前提を踏まえた上で入らないとやっぱり
認識のズレだったりなんか非反応となったりするので、ここは結構大事ですよね。
ではでは早速本文に入りますが、まずJavaScript編ですと。
一つ目ですね、複数の非同期処理というのはPromise.orgを使いましょうという話ですね。
もし互いに依存関係のない複数の非同期処理を実行しているのであれば、
Promise.orgを使うのも一つの手ですよというふうに言っています。
MDNでPromise.orgの記事のリンクを貼られていますけど、
あとはソースコードですね、いきなりガーッと払えていて、ソースコードだらけなんですよ今記事は。
なのでちょっと音読になってしまって申し訳ないですけど。
1個、Asyncで1つ関数がバーッと作られていますと。
No use Promise.orgみたいな関数が作られていて、その中で冒頭Console.logをスタートしておいて、
Awaitでどっか的なAPIのフェッチをしますと。
しかもブラウザーの標準のフェッチAPIですね。使ってAwait.fetchでレスポンス1。
もう1回Await.fetchでレスポンス2ですね。
しかもこれはAPIは別のドメインのAPI叩いている、別のエンドポイントのAPIですね。叩いている前提です。
2つのAPIをそれぞれAwaitでフェッチをかけていると。
で変数に受け取ります。
で最後それが受け取り終わったらConsole.log.endっていうのを出すようにしてますと。
もう1個の方の関数はAsyncファンクションでUsePromise.orgってやつですね。
でこれはConsole.logでまず最初スタートしておいて、
Constのレスポンス1、レスポンス2っていうのを配列で受け取るようにしてますと。
で中身の方はAwaitにPromise.orgでさっきのフェッチっていうところを配列で渡してあげるということですね。
はいで終わりましたらConsole.endというとこです。
でまぁConsole.orgっていずれかの非同期処理が失敗すると、Promise.orgっていうのの結果そのものが失敗扱いにもなりますと。
失敗扱いにしたくない場合はPromise.allSettledっていうのがあるのでそれを使ってみてくださいと。
1個1個だから手続き的にAwaitを書くのではなくてPromise.allでそれぞれのフェッチのコール処理っていうのを配列で渡してあげちゃった方が少し改善するかもねっていうところでした。
06:03
実際にこれ試した数字だったりメトリクス的なものがあるわけではないのでこの辺は皆さんも試してみてくださいということですね。
あくまでアイディアとして出されているということでした。
はいでは続いて非同期処理は待たなくて良い場合は待たないというところですね。
はい行動を眺めてみて非同期処理を待たなくて良いところは待たないにしましょうと。
具体的にはAsync、Awaitコーブンを使っているならAwaitを使わなくていいよということですね。
ConstでSendErrorToServerみたいな関数が定義されていてAsyncのメッセージを受け取ると。
でまぁサーバー側に何かエラー処方を送る処理っていうのを関数定義しておきますと。
でまぁコンソールログで何かエラー起きたって出しておいてその後にSendErrorToServerっていうエラーです。
で高速の処理みたいなことをかけるんですけどその高速の処理みたいなところはサーバーにエラーを送る情報処理とは全然関係ないので別にAwaitをつけなくていいんじゃないのってことですね。
あのその予布関数そのものにAsyncがついてるけどその予布関数そのものが他の処理と別に何も依存関係がないんだったらそのまま
あのAwaitせずに投げればいいじゃんっていうことですね。これは基本ですね非同期処理の。
これもそうですねいかにもかかる非同期処理の時間かかるものがあったら先に走らせる意味越したことはないってことですね。
メインスレッドとしては別のものがどんどん走っているのでこれはそのまんまだなって感じです。
続いてキーバリューを頻繁に追加や削除する場合はマップを使いましょうというふうに言っています。
MDNにも記載はありますけどキーバリューのペアっていうのを頻繁に追加削除する場合はオブジェクトよりもマップを使った方がやっぱり最適ですよってことですね。
これはその公式サイトにそういうふうに書いてあるのでそれを使いましょうということですね。
なのでニューオブジェクトとかするんじゃなくてニューマップを使ってマップを作っておいてそれぞれにドットセットでキーと名前みたいな。
削除するときはデリートを使えばいいというところですね。
うーんそうなんですね。
これはちょっと僕は知りませんでした。
MDNにも書いてあるんですね。マップの方が早いよってところなんですね。
はいでは続いて膨大な配列の検索っていうのはキーバリューでやりましょうと言っています。
Javascriptで言うよりもロジックの問題かもしれないですけど膨大な配列を検索する場合はキーバリューに変換してから検索した方が実は早いですよと。
例えばオブジェクト配列として1000's people みたいなのがあって
一個一個にネームとエイジっていうのがセットされたオブジェクトがぶわーっととりあえず1000個ぐらいめちゃくちゃ多い配列が1個あったとしましょう。
でその1000's people の中からドットファインドで
コールバック関数の中でネームを受け取ってネームイコール例えばトムっていうのを探すとしましょう。
まあそういう処理をするんですけどそれは結構時間かかりますねと。たまたまその1000's people の一つ目の要素だったらそれは早いかもしれないですけど
最後の方にいた場合はめちゃめちゃ遅いよねって感じです。
そのことをやるんではなくてその1000's people をマップにしておいて
そもそもの people をオブジェクト配列にするんじゃなくてマップにしておいて1個のオブジェクトにしちゃう感じですねこれは。
09:02
でそれを検索する方がやっぱり早いよねってことです。その変換処理をじゃあどうするのってところは結構大事です。
さっきのその1000's people っていうオブジェクト配列を単なる一つのオブジェクト
一つのオブジェクトにしてしまった方がそれは早いんですけどその配列からオブジェクトへの変換をどうするのってところが
一個課題になるのでここをですねこれができればまあ早いんでしょうねってところですけど
試しにちょっとこれは後ほど実際に数値出してみたいですねどれぐらい早くなったのかは
自分のほうで検証してみたいなと思いました。はいでは続いて
関数の結果をキャッシュしましょうってところですね
頻繁に同じ比数で関数を実行したり重い処理を走らせるなら関数の結果をキャッシュするのも有効です。
次のようにデコレーター関数を作れば関数の結果をキャッシュできますってところですね
これもまあそのままって感じです。重い処理なんだけど結果がそんなに変化することが大きくないんだったら
キャッシュするのも全然いいなと思いました。例えばそのファンクションで
キャッシングデコレーターみたいな関数を定義しておいたとしましょうで中身にまず
const cache イコール new map ですねやはりマップを使うんですね
でリターンで毎引数受け取ってその引数の値がtrue c がどうかを見て
true c じゃなければ何か引数のファンクを使っておいて
return cache.get すると。でconst result でそのファンク引数のファンク関数ですね
を実行した結果を受け取ってそれをまたキャッシュ.set にしておいて
キーの名前はそのリターンのコールバック関数の引数をキーにしておくでvalue は
result ですねでreturn result しておけば良いよって感じですね
これはちょっと僕が今音楽してるから皆さんはちょっとわからないかもしれないですけど
これ多分ソースコード見てもらった方が早いと思います
で別の方でヘビーファンクノーキャッシュみたいなキャッシュもしないし重い処理みたいな関数をとりあえず定義しておきます
中身はなんか適当な重い処理ですよということですね でそのヘビーファンクのやつですけどさっきのキャッシングデコレーターという関数を使えば
そのヘビーファンクのノーキャッシュという関数をそれに引数で渡してあげると結果を中身が結局キャッシュされるので
今2回目の実行はキャッシュから返されるがすごく早いよねってことでした
まあ別にこれは何でしょうねそういうキャッシングのような関数を作るのも結構ですけど普通にストアを使って
状態を保っておくというのも一つの結果かもしれないですね 重い処理用の結果をどっか
グローバルステートでもいいですしどっかストアライブラリーの中で 状態管理として持っておくのも一つの手かもしれないですね
関数とかメソッドレベルで状態をストアに持たすというのはあんまりよろしくないというか あんまり聞いたことがないので
こういういわゆるメモ化に近いようなテクニックを使う方が一ついいかもしれないですね
実はキャッシングデコレーターはその中の方でニューマップをしているので呼び出すために新しいマップを使っているので
それぞれのメソッドレベルでの呼び出しもできたりするということができるから これはこれで一つの手ではあるんですが
しかもキャッシングデコレーターは最終的には関数を返すのでそのキャッシュをする機能を持たした別の関数を作って返すみたいなところなので
これは使い勝手がなかなか良さそうなんでこれは何ですかね
12:01
チップスとしてこのメソッドを覚えておいていいかもしれないなとは思いました
後ほどそのソースコードこの記事から見てみてください なるほどねってなると思います
では続いてリクワイヤーではなくインポートを使いましょうということですね
ほーんダイナミックインポートの話かな
JavaScriptのモジュールの読み込みにはリクワイヤーとインポートの2種類があります
リクワイヤーはいわゆる同期的でインポートは非同期的にモジュールを読み込むのでインポートの方が良いでしょう
ノードJSといったサーバーサイドでJavaScriptを記述する場合はリクワイヤーを使うことが多いと思いますが
まあそういうのはバージョンの問題ですね
バージョン14であればパッケージJSONだったりファイルの拡張子を.mjsにしたりいじることでインポートで読み込むことができますよと
この辺のお話についてはKiitaの別の記事が書いてあるのでこれを読んでくださいと
これが結構わかりやすいよってことでした
記事のタイトルはノードJSリクワイヤーは同期的ロードインポートは非同期型ロードっていう記事があるのでこれを見てみてくださいと
これスインさんの記事ですね
では続いてフェッチにはKeepaliveを使用しましょうというところですね
何度も同じドメインへアクセスするのであればKeepaliveっていうのを指定することでフェッチ処理が結構短縮されますよってことです
例えばAxiosというフェッチライブラリを使っていたとしましょう
でインポートAxiosFromAxiosですね
これ読み込んでインポートエージェントAsHttpAgentとか
でFromHttpですねインポートエージェントAsHttpsのエージェントFromHttps
とりあえずモジュールを何個か読み込むのとしましょうと
でそれぞれの読み込んだモジュールを実行するんですね
constのHttpAgent="new HttpAgentでKeepaliveをtrueにしておくと
でHttpsAgentの方も同じですねKeepaliveをtrueにした値を指定して
で入手で実行すると
でそれぞれのエージェントに対してAxios.createとかでエージェントのインスタンスをそれぞれ渡してあげるというのが良いということですね
アクセスするというかいわゆるHttpとかHttpsのコールの時にKeepalive trueっていうのを使っておくと
何度も同じドメインにアクセスすることがあるんであれば有効になりますよということですね
KeepaliveそのものについてはMDNのところに記事のリンクがあるのでここで勉強してもらうのがいいなというところでした
名前通りですね何をキープしておくのかというところが出てくるのでこれを使うと重い処理とか何度もすることをちょっと短縮されますよということですね
では続いて非同期の関数を使うというところです
Node.jsには同期と非同期で別で用意されている関数が実はあったりしますと
例えばそのファイル読み込みとかファイル書き込みをする関数ですね
ファイル書き込みにする関数としてはfsというモジュールがありますねNode.jsにあるんですけど
そのfs.writefilesyncというものとfs.writefilesっていう2つのメソッドがあります
フロントエンドアプリケーションのビルド時に静的なファイルを生成する必要がある場合は特段理由がなければfs.writefilesというのを使いましょうということですね
15:05
でまあケースバイケースでfs.writefilesyncというものがあるので同期的なものですね
使う場合も必要であればそれを使ってくださいと
ただ特にないんであれば基本的には非同期でやるwritefilesというメソッドの方を使うといいよということでした
とにかくパフォーマンスレベルでは非同期なものに倒す方がいいんじゃないのというお話ですね
では続いて不要なインポート分は削除しましょうというところです
不要なインポートによってスクリプトサイズが非大化していないように削除しましょう
例えばESLintを使っているのであればESLintプラグイン unused importsですね有名なオプションですね
で不要なインポートを発見できますのでこのオプションを設定してくださいということですね
VSCodeとかWebStormなどのIDEでファイル保存値にESLintを走らせるようにすると便利ですよということです
使ってないモジュールを読み込むとそれだけビルドする時とかバンドルする時のファイルサイズで非大化につながるので
これはそのまま削除してくださいというところですね
ESLintのプラグインでunused importsというのがあるのでこれを使ってくださいと
これはほぼ必須というか皆さんマストで入れてくださいぐらいの機能ですね
では続いてツリーシェイキングを意識して書くというところです
Webpackなどのバンドラーではコードを解析して利用していないコードを削除してくるいわゆるツリーシェイキングという仕組みがあります
このツリーシェイキングを理解しながらコードを書くとスクリプトサイズを落とすことができますよということですね
例えばクラスを使わずにできるだけ関数に分割してエクスポートするみたいなのが挙げられますと
例えばですね次のような2つのファイルがあったとします
ファイル1ではエクスポートクラスでテストみたいなクラスを定義しておいて中身にstatic、hogeとstatic、fugaという2つのメソッドがあります
中身は普通にコンソロログでhogeとfugaを出すだけなんですけど
というstatic関数を定義した1つのクラステストというのがあるとしましょう
でファイル2の方ですねファイル2の方は
別にクラスを使ってなくて単純にエクスポートファンクションhogeでコンソロログhogeと
もう1個エクスポートファンクションfugaでコンソロログのfugaという感じですね
さっきのクラスの中に定義しあったstaticメソッドをそのまま外に出してエクスポートで関数をそのままエクスポートしているという感じです
こういう2つのファイルがあった場合にこの時例えばhogeの関数を使いたい場合ですね
使いたい場合それぞれのコードは次のようになりますと
ファイル1の場合はクラスを使っているので
importtestというのはとりあえずインポートしておいてtest.hogeみたいな感じでメソッドをコールします
ファイル2の場合はimporthogeというメソッド名をそのままインポートをしてそのまま実行できるということですね
でファイル1のケースではテストクラスを1回丸ごとインポートしているため
ツリーシェイキングが効かず利用していないfugaというのもメソッドがですねバンドに含まれてしまいますよということですね
一方でファイル2の方ではそのhogeのみをインポートしているためツリーシェイキングが効いて
fugaはバンドに含まれず最終的なスクリプト量を軽減することができると
このようにツリーシェイキングを意識してコードを設計することによってスクリプトサイズを軽減することができますというところですね
18:00
雑な言い方をすればクラスを使わない方が早いよみたいなところがありますね本当に雑な言い方ですけど
ただそのメソッド名とかを直接インポートできる方がツリーシェイキングがしっかり効くのでファイルの被代価が減るよというところでした
確かにこれはそうだなというのはあるので要法要領というかケースバイケースでありますけどなるべく
特定のものを使うときに特定のものを読み込むというのがいいと思うのでそういうことを意識して書きましょうということでした
では続いてトランスファイル後のコードを意識して書くというのが次のお話ですね
バベルなどを使ってジャバスクリプトをブラウザが対応するバージョンへ変換トランスファイルすることが多いと思います
自分が書いたコードが最終的にどのようなコードに変換されるかは実はチェックした方が良いでしょうと
意外と皆さんはバンドルされたりビルドされた後のコードですね
トランスファイル後のコードを見ることって意外と少ないかもしれないですけどちゃんと見た方がいいですね確かにこれは
僕もそんなに必ず毎回見てるかってそういうわけではないですけどたまにやっぱり見てるときはありますね
例えば次のようなクラスを使ったコードをES-2015に変換するとしましょうと
クラステストっていうのがあって中身フォゲっていうメソッドでメソッドの中身を単純にコンソールを出すだけ
みたいなクラスが1個あったとしましょうこれをES-2015に変換したとします
するとですねスクリプトサイズがかなり大きくなってしまいますといろんなものがワーってガチャガチャ出てきて
ソースコードに吐き出されるというところですね これはバベルを使った場合ですけどこれをですね関数の場合はどうでしょうかと
さっきはクラスだったんですけど関数で単純にファンクションをフォゲで中身コンソールをフォゲだと
を出しているだけの関数ですねまあさっきのクラスの中身をそのまま引き
引っ張り出してきた感じですね そのコードをバベルにかけてみますとそれはそのままほぼ同じ形で変換をされますと
まあ一応ユーズストレイクとかが頭についてくれるかもしれませんけど このように同じ機能を実現しようとしたとしても書き方によってトランスファイル後のコードが
非大化することもありますということで 簡易的にトランスファイル後のコードを確認するツールっていうのもあるのでまぁそれも見てみて
いいんじゃないのかというところですね イエスシックスコンソール.コムみたいなドメインのサイトがありますのでここにそのソース
コードパって投げておくとあの確認ができますのでそれをその辺を使って自分のあの トランスファイル後のコードどうなるかみたいな見てもいいかもしれないですね
もちろんそのお仕事で書いているコードはどこまでそういうサードパーティーとか 外部サイトに投げていいか皆さんの方であのを守っていただければと思いますね
ライブラリー的なとかのヘルパー的な関数であれば全然まあ問題ないと思いますけど コアなところのソースコードをそこに貼るのは危険だと思うんでそこは気をつけて
くださいって感じですね まあなかなかバベルは今後もうちょっと使うと思いますね
IEが死んでくれたのでESXが全部ラウザーデフォルトで使えるようになってくると思うので そこをするとバベルがどこまで使うかっていう話は別で出てくる気はしますが
まあこのここの辺はでもやっぱり意識した方がいいなと思いますね やっぱりそのクラスを使うと基本的にやっぱりサイズ被害化するってのはよくある話だし
21:00
パフォーマンス的には良くないのでそもそもあんまりクラスは使わない方がいいよねって 話はそもそもあったりしますけど
でえっと今40分ですねはいまああともう5分ぐらいですかね やりたいと思います
ではさっきのが javascript 編でしたでは続いて html CSS などのリソース編の話になります
では一つ目ですけどイメージとかアイフレームとかリンクタグですね などにインポータンス属性を追加しましょう
インポータンス属性 あんまり意識して使ったことないんですけど
イメージとかアイフレームリンクタグなどでインポータンス属性を使うことで ブラウザーに読み込みの優先度というのを指定できますと
ああそういうことなんだはいはいはい タグだけでなくフェッチ関数でもオプションでインポータンスを指定できたりしますよということです
なんか海外の方がツイートしてますけど プライオリティヒンツでヒンツザインポータンスオブリソーシーですね
ローはハイプライオリティだと言うですね4オプティマルローディングですと なるほどローディングがまあ最適化されるということですね
アンオンラインリリテイラーリポーティッドアズあ 4%ファスター lcp トライングいたら lcp 4%速くなるんですね
インポータンスをつけるだけであこれちょっと地味 地味に効果ありますねへーなるほどでした
まあこの記事内でそのツイート自体もあのリンクされてますのでこのツイートを見て みてください
あのソースコード自体もあのツイートの中で画像パッと貼られているので いやいやいやなのでインポータンスの中にそのハイとローっていうのがつけられるそうですね
あの html の属性の中にインポータンスイコール 文字列でハイか文字列ローっていうのをつけておいて優先度を指定することができるとこれのあの
つけ方によって lcp は早くできますよってことでした
であとちょこれに関して追記がありましてインポータンス属性はフェッチプライオリティ 属性に変換されましたそうなんや
名前変わったそうですねでまたフェッチ関数を使う場合はえっとプライオリティ プロパティを指定することができるようになりますという感じですね
8 html タグの方はのフェッチプライオリティイコールローとか入っていうのを指定してくださいと であのフェッチ api ですねブラウザのヘッピーテッチ api を使う場合はフェッチの第1
引数にエンドポイントに言われる第2引数にオブジェクトでプライオリティ コロンまあローとか入っていうのを指定するとフェッチの方でもそれが有効できますよってことですね
なるほどしたなるほど これはちょっと意識的に僕も使っていこうかなと思いますね
インポータン属性全然ストイ意識したことなかった名前だけしか知らなくて調べたこと すらなかったのでこれは勉強になりました
続いてえっとイメージや i フレームタグにローディング属性を追加するとさらにまだもう1個 別の属性ですね
はいえっと img ですねイメージタグとか i フレームタグにローディング属性を使うことで読み込みのタイミングを 指定できますと
もしえっと遅延だったりとか非同期読み込みをしたい場合はローディングイコールレイズイと 使うと良いでしょうと
またはしファーストビューに使うと帰って読み込みが遅くなる可能性もあるので待ちを 用意しましょうということですね
はいなるほどしたまま名前通りレイジーをつけるとまあ遅延の読み込みができたりする ということですね
24:01
でもまあ書いてある通りですけどまぁファーストビュー使うとというところがあるんでまぁレイジ ローディング周りのところは使っているフレームワークとかあのサードパーティーのエコ
システムに依存するっていうのも一つの手かもしれないその辺のことを考えた上で あのそういうツールというのが作られているはずなので
レイジローディング周りのライブラリーっていうのを使う方がまだいいのかなでも ブラウザー標準でそういうのを用意されているのであればそっちも検討したいとこ
はありますし中身は実はこういうのを使っているかもしれないですけどね では続いて8イメージタグに
ディコーディング属性ですねっていうのを追加してみましょうと イメージタグっていうのはそのディコーディング属性を使うことでデコードを同期非同期に
読み込むかを指定することができると デコードイコールエーシンクってのを指定すれば非同期にデコード処理をブラウザーに指示できる
と あーこれも地味にありがたいですねなるほどねデコード処理っていうのを実は非同期的にやることが
指示できるんですね 続いてイメージタグにはサイズを指定しておきましょうとこれはなんかまあ知ってるかも
商法だな イメージタグのウィズとハイトですね属性を使って画像のサイズを指定しておきましょうと
ブラウザーのレンダリングを助けになりますしCLSの改善にもつながりますと 分からない場合はとりあえず大体のサイズを指定しましょうということですね
まあこれは指定するとしないので大きく話は変わってくるので あのつけておいたほうがいいよってお話ですね
まあでも普通にスタイリング周りとかあの画像サイズっていうのはCSSで指定するときも ありますけどイメージタグである程度
絞っておくの一つ大事な話ではあるので これはやっておくといいかなと思いますね
では続いて優先度の高いリソースっていうのはリンクタグにプリロードを指定しましょうと
ファーストビューに表示する画像など優先度の高いリソースっていうのがあると思いますけど そういうリソースはそのリンクタグのREL属性にプリロードを指定することで
早い読み込みが実は期待できますというところです ちょっと詳しい話に関してはそのMDNのリンクが貼られているので
そっちのほうを見てみてくださいという まあなんかもうあれですねMDNを一回ガーッと読んでいくとそのパフォーマンス周りのところが
意外と改善最適化されますみたいな情報が得られる可能性があるんで ひたすらMDNを読む回っていうのも面白いかもしれないですね
はいというところで途中と半端ですけど一旦ここで30分になりましたので朝からは区切ろうと思います まだまだ続くと思うのでこれは明日も引き続き
読んでいこうかなと思っておりますのでもし興味あれば参加してみてください この後ですねこの今日読んだ記事のリンクもツイートしますので
まあ興味ある方はそもそも本記事をですね読んでみていただければなと思います ではですね今日は冒頭申し上げましたこの後ですね12時13時から
PWAナイトカンファレンス2020が開催されます 今回も結構ビッグな名前の方々がご登壇いただきますしフロントエンド周りの
いろんな情報が得られると思いますので興味ある方は参加してみてください はいでは朝勝コーチだって終了したいと思います土曜日ですね
ゆっくり休んでいただければ幸いですでは終了しますお疲れ様でした
