Speculation Rules: 다음 페이지를 미리 당겨오는 예측 로딩
🤖 AI Summary
링크를 클릭한 뒤 다음 페이지가 뜨기까지의 짧은 공백, 이걸 없애는 방법이 예측 로딩입니다. Speculation Rules는 사용자가 다음에 갈 만한 페이지를 브라우저에 미리 알려, 클릭 전에 받아 두거나 렌더까지 해 두는 표준이에요. 방식은 두 가지죠. prefetch는 문서만 미리 받아 두고, prerender는 백그라운드에서 페이지를 완전히 렌더해 둬 클릭 순간 즉시 뜹니다. 다만 prerender는 iframe 하나를 띄우는 수준의 자원을 쓰니, 언제 당길지를 정하는 eagerness와 대상 범위를 신중히 잡아야 해요. 이 글은 예측 로딩의 원리, prefetch와 prerender의 차이, eagerness, 실무 주의점을 MDN·Chrome 문서 기준으로 정리합니다.
블로그 목차
예측 로딩은 무엇을 해결하나요?
사용자가 다음에 갈 페이지를 미리 받아 두면, 클릭 후 기다림 없이 즉시 열립니다. 아무리 최적화해도 클릭에서 새 페이지가 뜨기까지는 네트워크 왕복과 렌더 시간이 남죠. 예측 로딩은 이 시간을 클릭 이전으로 옮기는 발상이에요. 첫 검색 결과나 페이지네이션의 다음 쪽처럼 다음 행선지가 어느 정도 예측되는 상황이라면, 그 페이지를 미리 준비해 두면 됩니다.
Speculation Rules는 이 미리 준비할 대상을 브라우저에 선언하는 표준 방법입니다. script 태그의 type을 speculationrules로 지정하고, 그 안에 JSON으로 URL 목록이나 조건을 적으면 브라우저가 알아서 받아 두죠. 같은 성능 계열이지만 방향이 다른 리소스 힌트, 즉 지금 페이지의 자원을 앞당기는 preload·preconnect 글과 비교하면, Speculation Rules는 아예 다음 페이지 전체를 겨냥한다는 점이 다릅니다.
prefetch와 prerender는 어떻게 다른가요?
prefetch는 문서만 미리 받아 두고, prerender는 페이지를 백그라운드에서 완전히 렌더까지 해 둡니다. 둘의 차이는 어디까지 미리 하느냐에 있어요. prefetch는 다음 페이지의 문서(HTML 응답)만 받아 둡니다. 이미지·스크립트 같은 하위 자원은 받지 않죠. 비용이 작아 넉넉히 써도 부담이 적습니다.
반면 prerender는 문서는 물론 하위 자원까지 받아 스크립트를 실행하고, 보이지 않는 탭에서 페이지를 완전히 렌더해 둡니다. 클릭하는 순간 이미 준비된 화면으로 즉시 전환되니 체감이 가장 빠르죠. 대신 iframe 하나를 띄우는 정도의 메모리와 대역폭을 쓰기 때문에, 방문 가능성이 높은 페이지에만 아껴 써야 합니다. 미리 받는 요청도 CDN 캐시에서 처리되면 오리진 부담을 덜 수 있지만, prerender를 남발하면 그만큼 실제로 안 볼 페이지까지 완성하는 비용이 쌓입니다.
언제 미리 당길지는 어떻게 정하나요?
당기는 시점은 eagerness 값으로 정하는데, 곧바로 당길지 링크에 다가올 때 당길지를 정합니다. immediate는 규칙을 읽는 즉시, moderate는 200ms 호버, conservative는 클릭 직전에 당기고, eager는 현재 immediate와 같게 동작하죠. 예측 로딩의 딜레마는 일찍 당길수록 빠르지만, 안 갈 페이지까지 당기면 낭비라는 점이에요. eagerness는 이 저울의 눈금인 셈이죠.
eagerness | 당기는 시점 | 자원 한도 |
|---|---|---|
immediate | 규칙을 읽는 즉시 | prefetch 50 · prerender 10 |
eager | 현재는 immediate와 동일 | prefetch 50 · prerender 10 |
moderate | 링크에 200ms 머무를 때 | 각 2개 |
conservative | 클릭을 누르기 시작할 때 | 각 2개 |
값을 따로 적지 않으면 URL 목록 규칙은 immediate, 조건(where) 규칙은 conservative가 기본입니다. 즉 콕 집은 몇 개 주소는 바로 당기고, 페이지의 링크들을 조건으로 훑는 규칙은 사용자가 실제로 누를 때까지 기다리는 식이죠. 이 기본값만 이해해도 과한 낭비는 대부분 피할 수 있습니다.
실무에서 무엇을 주의해야 하나요?
안 갈 페이지까지 당기면 대역폭과 오리진 부하가 늘고, 로그아웃·장바구니 URL은 미리 당기면 안 됩니다. 첫째, 범위를 좁히세요. 조건 규칙의 href_matches로 로그아웃·장바구니·결제처럼 미리 부르면 안 되는 경로를 제외하는 것이 기본입니다. 요청하는 것만으로 상태가 바뀌는 URL(장바구니 담기, 로그아웃, 광고 전환 집계)은 특히 위험해요.
둘째, prerender는 아껴 쓰세요. 페이지를 실제로 렌더하니, 서버는 Sec-Purpose 헤더로 예측 요청을 구분해 처리하고, 클라이언트는 Document.prerendering으로 분석·집계 코드를 실제 방문 시점까지 미룰 수 있습니다. 셋째, 지원 범위를 감안하세요. Speculation Rules는 아직 일부 주요 브라우저에서 동작하지 않으니, 지원되는 곳에서 더 빠르게 만드는 점진적 개선으로 접근하는 편이 안전합니다.
이것만 기억하세요
Speculation Rules는 다음에 갈 페이지를 미리 준비해, 클릭 순간을 기다림 없이 만드는 표준입니다. prefetch는 문서만 받아 저비용, prerender는 완전히 렌더해 즉시 전환하지만 iframe급 자원을 쓰죠. 언제 당길지는 eagerness로 정하고, 값이 없으면 URL 목록은 immediate·조건 규칙은 conservative가 기본입니다. 로그아웃·장바구니처럼 요청만으로 상태가 바뀌는 URL은 제외하고, 지원되지 않는 브라우저를 고려해 점진적 개선으로 적용하세요.
자주 묻는 질문 (FAQ)
Q. 예측 로딩은 무엇을 해결하나요?
사용자가 다음에 갈 페이지를 미리 받아 두면, 클릭 후 기다림 없이 즉시 열립니다. Speculation Rules는 이 미리 준비할 대상을 브라우저에 선언하는 표준 방법으로, script 태그에 type을 speculationrules로 지정하고 JSON으로 URL이나 조건을 적습니다.
Q. prefetch와 prerender는 어떻게 다른가요?
prefetch는 다음 페이지의 문서만 받아 두고, prerender는 하위 자원까지 받아 완전히 렌더해 둡니다. prerender는 스크립트를 실행하고 보이지 않는 탭에서 페이지를 준비하므로, iframe 수준의 자원을 써 방문 가능성이 높은 페이지에만 씁니다. prefetch는 비용이 작아 넉넉히 써도 됩니다.
Q. 언제 미리 당길지는 어떻게 정하나요?
eagerness로 정합니다. immediate와 eager는 규칙을 읽는 즉시, moderate는 링크에 200ms 머무를 때, conservative는 클릭을 누르기 시작할 때 당깁니다. 값을 적지 않으면 URL 목록 규칙은 immediate, 조건 규칙은 conservative가 기본입니다.
Q. 미리 당기면 안 되는 페이지가 있나요?
있습니다. 요청만으로 상태가 바뀌는 URL은 위험합니다. 로그아웃, 장바구니 담기, 광고 전환 집계처럼 부수 효과가 있는 경로는 조건 규칙으로 제외하고, 서버는 Sec-Purpose 헤더로 예측 요청을 구분해 처리합니다.
Q. 모든 브라우저에서 되나요?
아직 아닙니다. Speculation Rules는 일부 주요 브라우저에서는 동작하지 않아, 지원되는 곳에서 더 빠르게 만드는 점진적 개선으로 쓰는 것이 안전합니다. HTMLScriptElement.supports로 지원 여부를 확인할 수 있습니다.
