[WEB_DEV] Lazy load images and <iframe> elements

로선생·2025년 8월 12일

균형

어처피 할거라면 공부와 부담되지 않는 취미를 가지자
회사에서는 완벽한 일과 완벽한 사이드 잡을 원함..
다들 슈퍼맨인가.. 사이드 프로젝트
잘하는 분들 너무 많다 ㅠ ㅠ
회사에서는 확실히 잘 하는 사람에게 마이크가 많이 간다.. 그들을 부러워하고,, 부러워하고 ,,
그래도 나는 벅뚜벅뚜 하던 공부 계속 하자
항상 하는 생각: 6년차에 혼나기보다 그냥 지금 혼나는 것이 낫다

한 주간 작업

Figma 플러그인

이번주 내용

이미지와 <iframe> 요소는 다른 유형의 리소스보다 더 많은 대역폭bandwidth을 소비하는 경우가 많다. <iframe> 요소의 경우, 그 안에 있는 페이지를 로드하고 렌더링하는 데 상당한 추가 처리 시간이 소요될 수 있다.

c.f. 대역폭? 컴퓨터 공학에서는 데이터의 최대 전송 속도를 대역폭이라고 한다.

이미지의 지연 로딩의 경우, 초기 뷰포트 외부에 있는 이미지의 로딩을 지연시키는 것이 초기 뷰포트 내의 더 중요한 리소스에 대한 대역폭 경쟁을 줄이는 데 도움이 될 수 있다.
Largest Contentful Paint(LCP)를 개선할 수 있다.

부연되는 장점

초기 로딩 속도 향상
데이터 절약
리소스 최적화

LCP란 페이지의 주요 콘텐츠가 로드되었을 가능성이 높은 시점을 표시하며,
사용자가 페이지에 처음 접속한 시점부터 
뷰포트에 보이는 가장 큰 이미지, 텍스트 블록, 또는 동영상의 렌더 시간을 보고한다. 
이는 중요한 안정적인 Core Web Vital 지표 중 하나이다.

중요 포인트: LCP는 이전 페이지의 언로드 시간, 연결 설정 시간, 
리디렉션 시간, 그리고 Time To First Byte(TTFB) 지연 시간까지 포함한다.

<iframe> 의 경우 자체 하위 리소스를 가진 완전히 별개의 HTML 문서이기 때문에 지연 로딩을 통해 페이지의 다음 페인트와의 상호작용(INP)을 개선시킬 수 있다.

INP는 사용자가 페이지를 방문하는 동안 발생하는 모든 클릭, 탭,
키보드 상호작용의 지연 시간을 관찰하여 페이지의 전반적인 반응성을 평가하는 지표

그럼 어떻게 지연시킬 수 있냐?

이미지: 로딩 속성 넣기

loading속성은 <img> 요소에 추가되어 브라우저가 이미지를 어떻게 로드해야 하는지 알려줄 수 있다. 이는 대부분의 브라우저에서 지원되는 속성이다.

"eager"는 브라우저에게 이미지가 초기 뷰포트 외부에 있더라도 즉시 로드해야 함을 의미. (로딩 속성의 기본값)
"lazy"는 이미지가 보이는 뷰포트에서 설정된 거리 내에 있을 때까지 이미지 로딩을 지연시킨다.

초기 뷰포트에 있는 이미지를 지연 로딩하지 않기

loading="lazy" 속성은 초기 뷰포트 외부에 위치한 <img> 요소에만 추가해야 한다.

그러나 페이지가 렌더링되기 전에 요소가 뷰포트 내에서 상대적으로 정확한 위치를 아는 것은 복잡하다. PC, MO ... 등등의 케이스도 고려해야 한다.

그러나 모든 뷰포트의 상단에 위치할 가능성이 높은 이미지는 LCP 후보가 되므로 지연 로딩 속성을 생략해야 한다.

loading="lazy"를 가진 이미지가 화면 안에 있더라도 즉시 로드되지 않고, CSS 레이아웃 계산이 끝난 뒤에야 네트워크 요청을 시작한다.

순서
1. 브라우저는 HTML을 읽으면서 이미지나 스크립트 같은 리소스를 미리 찾기 위해 preload scanner를 사용한다.
2. 일반 <img> (lazy가 아닌)는 preload scanner가 발견하자마자 요청을 시작한다. (img 다운로드 시작/ CSS 요청 전이라도 네트워크 요청 이미 진행)
3. 하지만 <img loading="lazy">는 프리로드 스케너가 발견해도 바로 다운로드 하지 않는다. 먼저 모든 CSS 파일을 다운로드 → 파싱 → 적용한 이후 최종 레이아웃에서 이미지가 뷰포트 안에 있는지 확인한 후. ㅔ트워크 요청을 시작한다.
4. CSS 파일이 많거나 크면 이미지 로드가 늦어져 LCP(최대 콘텐츠 페인트)에 악영향을 줄 수 있다.

`<iframe>`도 로딩 속성 넣기

<iframe> 요소는 본질적으로 최상위 문서 내에 로드된 전체 HTML 문서이므로, 상당한 수의 하위 리소스, 특히 JavaScript를 포함할 수 있다.
이를 뷰포트에서 보일 때까지 지연 로딩하면 상당한 데이터를 절약하고 최상위 페이지 로드에 필요한 중요한 리소스의 로딩을 개선할 수 있으며, INP에 상당한 영향을 미칠 수 있다.

페이지의 접힌 부분 아래에 <iframe>이 있는 경우, 이를 지연 로딩하는 것을 강력히 고려해야 한다.

<iframe> 요소의 로딩 속성은 모든 주요 브라우저에서 지원되며, 로딩 속성의 값과 동작은 <img> 요소의 로딩 속성과 동일:

"eager"는 브라우저에게 <iframe> 요소의 HTML과 하위 리소스를 즉시 로드하도록 알림(기본값)
"lazy"는 <iframe> 요소의 HTML과 하위 리소스를 뷰포트에서 미리 정의된 거리 내에 있을 때까지 로딩을 지연시킨다.

Facades

페이지 로드 시 무거운 리소스를 즉시 불러오지 않고, 사용자와의 실제 상호작용이 발생할 때만 불러오는 패턴

유튜브 영상 Facade 예시

페이지 로드 시 <iframe> 대신 정적 이미지(썸네일) + 재생 버튼 아이콘 표시
사용자가 클릭하면 <iframe>로 교체 → 유튜브 영상 및 관련 JS 리소스 로드 시작

라이브러리

Intersection Observer API 특정 요소가 뷰표트와 교차하는지를 비동기적으로 감지할 수 있는 브라우저의 API

리소스 힌트를 주자: 프리패치, 프리렌더, 프리캐시

소스 로딩을 지연시키면 필요할 때 리소스를 다운로드하여 초기 페이지 로드 시 네트워크 및 CPU 사용량을 줄일 수 있지만, 필요한 리소스가 이미 로드되지 않은 경우 후속 상호작용에 지연이 발생할 수 있다.

이러한 균형을 찾기 위해 여러 방법 중 리소스를 미리 가져오기, 전체 페이지를 사전 렌더링하기, 서비스 워커를 사용하여 리소스를 사전 캐싱하는 등의 기술을 다뤄보자.

Prefetch resources needed in the near future at low priority

리소스 힌트: 브라우저야 미리 준비해줘

리소스 힌트인 <link rel="prefetch">를 사용하여 이미지, 스타일시트 또는 JavaScript 리소스를 포함한 리소스를 미리 가져올 수 있다. prefetch 힌트는 브라우저에게 리소스가 가까운 미래에 필요할 가능성이 있음을 알린다.

prefetch 힌트가 지정되면 브라우저는 현재 페이지에 필요한 리소스와 경쟁하지 않도록 최저 우선 순위로 해당 리소스에 대한 요청을 시작할 수 있다.

prefetch 리소스 힌트는 단지 힌트일 뿐이다. 브라우저는 네트워크 품질, 시스템 수준의 기본 설정 또는 기타 요인에 따라 prefetch 힌트를 수용할지 여부를 결정할 수 있다.

리소스를 미리 가져오면 사용자가 가까운 미래에 필요한 리소스를 다운로드할 필요가 없으므로 사용자 경험이 개선된다. 리소스는 필요할 때 디스크 캐시에서 즉시 검색할 수 있다.

여기서 말하는 디스크 캐시(disk cache)는 브라우저가 사용자 로컬 디스크(하드디스크나 SSD)에 저장해 두는 캐시 공간

디스크 캐시란?
브라우저는 웹 리소스(HTML, CSS, JS, 이미지 등)를 네트워크로 내려받은 뒤, 로컬 디스크에 파일 형태로 저장해 둡니다.
이렇게 저장된 캐시를 디스크 캐시(disk cache)라고 부릅니다.
다음에 같은 리소스를 요청할 때, 네트워크 대신 이 로컬 저장본을 바로 불러옵니다.

. 디스크 캐시 위치
OS와 브라우저마다 다르지만, 일반적으로는:
Chrome (macOS): ~/Library/Caches/Google/Chrome/Default/Cache
Chrome (Windows): C:\Users\<사용자>\AppData\Local\Google\Chrome\User Data\Default\Cache
Firefox: 프로필 폴더 안의 cache2 디렉토리

<head>
  <!-- ... -->
  <link rel="prefetch" as="script" href="/date-picker.js">
  <link rel="prefetch" as="style" href="/date-picker.css">
  <!-- ... -->
</head>

HTML 파싱 & 리소스 발견
브라우저가 를 발견
해당 리소스는 "곧 필요할 수 있으니, 현재 페이지 로딩이 끝난 뒤에 미리 받아도 된다"는 힌트로 인식
현재 페이지 필수 리소스 우선 로드
HTML, CSS, JS, 이미지 등 현재 페이지 표시·동작에 꼭 필요한 리소스를 먼저 로드
이 단계에서 prefetch 리소스는 대기 상태
브라우저 idle(유휴) 상태 감지
페이지 필수 리소스 다운로드 완료 & CPU 작업 여유가 생김
네트워크도 한가하면 브라우저가 prefetch 다운로드 시작
다운로드 우선순위: 최하(priority lowest)

컴퓨터 처리 장치에서 유휴 또는 아이들(idle)은 어떠한 프로그램에 의해서도 사용되지 않는 상태를 말한다.

리소스 디스크 캐시에 저장
받은 파일은 disk cache에 저장
현재 페이지에서는 즉시 쓰이지 않음
미래 시점에 필요해질 때 사용
예: 다음 화면에서 date-picker 기능이 실행될 때 /date-picker.js와 /date-picker.css 요청 발생
브라우저는 네트워크 대신 disk cache에서 즉시 로드
네트워크 지연 없이 바로 실행 → UX 개선

prefetch는 Safari를 제외한 모든 최신 브라우저에서 지원되지만, Safari에서는 기능 플래그를 통해서만 사용할 수 있다.

미래 탐색 속도를 높이기 위해 페이지를 미리 가져오기

HTML 문서를 가리킬 때 as="document" 속성을 지정하여 페이지와 모든 하위 리소스를 미리 가져올 수도 있다:

<link rel="prefetch" href="/page" as="document">

단,

교차 출처(cross-origin) 문서 prefetch는 피해야 한다.로 **다른 도메인(출처)**의 HTML 문서를 미리 불러오면 **중복 요청(bug)**이 발생하는 이슈가 있다.

<link rel="prefetch" href="https://other-site.com/page.html">

→ 브라우저가 한 번 prefetch로 받음
→ 사용자가 실제 페이지로 이동할 때 다시 네트워크 요청 발생 (prefetch 캐시를 재사용 못하는 경우)
→ 불필요하게 두 번 다운로드 → 대역폭 낭비

개인화된 same-origin 문서도 피하라

로그인 상태에서 서버가 동적으로 생성하는 HTML(개인화된 콘텐츠)은 보통 캐시 안 됨

prefetch해도 디스크 캐시에 저장되지 않거나, 나중에 쓸 때 재요청 발생 가능성 큼

<link rel="prefetch" href="/my-dashboard">

→ 사용자 전용 HTML이므로 캐시 불가 → 결국 나중에 또 다운로드 → bandwidth 낭비

prefetch는 재사용 가능성이 높고 캐시 가능한 정적 리소스에만 써야 한다.

Prerender pages

프리렌더: 다음 페이지를 보이지 않는 백그라운드 탭에서 미리 완전히 렌더링하는 기술이다.

리소스를 미리 가져오는 것 외에도 사용자가 페이지로 탐색하기 전에 페이지를 사전 렌더링하도록 브라우저에 힌트를 줄 수도 있다. 이렇게 하면 페이지와 리소스가 백그라운드에서 가져오고 처리되므로 거의 즉각적인 페이지 로드를 제공할 수 있다.

사전 렌더링은 Speculation Rules API를 통해 지원된다:

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "list",
      "urls": ["/page-a", "page-b"]
    }
  ]
}
</script>

전체 사전 렌더링은 사전 렌더링되는 페이지의 JavaScript도 실행한다. JavaScript는 상당히 크고 계산 비용이 많이 드는 리소스 유형일 수 있으므로, prerender는 사용자가 사전 렌더링된 페이지로 탐색할 의도가 확실한 경우에만 신중하게 사용하는 것이 좋다.

cpu 메모리 등등을 가장 많이 씀
GA 같은 분석 툴 혼란 야기할 수 있음.

Precache: 서비스 워커를 사용한 캐싱

프리캐시는 서비스워커를 사용하여 앱의 핵심 리소스를 캐시에 미리 저장하는 기술이다. PWA에서 주로 사용된다.

서비스 워커 실행 시 지정된 파일 목록 다운로드 하여 캐시 스토리지에 저장하고, 이후 사용자가 페이지 요청하면 네트워크 안 거치고 캐시에서 직접 리소스 가져옴.

workBox 등의 라이브러리를 사용하면 쉽게 구현 가능하다

서비스 워커(Service Worker)는 브라우저와 서버 사이에서 동작하는, 웹 페이지와 별개로 실행되는 백그라운드 자바스크립트 코드이다. 브라우저와 서버 사이에서 중간에서 요청을 가로채서 처리하는 역할을 한다.
웹 앱에 네트워크 요청 가로채기, 캐싱, 푸시 알림 같은 기능을 추가할 수 있게 해준다.

서비스 워커의 사전 캐싱(pre-caching)은 서비스 워커가 설치될 때 필요한 정적 자원들을 서비스 워커 설치 시점에 다운로드해서 캐시에 저장하는 전략

서비스 워커를 사용하여 리소스를 추측적으로 미리 가져올 수도 있습니다. 서비스 워커 사전 캐싱은 Cache API를 사용하여 리소스를 가져오고 저장할 수 있으며, 브라우저가 네트워크에 접속하지 않고 Cache API를 사용하여 요청을 제공할 수 있습니다.
이 패턴은 리소스가 서비스 워커 캐시에 배치되면 요청 시 거의 즉시 가져오기 때문에 매우 효과적이다.

슬랙웹은 모든 자원들이 서비스 워커로 떨어짐 0ㅇ0
새로고침해도 받았던 것 들이 서비스 워커에 많이 가있고, 캐시 스토리지에 파일들이 굉장히 많음.

next link component > prefetch로 설정한 링크는 해당 페이지의 정보를 미리 가져오는 기능이 있음.

로선생

이제는 이것저것 먹어요

이전 포스트

[WEB_DEV] 웹 폰트와 코드 스플리팅 + 업무고민이 살짝 첨가된

다음 포스트

[WEB_DEV] Lazy load images and <iframe> elements

균형

한 주간 작업

이번주 내용

그럼 어떻게 지연시킬 수 있냐?

이미지: 로딩 속성 넣기

초기 뷰포트에 있는 이미지를 지연 로딩하지 않기

`<iframe>`도 로딩 속성 넣기

Facades

라이브러리

리소스 힌트를 주자: 프리패치, 프리렌더, 프리캐시

Prefetch resources needed in the near future at low priority

미래 탐색 속도를 높이기 위해 페이지를 미리 가져오기

Prerender pages

Precache: 서비스 워커를 사용한 캐싱

[WEB_DEV] 웹 폰트와 코드 스플리팅 + 업무고민이 살짝 첨가된

[WEB_DEV] Web worker

0개의 댓글

[WEB_DEV] Lazy load images and <iframe> elements

균형

한 주간 작업

이번주 내용

그럼 어떻게 지연시킬 수 있냐?

이미지: 로딩 속성 넣기

초기 뷰포트에 있는 이미지를 지연 로딩하지 않기

<iframe>도 로딩 속성 넣기

Facades

라이브러리

리소스 힌트를 주자: 프리패치, 프리렌더, 프리캐시

Prefetch resources needed in the near future at low priority

미래 탐색 속도를 높이기 위해 페이지를 미리 가져오기

Prerender pages

Precache: 서비스 워커를 사용한 캐싱

[WEB_DEV] 웹 폰트와 코드 스플리팅 + 업무고민이 살짝 첨가된

[WEB_DEV] Web worker

0개의 댓글

`<iframe>`도 로딩 속성 넣기