• Web Performance
  • Front-end

Preload: 웹 성능에서 어떤 리소스를 미리 불러와야 할까?

리소스를 preload하면 페이지 로딩을 가속할 수 있습니다. preload를 효과적으로 사용하는 방법을 알아보세요.

Preload 없음
document
styles.css
font.woff2
hero.avif LCP
app.js
icons.svg
analytics.js
gtm.js
↳ 크리티컬 체인 : HTML → CSS → font / hero
LCP 2.8s
Preload 적용
document
styles.css
preload font.woff2
preload hero.avif LCP
app.js
icons.svg
analytics.js
gtm.js
✓ 크리티컬 체인 해소 — font + hero dès le HTML
LCP 2.3s
LCP 개선: 2.8s → 2.3s −500ms
Paul Delcloy

Paul Delcloy

저자

웹 페이지가 로드될 때, 브라우저는 서버에서 HTML 파일을 다운로드하고 그 내용을 처리한 뒤, 코드에 포함된 리소스에 대한 다양한 요청을 보냅니다. 사용자 입장에서는 어떤 리소스가 중요한지 알고 있습니다. 반면 브라우저는 사용자가 페이지를 최대한 빠르고 효율적으로 보도록 우선순위 리소스를 식별하는 데 도움이 필요합니다. 이를 위해, 를 사용해 브라우저에 우선순위를 안내할 수 있습니다.

preload는 어떻게 동작하나요?

preload는 브라우저가 보통 늦게 발견하는 리소스에 유용한 현대적 메커니즘입니다.

Chrome DevTools 캡처: 페이지 로드 막바지에 폰트 파일이 다운로드되는 waterfall 이 예에서 폰트 파일은 @font-face로 선언된 CSS 파일이 로드된 뒤에야 발견됩니다. 브라우저는 CSS 파일을 다운로드하고 파싱한 다음에야 폰트 다운로드를 시작합니다. 일부 리소스를 현명하게 preload하면, 브라우저가 평소보다 훨씬 이르게 해당 파일을 받아 두도록 지시할 수 있습니다. 현재 페이지 로드에 반드시 필요하다고 확신되는 파일이기 때문입니다.

Chrome DevTools 캡처: preload된 폰트 파일이 CSS와 병렬로 다운로드되는 waterfall 이 예에서 폰트 파일은 미리 로드되었고, 이제 CSS와 동시에 다운로드됩니다. 이런 여러 파일 간의 의존 관계는 크리티컬 요청 체인이라고 하며, 한 파일이 다른 파일을 참조하는 동안 브라우저는 앞선 파일을 파싱하기 전에는 어떤 파일을 미리 로드해야 할지 알 수 없습니다.

이런 문제를 완화하려면 preload 링크 태그로 리소스를 미리 로드하는 것이 종종 유용합니다:

<link rel="preload" href="style.css" as="style" />
<link rel="preload" href="main.js" as="script" />

이 태그는 리소스 유형(as 속성)과 리소스의 URL(href 속성)에 맞게 설정해야 합니다. 주의: href 값의 민감도가 높습니다. 슬래시 하나나 쿼리스트링이 달라도 파일이 두 번 로드됩니다.

⚠️ as 속성이 지정되지 않으면 요청은 XHR 호출로 간주되어 2번 수행되어, preloading의 효과가 사라집니다.

브라우저는 이 preload 지시어를 발견하면 파일을 사용자 캐시에 다운로드해 필요할 때 사용할 수 있도록 준비합니다. JavaScript 파일은 실행되지 않으며, 해당 파일이 페이지에서 호출되기 전까지 CSS는 적용되지 않습니다.

💡 파일을 preload로 지정했는데 load 이벤트 이후 3초 이내에 호출되지 않으면, Chrome은 개발자 콘솔에 warning을 표시합니다.

폰트 프리로드: 특수한 경우

앞서 말한 대로 폰트를 미리 로드하려고 하나요? 이 경우는 조금 특별합니다. 복잡한 기술적 이유로 인해 (confer), 폰트는 기본적으로 crossorigin으로 로드됩니다.

따라서 woff2(또는 다른 폰트 포맷) 파일을 올바르게 미리 로드하려면 다음과 같이 HTML 태그에 crossorigin 속성을 추가해야 합니다:

<link rel="preload" href="fonts/cicle_fina-webfont.woff2" as="font" type="font/woff2" crossorigin />

preload가 Core Web Vitals에 미치는 영향

preload의 사용은 웹 성능 최적화에서 강력한 무기이며, 미리 로드를 통해 사이트 속도를 눈에 띄게 높일 수 있습니다. 이러한 최적화는 Core Web Vitals의 뚜렷한 변화를 이끌 수 있습니다. 따라서 preload의 동작을 테스트하고 이해하는 것은 매우 가치가 있습니다.

Largest Contentful Paint (LCP)

preload는 폰트와 이미지에 대해 LCP에 큰 영향을 미칩니다. 폰트와 이미지는 LCP의 후보가 될 수 있기 때문입니다. 히어로 섹션의 이미지나, 추가 폰트 파일에 의존하는 중요한 텍스트 블록은 신중한 preload로 큰 이점을 얻을 수 있습니다. 코드 한 줄만으로 페이지 로딩 시간에서 수백 ms를 절약할 기회를 놓치지 마세요!

반대로, preload 태그를 남용하는 일은 피해야 합니다. 너무 많은 리소스를 미리 로드하면, 아무 것도 미리 로드하지 않은 것과 다를 바 없습니다. 과도한 preload는 리소스 간 대역폭 경쟁을 유발할 수 있습니다.

한 페이지의 웹 성능을 실제로 개선하려면 리소스의 모던 포맷만 미리 로드할 것을 권합니다(폰트는 WOFF2, 이미지는 WebP 또는 AVIF).

Cumulative Layout Shift (CLS)

Cumulative Layout Shift (CLS)는 중요한 Core Web Vitals로, 특히 폰트 로딩 방식을 커스터마이즈하기 위해 CSS의 font-display 속성을 사용할 때 폰트에 의해 부정적인 영향을 받을 수 있습니다.

웹폰트 로딩을 위해 가능한 다양한 값을 실험하는 것이 중요합니다. 폰트 파일을 미리 로드하는 경우에는 layout shift를 없애기 위해 block 값을 사용할 것을 권장합니다.

조금 더 기술적으로 접근하면, 비율에 기반해 계산된 대체 폰트를 사용해, 사용자 기기에 기본으로 설치된 시스템 폰트로 우선 텍스트를 표시해 두고 커스텀 폰트가 로드되기를 기다리는 방법도 가능합니다.

Preload: 2026년에 웹 성능에서 필수 솔루션

사이트를 빠르게 만들려면, 서버에 의해 늦게 발견되는 페이지의 중요한 리소스를 미리 로드하는 것이 필수적입니다. 페이지의 모든 리소스를 전부 미리 로드하는 것은 오히려 역효과이므로, preload는 필요한 만큼만 신중히 사용하고 필드 데이터에서 그 영향을 측정하세요.

게시일 23 9월 2023

업데이트 31 3월 2026

당신의 성과를 향상시키고 싶으신가요?

전문 웹 성능 전문가
즉시 가능
8년 이상의 경험
고객 만족도 100%
2023-2025 데이터