Skip to main content

browser

ブラウザの仕組みやセキュリティ、Tipsなど

Next.jsで高パフォーマンスにする

ブラウザの仕組み

ブラウザはすべてのリクエストにOriginヘッダーを追加する。
リクエストがサーバーに届くと、リクエストのオリジンがリソース取得許可リストに含まれている場合に、サーバーが Access-Control-Allow-Origin ヘッダーをレスポンスに追加する。 この情報からブラウザはコンテンツがこのオリジンにアクセスできると判断する。

同一オリジンポリシー

リファレンス

同一オリジンポリシーは重要なセキュリティの仕組みであり、あるオリジンによって読み込まれた文書やスクリプトが、他のオリジンにあるリソースへアクセスできる方法を制限するもの。

オリジンの定義

2つのページのプロトコル、ポート番号(もしあれば)ホストが等しい場合、両者のページは同じオリジンとみなす。

参考URL リファレンス

ブラウザの仕組みについて記載する。

同期処理はブラウザはしてほしくない

同期的にブロックする処理があると、ブラウザでは大きな問題となる。 JSは基本的にブラウザのメインスレッド(UIスレッドとも呼ばれる)で実行されるため。 メインスレッドは表示の更新といったUIに関する処理も行なっているためメインスレッドが他の処理で占有されると表示が更新されなくなりフリーズしたようになる。

session(セッション)

  • セッションIDの**生成方法はHTTPの仕様として定まっていない。**サーバー側の実装に依存する
  • セッションはWebサーバ側で保持する(セッション情報はDBやファイルなどで管理・保持する)

ブラウザ側ではCookie(クッキー)にセッション情報が保存されます。Cookie以外の方法もありますが、現在ではCookieを利用するのが主流です。 またCookieに保存するセッション情報は詳しい個人情報などではなく、次項から説明するセッション管理で使用するセッションIDだけ保存します。 そのためクライアント側ではセッションIDしか見えないため、万が一改ざんされても大きな影響はありません。

セッションID生成方法

各プログラム言語にはメジャーなセッションライブラリがあり、セッションID生成には、それらを使うことが多い それらのライブラリの多くのデフォルトの実装は、セッションIDとしてユニークで推測しずらい値を生成し、それをキーとして「ユーザーID」などのユーザーデータを紐付けて、ローカルファイルやメモリ上にキーバリューデータとして保存しておく そして、ブラウザーからアクセスがあった場合は、クッキーからセッションIDを読み取り、セッションIDをキーに、キーバリューデータから該当するユーザーデータを復元する キーバリューデータをサーバーのローカルファイルやメモリに保存するため、サーバーを複数設置して負荷分散させた場合、接続毎に接続先のサーバーが変わってしまうので、セッションが維持できなくなってしまう なので、どのサーバーにアクセスしても適切なユーザーデータが復元できるように、キーバリューデータをローカルではなく、データベースに格納するようにすることも多い

Expressでのセッション管理

Expressには、以下の2つのセッションモジュールがある

  • cookie-session
  • express-session cookie-sessionはCookieにセッションデータを保存するミドルウェアです。 express-sessionはCookieにセッションIDのみを保存して、セッションデータは別のストレージに保存するミドルウェアです

スクロール位置の復元

Next.jsはどうやってスクロール位置を復元するのか

デフォルトでのブラウザ挙動

ブラウザのhistory entryに格納されるstateにはscroll position dataというものがあり、「scroll restoration modeがautoならscroll position dataをもとにuser agentはスクロール位置を復元することができる」とされています。scroll restoration modeはhistory.scrollRestoration にauto(初期値)かmanualを代入することで設定できます。

リモートVPSでe2eテストをする。

参考URL

画面のないVPSサーバーでSeleniumを使ってChromeブラウザを操作してみる

フロントエンジニアなら知っておきたいブラウザレンダリングの仕組みをわかりやすく解説

参考URL

スクロールをしていてカクつく。またはアニメーションがカクカクしている時というのはブラウザがどういう状態なのでしょうか?

まずは、この状態を定量的に説明するためFPS(フレームレート)から説明します。

FPS(Frame Per Second)

FPSとはFrame Per Secondの略で1秒ごとの画面(フレーム)の切り替わる回数を表しています。 ブラウザでサイトを見た際には最高で60fpsとなるため、1秒間に60回画面が更新されていることになります。 スクロールによる表示の更新やアニメーションはテレビと同じ様に静止画を高速で切り替えることで動いているように見せているわけです。

ブラウザの処理フロー

ブラウザの処理順は以下の流れで画面にどの様に表示すればよいのかを計算しています。

  1. Parse(パース)
  2. Style(スタイル)
  3. Layout(レイアウト)
  4. Paint(ペイント)
  5. Composite(コンポジット)
  • 画面の初期表示にはブラウザはこの処理フローを最初から行う
  • 画面の表示内容に更新があった場合は必要な工程のみを処理し、再計算が不要な工程は省略する。
  1. Parse この工程ではHTMLとCSSの解析が行われる。 ブラウザはHTMLとCSSを平行して解析する これらの構造体を生成するのがパースの役割。

HTML → DOMツリーの作成 CSS → Style Rulesの作成

  1. Style この工程では先ほど作成したDOM TreeとStyle Rulesの紐付けが行われる。

具体的にはどのスタイルがどの要素に適用されるのかをマッチングし、複数個のスタイルが一致する要素に関しては、スタイル適用の優先順位に従って最終的に適用されるスタイルを割り出します。