대용량 이미지 블로킹 해결하기

camel·2024년 12월 22일

fetchpriority 성능 최적화 이미지 블로킹 이미지 최적화

✅ 개요

병원을 주 고객층으로 하는 서비스에서 이미지 템플릿 업로드 기능을 구현했습니다.
DSLR 카메라로 촬영된 고용량 이미지를 자주 다루게 되면서, 성능 최적화가 필요한 상황이 발생했습니다.

QA 팀과 함께 98MB의 고용량 이미지를 사용하여 테스트를 진행하였고, 블로킹 현상이 나타서 이를 개선하는 과정을 정리해보았습니다.

💡 레이아웃 쉬프트 관련 이슈는 다루지 않습니다.

🔍 문제 상황

현상:

이미지 URL을 img 태그에 할당하는 순간 UI 블로킹 발생
전체 페이지의 인터랙션이 일시적으로 멈추는 현상 관찰

구체적인 측정 결과:

이미지 로드 소요시간: 12초

프레임 드롭 현상:

1초와 3초 구간에서 번갈아가며 프레임 드롭 발생
전체 블로킹 구간: 약 6초

개선전에는 2.8초와 6.4초의 긴작업이 있어서 총 9.2초의 블로킹 현상이 발생했습니다.

98MB라는 극단적인 케이스였지만, 실제 운영 환경에서는 이와 비슷하지만 좀 더 약하게 발생할 수 있는 시나리오라고 판단하여 개선이 필요했습니다.
(이후 db를 확인해보니 최대 용량은 150MB였습니다.)

🤔 fetchPriority를 통한 최적화

이미지 태그의 URL 요청에 대한 성능을 분석한 결과, 네트워크 요청 단계별로 다음과 같은 특징을 보였습니다:

1. 초기 상태 (fetchPriority 적용 전)

Initial Priority: Low
처리 단계별 소요 시간:
- 초기 연결 및 대기열 진입: 24ms
- 요청 전송 및 응답 대기: 114ms
- 콘텐츠 다운로드: 4.82s
- 메인 스레드 대기: 38ms

💡 Initial Priority는 네트워크 대역폭 할당과 메인 스레드 처리 우선순위에 직접적인 영향을 미칩니다.

2. fetchPriority='high' 적용 후

Initial Priority: High
처리 단계별 소요 시간 변화:
- 초기 연결 및 대기열 진입: 24ms → 22ms
- 요청 전송 및 응답 대기: 114ms → 155ms
- 콘텐츠 다운로드: 4.82s → 3.14s (-1.7s)
- 메인 스레드 대기: 38ms → 11ms

우선순위 상향 조정으로 전체 처리 시간이 약 1.7초 감소했습니다.
추가로 fetch API를 통한 선행 요청 테스트에서도 비슷한 성능 향상을 확인했습니다.

📐 이미지 사이즈 최적화

object-fit: contain 속성 사용을 사용하여 부모 요소 크기에 맞춘 렌더링으로 레이아웃 쉬프트를 최대한 방지하였습니다.

object-fit: contain이란?
이미지의 원본 비율을 유지하면서 컨테이너 내에 전체 이미지를 표시하는 속성입니다. 단, 컨테이너를 완전히 채우지 않을 수 있습니다.

실제 이미지 태그에 그려진 이미지를 확인해보니 몇가지 문제점이 있었습니다.

문제점:

실제 표시 크기와 무관하게 원본 크기로 로드되어 불필요한 리소스 사용
렌더링된 크기 대비 지나치게 큰 원본 이미지 사용

이러한 분석을 바탕으로 이미지 리사이징 작업의 필요성이 확인되었습니다.

🖼️ 이미지 리사이징 전략

메인 스레드 블로킹을 방지하기 위해 비동기 방식의 이미지 리사이징 전략을 구현했습니다.
다음과 같이 3단계로 진행하였습니다.

이미지 로드 및 원본 비율 계산
Canvas API를 활용한 리사이징
최적화된 이미지 URL 생성

구현 코드:

const optimizeImage = async (img: HTMLImageElement, objectUrl: string): Promise<string> => {
  // 이미지가 최대 크기보다 작으면 원본 반환
  if (img.width <= IMAGE_CONFIG.MAX_SIZE && img.height <= IMAGE_CONFIG.MAX_SIZE) {
    return objectUrl;
  }
  
  // Canvas 설정
  const canvas = document.createElement('canvas');
  const ctx = canvas.getContext('2d');
  
  // 비율 계산 및 캔버스 크기 지정
  const ratio = Math.min(
    IMAGE_CONFIG.MAX_SIZE / img.width, 
    IMAGE_CONFIG.MAX_SIZE / img.height
  );
  canvas.width = img.width * ratio;
  canvas.height = img.height * ratio;
  
  // 이미지 그리기 및 최적화된 URL 생성
  ctx?.drawImage(img, 0, 0, canvas.width, canvas.height);
  return new Promise((resolve, reject) => {
    canvas.toBlob(
      (blob) => {
        if (blob) {
          URL.revokeObjectURL(objectUrl);
          const optimizedUrl = URL.createObjectURL(blob);
          resolve(optimizedUrl);
        } else {
          reject(new Error('Failed to create optimized image'));
        }
      },
      'image/jpeg',
      IMAGE_CONFIG.JPEG_QUALITY,
    );
  });
};

최적화 결과:

이미지 해상도: 16667 x 25000px → 1333 x 2000px
파일 크기: 98.3MB → 292KB (약 337배 감소)

품질 유지:

최종 렌더링 크기: 760 x 726px (동일)
JPEG 품질: 80% 설정
시각적 차이: 일반 사용자가 인지하기 어려운 수준

이미지 해상도와 파일크기를 줄임으로서 성능을 개선할 수 있었습니다.

📊 성능 개선 결과 분석

이미지 최적화 적용 전후의 성능을 여러 측면에서 비교 분석했습니다.

1. 이미지 로딩 시간

개선 전

총 소요 시간: 12초
사용자가 긴 대기 시간 경험

개선 후

총 소요 시간: 5.5초
약 54% 로딩 시간 단축

2. 프레임 드롭 현상

개선 전

1.3초 구간: 프레임 드롭
3.4초 구간: 프레임 드롭
총 프레임 드롭 시간: 4.7초

개선 후

프레임 드롭 발생 구간: 1초 미만
전반적인 UI 반응성 크게 향상

3. 작업 블로킹 시간

💡 자바스크립트의 긴 작업은 메인 스레드를 블로킹하여 사용자 인터랙션을 방해할 수 있습니다.

개선 전

첫 번째 긴 작업: 2.8초
두 번째 긴 작업: 6.4초
총 블로킹 시간: 9.2초

개선 후

단일 긴 작업: 2.7초
총 블로킹 시간 70% 감소
사용자 인터랙션 반응성 크게 개선

🎯 개선 효과 요약

이미지 로딩 시간: 12초 → 5.5초 (54% 감소)
프레임 드롭: 4.7초 → 1초 미만 (약 80% 감소)
작업 블로킹: 9.2초 → 2.7초 (70% 감소)

이러한 최적화를 통해 전반적인 사용자 경험이 크게 개선되었으며, 특히 고용량 이미지 처리 시의 성능 병목 현상을 효과적으로 해결할 수 있었습니다.

🔄 추가 최적화 고려사항

1. 이미지 URL 생성 전략: Base64 vs URL.createObjectURL

이미지 태그에 blob 데이터를 직접 전달할 수 없어, 다음 두 가지 방식을 검토했습니다:

Base64 인코딩 방식

장점:
- 별도의 메모리 관리가 불필요
- 즉시 사용 가능한 문자열 형태
단점:
- 원본 대비 약 33% 더 큰 용량
- 인코딩/디코딩 과정에서 추가 리소스 사용

URL.createObjectURL 방식 ✅

장점:
- 메모리 효율적 사용 (실제 데이터 대신 참조만 생성)
- 원본 크기 유지
단점:
- 명시적인 메모리 해제 필요
- 컴포넌트 언마운트 시 관리 필요

// 메모리 관리 예시
useEffect(() => {
  return () => {
    if (objectUrl) {
      URL.revokeObjectURL(objectUrl);
    }
  };
}, [objectUrl]);

2. 이미지 로딩 중복 방지: AbortController 활용

문제 상황:

대용량 이미지 로딩 중 다른 이미지 선택 시 이전 이미지 로딩이 완료되어 화면에 잘못 표시되는 현상

해결 방안:

abortController를 사용하여 이전 요청의 응답을 받지 않고,
현재 사용하는 응답만 받도록 작성하였습니다.

const ImageLoader = () => {
  const abortControllerRef = useRef<AbortController | null>(null);
  const optimizedUrlRef = useRef<string | null>(null);

  const loadImage = async (imageUrl: string) => {
    // 이전 요청 중단 및 메모리 정리
    if (abortControllerRef.current) {
      abortControllerRef.current.abort();
    }
    if (optimizedUrlRef.current) {
      URL.revokeObjectURL(optimizedUrlRef.current);
    }

    // 새로운 요청 설정
    abortControllerRef.current = new AbortController();
    
    try {
      const response = await fetch(imageUrl, {
        cache: 'force-cache',
        signal: abortControllerRef.current.signal
      });
      // 이미지 처리 로직...
    } catch (error) {
      if (error.name === 'AbortError') {
        console.log('이미지 로딩이 취소되었습니다.');
      }
    }
  };
  
  // ...
};

이러한 최적화를 통해 메모리 누수를 방지하고, 잘못된 이미지 표기하는 문제를 해결할 수 있었습니다.

💭 아쉬운 점과 향후 개선 방향

현재 접근 방식의 한계

현재는 이미지 최적화를 output 단계에서 처리하고 있지만, 이는 근본적인 해결책이 아닐 수 있다는 점을 깨달았습니다.
서버로 전송되는 원본 이미지의 크기가 커도 실제로 보여지는 이미지는 그렇지 않기때문에, 불필요하게 사용되고 있습니다.

더 나은 해결 방안: Input 단계 최적화

이미지 업로드 시점(input)에서 최적화를 진행하면 다음과 같은 이점이 있습니다:

서버로의 불필요한 대용량 파일 전송 방지
스토리지 자원 효율적 사용
전반적인 서비스 응답 시간 개선

개선 진행 상황

프론트엔드 리더분과 협의하여 다음과 같은 방향으로 개선을 진행하기로 했습니다:

파일 업로드 단계에서 이미지 압축 및 리사이징 구현
사용자가 업로드 전에 최적화된 이미지를 미리 확인할 수 있는 기능 추가

🎯 끝으로

이번 이미지 최적화 프로젝트를 통해 많은 것을 배우고 성장할 수 있었습니다.

병원이라는 특수한 환경에서 DSLR 카메라로 촬영한 고용량 이미지를 고려하면서, 기술적 해결책을 찾아가는 과정은 값진 경험이었습니다.

이미지 최적화에 대한 새로운 시각을 얻을 수 있었습니다.
처음에는 단순히 width와 height 속성 조정으로 해결될 것이라 생각했지만, Canvas를 활용한 실제 이미지 리사이징의 필요성과 그 효과를 직접 경험해볼 수 있었습니다.

Chrome Performance 탭을 활용한 성능 분석 경험도 좋았습니다.
구체적인 수치를 통해 개선사항을 확인해볼 수 있었습니다.

AbortController를 활용한 불필요한 네트워크 요청 제어와 Base64와 createObjectURL의 비교 분석을 통한 최적의 방법을 찾아가는 경험도 기억에 남았습니다.

끝으로 아쉬운 점도 복기하면서 더 좋은 방법까지 고려할 수 있어서 좋았습니다.
감사합니다!

출처:

HTML의 이미지
https://developer.mozilla.org/ko/docs/Learn/HTML/Multimedia_and_embedding/Images_in_HTML

JavaScript에서 이진 데이터 이해하기 : ArrayBuffer, TypedArray, Blob, File
https://bichoninthefront.vercel.app/2024-jsBinaryDataTypes#%ED%83%80%EC%9E%85%EC%9D%B4-%EC%9E%88%EB%8A%94-%EB%B0%94%EC%9D%B4%EB%84%88%EB%A6%AC-%EB%8D%B0%EC%9D%B4%ED%84%B0-blob

camel

잘부탁드립니다.

이전 포스트

왜 Object.keys는 string[] 타입을 리턴하나요?

다음 포스트

대용량 이미지 블로킹 해결하기

✅ 개요

🔍 문제 상황

🤔 fetchPriority를 통한 최적화

📐 이미지 사이즈 최적화

🖼️ 이미지 리사이징 전략

📊 성능 개선 결과 분석

1. 이미지 로딩 시간

2. 프레임 드롭 현상

3. 작업 블로킹 시간

🎯 개선 효과 요약

🔄 추가 최적화 고려사항

1. 이미지 URL 생성 전략: Base64 vs URL.createObjectURL

2. 이미지 로딩 중복 방지: AbortController 활용

💭 아쉬운 점과 향후 개선 방향

현재 접근 방식의 한계

더 나은 해결 방안: Input 단계 최적화

개선 진행 상황

🎯 끝으로

왜 Object.keys는 string[] 타입을 리턴하나요?

2024년 회고: 300, 퇴사, 이직, 계획

0개의 댓글

관련 채용 정보