웹페이지를 열었을 때 화면이 한 번에 뜨지 않고 요소들이 순서대로 나타나는 경험, 누구나 해봤을 겁니다. 글자는 보이는데 버튼이 한참 뒤에 반응하거나, 이미지가 하나씩 천천히 떠오르는 상황 말입니다. 이런 현상은 단순히 인터넷 속도 문제가 아니라, 브라우저가 정해진 로딩 순서를 따라 웹페이지를 처리하기 때문에 발생합니다. 저도 처음엔 그냥 "느린 사이트"라고만 생각했는데, 이 구조를 알고 나니 어디서 병목이 생기는지 보이기 시작했습니다.
DOM 생성
브라우저가 웹페이지를 열 때 가장 먼저 하는 일은 HTML 문서를 받아서 DOM(Document Object Model)이라는 구조를 만드는 겁니다. DOM이란 웹페이지의 뼈대를 나타내는 트리 구조로, 브라우저가 화면에 무엇을 표시할지 결정하는 기준이 됩니다. 쉽게 말해, HTML 태그들을 브라우저가 이해할 수 있는 형태로 변환하는 과정입니다.
이 단계에서 브라우저는 HTML을 위에서 아래로 읽으면서 각 요소를 메모리에 저장합니다. 예를 들어 <div>, <p>, <img> 같은 태그들이 순서대로 처리되는 거죠. 문제는 이 과정에서 자바스크립트 파일을 만나면 DOM 생성이 멈춘다는 점입니다. 스크립트가 DOM을 조작할 가능성이 있기 때문에, 브라우저는 일단 스크립트를 실행한 뒤에야 다음 단계로 넘어갑니다.
여러 사이트를 비교해본 결과, DOM 생성 단계에서 큰 용량의 외부 스크립트를 불러오는 사이트일수록 초기 화면이 늦게 뜨는 경우가 많았습니다. 특히 광고 스크립트가 많은 뉴스 사이트에서 이런 현상이 두드러졌습니다. 화면 구조 자체가 간단해도, 스크립트 처리 때문에 체감 속도가 느려지는 겁니다.
렌더링
DOM이 만들어지면 이제 CSS를 해석해서 CSSOM(CSS Object Model)을 생성합니다. CSSOM이란 웹페이지의 스타일 규칙을 담은 구조로, 각 요소가 어떤 색상, 크기, 위치로 표시될지 결정합니다. DOM과 CSSOM이 합쳐져서 렌더 트리(Render Tree)가 만들어지고, 이를 바탕으로 브라우저는 화면에 실제로 그릴 요소들을 계산합니다.
렌더링 과정은 크게 세 단계로 나뉩니다. 첫째, 레이아웃(Layout) 단계에서 각 요소의 정확한 위치와 크기를 계산합니다. 둘째, 페인트(Paint) 단계에서 실제로 픽셀을 색칠합니다. 셋째, 컴포지트(Composite) 단계에서 여러 레이어를 합쳐서 최종 화면을 완성합니다. 이 세 단계를 거쳐야 비로소 우리가 보는 화면이 나타나는 겁니다.
여기서 중요한 건 CSS가 렌더링을 막는 리소스(render-blocking resource)라는 점입니다. 브라우저는 CSS를 모두 받아서 CSSOM을 만들기 전까지 화면을 그리지 않습니다. 스타일 정보 없이 화면을 그렸다가 나중에 다시 그리면 사용자 경험이 나빠지기 때문입니다. CSS 파일이 큰 사이트를 열 때 한동안 하얀 화면만 보다가 갑자기 화면이 뜨는 경험을 자주 했는데, 이게 바로 CSS 로딩을 기다리는 시간이었던 겁니다(출처: Web.dev).
스크립트 실행
자바스크립트는 웹페이지에 동작을 부여하는 언어입니다. 버튼 클릭, 스크롤 이벤트, 데이터 요청 같은 모든 동적 기능이 자바스크립트로 구현됩니다. 문제는 자바스크립트가 DOM과 CSSOM을 모두 조작할 수 있기 때문에, 브라우저가 스크립트를 만나면 렌더링을 멈추고 스크립트를 먼저 실행한다는 점입니다.
일반적으로 알려진 대로 <script> 태그는 HTML 파일의 <head>나 <body> 어디에나 위치할 수 있지만, 위치에 따라 로딩 순서가 크게 달라집니다. <head>에 있으면 DOM 생성 전에 실행되고, <body> 끝에 있으면 DOM이 거의 완성된 뒤 실행됩니다. 최근엔 async나 defer 속성을 써서 스크립트를 비동기로 불러오는 방식도 많이 쓰입니다. async는 스크립트를 다운로드하자마자 바로 실행하고, defer는 DOM 생성이 끝난 뒤 실행합니다.
솔직히 웹페이지를 쓰면서 가장 답답했던 순간이 바로 이 부분입니다. 화면은 다 떴는데 버튼을 눌러도 반응이 없거나, 스크롤이 갑자기 멈추는 경험 말입니다. 이건 대부분 무거운 자바스크립트가 아직 실행 중이거나, 외부 라이브러리를 기다리고 있기 때문입니다. 특히 광고나 분석 스크립트가 많을수록 이런 현상이 심해집니다. 화면이 보인다고 해서 실제로 사용 가능한 상태는 아닌 거죠.
- DOM 생성: HTML을 읽어 문서 구조를 만듭니다.
- CSSOM 생성: CSS를 해석해 스타일 규칙을 정리합니다.
- 렌더 트리 구축: DOM과 CSSOM을 합쳐 화면에 그릴 요소를 결정합니다.
- 레이아웃 계산: 각 요소의 위치와 크기를 계산합니다.
- 페인트: 실제로 픽셀을 색칠합니다.
- 스크립트 실행: 자바스크립트가 동작 로직을 추가합니다.
리소스 요청과 병목
웹페이지에는 HTML, CSS, 자바스크립트 외에도 이미지, 폰트, 동영상 같은 리소스들이 포함됩니다. 브라우저는 이 리소스들을 병렬로 다운로드하지만, 모든 리소스가 똑같이 처리되는 건 아닙니다. CSS와 자바스크립트는 렌더링을 막지만, 이미지나 폰트는 뒤에서 조용히 로딩됩니다. 그래서 화면은 떴는데 이미지가 나중에 하나씩 뜨는 현상이 생기는 겁니다.
최근 브라우저들은 프리로드 스캐너(Preload Scanner)라는 기능을 씁니다. 이건 HTML을 빠르게 훑으면서 필요한 리소스를 미리 파악해서 다운로드를 시작하는 기술입니다. 덕분에 스크립트 실행 중에도 다른 리소스를 동시에 받을 수 있어서 전체 로딩 속도가 빨라집니다. 하지만 외부 도메인에서 리소스를 불러올 때는 DNS 조회, 연결 설정 같은 추가 시간이 들기 때문에 여전히 병목이 생길 수 있습니다.
경험상 가장 체감 속도에 영향을 준 건 외부 광고 스크립트였습니다. 광고 서버 응답이 느리면 그만큼 전체 페이지 로딩이 지연됩니다. 화면은 거의 다 떴는데 광고 영역만 빈 채로 한참 기다리는 경우가 많았는데, 이게 바로 외부 리소스 대기 시간 때문이었습니다. 이런 사이트는 새로고침을 여러 번 해도 소용없고, 그냥 기다리는 게 답이었습니다(출처: MDN Web Docs).
웹페이지 로딩은 단순히 파일을 다운로드하는 게 아니라, 정해진 순서에 따라 단계적으로 화면을 준비하는 과정입니다. DOM 생성부터 렌더링, 스크립트 실행까지 각 단계가 서로 영향을 주고받기 때문에, 어느 한 부분에서 지연이 생기면 전체 속도가 느려집니다. 이 구조를 이해한 뒤로 웹사이트를 볼 때 "이 사이트는 스크립트가 무거운가?" "외부 리소스가 많은가?" 같은 질문을 하게 됐습니다. 단순히 빠르다 느리다를 넘어서, 왜 느린지 구조적으로 파악할 수 있게 된 거죠. 만약 화면은 떴는데 조작이 안 된다면, 아직 스크립트 처리 중일 가능성이 높으니 조금 기다려보는 게 더 나을 수도 있습니다.
댓글
댓글 쓰기