00:05
PWA Night Conferenceが無事開催されましてですね、
とどこおりなく終わったんですけど、本当にとても素晴らしい話だらけで、
やっぱり勉強会、カンファレンスっていいなぁとつくづく思いましたし、学びが本当に多くてですね、
あとやってみたいとか、すごい技術的なモチベーションがめちゃめちゃ上がったので、
YouTubeでも公開されてますので、皆さんぜひぜひ見てみてください。
特に僕のおすすめはやっぱり昨日とですね、貴重講演、すごく良かったので、
フロントエンドエンジニアなら一度は聞いても損はないような講演ですので、
ぜひ聴いてみてください。はい、おはようございます。ひめめのkeeth古属版ハラです。
では、本日も朝活を始めていきたいと思います。
で、タイトルありますとおり、昨日に引き続き、
Webフロントエンドパフォーマンスチューニング70選という聞いたの記事があるんですけど、
もうすでに、イーネス1288というもう素晴らしい記事だったんですけど、
70個もありますけど、やっぱりパフォーマンス周りって僕も全然まだ勉強中ですので、
これすごく勉強になるなと思って読んでました。はい。
では、昨日に引き続き、今日もこの記事の途中からですけど、
読んでいこうと思います。
昨日はですね、JavaScript編がガーッと読みまして、終わりまして、
で、今日からHTML、CSSの、CSSリソース編が若干入ったんですけど、
ざっくりタイトルだけいくと、HTML、CSS編のだけでいくと、
まずはイメージタグやiフレーム、リンクタグなどにインポータンス属性を追加しましょうとか、
イメージタグ、iフレームタグにローディング属性を追加しましょうとか、
イメージタグにリコーディング属性を追加しましょうとか、
イメージタグにサイズを指定しましょうとか、ウィッツとかハイトとかを指定しましょうとか、
優先度の高いリソースはリンクタグにプリロードをつけましょうとか、
優先度の高い外部ドメインへのアクセスがあるときはリンクタグにDNSプリフェッチとかプリコネクトっていうのを指定しましょうとかですね、
この辺まで読んでいたような気がします。
では今日はその続きからいきたいと思います。
読んでたけど、今言ったDNSプリフェッチ、もしくはプリコネクトを指定するっていうところは、
昨日読んだかちょっと不安なので、改めて、今日はここから行こうかと思います。
はい、じゃあ改めていきますね。
優先度の高い外部ドメインへのアクセスがあるときっていうのはリンクタグにDNSプリフェッチまたはプリコネクトっていうのを指定してみましょうと。
外部ドメインからリソースを取得したりとか重要度の高い外部リンクを設置している場合などは、
リンクタグのDNSプリフェッチやプリコネクトっていうのが使えます。
DNSプリフェッチはDNSプリコネクトっていうのは事前接続まで行ってくれますと。
かなり優先度の高い外部ドメインへのアクセスはプリコネクト。
少し優先度が落ちる場合はDNSプリフェッチを使うと良いでしょうと。
詳しいことは詳細のところに関してはそのMDNを見てみてくださいということでした。
では続いて、ユーザーがよく遷移するページっていうのはリンクタグにプリレンダーと指定しましょうと。
リンクタグのREL属性にプリレンダーを指定することで、ブラウザーを指定されたページをバックグラウンドでレンダリングします。
03:03
なのでユーザーが指定されたページへ遷移するときはすぐに画面が表示されますと。
ユースケースとしてランディングサイトのようなページで1のページへ遷移するユーザーが多いので、
プリレンダーをしておくと良いかもしれません。
ただしレンダリングされる都合上、ブラウザーへの負荷が高かったり、
JavaScriptを差し込んでいる計測処理が発火するなどの注意が必要です。
ここは想像ですよね。
結局はレンダリング処理をしていることには変わりないので、その辺の考慮はやっぱり必要だよねってところなので。
ここはちょっとテクニカルな使い方になる気がしましたね。
いわゆる先読みというかプリレンダーの仕組みというパフォーマンスの観点ではすごく大事ですので。
システム的というよりもユーザー体験として速い、サクサク表示されるところの体験としては重要だと思いますけども。
では続いていきます。
続いてはスクリプトタグにDiffer属性だったりAsync属性を追加しましょうというものです。
ブラウザでスクリプトが読み込まれるとHTMLやCSSの解析がブロックされますと。
このような問題を解決するためにはDifferであったりとかAsyncみたいな属性が付けられます。
DifferはHTMLやCSSの解析をブロックすることなくスクリプトを読み込んでおいて、解析が完了したらスクリプトを実行しますというものですね。
AsyncはHTMLやCSSの解析とは独立してスクリプトの読み込みを実行します。
聞いたのこの記事がわかりやすいですと。
別の記事のリンクが貼られていて、スクリプトタグにAsync、Differを付けた場合はタイミングみたいな記事がありますね。
続いて優先度の高いリソースの読み込みはできるだけHTML上部で定義しましょうというものです。
ブラウザはHTMLドキュメントの上から解釈をしてきますので、例えば同じプリロードを指定するリソースでも、
さらに優先度の高いものはよりHTML上部に定義して早めにブラウザが読み込めるようにしましょうと。
これは地道なテクニックの一つですけど、早く指定されれば早く読み込まれて早く解析されるというところなので、とにかく上に書くのがいいよという話でした。
続いて、CSSで余計なセレクターを書かない。
ブラウザはそのCSSセレクターを右から左に解析します。
CSSセレクターを右から左に。
ですので、できる限り単一のクラス名やIDで指定した方が解析のスピードは上がります。
ブラウザでそのすべてのdivタグを探して、
例えば、CSSのクラス名が.hogue.div.〇〇とか、
CSSの書き方をしていた場合と、
.hogue.〇〇と、
シャープですね。
ID属性がシャープ、ホゲ、イコール、〇〇〇みたいな。
というようなCSSの書き方をしていた場合、
前者の方、.hogue.〇〇みたいな感じで、
詳細度が上がれば上がるほどピックアップは確実になりますし早いですけど、
ただ解析のスピードが遅くなるので、
ベストプラクティスとしては単一のクラス名、
クラス名一つのセレクターにしてあげるのがいいよということでした。
06:00
余計なセレクターを書かない方がCSSの解析スピードが速いよという話でした。
では続いて、スタイル属性を使って直接スタイルというのを指定しましょう。
クラスなどセレクターを指定してCSSを書くよりも、
直接htmlタグのスタイル属性を使った方がブラウザの解析は速いです。
ただしコードの過属性やメンテは厳しくはなりますよということでした。
これも確か僕の記憶上間違っていなければ、
属性は直接確保が速いはずです。
いわゆるCSSの読み込みと解析みたいなところが一段階、
仮定が減るので、直接確保が速いよねっていうところです。
なのでCSS in JSとかも確か思想的にはそれと似ているというか、
CSS in JSはJSで全てを関連されることで、
JSの変数とCSSのスタイリングを一色単にできるというのが一つのメリットでありますし、
スコープをしっかり絞れるというのがもう一つのメリットですね。
ただもう一個裏のメリットとしては、
確かビルドするときにCSS in JSって結局は、
htmlタグ直接にスタイル属性として、
htmlタグに書き込まれるはずなので、
それが一つ速い理由だった気がします。
確かに過属性のメンテは厳しくなるので、
やっぱりCSS in JSでやるのが開発体験としてもいいんじゃないかなと思ったりはしていますが、
一方で最近CSS in JSの風当たりが強いらしくて、
CSSモジュール図がもう一回盛り上がってくるんじゃないのっていう話もされたりしていて、
なかなか難しいところですね。
ただパフォーマンス観点で言えば、
スタイル属性を使って直接スタイルを書く方が速い。
そうなるようなビルドをされるCSS in JSの方が僕は速いんじゃないのかなと思ったりしていますが、
ちゃんとこの辺を解析したりとか、
自分で計測したことがないので、
この辺をちゃんといつかやりたいなと思っております。
余談でした。
続いて、不要なCSSを削除しましょうということです。
これはもうそのままですね。
使っていないCSSは削除しましょうと。
Chromeのデベロッパーツールとかを使うと、
実は不要なCSSを洗い出すことができるんですね。
最近、CSPを作ることによって、
一つのhtmlファイルしか作らなくなったんですけど、
ちゃんとチャンク分けとかをしないと、
全ページで同じCSSをガンと読み込むみたいな、
バンドルされた一つのCSSを読み込むので、
このページでは使ってないよねっていうCSSがたくさんあったりするので、
結局そのページ自体のレンダリングが遅いじゃんみたいな話が出たりするので、
チャンク分けをしっかりするか、
そもそも使ってないCSSをしっかり洗い出して削除するのがいい話だなと思います。
Chromeのデベロッパーツールって、
実はCSS使ってないものって見えたりするんですよ。
何パーセントみたいな確か数字が出たと思うので、
この辺を使ってみてください。
続いては不要なJavaScriptを削除しましょうと。
CSS同様、JavaScriptを削除しましょうとですね。
例えば、コンソールログってのは基本的にはプロビジョン、
プロダクションのコードでは不要なんで、
ESLintで検出するなり、バベルで削除するなりしましょうと。
これ、昨日読んだ範囲の中で、
確か不要なインポート文を削除しましょうみたいなやつですね。
インポート文使ったはいいけど、
結局インポートしたモジュールを使わなかったら、
09:02
それは単純にファイル被害化にしかならないので、
デメリットしかないからそれは削除しましょう。
そういうのもESLintのプラグインの中にオプションで
弾けるやつがあるので、それを使いましょうみたいなことですね。
とにかく不要なものは削除しましょうというお話でした。
では続いて、
ファーストビューに影響のあるCSSは、
ヘッドタグの先頭で読み込みをしましょうというふうなお話です。
JavaScriptと違って、
ブラウザーのCSSの解析っていうのは、
HTMLの解析をブロックはしませんと。
ファーストビューで読み込ませたいCSSは、
できるだけヘッドタグのしかも先頭に読み込ませておいて、
早くスタイリングされたファーストビューを
ユーザーに見せるようにしましょうと。
この辺もテクニカルなお話ですけども、
地味にやっといて損はないなというものですね。
では続いて、
ファーストビューに影響のない方のCSSというのは、
ボディタグの末尾で読み込みましょうと言っています。
逆にファーストビューに影響のないCSSは、
ボディタグの末尾ですね。
読み込ませることで、
ブラウザにCSSの読み込みを逆に遅らせるということですね。
遅延させましょうということです。
遅延の方法は他にもいっぱいありましたし、
テクニックってあるんですよね。
優先度を決めるみたいなタグがあったりするので、
それを使ってもいいですけど、
なんだかんだボディタグの一番下にある方が、
最後に解析されるのでいいんじゃないのという話ですね。
先ほども言った通り、
ブラウザはHTMLを上から下に解析していくので、
ボディの一番下にある方が、
読み込みの解析のスピードが、
一番最後まで遅らせることができるので、
こういうテクニックもありかなと思いますね。
では続いて、
JavaScriptはボディタグの末尾で読み込みましょうということです。
ブラウザはJavaScriptの解析を始めると、
HTMLやCSSの解析をストップします。
いわゆるブロッキングしますということですね。
なのでJavaScriptはボディタグの末尾で読み込んで、
HTMLやCSSの解析が終わった後のJavaScriptを解析するようにしましょう。
これは上等手段というかよくやるやつですね。
ただしGoogleアナリティクスなどの解析用のJavaScriptというのは除きます。
それはそうですよね。
あの辺はJavaScriptの処理というよりも、
ページがレンダリングされてからスクリプトを開始したりとかあるので、
この辺はボディの一番後ろでやっても動くものもあるんですけど、
ヘッダーにつけていく方がいいよみたいなものもあったりするので、
何を解析するかによるかもしれないですね。
解析させたいものによっては別に後にしてもいいかもしれないですけど、
この辺はしっかりチェックしましょうというお話でした。
では続きまして、
HTMLやCSS、JSをミニファイもしくはバンドルしましょうというところです。
これはもう言わずもがなって感じで、皆さんやってると思いますね。
WebpackとかSWCなどのバンドラを使って、
最終的には一つのファイルにバンドルしましょうということですね。
では続きまして、
JavaScriptのトランスファイルを最新のESに合わせましょうということです。
もしJavaScriptをES2015でトランスファイルしている場合は、
それよりも最新のバージョンでトランスファイルすることによって、
JavaScriptのサイズを落とすことができます。
12:00
ただし、IEといった古いプライザーを切り捨てる覚悟が必要です。
そうなんよ。最新のバージョンのESの方がJavaScriptのサイズを落とせるんですね。
それは知りませんでした。
単純にトランスファイルするだけじゃなくて、
トランスファイル後のソースコードが小さくなるんですね。最新の方が。
やっぱり技術の進化でそういうところもしっかり見て、
ES周りというところは成長し続けているんですね。
ちょっと知りませんでした。
では続きまして、続いては画像周りの話ですけど、
画像はWebPやAVIFを使いましょうという話です。
次世代の画像フォーマットとしてWebPやAVIFというものがありますが、
これらの画像フォーマットを使うことで、
従来のPingとか等の形式よりも画像サイズを縮小できたりします。
IKEAではそのAVIFによって画像の転送量を21.4%削減した例もあります。
すごいですね、IKEA。
IKEAみたいな一時サイトってもう画像だらけだと思いますので、
その画像の転送量を21.4%削減って結構インパクトあったんじゃないですかね。
へー、なるほどでした。
WebPとかは普通に使ったりしますけど、
AVIFは僕はあんまり使ってなかったので、
これもちゃんとチェックして使い方とかしっかり勉強しなきゃなという。
これちょっとやらなきゃいけないなという気がしましたね。
はい、ありがとうございます。
では続きまして、画像サイズを縮小しましょうという話です。
画質を落とすなり幅とか高さを小さくするなりして、
画像サイズを縮小させましょうと。
例えばSVGでは作成したツールによってはコメントアウトが残っていたりで、
最適化されずに出力されている場合もあったりするので、
手動で作業するなりツールを使うなりで縮小させましょうというところです。
これはそうですね。
とにかくサイズが小さければ速くなるというのはその通りだと思うので。
はい、では続いてもう一個画像の話。
画像をインライン化しましょうということです。
インライン画像としてHTMLに直接埋め込むことで、
画像のリクエスト数を抑えることができます。
ただし画像サイズが大きくなったり、
ブラウザのキャッシュが効かない等のデメリットはあったりします。
画像サイズが小さく一度しか埋め込まれない場合などに有効と言われています。
現代はキャッシュ周りのお話がすごく重要で、
昨日のPWAカンファレンスの講演の一つに何回もやりました。
ウェブパフォーマンスのお話が結構あって、
BFCacheというものが今後すごく重要だなというお話をされていまして、
僕もそれを聞いたと確かに思ったんですね。
BFCacheというのはバックフォワードキャッシュの略だったと思っていて、
進む戻るみたいなやつですね。
ユーザーがアプリケーション内で戻るボタンとか用意したりすると思うんですけど、
ブラウザそのもののバックとかを使ったりするってどっちが多いかというと、
結局はアプリケーション内のボタンの方が多いんですけど、
一方でブラウザバックとかブラウザの進むみたいなやつってどれくらい使うかというと、
意外と15%以上の使用度があったっていう話を、
昨日そのYahooの方がおっしゃっていて、
結構バカにならないなっていうところがあるんですよね。
というところで、意外とキャッシュ周りの話って今後もすごく重要ですし、
15:00
キャッシュから早く読み込ましたり早く表示するっていうのは、
ユーザー体験にとってはすごくいいことであるので、
インライン化するかっていうのは結構重要かなと思ったりはしますね。
ただでもやっぱりリクエスト数を抑えることができるんで、
初期レンダリングのスピードは絶対インライン化した方が早いんだろうなっていう気はするので、
どっちを使うかという感じですね。
では続きまして、課題なDOMを避けましょうというところです。
DOMが多すぎるとブラウザの描画に負担をかけてしまいますので、
不要なDOMを削除するのはもちろん遅延読み込みとか仮想無限スクロールとか、
使用してユーザーに表示されている部分だけを描画することで対策できますと。
いわゆるディレイチローディングしたりとか、
とにかく表示されている画面の枠ないだけのものだけをまず表示させて、
スクロールしたりして初めて読み込みをしたりとかする方が早いよねってことですね。
一度にとにかくでかいDOMをブラウザとかに渡すと、
ブラウザが深くかかってしまうので、結果もっさりしたりするので、
遅いよねって話にはなるんですよね。
ここはDOMを小さくするっていうのも大事ですけど、
そもそものシステムとかアプリケーションの設計のところで、
いかに情報量を減らすかっていうのも結構大事だと思いますね。
情報量が多いから結果表示するためのDOMが増えていくのは間違いないので、
ちゃんと情報設計を最初にするみたいな話はすごく重要かなと思ったりしています。
では続きまして、
サードパーティースクリプトの読み込みにはパーティータウンを使いましょうという話です。
これも昨日のパフォーマンス概念の講演の中にも確かにあったんですよね。
これ何かっていうと、
Google Analyticsのような分析だったり、
Google AdSenseのような広告などですね、
いわゆるサードパーティーのスクリプトをサイトに貼っている人は多いと思いますけど、
このようなサードパーティースクリプトっていうのは、
ブラウザのメインスレッドの処理を妨げることがあります。
この記事の執筆現在ですけど、まだベータ版ではありますけど、
パーティータウンというライブラリーがあります。
詳しい仕組みというのは割愛しますし、
使い方に関しては公式サイトにしっかり書いてあるので、そこを見てみてください。
要は何かというと、
パーティータウンによってサードパーティースクリプトの読み込みを、
いわゆるウェブワーカーに移情するんですね。
バックグラウンドでワーカーに渡してあげて、
そっちで処理をすることで、
メインスレッドの負荷を軽減させることができるよっていうようなものなんですね。
これ結構厚いものですよね。
結構アナリティクス系とかそういう解析タグ、リターゲティングタグとかを使っている
ECサイトって本当にたくさんあると思うんですけど、
初期レンダリングが遅い理由って、
大体その解析タグの処理だったりすることって結構あるんですよ。
なのでこの辺をウェブワーカーに移情することができて、
メインスレッドは本来のアプリケーションのレンダリングだったり描画ってところに
重きを受けるっていうのはすごく大事な話なので、
まだまだベータ版ではあるんですけど、
とはいえやっぱりこのパーティータウンですね。
結構重要視して、全然いいと思ったりしてます。
僕も昨日久しぶりにパーティータウンの名前聞いたんですけど、
それぐらいちゃんとヤフーの方がおっしゃられるぐらいには
結構これ使えるんだってところで、結構気にしていこうかなと思いました。
では続きまして、続いては
特定の文字のみGoogleフォントを使っている場合は
テキストパラメータを使いましょうということです。
もしあなたのサイトで特定の文字の装飾のために
18:00
Googleフォントを読み込んでいる場合は
テキストパラメータに装飾したい文字だけを指定することで
パフォーマンスを上げることができますよと。
これもTwitterのツイートリンクが貼られているので
もし興味ある方はこのツイートリンクを見てみてください。
そこでどういう使い方をしているかというのが書いてありますので。
ざっくり言うと読み込みするときの
https://fonts.googleapis.comみたいなので
まずドメインを指定して
その後ろの方にいろんなものを指定するんですけど
クエリの最後に&text="about="みたいな感じで
このテキストだけを装飾したい場合は
そういうテキストそのものを指定しましょうということですね。
これによって、場合によってはですね
Googleフォントサイズの読み込みの
90%をカットできるよという風に言っていますね。
それはすごいね。90%カットかなりデカいですね。
はい、というところでした。
意外とフォントファイルの読み込みって意外と重いですからね。
では続いて
CSS Containmentというのを活用しましょうと。
JavaScriptでDOMを挿入するように
DOMの構造が変わることで全体のスタイリングの再計算が走ります。
そうなのよね。
DOMの変更があると
JavaScript自体は処理を
仮想DOMとか使っていれば
変更したところだけ再レンダリング、再描画する
書き換えをするので
簡単かもしれないですけど
結果でもDOM自体が変わると
CSSの再計算は結局走ってしまうので
そこの処理自体はやっぱり重いんですよね。
なんですけど
CSSのContainmentを活用することで
ある箇所でDOMの変更があっても
他の箇所のスタイルの再計算を走らせない
みたいな制御ができるようになりますと。
これは厚い。かなり厚いですね。
全然知りません。
CSS Containmentってのがあるんですね。
JSDSの仮想DOMみたいなことの
CSSで同じようなことができるってことですよね。
特定の変更の箇所だけ再計算させる
ってことができるのは厚いですね。
では続きまして
リダイレクトを避けましょうという話です。
Aタグだったらイメージタグなどを
ブラウザからリソースを取得する場合ですね
できる限りリダイレクトが発生しない
URLを設定した方が
リソースの取得が早くなりますよってことですね。
書き方として
イメージタグがあって
ソースイコールURLみたいな書き方をするんですけど
例えば
www.test.com
イメージーズ.ホゲ.png
みたいなやつの書き方をするのではなくて
test.com
イメージーズ.1234.ping
みたいな感じですね。
例えばそのwww.というのを外すとかですね
こういうことをすると
リダイレクトが結局しているので
それの処理が一段階ちょっと早くなるよってことでした。
よくやることですね。
正確なURLで書くのであれば
www.test.comみたいな書き方をするけど
結局そういったリダイレクトをするので
test.comでよいじゃんっていう話ですね。
これは確かにその通りだと思うので
これもすごい地味なテクニックでありますけど
細かいところでこういうのをやるのも大事だなという話でした。
続いて
画像を使わずHTML、CSSでアイコンを表示しましょうという話です。
複雑なアイコンでなければ
インラインでSVGを埋め込んだり
外部から画像をリクエストせずに
HTML、CSSを使ってアイコンを表示できたりします。
例えば例としてハンバーガーボタンとか言ってみます。
21:02
ハンバーガーボタンは次のようなHTML、CSSで作成できますというところで
ソースコードがバーっと張られています。
ボタンのタグがあってその中に
例えばハンバーガーボタンみたいなクラス名が指定されたとしましょう。
その中にリブタグでクラスバーみたいな
適当なリブタグが1個ボタンの中に挟まれているとします。
そのバーのところをCSSでわーっといろんなものを書いて
そのハンバーガーボタンを実装したとしますね。
そうするとハンバーガーボタン用の画像とかSVGアイコンを読み込むよりも
結局CSSとかの解析の方が早いよねという話なので
その方がいいんじゃないのという話でした。
複雑なものじゃなければというところですね。
これは確かにそうですね。
画像の読み込みが一番遅いというのはよくある話なので
ブラウザーの解析だったりパフォーマンスを上げるんだったら
画像を減らすというのはすごく大事なお話ですね。
では最後はHTMLとCSSの項目のラストの話です。
ビフォーアやアフターの擬似要素を使って
とにかく不要なドムを作らないことが大事ですよということでした。
擬似要素のビフォーアやアフターを使えば
必要以上のドムの作成というのを抑えることができます。
戦術の画像を使わずHTMLとCSSでアイコンを表示する
1個前のお話ですね。
のハンバーガーメニューをやっぱり例にもう1回挙げますと。
でも擬似要素を使わない場合は次のようなHTMLになりますということで
さっきのようにボタンタグがあって
クラスにハンバーガーボタンみたいなのを付けておく。
その中にDIVタグですね。
ハンバーガーなのでバーが3つぐらいあるとしますね。
DIVでクラスバー1バー2バー3みたいな感じで
DIVタグ3つ挟むというのはよくやるやり方ですね。
このように装飾のためにDIVを作成する必要があるんですけど
一方で画像を使わないで
HTMLとCSSでアイコンを表示するような感じでお話をすると
いわゆる擬似要素を使うとビフォーアとかアフターを使って
DIVタグを減らすことができると。
DIVをとりあえずクラスバーに1つに絞っておいて
ビフォーアとアフターの方でそのコンテンツをガンと入れるという感じですね。
要はCSSで全部やってしまうというところですね。
すればDIVタグ1個に抑えられることができるので
結果ブラウザに解析されるDOMの量も減るというところですね。
結果そのHTMLファイルのサイズの削減にもつながりますと。
CSSはその代わりちょっと増えるんですけど
結果ミニファイするので文字列にしてもそんなに豪華にならないから
ブラウザとしては問題ないよということですね。
チリツモとはいえですけど
画像よりはCSSの解析の方が早いよという話ですね。
あとはコードの可読性を高めたりとか
SEO対策ですね。
直接的にそのページのコンテンツに関係ないものを省けて
適切なコンテンツ評価につながるというようなメリットもあるので
SEO観点で結局DOMの数とかDOMの話になってくるので
不要なDOMを避けることでよりSEO周りのところの対策ができる
確かにその通りだと思いました。
ではちょっと早口で申し上げなかったし
駆け足だったんですけど
今日の朝勝はここで一旦区切らせていただいて
ちょっとまだ長いんで
この記事は明日に続きます。
明日からはですね
ブラウザAPI編のパフォーマンス改善のテクニックの話に
入っていこうと思いますので
興味ある方はまたご参加いただければと思います。
では今日はですね
プテラドドさんですね
ご参加いただき大変にありがとうございました。
24:01
また明日も緩く読んでいきますので
参加していただけると幸いです。
では日曜日ですね
今日も一日ゆっくり休んでいただければなと思います。
それでは朝勝終了したいと思います。
お疲れ様でした。
