사용자가 창 닫기 전, 1초 만에 페이지 띄우는 비결

예전에 프로젝트를 진행하면서 열심히 만든 기능이 '느리다'는 이유로 외면받을 때 가장 속상하더라고요.

혹시 여러분도 이런 경험 없으신가요? 기능은 완벽한데, 페이지 로딩이 5초, 10초씩 걸려서 사용자가 다 떠나버리는 상황 말이에요. 사용자는 절대 기다려주지 않습니다. 아마존의 연구에 따르면, 로딩 시간이 단 0.1초만 느려져도 매출이 1% 감소한다고 해요.

이 글에서는 복잡하고 어려운 이론 대신, 당장 여러분의 프로젝트에 적용해서 눈에 띄는 웹 성능 최적화를 이뤄낼 수 있는 현실적인 방법 3가지를 알려드릴게요. 이 글을 다 읽고 나면, 더 이상 '느리다'는 피드백에 작아지지 않을 거예요.

1. 왜 웹 성능이 '기능'만큼 중요할까요?

우리는 종종 새로운 기능을 추가하는 데 집중한 나머지, 사용자가 그 기능을 경험하기까지의 '속도'를 간과합니다. 구글은 좋은 사용자 경험을 제공하는 웹사이트를 판단하기 위해 Core Web Vitals라는 핵심 지표를 사용하는데요, 그중 가장 중요한 지표 중 하나가 바로 LCP(Largest Contentful Paint)입니다.

LCP는 쉽게 말해 '사용자가 페이지에 접속했을 때, 화면의 가장 큰 이미지나 텍스트 블록이 표시되기까지 걸리는 시간'을 의미해요. 이 시간이 길어지면 사용자는 "아, 이 사이트는 느리구나"라고 직감적으로 느끼고, 가차 없이 뒤로 가기 버튼을 누릅니다. 즉, 아무리 멋진 기능을 만들어도 LCP가 느리면 사용자는 경험할 기회조차 갖지 못하는 거죠. 웹 성능 최적화는 더 많은 사용자를 붙잡아두기 위한 첫 번째 관문입니다.

2. 이미지 최적화, 용량만 줄이면 끝일까요?

느린 웹사이트의 주범을 찾아보면 십중팔구 '이미지'가 있습니다. 많은 프론트엔드 개발자가 이미지 압축의 중요성은 알지만, 거기서 멈추는 경우가 많아요.

✅ 차세대 포맷 WebP 사용하기

아직도 JPG나 PNG만 고집하고 있나요? WebP는 구글이 개발한 차세대 이미지 포맷으로, 같은 화질을 유지하면서도 용량은 JPG보다 약 25~35% 더 작습니다. 대부분의 최신 브라우저에서 지원하므로, 특별한 이유가 없다면 이미지 포맷을 WebP로 바꾸는 것만으로도 엄청난 성능 개선 효과를 볼 수 있습니다.

✅ Lazy Loading (지연 로딩) 적용하기

한 페이지에 이미지가 20장 있다고 가정해 봅시다. 사용자가 접속하자마자 20장을 전부 불러올 필요가 있을까요? 화면에 보이지 않는 이미지까지 처음부터 로딩하는 건 엄청난 낭비입니다. 이때 필요한 것이 바로 Lazy Loading입니다.

Lazy Loading은 사용자가 스크롤을 내려서 해당 이미지가 화면에 보일 때쯤 로딩을 시작하는 기술이에요. HTML <img> 태그에 loading="lazy" 속성 하나만 추가하면 간단하게 적용할 수 있습니다.

3. 렌더링을 막는 범인을 잡아라

웹 브라우저가 화면을 그리는 과정을 '렌더링'이라고 합니다. 그런데 어떤 코드들은 이 렌더링 과정을 중간에 멈추고 자신을 먼저 처리하라고 요구해요. 이를 렌더링 차단 리소스(Render-Blocking Resources)'라고 부르며, 주로 CSS와 JavaScript 파일이 여기에 해당합니다

✅ CSS는 head에, JavaScript는 body 맨 아래에

CSS는 화면을 어떻게 그릴지 결정하는 '설계도'이므로, 브라우저는 CSS를 전부 다운로드하고 해석하기 전까지 렌더링을 시작하지 않아요. 그래서 CSS 파일은 <head> 태그 안쪽에 두어 최대한 빨리 불러오는 게 좋습니다.
반면 JavaScript는 주로 클릭 이벤트 처리나 동적인 기능처럼 렌더링이 끝난 후에 필요한 경우가 많습니다. 만약 무거운 JavaScript 파일을 <head>에서 먼저 불러오면, 그 파일을 다운로드하고 실행하는 동안 화면은 그냥 백지로 남아있게 됩니다. 따라서 특별한 경우가 아니라면 <body> 태그가 닫히기 직전에 두는 것이 좋습니다.

✅ async와 defer 속성 활용하기

그래도 JavaScript를 일찍 불러와야 한다면, async나 defer 속성을 활용할 수 있습니다.

defer: HTML 렌더링을 막지 않고 스크립트를 다운로드한 뒤, 렌더링이 모두 끝난 후에 실행합니다. 실행 순서가 보장되어 의존성이 있는 여러 스크립트에 사용하기 좋습니다.
async: HTML 렌더링을 막지 않고 스크립트를 다운로드하고, 다운로드가 끝나면 즉시 실행합니다. 실행 순서가 보장되지 않으므로 다른 스크립트와 의존성이 없는 경우(ex. 광고, 분석 스크립트)에 사용합니다.

첫 번째 병목 현상: 반복문 안에서의 무자비한 DOM 조작

API를 통해 받은 데이터 배열을 화면에 리스트로 뿌려주는 것은 가장 흔한 작업 중 하나입니다. 많은 분들이 아래와 같이 코드를 작성하곤 합니다.

const $container = document.getElementById('list-container');
const data = Array.from({ length: 1000 }, (_, i) => `아이템 ${i + 1}`); // 1000개의 데이터

function displayItems() {
  console.time('DOM 조작 시간');
  data.forEach(itemText => {
    const $li = document.createElement('li');
    $li.textContent = itemText;
    $container.appendChild($li); // 👈 반복문 안에서 매번 DOM에 접근!
  });
  console.timeEnd('DOM 조작 시간');
}

displayItems();

이 코드는 1000개의 아이템을 화면에 잘 보여줍니다. 하지만 데이터가 수천 개로 늘어나면 눈에 띄게 버벅거리기 시작하죠.

왜 느려질까요? Reflow와 Repaint의 함정

문제는 appendChild가 반복문 안에서 1000번 호출된다는 점입니다. 브라우저가 화면을 그리는 과정은 생각보다 비용이 비쌉니다. DOM에 새로운 요소가 추가되거나 크기, 위치가 변경될 때마다 브라우저는 리플로우(Reflow)와 리페인트(Repaint)라는 과정을 거칩니다.

Reflow (리플로우): 요소의 크기나 위치가 변경될 때, 다른 요소들의 레이아웃에 미치는 영향을 다시 계산하는 과정. (가구 재배치)
Repaint (리페인트): Reflow 후, 변경된 부분을 화면에 다시 그리는 과정. (벽지 다시 칠하기)

위 코드는 <li>를 하나 추가할 때마다 "가구 재배치"와 "벽지 칠하기"를 1000번 반복하는 것과 같습니다. 이는 브라우저에게 엄청난 부담을 줍니다.

어떻게 수정해야 할까요? DocumentFragment 사용하기

이 문제를 해결하는 열쇠는 DocumentFragment입니다. DocumentFragment는 DOM의 일부를 담을 수 있는 가상의 '메모리상 DOM'입니다. 여기에 모든 변경사항을 한 번에 담아두었다가, 실제 DOM에는 단 한 번만 추가하는 방식입니다.

const $container = document.getElementById('list-container');
const data = Array.from({ length: 1000 }, (_, i) => `아이템 ${i + 1}`);

function displayItemsOptimized() {
  console.time('최적화된 DOM 조작 시간');
  
  const fragment = document.createDocumentFragment(); // 👈 가상의 컨테이너 생성
  
  data.forEach(itemText => {
    const $li = document.createElement('li');
    $li.textContent = itemText;
    fragment.appendChild($li); // 👈 메모리상에서만 작업
  });

  $container.appendChild(fragment); // 👈 실제 DOM 접근은 단 한 번!
  
  console.timeEnd('최적화된 DOM 조작 시간');
}

displayItemsOptimized();

최적화는 실제로 어떻게 동작하나요?

DocumentFragment는 실제 DOM 트리의 일부가 아닙니다. 따라서 fragment 내부에 요소를 아무리 추가하고 변경해도 Reflow나 Repaint가 발생하지 않습니다. 모든 <li> 요소가 준비된 fragment를 마지막에 $container에 appendChild하는 순간, 브라우저는 단 한 번의 Reflow/Repaint만으로 모든 변경사항을 화면에 그려냅니다. 1000번의 비효율적인 작업을 단 한 번의 효율적인 작업으로 바꾼 셈이죠.

두 번째 병목 현상: 수백, 수천 개의 이벤트 리스너

이제 위에서 만든 리스트의 각 아이템을 클릭할 수 있게 만들어야 합니다. 가장 직관적인 방법은 각 <li> 요소에 addEventListener를 추가하는 것이겠죠.

// ... displayItems() 함수 내부 ...
data.forEach(itemText => {
  const $li = document.createElement('li');
  $li.textContent = itemText;
  
  // 👈 1000개의 요소에 각각 이벤트 리스너를 등록
  $li.addEventListener('click', () => {
    console.log(`${itemText} 클릭됨!`);
  });
  
  $container.appendChild($li);
});

왜 느려질까요? 메모리 누수

이벤트 리스너 하나하나는 작은 함수 객체입니다. 하지만 이것이 1000개, 10000개가 되면 무시할 수 없는 메모리를 차지하게 됩니다. 이는 특히 저사양 기기나 모바일 환경에서 페이지 전체의 반응성을 떨어뜨리는 주범이 됩니다. 또한, 나중에 동적으로 아이템이 추가될 때마다 또 이벤트 리스너를 붙여줘야 하는 번거로움도 있습니다.

어떻게 수정해야 할까요? 이벤트 위임(Event Delegation) 활용하기

해결책은 이벤트 위임 패턴에 있습니다. 각 자식 요소(<li>)에 이벤트를 하나씩 달아주는 대신, 그들의 부모 요소(<ul> 즉, $container)에 단 하나의 이벤트 리스너를 다는 것입니다.

최적화된 코드 예시

const $container = document.getElementById('list-container');

// ... (displayItemsOptimized 함수로 리스트를 렌더링한 후) ...

// 👈 부모 요소에 단 하나의 이벤트 리스너를 등록!
$container.addEventListener('click', (event) => {
  // 클릭된 요소가 LI가 맞는지 확인
  if (event.target.tagName === 'LI') {
    console.log(`${event.target.textContent} 클릭됨! (위임)`);
  }
});

최적화는 실제로 어떻게 동작하나요?

이는 이벤트 버블링(Event Bubbling)이라는 브라우저의 동작 원리를 이용한 것입니다. 자식 요소에서 발생한 이벤트는 DOM 트리를 따라 부모 요소로, 또 그 부모 요소로 계속해서 전파되는(마치 물거품처럼 올라가는) 특징이 있습니다.

우리는 이 원리를 이용해 부모인 $container에서 모든 자식(<li>)의 클릭 이벤트를 '잡아채는' 것입니다. event.target 프로퍼티를 사용하면 실제로 이벤트가 시작된 요소를 정확히 알 수 있습니다. 결과적으로 단 하나의 이벤트 리스너만으로 수천 개의 자식 요소를 모두 제어할 수 있게 되어, 메모리 사용량을 획기적으로 줄이고 코드도 훨씬 깔끔해집니다.

🤯 이것만은 피하세요!

가장 흔히 하는 실수 중 하나는 브라우저 캐싱(Browser Caching)을 전혀 고려하지 않는 것입니다. 사용자가 우리 웹사이트에 재방문했을 때, 로고 이미지나 CSS 파일처럼 바뀌지 않는 파일들을 또 다운로드하게 만드는 건 불필요한 낭비입니다.

서버 설정을 통해 이런 정적 파일(Static Assets)에 적절한 캐시 정책을 적용하면, 브라우저는 파일을 한 번 다운로드한 뒤 특정 기간 동안 메모리나 디스크에 저장해 두고 재사용합니다. 이는 재방문 시 페이지 로딩 속도를 비약적으로 향상합니다. 웹팩(Webpack) 같은 번들러를 사용한다면 파일 이름에 해시(hash)를 추가하여 캐시를 효율적으로 관리할 수 있으니 꼭 확인해 보세요.

'😺JS & TS' 카테고리의 다른 글

"코딩 1도 몰라도 OK! 10분 만에 내 디스코드 서버에 봇 만들기" (0)	2025.10.01
TypeScript가 느려지는 N가지 이유: 컴파일 성능 최적화 실전 가이드 (3)	2025.08.30
타입스크립트 타입 호환성 (4)	2025.08.28
🚀 JavaScript this와 바인딩 완벽 가이드 (2)	2025.08.26
🚀 TypeScript와 Tailwind CSS로 개발 환경 구축 (1)	2025.08.26

1. 왜 웹 성능이 '기능'만큼 중요할까요?

2. 이미지 최적화, 용량만 줄이면 끝일까요?

3. 렌더링을 막는 범인을 잡아라

첫 번째 병목 현상: 반복문 안에서의 무자비한 DOM 조작

어떻게 수정해야 할까요? DocumentFragment 사용하기

최적화는 실제로 어떻게 동작하나요?

두 번째 병목 현상: 수백, 수천 개의 이벤트 리스너

최적화는 실제로 어떻게 동작하나요?

🤯 이것만은 피하세요!

'😺JS & TS' 카테고리의 다른 글

티스토리툴바