サイトに接続する時に裏ではどんなことが行なっているか:サーバーサイド・クライアントサイド/フロントエンド・バックエンド観点
前置き
サイトに接続する時に裏ではどんなことが行なっていますでしょうか。
恐らく、この疑問点についてただ利用するだけの利用者立場ではそこまで気にしてないところかと思います。
しかし、開発者としてはどうでしょうか。
もちろん、プログラミングと言う観点ではこのプロセスに理解しなくても開発は何となくできます。
ただ、良いエンジニアになりたいなら話が少し違うかもしれません。
良いエンジニアの特徴は人によって違うと思いますが、
私は一つの特徴として最適化(Optimaize)が可能かどうかも含まれています。
そのため、全体プロセスを理解した上で、性能観点でも、プロダクトの生産性観点でも
最適化が可能なエンジニアが良いエンジニアかと考えております。
性能改善によってUX増加とサーバーの運用コスト減少が、
生産性改善によってプロジェクト運用コスト減少とその分他の作業に使える時間も増えますので
できれば最適化はする方が良いでしょう。
前回記事で結構重く作成しまったこともあり
今回の記事はシンプルな感じで作成して行きたいですので、
こちらで紹介している技術まで詳細に説明までは紹介つもりではありません。
もちろん、今後記事で作成する可能性ももちろんございますが、
こちらはご自身で検索いただけたらと幸いです!
全体プロセス図
私はこの全体プロセスを大きくクライアントサイドとサーバーサイドで分類して、
小分類としてまたフロントエンド、バックエンド観点で分類したいと思います。
なぜかと言うと、実際業務の中でもほぼこの分類で話す方が多いからです。
まずは全体プロセスから確認して見ましょう。

上の画像は、ブラウザーで「www.yahoo.co.jp」を入力する時から
ユーザーのブラウザーに表示されるまでの全体的なプロセスを表示しています。
Yahooの静的ページが格納されているサーバーIP検索/取得
実は「www.yahoo.co.jp」はドメインアドレスで実際サーバーのアドレスではありません。
これはユーザーがIPを覚えるのはなかなか難しいので、
別途で用意したサーバー名でこれだけだと、サーバーに接続できません。
なので、この「www.yahoo.co.jp」に対するサーバーアドレス、
つまり、IPアドレスを取得する必要があります。
これを担当するサーバーがDNS(Domain Name System)と言うサーバーになります。
せっかくなので実際, Yahooの静的ページが格納されているサーバーは
どんなIPを持っているか確認して見ましょう。
MAC OS基準、以下のターミナルでコマンドで確認できます。
dig www.yahoo.co.jp
コマンド実行ログ
; <<>> DiG 9.10.6 <<>> www.yahoo.co.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46488
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.yahoo.co.jp. IN A
;; ANSWER SECTION:
www.yahoo.co.jp. 361 IN CNAME edge12.g.yimg.jp.
edge12.g.yimg.jp. 52 IN A 182.22.16.251
;; Query time: 47 msec
;; SERVER: 103.5.140.1#53(103.5.140.1)
;; WHEN: Mon Jun 30 19:12:52 JST 2025
;; MSG SIZE rcvd: 88
上の、ログを少し解析して見ると
IPアドレスが103.5.140.1であるサーバーの53番ポートから情報をもらっています。
恐らく、この記事をスタバで無料WIFIを利用して作業しているので
「Wire and Wireless(Wi2)」サービスでのDNSサーバーの確率が高いですね。
「www.yahoo.co.jp」の情報は361番ポートでedge12.g.yimg.jpと言うドメイン名が確認でき、
edge12.g.yimg.jpは182.22.16.251と言うIPアドレスを、
「www.yahoo.co.jp」に対するファイルは52番ポートにあることを確認できます。
ウィキペティアの「TCPやUDPにおけるポート番号の一覧」ページ[1]によると

一般的に、52番ポートはXNS (Xerox Network Systems) Time Protocol、
53番ポートは**Domain Name System (DNS)**で利用しているらしいです。
ただ、XNS (Xerox Network Systems) Time Protocolは1970代後半開発されたプロトコルのため、実際はこのプロトコルを利用してないかと思います。
多分、ページのデータを信頼性を高めるために一般的にはTCPを利用するので、実際はTCPで利用しているかと考えられます。
詳細プロセス

まとめると、ブラウザーは以下のプロセスで、ドメイン名に対するIPを取得します。
- ChromeはOSまたは、DHCP(ルータ)からDNSのIPアドレスを取得
- ドメイン名「www.yahoo.co.jp」対するIPアドレスおよびポート番号を取得
- 取得したIPアドレス・ポート番号でTCPで連結
例としたら、最終的にはブラウザーは182.22.16.251の52番ポートと接続する感じになります。
バックエンド処理/送信
次は、バックエンド処理と処理したファイルをクライアント(ブラウザー)に送信するサーバーサイド処理になります。
実際はどうか分かりませんが、Yahooサイトは結構前構築されシステムのため、
今回はSSR(Server Side Rendering)でレンダリングしていると想定します。
SSRについては、以前の記事で紹介しているので、以下の記事を参考してください。
このプロセスのポイントとしては、
UDP(User Datagram Protocol)ではなく、TCP(Transmission Control Protocol)で通信することです。
TCPで通信する理由は、Webアプリケションはデータの信頼性、
つまり、データが一つでも失ってしまうと正しい情報をユーザーに伝えることができないからです。
データ損失例
例えば、以下のページをユーザーに送信したいと仮定して見ましょう。
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
</head>
<body>
<h1>UDP通信によるデータ欠落 再現デモ</h1>
<div class="product-card">
<h2>商品A</h2>
<p>価格: 5,000円</p>
<button>購入する</button>
</div>
</body>
</html>
しかし、UDPで通信してしまい、データの一部の損失が発生。
以下のファイルがユーザーに送信されたらどうなりましょうか。
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
</head>
<body>
<h1>UDP通信によるデータ欠落 再現デモ</h1>
<div class="product-card">
<h2>商品A</h2>
<p>価格: 5,00円</p>
<button>購入する</button>
</div>
</body>
</html>
当然、ユーザーは該当する商品が500円で見えますので、良いアプリケーションと言えないでしょう。
そのため、特別に理由がなければTCPを利用する方が良いです。
詳細プロセス

まとめると、バックエンド処理/送信プロセスでは、サーバーとクライアントはTCPで通信、
SSRの場合はhtmlファイルサーバーで作成しなければならないです。
その結果、サーバーは加工されたhtmlファイル、CSSファイル、JavaScriptファイルを送信、
クライアントは三つのファイルを取得します。
まとめると、以下のプロセスになります。
- ファイル送信/取得するために、サーバーはクライアントをTCPで連結
- (SSRの場合サーバーサイド処理)表示するデータを取り込んだHTMLファイルを作成
- 静的ファイル(HTML,JavaScript,CSS)をTCPでブラウザーへ送信
正常に取得したら、ブラウザーはユーザーの画面に表示させるためにフロントエンド処理を実行します。
フロントエンド処理/画面表示
最後には、サーバーから取得したHTML,JavaScript,CSSを画面に表示されるために解析および処理を行います。

CSR(Client Side Rendering)とは詳細なプロセスが相違がありますが、大分類としては違いはありません。
ただ、JavaScriptの実行タイミングが状況によって相違があります。
JavaScriptロードタイミングについて
フロントエンド処理内で、JavaScriptをロードするタイミングが決めれます。
つまり、コードの上、<script> ~ </script>のポジションによってタイミングが変わります。
Render Tree作成前/後、ロードするパータン
最初はRender Tree作成前/後、ロードするパータンです。
このパータンは、以下の構成通り、<script> ~ </script>が<head> ~ </head>タグ下、
正確には<body> ~ </body>タグ内に配置されるパータンです。
<html>
<head></head>
<body>
<div>Hello</div>
<script>
console.log(document.body);
</script>
</body>
</html>
このパータンが一般的に良く使われているパータンです。
なぜかと言うと、<script> ~ </script>が<head> ~ </head>タグ内に配置してしまうと
JavaScriptをロードするために、DOM Treeの作成が遅延になるからです。
場合によってはレンダリング時間が比較的に遅くなるので、
DOM Treeの作成され、同様にRender Treeが作成される<script> ~ </script>が<body> ~ </body>内に配置されるパータンを使います。
Tree作成とは別のプロセスで実行されます。
JavaScriptを先にロードするパータン
<script> ~ </script>が<head> ~ </head>タグ内に配置するパータンです。
<html>
<head>
<script>
console.log(document.body);
</script>
</head>
<body>
<div>Hello</div>
</body>
</html>
上で説明した通り、JavaScriptをロードするために、DOM Treeの作成が遅延になり、
その分レンダリング時間も遅延になるので、明確な理由がない限り使わないパータンになります。
Hydrationについて
最新フレームワーク(Next.js, Nuxt.jsなど)ではHydrationと言う技術を採用しています。
Hydrationの場合は、以下の画像通り、

Compositeまで終わって、ブラウザーがユーザーの画面に表示されるタイミングに実行されます。
Hydrationについては前回の記事で作成したので、検索また以下の記事を参考してください。
詳細プロセス
まとめると、フロントエンド処理では以下のプロセスになります。
- HTML参照してDocument Object Model Tree、CSSから CSS Object Treeを作成する
- 別途のプロセスでJavaScriptロード開始
- DOM TreeとCSSOM Treeを結合してRender Tree作成
- Render Treeを基盤で、枠のポジション(x,y)と範囲(width, hegiht)が取り込んんでいるLayout作成
- Layoutを基盤で、具体的な色(Color)・背景(Background)・枠(Border)・フォント(Font)などの具体的なスタイル取り込んでいるPaintを作成する
- PaintをGPUで合成する
- 合成した結果を(Composite)を基盤で、Chromeが画面に表示する。
- ユーザーが画面を操作できる
まとめ

全体をまとめるとサイトに接続する時に裏では以下のプロセうが行います。
- ユーザーが「www.yahoo.co.jp」へアクセス
- ChromeはOSまたは、DHCP(ルータ)からDNSのIPアドレスを取得
- ドメイン名「www.yahoo.co.jp」対するIPアドレスおよびポート番号を取得
- 取得したIPアドレス・ポート番号でTCPで連結
- ファイル送信/取得するために、サーバーはクライアントをTCPで連結
- (SSRの場合サーバーサイド処理)表示するデータを取り込んだHTMLファイルを作成
- 静的ファイル(HTML,JavaScript,CSS)をTCPでブラウザーへ送信
- HTML参照してDocument Object Model Tree、CSSから CSS Object Treeを作成する
- 別途のプロセスでJavaScriptロード開始
- DOM TreeとCSSOM Treeを結合してRender Tree作成
- Render Treeを基盤で、枠のポジション(x,y)と範囲(width, hegiht)が取り込んんでいるLayout作成
- Layoutを基盤で、具体的な色(Color)・背景(Background)・枠(Border)・フォント(Font)などの具体的なスタイル取り込んでいるPaintを作成する
- PaintをGPUで合成する
- 合成した結果を(Composite)を基盤で、Chromeが画面に表示する。
- ユーザーが画面を操作できる
終わり
今回の記事はいかがでしょうか。
ブラウザーでは裏で何をしているかについて道全体的に理解ができるんであれば幸いです。
このテーマは面接でもよく話題に上がる内容ですので、
少しでも理解を深めておくと役立つ場面があるかもしれません。
私自身もこれから忙しい時期に入りますので、
次回の記事の公開は少し遅くなるかもしれませんが、
ひと区切りとして今回の記事を締めくくりたいと思います。
最後まで読んでいただき、ありがとうございました。
Discussion