Preload, prefetch, preconnect: 각각은 언제 실제로 도움이 될까
Resource hint는 실제 브라우저 병목과 맞아떨어질 때 유용합니다. 무심코 사용하면 우선순위 잡음이 늘고, 때로는 페이지가 더 느려집니다.
목차
- Resource hint는 마법이 아닙니다
- 브라우저가 이미 잘하는 것
- Preload: 너무 늦게 발견되는 현재 페이지 리소스용
- Preload와 LCP image
- Prefetch: 이 페이지가 아니라 다음 페이지용
- Preconnect: 중요한 origin으로 가는 비용이 큰 연결용
- DNS-prefetch: 더 가벼운 사촌
- 결정 방법: 실용적인 workflow
- 1. 병목 식별하기
- 2. 힌트는 한 번에 하나씩 추가하기
- 3. 우선순위 부작용 확인하기
- 4. Header와 caching 검증하기
- 흔한 실수
- 너무 많이 preload하기
- 필수 리소스에 prefetch 사용하기
- 모든 서드파티에 preconnect하기
- Mobile 조건을 잊기
- 간단한 결정 표
- 차분한 규칙
Resource hint는 마법이 아닙니다
preload, prefetch, preconnect는 종종 성능 체크리스트처럼 다뤄집니다. <head>에 태그 몇 개를 추가하고, Lighthouse를 다시 돌리고, 마음을 놓는 식입니다. 하지만 이들은 그렇게 동작하지 않습니다.
이 힌트들은 브라우저의 로딩 파이프라인에 주는 지시입니다. 브라우저가 충분히 일찍 알아낼 수 없는 정보를 알고 있을 때 도움이 될 수 있습니다. 반대로 추측하거나, 중요하지 않은 작업의 우선순위를 과하게 높이거나, 사용자가 전혀 필요로 하지 않는 연결을 미리 준비하면 해가 될 수 있습니다.
짧게 말하면 다음과 같습니다.
preload는 현재 페이지에 필요하지만 너무 늦게 발견되는 리소스에 사용합니다.prefetch는 현재 페이지의 필수 리소스가 아니라, 앞으로 이동할 가능성이 높은 탐색 리소스에 사용합니다.preconnect는 연결 설정이 실제 지연을 만드는 중요한 서드파티 origin에 사용합니다.
실용적인 질문은 “어떤 힌트가 가장 빠른가?”가 아닙니다. “브라우저가 무엇을 기다리고 있으며, 이 힌트가 그 기다림을 없앨 수 있는가?”입니다.
브라우저가 이미 잘하는 것
현대 브라우저는 수동적인 파일 다운로더가 아닙니다. HTML을 파싱하고, 리소스를 미리 스캔하고, 우선순위를 부여하고, 연결을 재사용하고, 보이지 않는 작업을 지연시키며, 네트워크 상태에 맞게 적응합니다.
따라서 resource hint는 선별적으로 사용해야 합니다. stylesheet, script, image, font가 이미 일찍 발견되고 올바른 우선순위를 받고 있다면, 힌트를 추가해도 아무 변화가 없을 수 있습니다. 더 나쁘게는 더 중요한 리소스와 경쟁할 수도 있습니다.
힌트를 추가하기 전에 DevTools의 waterfall trace나 실험실 보고서를 살펴보세요. Lighthouse를 사용한다면 점수보다 진단 항목부터 보세요. 당황하지 않고 Lighthouse report를 읽는 별도 가이드도 있습니다. 다만 올바른 URL은 대소문자를 구분하므로, 필요하다면 사이트 내비게이션에서 연결된 글을 사용하세요.
실제 증거는 보통 세 곳에서 보입니다.
- 브라우저가 리소스를 늦게 발견해서 중요한 리소스가 늦게 시작됩니다.
- 중요한 origin에 대한 연결이 첫 요청 전에 눈에 띄는 시간을 소모합니다.
- 다음 페이지 리소스가 매우 예측 가능하고, 유휴 시간에 가져오기 부담이 적습니다.
이 중 아무것도 사실이 아니라면, 힌트는 아마 장식에 가깝습니다.
Preload: 너무 늦게 발견되는 현재 페이지 리소스용
preload는 브라우저에 “현재 페이지가 이 리소스를 필요로 하니 지금 가져와라”라고 말합니다.
대표적인 예는 CSS 내부에서 참조되는 web font입니다. 브라우저는 HTML을 다운로드하고, CSS를 발견하고, CSS를 다운로드하고, 이를 파싱한 뒤 font를 발견하고, 그제야 font를 요청해야 합니다. 그 font가 above-the-fold 텍스트에 중요하다면, 발견이 늦어 레이아웃 이동이나 텍스트 렌더링 지연이 생길 수 있습니다.
preload는 그 요청을 더 앞당길 수 있습니다.
<link rel='preload' href='/fonts/inter-var.woff2' as='font' type='font/woff2' crossorigin>as 속성은 중요합니다. 브라우저에 이 리소스가 어떤 종류인지 알려주며, 이는 우선순위, 캐싱, 콘텐츠 보안 정책, 요청 헤더에 영향을 줍니다. Font는 같은 사이트에서 제공되더라도 보통 crossorigin이 필요합니다. font 가져오기가 CORS 모드를 사용하기 때문입니다.
좋은 preload 후보는 다음과 같습니다.
- 보이는 텍스트에 사용되는 기본 web font.
- Largest Contentful Paint 요소이지만 일찍 발견되지 않는 hero image.
- 간접적으로 로드되는 critical CSS 파일.
- 매우 일찍 필요하지만 다른 script 뒤에 숨어 있는 module 또는 script.
나쁜 preload 후보는 다음과 같습니다.
- design system의 모든 font weight.
- fold 아래의 image.
- 초기 렌더링에 필요하지 않은 script.
- 브라우저가 첫 HTML chunk에서 이미 발견하는 리소스.
Preload는 현재 페이지의 우선순위에 영향을 주기 때문에 강력합니다. 바로 그 이유로 오용하기도 쉽습니다. 큰 asset 다섯 개를 preload한다면 더 이상 브라우저를 돕는 것이 아닙니다. 브라우저와 다투고 있는 것입니다.
Font가 전형적인 사례입니다. 기본 font 파일 하나를 preload하는 것은 도움이 될 수 있습니다. 여섯 가지 weight와 italic을 preload하면 보통 더 나빠집니다. font가 병목이라면 먼저 font set을 정리하세요. web fonts are still the easiest performance win on most sites에 대한 가이드에서 그 정리를 더 자세히 다룹니다.
Preload와 LCP image
LCP image를 preload하는 것은 해당 image가 초기 HTML에 보이지 않을 때 유용할 수 있습니다. 흔한 원인으로는 CSS background image, client-rendered component, 늦게 나타나는 responsive image logic이 있습니다.
하지만 hero image가 이미 합리적인 srcset, sizes, dimensions를 갖춘 <img>로 HTML에 있고 lazy loading도 없다면, 브라우저는 아마 빠르게 찾을 수 있습니다. 이 경우 페이지에 따라 preload보다 fetchpriority='high'를 추가하는 것이 더 적절할 수 있습니다.
좋은 테스트는 이렇습니다. waterfall에서 image 요청이 늦게 시작되고 그 image가 LCP 요소가 된다면 preload를 고려하세요. 요청은 일찍 시작하지만 다운로드가 느리다면 문제는 발견이 아니라 크기, 포맷, CDN 동작, 서버 지연입니다. Image format 결정에 대해서는 when AVIF beats WebP and when it does not를 참고하세요.
Prefetch: 이 페이지가 아니라 다음 페이지용
prefetch는 브라우저에 “이 리소스가 곧 필요할 수 있지만, 지금 당장 필수는 아니다”라고 말합니다.
이 구분은 중요합니다. Prefetch는 의도적으로 낮은 우선순위입니다. 브라우저는 유휴 시간에 이를 가져와 나중에 사용하도록 저장할 수 있습니다. 또한 연결이 좋지 않거나, 데이터 절약 모드이거나, 메모리 압박이 있을 때는 건너뛸 수도 있습니다.
사용자 의도가 충분히 강해 다음 리소스가 필요할 가능성이 높을 때 prefetch를 사용하세요.
좋은 prefetch 후보는 다음과 같습니다.
- multi-page checkout의 다음 단계.
- 사용자가 query를 입력하기 시작한 뒤, 다음 route가 예측 가능한 경우의 search results.
- 사용자가 주변 콘텐츠를 적극적으로 읽고 있을 때 table of contents에서 연결된 documentation page.
- 사용자가 navigation item에 hover하거나 focus한 뒤 single-page app의 route chunk.
나쁜 prefetch 후보는 다음과 같습니다.
- 전체 navigation tree.
- 큰 video나 image gallery.
- “혹시 몰라서” 넣는 third-party script.
- 사용자가 다음에 거의 방문하지 않는 page.
Prefetch에서는 절제가 성과로 이어집니다. 가져왔지만 사용되지 않는 리소스는 공짜가 아닙니다. bandwidth, server capacity, energy, 그리고 경우에 따라 user data를 소비합니다. Mobile network에서는 speculative fetching이 실제로 사용자에게 불친절할 수 있습니다.
많은 사이트에서 최선의 prefetch 전략은 의도 기반입니다. home page가 로드되자마자 pricing page를 prefetch하지 마세요. 사용자가 pricing menu를 열거나, pricing link에 hover하거나, 탐색을 강하게 예측하는 call-to-action 근처까지 scroll할 때 prefetch하세요.
브라우저 동작이 다양하다는 점도 기억하세요. 어떤 브라우저는 prefetch에 보수적이고, 일부 privacy setting은 speculative loading을 줄이거나 비활성화합니다. Prefetch를 정합성을 보장하는 장치가 아니라 기회주의적 개선으로 다루세요.
Preconnect: 중요한 origin으로 가는 비용이 큰 연결용
preconnect는 브라우저에 “이 origin으로의 연결 설정을 지금 시작하라”라고 말합니다.
여기에는 DNS lookup, TCP connection, TLS negotiation이 포함될 수 있습니다. 서드파티 origin의 경우 이 설정은 특히 지연 시간이 큰 네트워크에서 수백 밀리초가 걸릴 수 있습니다. 페이지가 곧 해당 origin의 critical request를 필요로 한다면, preconnect가 이후 요청을 더 빠르게 만들 수 있습니다.
예:
<link rel='preconnect' href='https://fonts.gstatic.com' crossorigin>좋은 preconnect 후보는 다음과 같습니다.
- render-blocking text에 사용되는 font origin.
- 초기 interaction 중 필요한 critical API origin.
- above-the-fold asset을 제공하는 CDN origin.
- 사용자 action 직후 즉시 필요한 payments 또는 identity provider.
나쁜 preconnect 후보는 다음과 같습니다.
- 사용자에게 중요하지 않은 analytics 및 advertising endpoint.
- 일부 session에서만 사용되는 origin.
- 긴 third party 목록.
- 브라우저가 이미 연결을 가지고 있거나 곧 열 같은 origin resource.
Preconnect에는 유지 비용이 있습니다. 열린 socket은 memory와 network resource를 소비합니다. 브라우저는 사용되지 않는 연결을 닫지만, 그렇다고 불필요한 preconnect가 무해해지는 것은 아닙니다.
유용한 규칙은 이렇습니다. 한 페이지에서 확신도가 높은 중요한 서드파티 origin은 많아야 하나 또는 둘만 preconnect하세요. 더 추가하고 싶어진다면, 힌트를 늘리기보다 서드파티 아키텍처를 검토해야 할 가능성이 큽니다.
DNS-prefetch: 더 가벼운 사촌
dns-prefetch도 볼 수 있습니다.
<link rel='dns-prefetch' href='https://example-cdn.com'>이는 domain name만 해석합니다. TCP 또는 TLS 연결은 열지 않습니다. preconnect보다 저렴하지만, 도움도 더 적습니다.
DNS-prefetch는 full preconnect가 너무 공격적으로 느껴지는, 확신도가 낮은 서드파티 origin에 합리적일 수 있습니다. 실제로 origin이 critical하고 곧 반드시 사용된다면 preconnect를 선호하세요. 단지 가능성이 있는 정도라면 DNS-prefetch를 사용하거나 아무것도 하지 마세요.
결정 방법: 실용적인 workflow
태그가 아니라 측정에서 시작하세요.
1. 병목 식별하기
performance trace를 열고 늦은 발견을 찾으세요. font, hero image, script 요청이 다른 파일을 다운로드하고 파싱한 뒤에야 시작되었나요? 그렇다면 preload 후보입니다.
요청이 서드파티 origin에 대한 긴 DNS/TCP/TLS 설정 이후에야 시작된다면 preconnect 후보입니다.
현재 페이지는 괜찮지만 다음 탐색이 예측 가능하게 느리다면 prefetch가 도움이 될 수 있습니다.
2. 힌트는 한 번에 하나씩 추가하기
Resource hint는 서로 상호작용합니다. 하나를 추가하고, 테스트하고, waterfall이 개선되며 사용자 지표가 나빠지지 않을 때만 유지하세요.
Preload의 경우 힌트가 붙은 리소스가 실제로 곧 사용되는지 확인하세요. Chrome은 preload된 리소스가 로드 직후 사용되지 않으면 경고할 수 있습니다. 그 경고를 진지하게 받아들이세요.
3. 우선순위 부작용 확인하기
preload는 더 중요한 CSS, JavaScript, image에서 bandwidth를 빼앗을 수 있습니다. preconnect는 connection slot을 차지할 수 있습니다. prefetch는 background traffic을 추가할 수 있습니다.
올바른 결과는 “힌트가 붙은 파일이 더 일찍 시작된다”가 아닙니다. 올바른 결과는 “사용자에게 페이지가 의미 있게 더 좋아진다”입니다. 가능하다면 LCP, INP, CLS, real-user monitoring을 보세요.
4. Header와 caching 검증하기
힌트는 HTML 또는 HTTP Link header로 보낼 수 있습니다. Header는 서버가 페이지에 무엇이 필요할지 일찍 알고 있을 때 유용하지만, 가볍게 살펴보기는 더 어렵습니다. production에서 힌트가 실제로 존재하는지 debugging한다면 raw header가 중요합니다. 이는 our guide to debugging redirects and HTTP headers에서 다루는 바로 그런 상황입니다.
Caching도 중요합니다. credentials가 맞지 않거나, as가 잘못되었거나, URL parameter가 다른 리소스를 preload하면 중복 다운로드가 발생할 수 있습니다. 이것은 선의의 preload가 performance bug가 되는 가장 흔한 방식 중 하나입니다.
흔한 실수
너무 많이 preload하기
모든 것이 critical하다면, 아무것도 critical하지 않습니다. preload는 초기 렌더링이나 즉각적인 interactivity에 필요한 리소스로 제한하세요. 일반적인 페이지에는 preload가 스무 개가 아니라 0개에서 3개 정도여야 합니다.
필수 리소스에 prefetch 사용하기
Prefetch는 낮은 우선순위이며 선택 사항입니다. 현재 페이지에 필요한 asset에는 사용하지 마세요. 페이지에 지금 필요하다면 preload 또는 일반적인 HTML discovery를 고려하세요.
모든 서드파티에 preconnect하기
서드파티가 많은 페이지에는 외부 origin이 열 개 이상인 경우가 흔합니다. 이 모두에 preconnect하면 잡음이 생깁니다. critical하면서도 예측 가능하게 사용되는 하나 또는 둘을 고르세요.
Mobile 조건을 잊기
Resource hint는 느린 연결에서 가장 가치 있지만, 바로 그곳에서 가장 위험하기도 합니다. 빠른 desktop connection에서 낭비된 prefetch는 반올림 오차에 가깝습니다. 제한된 mobile plan에서는 나쁜 거래입니다.
간단한 결정 표
| Situation | Best hint | Why | |---|---:|---| | CSS를 통해 발견되는 critical font | preload | 현재 페이지에 필요하고, 발견이 늦음 | | CSS 또는 client rendering 뒤에 숨은 hero image | preload | image가 늦게 시작될 때 LCP를 개선할 수 있음 | | 사용자 의도 이후 가능성이 높은 다음 route | prefetch | 현재 페이지를 막지 않고 future navigation을 도움 | | Critical third-party font/API origin | preconnect | critical path에서 connection setup을 제거함 | | 가능성은 있지만 불확실한 third-party origin | dns-prefetch 또는 none | 더 낮은 비용, 더 낮은 확신도 | | Below-the-fold image | none | lazy loading과 browser priority가 작동하게 둠 |
차분한 규칙
Resource hint는 지루하고 구체적일 때 가장 잘 작동합니다. Font 하나. LCP image 하나. 중요한 서드파티 origin 하나. 의도 이후 가능성이 높은 다음 route 하나.
낙관으로 사용할 때는 잘 작동하지 않습니다. 사용자가 이것을 필요로 할지도 모르고, 브라우저가 저것을 가져와야 할지도 모르고, 힌트가 많을수록 더 빠를지도 모른다는 식입니다.
브라우저는 이미 적극적으로 최적화합니다. 당신의 일은 모든 요청을 세세하게 관리하는 것이 아닙니다. 브라우저가 적절한 순간에 정보를 갖고 있지 못한 몇 가지 경우를 바로잡는 것입니다.
자주 묻는 질문
모든 font를 preload해야 하나요?
모든 internal link에 prefetch를 사용해도 안전한가요?
preconnect와 dns-prefetch의 차이는 무엇인가요?
Resource hint가 Core Web Vitals를 개선할 수 있나요?
Resource hint는 HTML에 추가해야 하나요, HTTP header에 추가해야 하나요?
출처 및 추가 읽기
