ブラウザ
画面が描かれる仕組みと、その上の制約
ブラウザは HTML を受け取ってから描画するまでに決まった工程を通る。どの CSS プロパティを触ると工程のどこからやり直しになるか、なぜ非同期処理が「詰まる」のか。そして、そこに被さる同一オリジンという安全装置。
読み終わると、これに答えられるようになります
- ?top を書き換えると重く、transform だと軽いのはなぜか
- ?重い処理中にクリックが効かなくなるのはなぜか
- ?CORS エラーはサーバーとブラウザのどちらが出しているのか
レンダリングパイプライン — どのCSSが重いかは工程で決まる
ブラウザが HTML を受け取ってから画面を描くまでの工程。どのプロパティを触ると、どの工程からやり直しになるのか。
スクロール連動アニメーションで top を毎フレーム書き換え、スマホで完全に固まった
イベントループ — 1本のスレッドで待たずに捌く
JavaScript が1スレッドなのに、なぜ複数の処理を同時に進められるのか。そして、なぜ「重い処理」が画面ごと止めるのか。
10万件の配列を同期でループし、その間ボタンもスクロールも一切反応しなくなった
同一オリジンポリシー — ブラウザが最初から持っている壁
なぜ他のサイトの JavaScript から自分のページのデータを読めないのか。この制約がなければ Web はどうなっていたか。
iframe で埋めた別ドメインの画面を JS から操作しようとして、原因不明のエラーで1日溶かした
CORS — 壁に穴を開けるのは「読まれる側」
プリフライトはなぜ飛ぶのか。ワイルドカードと Cookie が同時に使えないのはなぜか。エラーメッセージから原因を逆算する。
CORS エラーを直そうとフロント側の fetch オプションを1日いじり続けた
ブラウザのストレージ — 読めるか、と、送られるかは別の話
Cookie / localStorage / sessionStorage / IndexedDB を容量ではなく「誰が読めて、いつ送られるか」で分ける。認証情報の置き場所を決めるための判断軸。
アクセストークンを localStorage に置き、外部スクリプト経由で持ち出されて8時間なりすまされた
Core Web Vitals — 数字を上げるのではなく、何が遅いかを特定する
LCP・INP・CLS は原因ではなく症状の分類。3つが何の代理指標なのかを知ると、直す場所が工程の中で決まる。
LCP の数字だけを追って画像を軽くしたが、遅さの原因は別の工程にあった