Intersection Observer 로 화면에 보이는 부분만 로딩하기 (feat. Lazy loading)

 

🖥️ 최근 회사에서 개발하던 기능 중 요소의 가시성에 따라 API 를 호출해야하는 작업이 있었습니다. 
기존에는 페이지에 진입하는 순간 관련 API를 모두 호출하여 화면에 그려주는 방식으로 구현이 되어있었는데요,
해상도나 유저의 세팅 상태에 따라 보이지 않는 기능의 API까지 전부 호출하던 부분이 비효율적이라고 판단되어, 일반적으로는 이미지를 Lazy loading 하는데에 주로 쓰이는 Intersection Observer API 를 활용하여 서버로 호출하는 API 자체도 Lazy loading 을 시도해보았고, 관련 내용을 공유해보려고 합니다. 

 
 
 

Lazy loading 이란?

 
Lazy loading 은 '지연 로딩', 즉 리소스를 식별하여 필요할 때만 로드하는 전략입니다. 
 
웹이 발전함에 따라 사용자에게 전송되는 assets의 수와 크기는 엄청나게 증가했습니다. 이 문제를 해결하는 데 사용할 수 있는 방법 중 하나가 렌더링이 발생하는 데 중요하지 않은 리소스를 지연 로드하여, 렌더링 경로 길이를 줄이는 것입니다.
지연 로딩은 애플리케이션에서 여러 순간에 발생할 수 있지만 일반적으로 스크롤 및 탐색과 같은 일부 사용자 상호 작용에서 발생합니다.

 
 가장 일반적으로 쓰이는 예시는 쇼핑몰이나 블로그 등 타임라인 형태로 많은 이미지와 함께 랜더링되는 서비스인 경우에 이미지에 지연로딩 처리를 하여  경우가 많습니다. 기본적으로 CSS는 렌더링 차단 리소스로 취급되기 때문에 브라우저는 CSSOM이 구성될 때까지 처리된 콘텐츠를 렌더링하지 않습니다. 따라서 CSS는 가능한 한 빨리 전달되어야 합니다. 따라서 브라우저가 DOM 및 CSSOM을 완료하고, 렌더링 트리를 구축하고, 표시되는 모든 콘텐츠의 스타일을 계산하고, 모든 렌더 트리 요소의 위치와 크기를 정의하기까지의 과정에서 불필요한 컨텐츠의 로딩을 최적화 하기 위해서 지연 로딩의 개념이 탄생한 것이죠. 
 

<img src="image.jpg" alt="..." loading="lazy" />
<iframe src="video-player.html" title="..." loading="lazy"></iframe>

 
 사실 이번에 저의 경우엔 브라우저 로딩을 최적화하기 위한 목적으로 지연 로딩을 사용한 것은 아닙니다. 브라우저에 그려지는 콘텐츠를 최적화하기 위해 '필요한 리소스만 렌더링한다' 는 위 개념에서 인사이트를 얻어, '보이지 않는 수많은 값들을 한번에 불러오는건 비효율적이니, 화면에 그려지는 부분만 API 호출을 먼저 하면 되지 않을까?' 라는 생각을 하게 되었고, Lazy loading 을 위해 쓰이는 방법 중 저의 케이스에 도입해보기에 적합하다고 판단된 Intersection Observer API 를 활용하게 된 경우이죠. 보편적으로 소개되는 '이미지를 지연로딩하는 경우'가 아니더라도 Intersection Observer 를 다양하게 활용할 수 있다는 것을 소개하는 정도의 글로 이해해주시면 좋을 것 같습니다. 
 
 
 
 

Intersection Observer API 란?

 
Intersection Observer API는 타겟 요소와 상위 요소 또는 최상위 document 의 viewport 사이의 intersection 내의 변화를 비동기적으로 관찰하는 방법입니다. 공식문서에서 소개하는 활용 케이스는 아래와 같습니다. 저의 경우는 네번째에 해당이 되겠네요.
 

• 페이지가 스크롤 되는 도중에 발생하는 이미지나 다른 컨텐츠의 지연 로딩.
• 스크롤 시에, 더 많은 컨텐츠가 로드 및 렌더링되어 사용자가 페이지를 이동하지 않아도 되게 하는 infinite-scroll 을 구현.
• 광고 수익을 계산하기 위한 용도로 광고의 가시성 보고.
• 사용자에게 결과가 표시되는 여부에 따라 작업이나 애니메이션을 수행할 지 여부를 결정.

과거에 intersection 감지를 구현하면 영향을 받는 모든 요소를 알기 위해서 Element.getBoundingClientRect()와 같은 메서드를 호출하는 여러 이벤트 핸들러와 루프가 얽혀있었습니다. 화면의 크기를 먼저 계산하고, 요소의 위치를 계산하는 등의 모든 코드가 메인 스레드에서 실행되기 때문에, 이 중 하나라도 성능 문제를 일으킬 수 있고 이러한 계산 로직들과 함께 페이지가 로드되면 상황이 더욱 나빠질 수 있었습니다.
 

하지만 Intersection Observer API 는 감시하고자 하는 요소가 다른 요소(viewport)에 들어가거나 나갈때 또는 요청한 부분만큼 두 요소의 교차부분이 변경될 때 마다 실행될 콜백 함수를 등록할 수 있습니다. 즉, 요소의 교차를 지켜보기 위해 메인 스레드를 사용할 필요가 없어지고, 브라우저는 원하는 대로 교차 영역 관리를 최적화 할 수 있습니다. 아직까지는 정확히 몇 픽셀이 겹쳐졌고 어떠한 픽셀이 겹쳐졌는지는 알 수가 없지만, "N% 정도 교차하는 경우 상호작용이 이루어져야한다." 와 같은 경우엔 사용이 가능합니다.

 
 
 

활용 방법

 

1. Observer 생성

let options = {
  root: document.querySelector('#관찰요소를포함한영역'),
  rootMargin: '0px',
  threshold: 0.7
}

let observer = new IntersectionObserver(callback, options);

 

1) root

대상 객체의 가시성을 확인할 때 사용되는 뷰포트 요소입니다. 이는 관찰하고자하는 대상 객체의 조상 요소여야 합니다. 기본값은 브라우저 뷰포트이며, root 값이 null 이거나 지정되지 않을 때 기본값으로 설정됩니다.
 

2) rootMargin

root 가 가진 여백으로, CSS의 margin 속성과 유사합니다. 기본값은 0입니다.
 

3) threshold

observer의 콜백이 실행될 대상 요소의 가시성 퍼센티지를 나타내는 단일 숫자 혹은 숫자 배열입니다. 만일 50%만큼 요소가 보여졌을 때를 탐지하고 싶다면, 값을 0.5로 설정하면 됩니다. 혹은 25% 단위로 요소의 가시성이 변경될 때마다 콜백이 실행되게 하고 싶다면 [0, 0.25, 0.5, 0.75, 1] 과 같은 배열을 설정 할 수도 있습니다. 기본값은 0이고, 0으로 설정하는 경우는 대상 요소가 1픽셀이라도 보이면 바로 콜백이 실행됨을 의미합니다. 그리고 반대로 1.0은 요소의 모든 픽셀이 화면에 노출되기 전에는 콜백을 실행시키지 않음을 의미합니다.

 
 
 
 

2. 관찰할 요소 타겟팅

let target = document.querySelector('#관찰할요소');
observer.observe(target);

 
 

3. callback 

이제는 관찰할 요소가 1번에서 지정한 옵션의 임계값을 충족할 때마다 콜백이 호출됩니다.

callback(entries, observer) {
  entries.forEach(entry => {
  
    // 관찰되는 요소들이 entries 로 들어오고, entry 로 각각의 요소의 값을 확인할 수 있습니다. 
    // target element:
    //   entry.boundingClientRect
    //   entry.intersectionRatio
    //   entry.intersectionRect
    //   entry.isIntersecting
    //   entry.rootBounds
    //   entry.target
    //   entry.time
    
    
    // 그리고 우리는 아래의 형태로 콜백을 활용할 수 있는 것입니다.
    if (entry.intersectionRatio >= 0.75) { // 관찰 대상이 viewport 안에 들어온 경우
        this.isIntersecting = true;
        console.log('이제 75% 눈에 보이니까 할일을 해라.')
        this.action();
    } else if (!entry.isIntersecting) {  // 관찰 대상의 교차 상태가 false 일 (보이지 않는) 경우
        this.isIntersecting = false;
    }
    
  });
};

회사의 코드를 가져올 수는 없어 콜백의 부분의 구조를 가져와보았습니다.
 
저의 경우엔 클래스형으로 구현된 컴포넌트에 위 콜백 함수를 넣어놓고, 컴포넌트가 만들어지는 순간 해당 함수를 콜백으로 등록한 옵저버를 생성시켰습니다. 그리고 해당 컴포넌트가 75퍼센트 이상 뷰포트에 들어오면 action 함수를 호출하는 형태로 구현을 하고, 중복실행을 방지하기 위한 플래그 값으로 isIntersecting 를 설정하여 action 함수가 중복실행되지 않도록 구현했습니다. 참 쉽죠!!?
 
 
 

마치며

프론트엔드 성능 최적화를 위해 Intersection Observer 를 활용하는 방법을 소개해 보았습니다.
실제로 해상도에 따라 보이는 요소만 골라 API 를 호출하도록 최종 구현된 모습을 이해를 위해 예시로 넣고 싶었지만, 아직 서비스에서 전체 유저에게 오픈된 기능이 아니라 아쉽게도 넣지 못했습니다. 추후 해당 기능이 성공적으로 오픈되면 어떤 형태로 운영환경에서 동작중인지, 혹시라도 위 API 를 현업에서 활용할때 더 고려할 수 있는 부분은 없는지에 대한 내용으로 보완해서 돌아오겠습니다. 감사합니다.
 
 
 
(위 내용에서 부족한 부분을 발견했거나 추가 의견 혹은 경험이 있으시다면, 언제든지 댓글 대환영입니다 🙌🏻)