フロントエンドのパフォーマンスチューニングを俯瞰する - 30歳からのプログラミング

去年からフロントエンドのパフォーマンスについて断続的に学んでいるが、自分の頭のなかにある知識はどれも断片的で、まとまりを欠いているような感覚があった。 知識と知識がつながっておらず、各施策が何のために行われるのかも、必ずしも自明ではなかった。何となく「パフォーマンスに効果がある」と言ってしまうが、それが何を指しているのかは実は曖昧だった。 このような状態では新しい知識を得ていくのが難しいというか、効率的に行えないように思えた。議論の背景が分からないし、文脈や問題意識を上手く掴めないから。何の話をしているのかよく分からない、という状態になりがち。書かれてあることの意味は分かっても論旨を掴めているわけではないから、自分のなかに定着しない。 そこで、現時点で自分が知っていることを整理して、自分なりに分類しておくことにした。 当たり前だが、どのテクニックがどの程度有効なのかは、状況によって違う。

[nmcli]

費用対効果考えると最近はいかにCDNに頼るかのことばっかり考えてる

[lirlia]

なんかこう、やりたいことシンプルなのに気にすべき観点が多すぎて無駄が多いというか、大変だなあというか。みんな一様に困ってるのだからブレイクスルー来てくれないかって気持ちで眺めてるり

[h5y1m141]

良いまとめだ！後半のレンダリング部分以外の所は、現在読書中のWeb配信の技術という書籍（https://www.amazon.co.jp/dp/4297119250）の内容に通じる気がするなぁ。

[ledsun]

解決したい問題ごとにまとめると良さそうな気がするなあ

[hatest]

チューニングする前に、どこがネックになっているかのあたりを付ける効率的な方法が知りたい

[ustam]

画像はWebPが圧倒的に軽いよ。

[akymrk]

“ブラウザがページをロードしレンダリングするために行う一連の処理のことを、クリティカルレンダリングパスと呼ぶ。”"Forced Synchronous Layout が頻発している状態を、Layout Thrashing という"

[waicode]

リソースを速く取得する、ページを速く構築する、快適な UI を実現する。見出しのまとめがうまい。

[efcl]

パフォーマンス改善での良く見るポイント

[Houhei2021]

ブックマークさせていただきます。

[shingo-sasaki-0529]

良いまとめだ。全部覚えて実行すると言うよりは、ボトルネックを見つけて、そこへのアプローチに何が考えられるかという段階で見返すと役立ちそう。

[Phenomenon]

前提としてボトルネックを探そうねっていうはなしなんだろうなあ

[d4-1977]

全体像がつかみやすくなる話！（ウェブフォントはファイルサイズが大きく、ダウンロードに時間がかかりやすい。また、レンダリングツリー（構築された DOM ツリー CSSOM ツリーから作られる）が完成してからリクエスト）

[northlight]

よい

[n314]

ライブラリとか構成とか考えるの大変だからClosure Toolsに頼ってる。

[RyotaTakimoto]

大変そう

[gyochan]

「適切なサイズの画像を使う」クライアントサイドでもデバイスの解像度にあわせてリクエストする画像を変えたりできるようになってきてますね https://developer.mozilla.org/ja/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images

[arapro]

メモメモ

[ogawa0071]

増田デザイン

[Dragoonriders]

フロントエンド界隈伏魔殿の如し／こんなチマチマ優先度を決めないといけないのめんどくさいだけでAIにやらせるかhttpなんかやめちゃえばいいと思った（暴論）

[buzztaiki]

計測せよ。

[hamamuratakuo]

Layout Thrashing を防ぐ　Forced Synchronous Layout が頻発している状態を、Layout Thrashing という。JavaScript コードのロジックを見直し、レイアウト情報の更新と参照が繰り返されないように修正する必要がある。

[tossy_yukky]

やっていき

[mayumayu_nimolove]

いいまとめ

[nekoruri]

良い整理