내가 Google.com에 접속했을 때 - Javascript

google.com 같은 사이트에 접속할 때 실제로 무슨 일이 벌어지는지를 이해하기 위한 오늘의 주제. 브라우저 단계 이후 자바스크립트 단계를 정리해보았다.

[네트워크]
DNS → TCP → HTTPS → index.html 다운로드
↓
[브라우저]
HTML 파싱 → JS 번들 다운로드
↓
[자바스크립트]
React/Vue 앱 실행
↓
[API 네트워크]
백엔드 API 호출
↓
[렌더링]
DOM 생성 → 화면에 UI 표시

1. [자바스크립트] React / Vue 앱 실행 (CSR 기준)

브라우저가 네트워크를 통해 index.html 파싱을 마치고, 그 안에 포함된 메인 자바스크립트 파일(Bundle.js)을 로드한 직후에 벌어지는 일

1) 자바스크립트 엔진의 코드 실행

브라우저의 JS 엔진(V8 등)이 다운로드된 코드를 읽고 실행. 이때 React나 Vue 같은 라이브러리의 코드가 메모리에 올라가고, 개발자가 작성한 컴포넌트 구조를 파악하기 시작한다.

2) 가상 DOM(Virtual DOM) 생성

브라우저의 실제 DOM을 건드리기 전에, JS 메모리 공간에 가상 DOM이라는 트리 구조를 먼저 만든다. (아직은 실제 화면에 아무것도 나타나지 않는 '설계도' 단계)
-> 이 단계에서 데이터 초기값에 따라 어떤 UI가 보여야 할지 계산.

3) 마운트 (Mounting) - 실제 DOM 주입

JS가 비어있던 HTML의 특정 요소(보통 <div id="root"></div>)를 찾아 그 안에 가상 DOM을 실제 DOM 노드로 변환하여 집어넣는 단계.

CSR의 특징: 이 과정에서 document.createElement() 같은 브라우저 API가 쉴 새 없이 호출되며 UI를 바닥부터 빌드
-> 이때 비로소 사용자는 흰 화면에서 벗어나 웹사이트의 초기 UI(로딩 바 혹은 빈 틀)를 보게 된다.

4) Event Binding

클릭, 입력 등 이벤트 리스너 연결

왜 이 단계가 무거운가?

• CPU 집중 작업: 브라우저는 수천 개의 DOM 노드를 자바스크립트로 생성하고 배치해야 한다. 저사양 기기에서는 이 과정에서 버벅임이 발생할 가능성
• 네트워크 대기: JS 번들 파일이 클수록 다운로드 시간이 길어지고, 그동안 사용자는 계속 흰 화면을 보게 됨.

-> 해결 방법이 있을까?

1. 네트워크 대기 문제 해결

JS 파일이 커서 발생하는 "흰 화면" 시간을 줄이는 방법.

• Code Splitting (코드 분할): 큰 JS 파일을 한 번에 다 받지 않고, 현재 페이지에 필요한 코드만 먼저 받는 방식
  ex) 메인 페이지 접속 시 마이페이지 관련 코드는 다운로드하지 않음

• Tree Shaking: 사용하지 않는 코드를 제거하여 번들 크기를 최소화

• Compression (Gzip/Brotli): 서버(Nginx 등) 설정에서 JS 파일을 압축해서 보내는 방법 -> 보통 70% 이상 크기가 줄어든다.

• CDN(Content Delivery Network, 콘텐츠 전송 네트워크)활용: 사용자와 물리적으로 가까운 서버에서 JS 파일을 서빙하여 다운로드 속도를 높인다.

2. CPU 집중 작업 문제 해결

수천 개의 DOM을 만드느라 브라우저가 버벅이는 현상을 해결하는 방법.

• Virtual Scrolling (가상 스크롤): 데이터가 1만 개라도 화면에 보이는 10개만 실제로 DOM으로 만들고, 스크롤할 때마다 내용을 갈아 끼우는 방식 (성능 개선 효과가 매우 큼)

• Web Workers: 무거운 연산 로직이 있다면 메인 스레드(UI 담당)가 아닌 별도의 스레드에서 처리하여 화면 끊김을 방지

3. 구조적 해결책 (백엔드와 밀접한 관련)

가장 근본적인 해결책으로, 최근 백엔드 개발자에게도 요구되는 지식

• SSR (Server Side Rendering) 도입
  방법: 서버(Node.js 등)에서 미리 HTML을 완성해서 보냄.

• Streaming SSR (Next.js 13+ 등)
  방법: 전체 페이지가 완성될 때까지 기다리지 않고, 준비된 부분부터 조각조각(Chunk) 브라우저로 보냄

4. 백엔드 개발자가 직접 기여할 수 있는 최적화

• BFF (Backend For Frontend) 패턴: 프론트엔드에 꼭 필요한 데이터만 가공해서 전달하는 중간 서버를 두는 방법. 프론트엔드가 여러 API를 호출해 복잡하게 데이터를 가공하는 로직(CPU 소모)을 줄여준다.

• Pagination & Partial Loading: 한 번에 너무 많은 데이터를 주지 않고, 필요한 만큼만 끊어서 주는 방법 (DOM 개수 최소화의 핵심)

• HTTP/2 or HTTP/3 도입: 여러 개의 작은 리소스를 병렬로 빠르게 전송할 수 있도록 서버 설정을 최적화

SSR인 경우 하이드레이션(Hydration)이라는 과정을 거치는데 하이드레이션이란 이미 그려진 HTML에 자바스크립트 이벤트 리스너를 결합하여 "살아있는" 페이지로 만드는 과정

SSR의 하이드레이션과 CSR의 이벤트 바인딩은 어떻게 다를까?
두 방식의 차이는 "누가 이벤트를 붙이느냐"가 아니라 "어떤 대상에 붙이느냐"의 차이.

• CSR에서의 이벤트 바인딩: 자바스크립트가 방금 자기가 새로 만든 따끈따끈한 DOM 요소에 이벤트를 붙인다.

• SSR(하이드레이션)에서의 이벤트 바인딩: 서버가 이미 만들어 보내준 차가운 HTML 요소들을 찾아내서 그 위에 이벤트를 붙인다.