홈페이지 다음 화면 미리 불러오기, 빨라지는 원리와 부작용

링크를 클릭하기 전에 다음 페이지가 이미 준비돼 있다면?

— 2026년 기준, 브라우저는 어떻게 "다음 화면"을 미리 그려두는가

---

쇼핑몰 상세페이지에서 다음 상품 목록으로 넘어갈 때, 혹은 블로그 글을 읽다가 다른 글로 이동할 때 화면이 흰 여백으로 잠깐 깜빡이는 순간을 겪어본 적이 있을 것이다. 이 짧은 지연은 사용자에게는 별것 아닌 듯 느껴지지만, 실제로는 이탈로 이어지는 결정적인 순간이다. 특히 다중 페이지 애플리케이션(MPA) 구조로 운영되는 쇼핑몰이나 정보성 웹사이트는 페이지를 이동할 때마다 브라우저가 문서를 처음부터 다시 요청하고 렌더링해야 하므로, 이 전환 순간의 체감 속도가 전체 사용자 경험을 좌우한다.

개발자라면 이 문제를 해결하기 위해 이미지 최적화, 서버 응답 속도 개선, CDN 도입 같은 방법을 시도해봤을 것이다. 하지만 이런 최적화는 "현재 페이지를 얼마나 빨리 보여주는가"에 초점이 맞춰져 있을 뿐, "다음 페이지로의 전환"이라는 문제는 그대로 남는다. 이 지점에서 등장한 것이 Speculation Rules API다. 이 기능은 사용자가 다음에 클릭할 가능성이 높은 링크를 브라우저가 미리 예측해, 문서를 백그라운드에서 미리 가져오거나 아예 렌더링까지 끝내두는 방식으로 작동한다.

다만 이 기술은 "무조건 빠르게 만드는 마법"이 아니라, 브라우저가 사용자의 다음 행동을 예측해 네트워크·메모리·CPU 자원을 미리 지불하는 구조라는 점을 이해해야 제대로 활용할 수 있다. 예측이 맞으면 체감 속도는 확실히 개선되지만, 예측이 틀리면 그만큼의 자원은 그대로 버려진다. 이 글에서는 이 기술이 실제로 어떻게 작동하는지, 어떤 조건에서 실행되고 어떤 상황에서 취소되는지, 그리고 실무에서 어떤 페이지에 적용하고 어떤 URL은 반드시 제외해야 하는지를 구체적으로 다룬다.

---

Speculation Rules API란 무엇이고 왜 MPA 성능의 핵심 변수인가

Speculation Rules API는 문서 단위의 내비게이션을 브라우저가 미리 준비하도록 지시하는 표준 웹 API이며, SPA 내부의 클라이언트 라우트 전환 자체를 프리렌더링하는 기능은 아니다. 즉 이 API는 전통적인 MPA처럼 페이지를 이동할 때마다 서버에 새 문서를 요청하는 구조에서 가장 큰 효과를 낸다. React나 Vue 기반의 SPA에서 클라이언트 사이드 라우팅으로 화면을 전환하는 경우에는 이 API의 적용 대상이 아니라는 점을 먼저 명확히 해둘 필요가 있다.

이 기능이 중요한 이유는 MPA 구조를 유지하면서도 SPA에 가까운 전환 체감 속도를 만들어낼 수 있기 때문이다. 쇼핑몰, 뉴스 사이트, 기업 홈페이지처럼 SEO와 서버 렌더링의 장점을 유지해야 하는 사이트는 여전히 MPA 구조를 선택하는 경우가 많은데, 이런 구조의 고질적인 약점이 바로 페이지 전환 속도였다. Speculation Rules API는 <​script type="speculationrules"> 태그 또는 Speculation-Rules 응답 헤더를 통해 규칙을 선언하며, 외부 파일로 분리할 경우 MIME 유형은 application/speculationrules+json으로 지정해야 브라우저가 인식한다.

이 API의 핵심은 두 가지 동작 방식, 즉 prefetch와 prerender를 상황에 맞게 선택하거나 조합할 수 있다는 점이다. 단순히 "링크를 미리 가져오는 기능" 정도로 이해하면 실제 적용 단계에서 자원 낭비나 상태 불일치 같은 부작용을 놓치기 쉽다. 브라우저는 이 규칙을 명령이 아니라 힌트로 취급하기 때문에, 개발자가 규칙을 선언했다고 해서 항상 실행되는 것도 아니다. 사용자의 기기 메모리 상태, 데이터 절약 모드(Save-Data), 절전 모드(Energy Saver), 백그라운드 탭 여부에 따라 실행이 보류되거나 취소될 수 있다는 점을 전제로 설계해야 한다.

---

prefetch와 prerender, 같은 목적 다른 비용 구조

prefetch와 prerender는 둘 다 "다음 페이지 미리 불러오기"를 위한 기능이지만, 브라우저가 실제로 소비하는 자원의 종류와 양이 근본적으로 다르다. prefetch는 문서의 HTTP 응답만 미리 가져올 뿐 렌더링이나 JavaScript 실행은 하지 않는다. 반면 prerender는 문서와 하위 리소스, JavaScript, 그리고 JavaScript가 시작한 데이터 요청까지 보이지 않는 문서 상태에서 모두 처리한 뒤, 사용자가 실제로 이동하는 순간 화면을 활성화한다.

예를 들어 쇼핑몰의 상품 목록 페이지에서 개별 상품 상세 페이지로 이동하는 링크에 prefetch를 적용하면, 사용자가 클릭했을 때 문서 다운로드 시간만 절약된다. 하지만 같은 링크에 prerender를 적용하면 사용자가 클릭하는 순간 이미 렌더링까지 끝난 화면이 그대로 전환되므로 체감 속도 차이가 훨씬 크다. 다만 그만큼 prerender는 더 많은 CPU와 메모리를 소비하며, MDN은 이 자원 사용량을 대략 iframe 하나를 렌더링하는 수준으로 비유해 설명한다.

Speculation Rules API의 prefetch 결과는 일반적인 내비게이션 처리와 동일하게 취급돼 메모리에 보관될 수 있다는 점도 실무에서 참고할 부분이다. 이는 사용자가 실제로 그 링크를 클릭했을 때 이미 받아둔 응답을 바로 활용할 수 있다는 의미이며, 완전히 새로운 요청을 다시 보내는 기존 방식과 비교하면 확실한 개선이다. 하지만 prefetch 결과는 약 5분 동안 캐시될 수 있어, 그 사이 서버 데이터가 바뀌면 사용자가 이전 상태의 콘텐츠를 보게 될 가능성도 있다. 재고 수량이나 가격이 실시간으로 바뀌는 페이지에 이 기능을 적용할 때는 이 캐시 유효 시간을 반드시 염두에 둬야 한다.

기본적으로 프리렌더링 대상은 동일 출처로 제한된다. 동일 사이트 내의 다른 출처(서브도메인 등)를 prerender 대상으로 삼으려면 대상 서버가 Supports-Loading-Mode: credentialed-prerender 응답 헤더를 통해 이를 명시적으로 허용해야 하며, 서로 다른 사이트 간의 프리렌더링은 아예 지원되지 않는다. 이는 보안과 프라이버시 측면에서 다른 사이트의 로그인 상태나 쿠키 정보가 의도치 않게 노출되는 것을 막기 위한 구조적 제약이다.

---

실행 한도와 휴리스틱, 브라우저는 어떤 기준으로 추측하는가

Chrome은 모든 링크를 무제한으로 프리렌더링하지 않으며, 규칙 유형별로 명확한 실행 한도를 두고 초과분은 FIFO 방식으로 관리한다. 즉시 실행되는 규칙(eagerness가 immediate인 경우)에서는 프리패치 최대 50개, 프리렌더 최대 10개까지 허용된다. 반면 사용자의 상호작용(호버, 클릭 예비 동작 등)을 기반으로 실행되는 규칙에서는 프리패치와 프리렌더 각각 2개로 한도가 훨씬 낮으며, 이 한도에 도달하면 가장 오래된 항목이 새 항목으로 대체되는 FIFO 구조가 적용된다.

이 한도가 의미하는 바는 명확하다. 페이지 하단에 나열된 수십 개의 링크에 무작정 즉시 실행 규칙을 걸어도 실제로는 정해진 개수만 처리되고 나머지는 무시되거나 대기 상태로 남는다. 따라서 어떤 링크를 우선순위로 삼을지 설계하는 작업이 실무에서 훨씬 중요해진다.

Chrome의 기본 동작 방식도 규칙 유형에 따라 다르다. 문서 기반 규칙의 기본 eagerness 값은 conservative로, 사용자의 명확한 의도가 확인될 때만 조심스럽게 실행된다. 반면 URL 목록 규칙의 기본값은 immediate로, 규칙이 등록되는 즉시 실행을 시도한다. 여기에 더해 Chrome 143부터는 데스크톱 환경에서 eager 설정이 immediate와는 다르게 동작하도록 구분됐고, 2026년 1월부터는 모바일 환경에서 앵커 링크가 뷰포트에 들어온 뒤 50밀리초가 지나야 단순한 뷰포트 기반 휴리스틱이 적용되는 방식으로 조정됐다.

데스크톱의 moderate 규칙은 사용자가 링크 위에 마우스를 200밀리초 이상 머무를 때 실행되며, 그보다 먼저 pointerdown(클릭 준비 동작)이 감지되면 그 시점에 실행될 수도 있다. 모바일에서는 마우스 호버라는 개념 자체가 없기 때문에 2025년 8월부터 스크롤이 멈춘 뒤 500밀리초가 지나는 시점과 앵커의 화면상 위치·크기 조건을 함께 고려하는 더 복잡한 휴리스틱이 적용되고 있다. 이는 데스크톱과 모바일에서 사용자의 "다음 행동 의도"를 감지하는 신호 자체가 다르기 때문에 나타나는 자연스러운 차이다.

---

상태 불일치와 서버 부작용, 반드시 제외해야 할 URL 패턴

프리렌더링은 사용자가 실제로 이동하기 전에 서버 요청을 발생시키기 때문에, GET 요청만으로 상태가 바뀌는 URL을 프리렌더링 대상에서 반드시 제외해야 한다. 로그아웃 링크, 장바구니에 상품을 추가하는 URL, 언어 변경 링크, 일회용 인증번호(OTP) 발송 URL, 광고 전환을 기록하는 URL 등이 대표적인 예다. 사용자가 클릭조차 하지 않았는데 브라우저가 미리 요청을 보내는 순간 이런 부작용이 실제로 발생해버리면, 사용자 모르게 로그아웃되거나 장바구니에 원치 않는 상품이 담기는 문제가 생길 수 있다.

이런 문제를 서버 단에서 구분할 수 있도록, 프리패치 요청에는 Sec-Purpose: prefetch 헤더가, 프리렌더 요청에는 Sec-Purpose: prefetch;prerender 헤더가 함께 전송된다. 서버는 이 헤더를 확인해 해당 요청을 일반 로깅에서 제외하거나, 부작용이 있는 동작의 실행 시점을 실제 활성화 시점까지 지연시키는 방식으로 대응할 수 있다. 예를 들어 상품을 장바구니에 담는 API가 이 헤더를 감지하면, 실제 데이터베이스 반영은 사용자가 페이지에 진입해 활성화가 완료된 이후로 미루는 식의 설계가 가능하다.

상태 불일치 문제는 부작용이 명확한 URL만의 문제가 아니다. 로그인 상태, 장바구니 내용, 언어 설정, 실시간으로 갱신되는 서버 렌더링 데이터가 프리렌더링이 시작된 이후에 바뀌면, 사용자가 실제로 그 페이지에 진입했을 때 오래된 상태의 화면을 보게 될 수 있다. 재고가 방금 소진된 상품이 여전히 "구매 가능"으로 표시되거나, 로그인 상태가 바뀌었는데 이전 세션 기준의 화면이 뜨는 상황이 생길 수 있다는 뜻이다.

이를 보완하기 위한 방법으로는 다음과 같은 것들이 있다.

첫째, Broadcast Channel을 활용해 탭 간 상태 변경을 실시간으로 전파하는 방식이다.
둘째, 활성화 시점에 fetch()로 최신 데이터를 다시 확인하는 방식이다.
셋째, WebSocket을 통해 서버 측 변경 사항을 지속적으로 수신하는 방식이다.
넷째, Clear-Site-Data 헤더의 prefetchCache, prerenderCache 지시자를 활용해 특정 시점에 캐시를 강제로 무효화하는 방식이다.

이 네 가지 방법 중 페이지의 데이터 민감도에 맞는 조합을 선택해 적용하는 것이 실무적인 접근이다.

---

성능 측정과 오리진 트라이얼, 2026년 현재의 진행 상황

프리렌더링이 실제로 얼마나 효과를 냈는지 측정하려면 일반 내비게이션과 프리렌더 후 활성화된 내비게이션을 구분해서 봐야 하며, 이를 위한 표준화된 방법이 이미 마련돼 있다. 프리렌더링이 진행되는 동안 document.prerendering 값은 true가 될 수 있고, 사용자가 실제로 그 페이지에 진입해 화면이 활성화되는 시점에는 prerenderingchange 이벤트가 발생한다.

성능 측정 관점에서 특히 중요한 값은 PerformanceNavigationTiming.activationStart다. 이 값이 0보다 크면 해당 내비게이션이 프리렌더링을 거쳐 활성화된 것으로 식별할 수 있다. 프리렌더링은 사용자가 링크를 클릭하기 전부터 백그라운드에서 진행되기 때문에, 이 값을 고려하지 않고 단순히 페이지 로딩 시작 시점부터 측정하면 실제 체감 로딩 시간보다 훨씬 느리게 집계되거나, 반대로 사전 준비 시간이 통째로 빠져 비정상적으로 빠르게 집계되는 오류가 발생할 수 있다. 분석 도구를 자체 구축했거나 커스텀 성능 측정 스크립트를 운영 중이라면, 이 값을 반드시 보정 로직에 반영해야 중복 집계나 왜곡된 지표를 피할 수 있다.

이런 이유로 web-vitals 라이브러리는 3.1.0 버전부터 프리렌더 내비게이션을 Chrome의 Core Web Vitals 측정 방식에 맞춰 처리하며, Metric.navigationType 필드를 통해 해당 지표가 프리렌더를 거친 것인지 여부를 표시한다. 크롬 사용자 경험 보고서(CrUX) 역시 활성화 시점을 반영해 집계하므로, 실제 서비스에서 Core Web Vitals 지표가 개선됐다면 그 개선이 진짜 렌더링 최적화 덕분인지, 프리렌더링으로 인한 측정 시점 이동 덕분인지 구분해서 해석하는 습관이 필요하다.

한편 2026년 1월 23일 Chrome은 Chrome 144부터 첫 번째 스크립트 실행 직전까지만 페이지를 준비해두는 prerender_until_script라는 오리진 트라이얼을 시작한다고 발표한 바 있다. 이는 등록된 사이트만 사용할 수 있는 실험적 기능으로, Chrome 150까지 진행될 예정이었다. 다만 이는 정식 기능이 아니라 실험 중인 중간 단계 방식으로 이해해야 하며, 발행 시점 기준으로 해당 오리진 트라이얼이 실제로 어떤 범위까지 지원되는지는 Chrome 공식 문서를 통해 다시 확인할 필요가 있다. 이 기능을 지원하지 않는 브라우저에서는 자동으로 prefetch로 대체되지 않으므로, 기능 감지 로직과 별도의 fallback 규칙을 함께 준비해야 한다.

---

페이지 미리 불러오기 방식의 선택지 비교

페이지 전환 속도를 높이는 방법은 하나가 아니며, 각 방식은 준비 비용과 실행 조건, 위험도가 서로 다르다. 실무에서 흔히 고려하는 선택지를 정리하면 다음과 같다.

이 표에서 확인할 수 있듯, 각 방식은 "얼마나 완전하게 준비해두는가"와 "그만큼의 자원을 감수할 수 있는가"라는 트레이드오프 위에 놓여 있다. prefetch는 상대적으로 가볍지만 개선 폭이 제한적이고, prerender는 확실한 체감 속도 개선을 기대할 수 있는 대신 자원 소비와 상태 불일치 위험을 함께 짊어져야 한다. 기존의 <​link rel="prerender"> 방식은 Chrome 중심으로 오래 사용돼 왔지만 표준화되지 못한 비표준 방식으로, 지원 브라우저에서는 Speculation Rules API로 대체되는 방향이 권장되고 있다.

---

실무 적용 시 놓치기 쉬운 판단 기준

프리렌더링을 도입할 때 가장 흔한 실수는 모든 링크에 동일한 규칙을 일괄 적용하는 것이며, 페이지의 성격에 따라 규칙을 세분화하는 판단이 실제 효과를 좌우한다. 예를 들어 쇼핑몰의 카테고리 목록 페이지에서 상품 상세 페이지로 이동하는 링크는 클릭 확률이 비교적 높으므로 prerender를 적용할 후보가 될 수 있지만, 검색 결과 페이지처럼 사용자가 실제로 클릭할 링크를 예측하기 어려운 구조에서는 즉시 실행 규칙보다 상호작용 기반 규칙(moderate)이 자원 낭비를 줄이는 데 더 적합하다.

또한 로그인 여부에 따라 콘텐츠가 달라지는 페이지, 실시간 재고나 가격이 반영되는 페이지, 개인화 추천이 포함된 페이지는 prerender 적용 전에 반드시 상태 갱신 전략을 함께 설계해야 한다. 이 부분을 건너뛰고 기능만 켜두면, 사용자가 실제로는 로그인 상태가 바뀌었는데 이전 세션 기준의 화면을 잠깐이라도 보게 되는 문제가 발생할 수 있다.

분석 도구를 운영 중이라면 프리렌더링 도입 이후 페이지뷰나 이벤트가 중복 집계되지는 않는지 점검하는 과정도 빼놓지 말아야 한다. 브라우저가 백그라운드에서 미리 페이지를 준비하는 과정에서 분석 스크립트가 실행돼 실제 방문이 아닌데도 페이지뷰로 잡히는 경우가 이론적으로 발생할 수 있기 때문이다. document.prerendering 값을 확인해 프리렌더링 중에는 분석 이벤트 전송을 보류하고, prerenderingchange 이벤트가 발생해 실제 활성화된 시점에만 집계하도록 설계하는 것이 안전하다.

서버 인프라 관점에서도 Sec-Purpose 헤더를 활용해 프리렌더 요청과 실제 사용자 요청을 구분하는 로깅 체계를 갖추는 것이 바람직하다. 이 구분이 없으면 실제 트래픽과 예측성 트래픽이 뒤섞여 서버 부하 분석이나 캐시 히트율 분석의 정확도가 떨어질 수 있다.

---

도입 전 점검해야 할 단계별 체크리스트

Speculation Rules API를 실제 서비스에 적용하기 전, 아래 단계를 순서대로 점검하면 자원 낭비와 상태 불일치 위험을 크게 줄일 수 있다.

1단계, 사이트 구조가 MPA인지 확인한다. SPA 내부 라우팅 전환에는 이 API가 적용되지 않는다.

2단계, 프리렌더링 대상에서 제외할 URL 목록을 먼저 작성한다. 로그아웃, 장바구니 추가, 언어 변경, 인증번호 발송, 광고 전환 기록 URL이 여기에 해당한다.

3단계, 페이지별로 prefetch와 prerender 중 어떤 방식이 적합한지 구분한다. 클릭 확률이 높고 정적인 콘텐츠는 prerender, 그 외에는 prefetch나 moderate 규칙을 고려한다.

4단계, 실행 한도(즉시 실행 프리패치 50개·프리렌더 10개, 상호작용 기반 각 2개)를 감안해 규칙에 우선순위를 부여한다.

5단계, 상태 갱신 전략을 마련한다. Broadcast Channel, fetch() 재확인, WebSocket, Clear-Site-Data 중 페이지 특성에 맞는 방법을 선택한다.

6단계, Sec-Purpose 헤더를 서버 로깅과 부작용 지연 로직에 반영한다.

7단계, activationStart 값과 document.prerendering을 활용해 분석 도구의 중복 집계 여부를 검증한다.

8단계, 실험적 기능인 prerender_until_script를 사용할 경우 기능 감지와 fallback 규칙을 별도로 준비한다.

---

기대할 수 있는 변화와 전제 조건

프리렌더링을 적절히 설계해 적용하면 페이지 전환 시 체감되는 대기 시간을 줄일 수 있지만, 이는 예측이 실제 사용자 행동과 얼마나 맞아떨어지는지, 그리고 상태 갱신 전략이 얼마나 촘촘한지에 달린 조건부 결과다. 프리렌더링이 항상 즉시 전환을 보장하는 기술은 아니며, 사용자 환경의 메모리 상태나 데이터 절약 설정에 따라 실행 자체가 되지 않을 수도 있다는 점을 항상 전제로 둬야 한다.

또한 이 기술이 만들어내는 가치는 단순히 속도 지표 하나로만 환원되지 않는다. 실행 한도와 FIFO 관리, 상태 불일치 대응, 분석 중복 집계 방지까지 함께 설계됐을 때 비로소 사용자 경험 개선과 인프라 안정성을 동시에 확보할 수 있다. 이 조건들을 갖추지 못한 채 기능만 켜두면 오히려 불필요한 서버 부하와 잘못된 성능 지표만 남을 수 있다.

---

자주 묻는 질문 (FAQ)

Q1. Speculation Rules API를 적용하면 SPA에서도 화면 전환이 빨라지나요?
아니다. 이 API는 문서 단위의 내비게이션을 대상으로 하며, SPA 내부의 클라이언트 라우트 전환 자체를 프리렌더링하지 않는다. MPA 구조에서 문서를 새로 요청하는 경우에 적용된다.

Q2. 프리렌더링을 설정하면 무조건 실행되나요?
아니다. 브라우저는 이를 실행 명령이 아닌 힌트로 취급하며, 사용자 설정·메모리 상태·Save-Data·Energy Saver·백그라운드 탭 여부 등에 따라 실행되지 않거나 도중에 취소될 수 있다.

Q3. 로그인 페이지나 장바구니 URL에도 적용해도 되나요?
GET 요청만으로 상태가 바뀌는 URL, 즉 로그아웃·장바구니 추가·언어 변경·인증번호 발송·광고 전환 기록 URL은 프리렌더링 대상에서 제외하는 것이 안전하다.

Q4. 다른 도메인의 페이지도 미리 준비할 수 있나요?
기본 대상은 동일 출처다. 동일 사이트의 다른 출처는 대상 서버가 Supports-Loading-Mode: credentialed-prerender 헤더로 허용해야 하며, 서로 다른 사이트 간 프리렌더링은 지원되지 않는다.

Q5. 성능 지표가 갑자기 좋아졌는데, 실제 개선인지 어떻게 확인하나요?
PerformanceNavigationTiming.activationStart 값이 0보다 큰지 확인하면 프리렌더 후 활성화된 내비게이션인지 식별할 수 있다. web-vitals 라이브러리 3.1.0 이상에서는 Metric.navigationType으로도 구분이 가능하다.

---

페이지 전환 속도는 단순한 기술적 지표를 넘어 사용자가 사이트를 "빠르다"고 느끼는지 여부를 결정하는 핵심 요소다. Speculation Rules API는 이 문제에 대한 표준화된 해법을 제시하지만, 그 효과는 어떤 페이지에 어떤 규칙을 얼마나 정교하게 설계했는지에 따라 달라진다. 무작정 켜두는 기능이 아니라, 자원 비용과 상태 관리 전략까지 함께 설계하는 접근이 필요한 이유가 여기에 있다.