주소창에 google.com을 치면 일어나는 일

I. 요약

1. URL 입력 및 처리

• URL 입력: 사용자가 URL을 입력하고 엔터를 누르면, 브라우저는 URL의 유효성을 검사하고 필요한 프로토콜을 추가합니다.
• 리다이렉트 확인: 초기 요청을 받은 서버가 URL을 다른 위치로 자동으로 보내도록 설정된 경우, 브라우저는 이 리다이렉트를 처리합니다. 예를 들어, http://로 시작하는 요청이 https://로 리다이렉트될 수 있습니다.
• 공유 캐시 확인: 특히 대규모 웹 서비스에서는 네트워크 내에 공유 캐시(캐싱 프록시)가 존재할 수 있습니다. 이 캐시는 자주 요청되는 리소스를 저장하고, 캐시에 있는 리소스는 DNS 조회나 서버 접속 없이 바로 제공될 수 있습니다.

2. DNS 조회

• 브라우저는 "google.com"의 IP 주소를 찾기 위해 도메인 이름 시스템(DNS) 조회를 시작합니다.
• 먼저, 브라우저는 로컬 DNS 캐시를 확인하여 이전에 조회한 정보가 있는지 확인합니다.
• 캐시에 정보가 없다면, 브라우저는 설정된 DNS 서버에 조회 요청을 보냅니다.
• DNS 서버는 "google.com"의 IP 주소를 찾아 응답합니다. 이 과정은 필요에 따라 여러 DNS 서버를 거칠 수 있습니다.

3. TCP 연결

• 리버스 프록시: 일부 대규모 웹 서비스에서는 리버스 프록시 서버를 사용하여 클라이언트와 내부 서버 간의 요청을 중개합니다. 리버스 프록시는 외부에서 받은 요청을 적절한 내부 서버로 전달하며, 이는 로드 밸런싱, SSL 종단, 캐시 등 여러 기능을 수행할 수 있습니다.
• TCP 연결: 리버스 프록시를 통해 결정된 내부 서버와의 안전한 TCP 연결을 설정합니다. 이 과정은 세 방향 핸드셰이크(3-way handshake)를 통해 이루어지며, 연결이 설정되면 데이터 전송이 시작됩니다.
  
  • SYN: 클라이언트가 서버에 연결 요청을 보냅니다.
  • SYN-ACK: 서버가 요청을 받고 연결을 수락하며, 응답합니다.
  • ACK: 클라이언트가 이를 확인하고 연결이 설정됩니다.

4. HTTPS 보안 설정

• TCP 연결이 설정되면, 브라우저는 HTTPS를 사용하여 데이터를 암호화합니다. 이는 SSL/TLS 핸드셰이크를 통해 이루어집니다.
  • 브라우저와 서버는 암호화에 사용될 키와 암호화 방식을 협상합니다.
  • 서버는 자신의 인증서를 브라우저에 제공합니다.
  • 브라우저는 인증서가 신뢰할 수 있는 발급 기관에 의해 서명되었는지 확인합니다.

5. HTTP 요청 및 응답

• 모든 연결 및 보안 설정이 완료되면, 브라우저는 HTTP GET 요청을 서버로 보냅니다.
• 서버는 요청을 처리하고 HTML, CSS, JavaScript 등 웹 페이지를 구성하는 데 필요한 데이터를 포함한 응답을 반환합니다.

6. 웹 페이지 렌더링

• 브라우저는 받은 데이터를 해석하여 사용자에게 웹 페이지로 표시합니다.
  • HTML은 페이지의 구조를 정의합니다.
  • CSS는 스타일을 적용합니다.
  • JavaScript는 동적 요소를 처리합니다.

7. 추가 리소스 로딩

• 웹 페이지에는 이미지, 폰트, 추가 JavaScript 등 외부 리소스가 포함될 수 있습니다. 이러한 리소스는 필요에 따라 별도의 HTTP 요청을 통해 로드됩니다.

이 과정을 통해 단순한 "google.com" 입력이 복잡한 네트워크 및 소프트웨어 상호작용을 거쳐 최종적으로 웹 페이지를 사용자에게 제공하는 일련의 작업으로 변환됩니다.

 

II. 자세히 알아보기

1. URL 입력 및 처리

• URL 입력: 사용자가 URL을 입력하고 엔터를 누르면, 브라우저는 URL의 유효성을 검사하고 필요한 프로토콜을 추가합니다.
• 리다이렉트 확인: 초기 요청을 받은 서버가 URL을 다른 위치로 자동으로 보내도록 설정된 경우, 브라우저는 이 리다이렉트를 처리합니다. 예를 들어, http://로 시작하는 요청이 https://로 리다이렉트될 수 있습니다.
• 공유 캐시 확인: 특히 대규모 웹 서비스에서는 네트워크 내에 공유 캐시(캐싱 프록시)가 존재할 수 있습니다. 이 캐시는 자주 요청되는 리소스를 저장하고, 캐시에 있는 리소스는 DNS 조회나 서버 접속 없이 바로 제공될 수 있습니다.

URL 구성 요소 이해

• URL(Uniform Resource Locator)은 웹 상의 자원 위치를 나타내는 주소입니다.
  기본 구조는 protocol://domain:port/path?query_string#fragment_id입니다.
  • 프로토콜: 자원에 접근하기 위한 메소드(예: http, https, ftp 등).
  • 도메인: 자원을 호스팅하는 서버의 주소(예: google.com).
  • 포트: 서버에서 특정 서비스에 접근하기 위해 사용하는 게이트웨이 번호(예: HTTP의 기본 포트는 80, HTTPS는 443).
  • 경로: 서버 내에서 특정 자원으로의 경로(예: /images/logo.png).
  • 쿼리 문자열: 서버에 제공되는 추가 파라미터(예: ?id=123).
  • 프래그먼트: 페이지 내의 특정 부분을 가리키는 식별자(예: #section1).

URL 검증 및 정규화

• 브라우저는 입력된 URL이 유효한지 검증합니다. 예를 들어, 사용자가 www.google.com만 입력했다면 브라우저는 이를 완전한 URL 형식으로 정규화하기 위해 자동으로 https://를 앞에 추가할 수 있습니다.

자동 완성 기능

• 현대 브라우저는 사용자가 URL을 입력할 때 자동 완성 기능을 제공하여 이전에 방문했던 사이트, 즐겨찾기 또는 인기 사이트를 기반으로 추천 URL을 제시할 수 있습니다.

특수 문자 처리

• URL에는 ASCII 문자 집합 외의 문자가 포함될 수 있습니다. 브라우저는 이러한 특수 문자를 올바르게 인코딩하여 서버가 이해할 수 있는 형태로 변환합니다. 예를 들어, 공백은 %20으로 변환됩니다.

이러한 과정을 거쳐 사용자가 입력한 원래의 텍스트는 네트워크를 통해 서버에 요청을 보내기 위한 형태로 변환되며, 이후 DNS 조회와 같은 다음 단계로 진행됩니다.

 

2. DNS 조회

DNS(Domain Name System) 조회는 인터넷에서 도메인 이름(예: "google.com")을 해당하는 IP 주소로 변환하는 과정입니다. 이는 사용자가 웹 사이트에 접근할 때 필수적인 단계로, 복잡한 인터넷의 구조 속에서 특정 서버를 찾아내는 데 필요합니다. 다음은 DNS 조회의 주요 단계입니다:

DNS 캐시 확인

• 브라우저는 DNS 조회를 시작하기 전에 로컬 DNS 캐시를 확인합니다. 이 캐시에는 최근에 방문한 웹사이트의 도메인 이름과 해당 IP 주소가 일정 시간 저장됩니다.
• 로컬 캐시에 해당 도메인의 정보가 있으면, DNS 서버에 요청을 보내지 않고 즉시 해당 정보를 사용합니다.

DNS 서버에 요청

• 로컬 캐시에서 해당 도메인의 정보를 찾을 수 없는 경우, 브라우저 또는 운영 체제는 구성된 DNS 서버에게 해당 도메인의 IP 주소를 조회하도록 요청합니다.
• 일반적으로 이 DNS 서버는 ISP(Internet Service Provider)에 의해 제공되거나, 사용자가 Google의 8.8.8.8 같은 공개 DNS 서버를 사용하기로 설정한 경우가 있습니다.

재귀적 및 반복적 조회

• 초기 DNS 서버는 요청 받은 도메인의 IP 주소를 직접 알고 있지 않을 경우, 다른 DNS 서버에 조회를 요청하는 재귀적 방식으로 동작할 수 있습니다.
• 이 과정에서 루트 DNS 서버, TLD(Top-Level Domain, 예: .com, .net) 서버, 그리고 궁극적으로 도메인의 권한을 가진 네임 서버에 이르기까지 여러 단계를 거칠 수 있습니다.
• 각 서버는 필요한 정보를 찾거나 다음 조회를 위한 참조를 제공합니다.

IP 주소 응답

• 최종적으로 도메인에 대한 권한이 있는 네임 서버가 해당 도메인의 IP 주소를 제공합니다.
• 이 IP 주소는 원래의 DNS 요청을 한 서버로 반환되며, 이 서버는 다시 IP 주소를 요청한 클라이언트(브라우저)에게 전달합니다.
• 이제 브라우저는 도메인 이름 대신 IP 주소를 사용하여 해당 서버에 접속할 수 있습니다.

캐싱

• 반환된 IP 주소는 일정 기간 동안 로컬 DNS 캐시에 저장되어, 추후 같은 도메인 이름으로의 조회 요청이 있을 때 빠르게 응답할 수 있도록 합니다.

DNS 조회 과정은 인터넷의 규모와 복잡성 때문에 매우 중요한 기능을 하며, 이 과정이 효율적으로 작동하지 않으면 웹 브라우징 경험이 크게 저하될 수 있습니다.

 

3. TCP 연결

TCP (Transmission Control Protocol)는 인터넷에서 데이터를 안정적으로, 순서대로, 오류 없이 전송하기 위해 사용되는 핵심 프로토콜 중 하나입니다. 웹 페이지를 요청하고 데이터를 교환하기 전에 클라이언트 (웹 브라우저)와 서버 간에는 안정적인 TCP 연결이 설정되어야 합니다. 이 과정은 주로 세 방향 핸드셰이크(Three-Way Handshake)를 통해 이루어집니다. 다음은 TCP 연결 설정의 주요 단계입니다:

3hand-shake

1. SYN (Synchronize)

• 클라이언트는 서버에 연결을 요청하는 SYN(Synchronize) 패킷을 보냅니다. 이 패킷은 연결을 시작하겠다는 신호이며, 클라이언트가 선택한 초기 시퀀스 번호(Sequence Number)를 포함합니다.
• SYN 패킷은 연결 설정을 위한 초기 단계임을 나타내고, TCP 연결의 양쪽에서 데이터가 순서대로 전송되고 수신될 수 있도록 시퀀스 번호를 동기화하는 데 사용됩니다.

2. SYN-ACK (Synchronize-Acknowledgment)

• 서버는 클라이언트의 SYN 요청을 받고, SYN과 ACK(Acknowledgment) 플래그가 설정된 패킷을 클라이언트로 보내 응답합니다. 이 패킷에는 서버의 초기 시퀀스 번호와 클라이언트의 시퀀스 번호에 1을 더한 값(즉, 클라이언트의 SYN 패킷을 확인했다는 의미에서 1을 추가)이 포함됩니다.
• 이 단계에서 서버는 클라이언트의 연결 요청을 수락하고, 자신의 시퀀스 번호를 클라이언트에 알리며, 이전에 받은 클라이언트의 시퀀스 번호를 확인합니다.

3. ACK (Acknowledgment)

• 클라이언트는 서버의 SYN-ACK 패킷을 받고, ACK 패킷을 서버에게 보냅니다. 이 패킷은 서버의 SYN-ACK 패킷을 받았음을 확인하고, 서버의 시퀀스 번호에 1을 더한 값이 포함됩니다.
• 이 단계를 마치면 클라이언트와 서버 간의 TCP 연결이 성공적으로 설정되며, 양방향 통신이 가능한 상태가 됩니다.

TCP 연결의 특징

• 신뢰성: TCP는 데이터가 손실, 중복, 또는 순서가 바뀌지 않도록 보장합니다. 만약 패킷이 손실되면 재전송을 요청합니다.
• 흐름 제어: TCP는 네트워크 상태와 수신자의 처리 능력을 고려하여 데이터 전송 속도를 조절합니다.
• 혼잡 제어: 네트워크 내의 혼잡 상태를 감지하고, 이에 따라 데이터 전송 속도를 조정하여 네트워크의 과부하를 방지합니다.

이렇게 TCP 연결을 통해 웹 서버와 클라이언트 간에 안정적이고 신뢰할 수 있는 통신 채널이 구축됩니다. 이 채널을 통해 HTTP 요청과 응답이 안전하게 교환될 수 있습니다. 일부 대규모 웹 서비스에서는 리버스 프록시 서버를 사용하여 클라이언트와 내부 서버 간의 요청을 중개합니다. 리버스 프록시는 외부에서 받은 요청을 적절한 내부 서버로 전달하며, 이는 로드 밸런싱, SSL 종단, 캐시 등 여러 기능을 수행할 수 있습니다.

 

4. HTTPS 보안 설정

 HTTPS(HyperText Transfer Protocol Secure)는 웹 통신의 보안을 강화하기 위해 HTTP에 SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security) 프로토콜을 결합한 것입니다. HTTPS는 데이터의 기밀성과 무결성을 보장하며, 클라이언트와 서버 간의 통신을 암호화합니다. HTTPS 설정 과정은 크게 SSL/TLS 핸드셰이크로 구성되며, 다음과 같은 단계를 포함합니다:

1. 클라이언트 헬로(Client Hello)

• 클라이언트가 서버에 연결을 시도할 때, 클라이언트는 "Client Hello" 메시지를 보냅니다. 이 메시지에는 클라이언트가 지원하는 SSL/TLS 버전, 지원하는 암호화 알고리즘(암호화 스위트), 세션 ID, 그리고 임의의 수(random number) 등이 포함됩니다.
• 이 단계에서 클라이언트는 서버에 자신의 암호화 기능과 선호도를 알립니다.

2. 서버 헬로(Server Hello)

• 서버는 "Server Hello" 메시지로 응답합니다. 이 메시지에는 선택된 SSL/TLS 버전, 선택된 암호화 스위트, 세션 ID, 서버의 임의의 수(random number), 그리고 서버의 디지털 인증서가 포함됩니다.
• 서버의 디지털 인증서는 신뢰할 수 있는 인증 기관(CA)에 의해 서명된 문서로, 서버의 공개키와 서버의 신원(예: 도메인 이름) 정보를 포함합니다.

3. 인증서 검증

• 클라이언트는 서버의 인증서를 받고, 해당 인증서가 신뢰할 수 있는 CA에 의해 발급되었는지 확인합니다. 또한 인증서가 유효한 날짜인지, 인증서에 기록된 서버 이름이 실제 접속하고자 하는 서버 이름과 일치하는지 검사합니다.
• 인증서 검증을 통해 클라이언트는 서버의 신원을 확인하고, 서버가 소유한 공개키를 안전하게 획득합니다.

4. 사전 마스터 비밀 생성(Pre-Master Secret)

• 클라이언트는 임의의 수를 생성하여 "Pre-Master Secret"을 만들고, 서버의 공개키로 암호화하여 서버에 전송합니다.
• 서버는 자신의 개인키로 이를 복호화하여 같은 "Pre-Master Secret"을 얻습니다.

5. 세션 키 생성

• 클라이언트와 서버는 "Pre-Master Secret"과 두 임의의 수를 조합하여 세션 중 사용될 "Session Keys"를 생성합니다. 이 키들은 통신 중 데이터를 암호화하고 복호화하는 데 사용됩니다.

6. 통신 준비 완료

• 클라이언트와 서버는 "Finished" 메시지를 교환하여 핸드셰이크 과정을 완료합니다. 이 메시지는 앞서 교환된 모든 메시지의 무결성을 확인하기 위해 보내집니다.

7. 암호화된 세션

• SSL/TLS 핸드셰이크가 성공적으로 완료되면, 클라이언트와 서버 간의 모든 통신은 암호화되어 보안을 유지하게 됩니다.

HTTPS 설정은 통신의 기밀성을 보장하여 중간자 공격(Man-in-the-Middle Attack)이나 데이터 유출 같은 보안 위협으로부터 사용자를 보호하는 중요한 역할을 합니다.

 

5. HTTP 요청 및 응답

HTTP(HyperText Transfer Protocol)는 클라이언트(웹 브라우저)와 서버 간의 통신을 위해 사용되는 프로토콜입니다. 웹 페이지를 요청하고 그 결과를 받는 과정은 주로 HTTP 요청과 응답을 통해 이루어집니다. 이 과정은 다음과 같은 단계로 구성됩니다:

1. HTTP 요청 보내기

• 요청 시작: 사용자가 웹 주소를 입력하고 엔터를 누르거나, 웹 페이지 내 링크를 클릭하는 순간, 웹 브라우저는 해당 리소스를 서버에 요청하는 HTTP 요청 메시지를 생성합니다.
• 메서드: HTTP 요청은 여러 종류의 메서드를 포함할 수 있습니다. 가장 일반적인 메서드는 GET (리소스 요청), POST (데이터 서버로 전송), PUT (리소스 업데이트), DELETE (리소스 삭제) 등입니다.
• 헤더: 요청 헤더에는 요청을 서술하는 데 필요한 메타데이터가 포함됩니다. 예를 들어, User-Agent 헤더는 클라이언트의 브라우저 정보를 제공하고, Accept 헤더는 클라이언트가 이해할 수 있는 콘텐츠 유형을 지정합니다.
• 바디: POST와 PUT 요청은 데이터를 서버로 전송할 때 요청 바디에 데이터를 포함시킬 수 있습니다. 이 데이터는 폼 데이터, 파일 업로드 등이 될 수 있습니다.

2. 서버에서의 처리

• 요청 수신: 서버는 HTTP 요청을 수신하고, 요청된 메서드, URI, 헤더 등의 정보를 분석합니다.
• 리소스 식별: 요청된 URI에 따라 서버는 요청된 리소스를 식별합니다. 리소스는 정적 파일(HTML, CSS, 이미지 파일 등) 또는 동적 리소스(서버 사이드 스크립트에 의해 생성된 데이터)일 수 있습니다.
• 리소스 처리: 서버는 요청에 맞는 처리를 수행합니다. 예를 들어, 데이터베이스 쿼리 실행, 세션 관리, 요청 데이터 처리 등을 포함할 수 있습니다.

3. HTTP 응답 생성

• 상태 코드: 서버는 처리 결과에 따라 HTTP 응답을 생성합니다. 응답은 상태 코드를 포함하여 클라이언트에게 요청의 성공 또는 실패를 알립니다 (예: 200 OK, 404 Not Found, 500 Internal Server Error 등).
• 응답 헤더: 응답 헤더는 응답에 대한 메타데이터를 제공합니다. 예를 들어, Content-Type은 응답 데이터의 타입을 지정하고, Set-Cookie는 클라이언트 브라우저에 쿠키를 설정할 때 사용됩니다.
• 응답 바디: 실제 요청된 데이터가 응답 바디에 포함됩니다. 이는 HTML 문서, 이미지, JSON 데이터 등이 될 수 있습니다.

4. 클라이언트에서의 처리

• 응답 수신: 클라이언트는 서버로부터 응답을 받고, 상태 코드를 확인하여 요청이 성공적으로 처리되었는지 판단합니다.
• 콘텐츠 렌더링: 클라이언트(웹 브라우저)는 응답 데이터를 파싱하고, 필요한 경우 추가적인 리소스(이미지, CSS, JavaScript 파일 등)를 요청합니다.
• 사용자 인터페이스 업데이트: 최종적으로, 브라우저는 받은 데이터를 사용자에게 시각적으로 표시합니다.

HTTP 요청과 응답의 이러한 과정은 웹 상에서 정보를 교환하는 기본적인 방법이며, 웹의 동작 원리를 이해하는 데 중요합니다.

 

6. 웹 페이지 렌더링

Render Tree

웹 페이지 렌더링은 서버로부터 받은 데이터와 리소스를 사용자에게 시각적으로 표시하는 과정입니다. 이 과정은 여러 복잡한 단계를 포함하며, 웹 브라우저는 HTML, CSS, JavaScript와 같은 파일들을 해석하여 사용자가 상호작용할 수 있는 웹 페이지로 변환합니다. 다음은 웹 페이지 렌더링의 주요 단계입니다:

1. HTML 파싱

• 문서 파싱: 브라우저는 서버로부터 받은 HTML 문서를 파싱하여 DOM(Document Object Model) 트리를 구성합니다. DOM 트리는 HTML 문서의 각 요소를 노드로 나타내며, 이 구조를 통해 스크립트와 스타일이 문서의 콘텐츠와 상호작용합니다.
• 스크립트 처리: HTML 내에 JavaScript가 포함되어 있으면, 파싱 과정 중 JavaScript 실행이 필요할 수 있습니다. 스크립트는 DOM 생성을 중단시킬 수 있으며, 스크립트 실행이 완료된 후 DOM 파싱이 계속됩니다.

2. CSS 파싱과 스타일 계산

• CSS 파싱: 별도의 CSS 파일이나 HTML 내의 스타일 태그로부터 CSS를 파싱하여 CSSOM(CSS Object Model)을 구성합니다. CSSOM은 CSS 속성을 저장하는 트리 구조로, 각 HTML 요소에 적용될 스타일을 정의합니다.
• 스타일 계산: DOM과 CSSOM을 결합하여 렌더 트리를 생성합니다. 렌더 트리는 실제로 화면에 표시될 요소들만 포함하며, 각 요소의 시각적 속성(크기, 색상 등)이 포함됩니다.

3. 레이아웃(Layout)

• 레이아웃 계산: 렌더 트리의 각 요소에 대한 정확한 위치와 크기를 계산합니다. 이 단계는 뷰포트 내에서 각 요소가 차지할 공간을 결정하며, 브라우저의 창 크기나 요소의 스타일에 따라 다릅니다.
• 리플로우: 요소의 크기나 위치가 변경될 때, 브라우저는 레이아웃을 다시 계산해야 할 필요가 있습니다. 이 과정을 리플로우라고 하며, 성능에 큰 영향을 미칠 수 있습니다.

4. 페인팅(Paint)

• 페인팅 준비: 레이아웃 단계에서 결정된 위치와 크기를 바탕으로 각 요소를 화면에 그립니다. 이 단계에서는 색상, 이미지, 텍스트 등의 시각적 디테일을 처리합니다.
• 레이어 별 그리기: 복잡한 웹 페이지의 경우, 여러 레이어로 구성되어 각 레이어를 별도로 그릴 수 있습니다. 이는 레이어 별로 합성(Composite)을 수행하여 최종적으로 화면에 표시합니다.

5. 합성(Composite)

• 합성: 여러 레이어를 최종적으로 하나로 합치는 과정입니다. 이 단계에서는 레이어들이 겹치는 방식, 투명도 등을 고려하여 최종적인 화면 출력을 준비합니다.

웹 페이지 렌더링 과정은 매우 복잡하며, 최적화된 렌더링 성능을 위해 브라우저는 다양한 기술과 최적화 기법을 사용합니다. 이 과정은 사용자 경험에 직접적인 영향을 미치기 때문에 웹 개발자는 효율적인 HTML, CSS, JavaScript 작성을 통해 렌더링 성능을 향상시키는 방법을 항상 고려해야 합니다.

 

7. 추가 리소스 로딩

웹 페이지를 완전히 렌더링하고 사용자에게 제공하기 위해서는 초기 HTML 문서 외에도 다양한 추가 리소스들이 로딩되어야 합니다. 이러한 리소스에는 이미지, 스타일시트(CSS), 자바스크립트(JS) 파일, 폰트, 동영상 등이 포함될 수 있습니다. 추가 리소스 로딩은 웹 페이지의 성능과 사용자 경험에 큰 영향을 미치므로, 이 과정을 효율적으로 관리하는 것이 중요합니다. 다음은 추가 리소스 로딩의 주요 단계입니다:

1. 리소스 발견

• 웹 브라우저는 HTML 문서를 파싱하면서 <link>, <script>, <img>, <video> 등의 태그를 통해 필요한 추가 리소스를 식별합니다.
• 이 태그들은 리소스의 URL을 포함하고 있으며, 브라우저는 이 URL을 사용하여 해당 리소스를 서버에서 요청합니다.

2. 리소스 요청

• HTML 문서 파싱 중 또는 파싱이 완료된 후, 브라우저는 식별된 리소스에 대한 HTTP 요청을 서버에 보냅니다. 이 과정은 비동기적으로 처리될 수도 있으며, 리소스의 종류와 필요성에 따라 다르게 우선순위가 지정될 수 있습니다.
• 예를 들어, 렌더링을 차단할 수 있는 CSS나 스크립트는 가능한 빨리 로딩되어야 할 수 있으며, 이미지와 같은 비동기 리소스는 페이지 로딩에 덜 중요할 수 있습니다.

3. 리소스 수신 및 처리

• 리소스 파일이 서버로부터 전송되면, 브라우저는 이 파일을 받아 적절한 처리를 합니다. 예를 들어, 이미지 파일은 디코딩 과정을 거친 후 렌더링 트리에 추가되고, CSS 파일은 파싱되어 기존 CSSOM에 통합됩니다.
• 자바스크립트 파일은 다운로드 후 즉시 실행될 수 있으며, 이는 동적으로 DOM을 수정하거나 추가적인 리소스 요청을 트리거할 수 있습니다.

4. 종속성 해결

• 특정 리소스는 다른 리소스에 의존할 수 있습니다. 예를 들어, 자바스크립트 라이브러리는 다른 스크립트 파일이 먼저 로드되고 실행된 후에야 정상적으로 작동할 수 있습니다.
• 이러한 종속성을 관리하기 위해 HTML에서는 리소스 로딩 순서를 제어하는 속성(async, defer 등)을 제공하며, 자바스크립트를 사용하여 동적으로 리소스를 로드하고 종속성을 해결할 수 있습니다.

5. 최적화 및 성능 개선

• 리소스 로딩은 페이지 로딩 시간에 직접적인 영향을 미치므로, 개발자들은 이 과정을 최적화하기 위해 다양한 기법을 사용합니다.
• 리소스를 압축하고, 캐싱 정책을 효율적으로 설정하며, 필요한 경우 CDN(Content Delivery Network)을 사용하여 리소스 로딩 속도를 향상시키고 사용자에게 더 빠른 액세스를 제공할 수 있습니다.

이와 같은 추가 리소스 로딩 과정은 웹 페이지의 완성도와 사용자 경험을 결정하는 중요한 요소입니다. 효율적인 리소스 관리와 로딩 전략은 웹 성능 최적화의 핵심적인 부분으로 간주됩니다.