이미지 프리로딩을 구현하며 알게 된 것들

최근에 이미지를 프리로드하는 기능을 만들었다. 페이지네이션으로 이미지를 불러오는 작업은 익숙했지만, 다른 화면에서 미리 이미지를 가져오는 건 처음이라 구현하면서 새로 알게 된 부분들을 간단히 정리해 보았다. 실제로 적용한 내용도 있고, 개인적으로 정리해 본 내용도 있다. ( +이번 작업을 진행하면서 브라우저가 이미지를 어떻게 로드하는지 궁금해 HTML Living Standard를 많이 참고했다.)

1. 브라우저의 이미지 요청 사이클

브라우저가 이미지를 화면에 표시하기까지의 단계는 다음과 같다.

Fetch → Decode → Paint → Composite

• Fetch: 네트워크/캐시에서 이미지 파일(압축 데이터)을 가져옴
• Decode: 가져온 압축 데이터를 화면에 뿌릴 수 있는 비트맵으로 풀어냄
• Paint: 요소에 비트맵을 칠함
• Composite: 여러 레이어를 GPU에서 합성해서 최종 프레임을 만듦

const img = new Image();
img.src = 'https://example.com/image.png';

이 한 줄이 실행되면 브라우저는 내부적으로 ‘image request’라는 요청 객체를 생성해 캐시를 확인하고, 필요시 네트워크를 통해 이미지를 가져오기 시작한다. 이 요청은 자바스크립트의 fetch()와는 별개의 시스템에서 처리되지만, 캐시 확인, 우선순위 스케줄링, 오류 처리 같은 단계는 유사하게 거친다. 

img.src = URL
  └─ 이미지 업데이트 알고리즘 실행
      ├─ "list of available images" 확인
      ├─ HTTP 캐시 확인
      ├─ 네트워크 요청 시작 (fetchPriority 반영)
      ├─ 데이터 수신 완료
      ├─ load 이벤트 발생 ← 다운로드 완료, 디코딩 X
      │
      └─ DOM 추가 & Paint 트리거 시점
          ├─ 디코딩 필요 확인
          │   ├─ decode() 호출했으면 → 캐시된 비트맵 사용
          │   └─ 안 했으면 → 지금 동기 디코딩 (메인 스레드 블로킹!)
          ├─ Paint (비트맵을 레이어에 그림)
          └─ Composite (GPU 합성)

+ "list of available images"는 HTML 표준에 정의된 브라우저 내부 캐시 구조로, 이미 요청된 이미지의 상태(다운로드 중, 완료, 실패 등)를 추적한다. 같은 URL의 이미지를 다시 요청하면 네트워크 없이 이 리스트에서 재사용한다. 

2. 디코딩과 표시 — decoding vs decode()

이미지는 다운로드 후 화면에 표시되기 전에 디코딩과정이 필요하다. 이는 압축된 바이너리를 GPU가 렌더링 가능한 비트맵으로 변환하는 단계다.

• img.decoding = 'async'
  → 브라우저에 “비동기로 디코딩해도 된다”는 힌트를 준다.
• await img.decode()
  → 디코딩이 완료될 때까지 명시적으로 기다린다.
  즉, decoding은 힌트이고 decode()는 실행 의미로 이해하면 된다. 아래 패턴을 쓰면 렌더링 플래시 없이 부드럽게 이미지를 표시할 수 있다.

const img = new Image();
img.decoding = 'async';
img.src = '/image.png';
await img.decode();
document.body.appendChild(img); // 완전히 디코딩된 상태에서 표시

3. 네트워크 우선순위 - fetchPriority

fetchPriority 속성은 브라우저의 네트워크 스케줄러에게 리소스 우선순위 힌트를 줄 수 있다.

img.fetchPriority = 'low'; 
img.fetchPriority = 'high';

• low: 우선순위를 낮춰 다른 리소스 로딩을 방해하지 않음
• high: 초기 렌더링에 중요한 리소스
• auto: 브라우저의 판단에 따름

4. 브라우저의 유휴 시간 활용 — requestIdleCallback

브라우저는 보통 초당 60 프레임 속도로 화면을 그리는데, 만약 어떤 프레임에서 렌더링 작업이 일찍 끝나면, 남는 시간이 생긴다. 그 짧은 여유 구간이 바로 브라우저의 유휴 시간이다. requestIdleCallback()은 바로 이 남는 시간 슬롯을 활용할 수 있게 해주는 API다.

requestIdleCallback((deadline) => {
  while (deadline.timeRemaining() > 0) {
    // idle 시간 안에서만 실행할 작업
  }
});

여기서 deadline.timeRemaining()은 현재 프레임이 끝나기 전까지 남은 시간을 밀리초 단위로 알려준다.

브라우저의 idle 스케줄링 방식

• idle time은 프레임마다 다르다 (렌더링 부하에 따라 0~10ms 수준)
• idle 콜백은 남는 시간이 있을 때만 실행된다
• idle 시간이 없으면 콜백은 다음 프레임으로 미뤄진다

만약 브라우저가 오랫동안 idle 상태에 들어가지 않으면, { timeout: 2000 } 옵션으로 "2초 안에는 반드시 실행해라" 같은 조건을 추가할 수 있다.

requestIdleCallback(preloadImages, { timeout: 2000 });

다만, 해당 API는 아직 모든 브라우저 버전에서 지원되는 것은 아니다. Electron은 내장된 Chromium 버전을 따르는데, 현재 사용 중인 Electron이 requestIdleCallback을 지원하는 Chromium을 포함하고 있어 안전하게 사용할 수 있었다.

5. 청크 단위 프리로딩

이미지를 한꺼번에 모두 요청하면 네트워크가 폭주하고, 렌더링에 필요한 리소스까지 밀릴 수 있다. 그래서 보통 청크 단위로 쪼개어 적정 병렬도만 유지하면서 순차적으로 프리로딩하기 때문에 나 또한 동일하게 적용하였다.  (아래는 간단하게 작성해 봤던 예시 코드다.) 

const PRELOAD_CONFIG = {
  // // 한 번에 요청할 이미지 개수
  IMAGE_CHUNK_SIZE: 5, 
};

async function preloadImageChunks(imageUrls: string[]): Promise<void> {
   
  let failed: string[] = [];

  for (let i = 0; i < imageUrls.length; i += PRELOAD_CONFIG.IMAGE_CHUNK_SIZE) {
    const chunk = imageUrls.slice(i, i + PRELOAD_CONFIG.IMAGE_CHUNK_SIZE);

    await Promise.all(
      chunk.map(
        url =>
          new Promise<void>(resolve => {
            const img = new Image();

            img.onload = async () => {
              // 지원된다면 디코딩 완료까지 보장
              try {
                await img.decode?.();
              } catch {}
              resolve();
            };
            img.onerror = () => {
            // 실패한 이미지 url 은 따로 저장
            failed.push(url);
            resolve();
          };

            img.src = url;
          }),
      ),
    );
  }
}