Speculation Rules API는 사용자가 다음에 방문할 만한 페이지를 브라우저가 미리 내려받거나 아예 미리 렌더링해 두게 하는 웹 표준이다. 링크를 클릭하는 순간 이미 준비된 페이지가 튀어나오기 때문에, 잘 맞아떨어지면 페이지 이동이 거의 0초처럼 느껴진다. 몇 년째 웹 성능의 마지막 병목이던 '페이지 간 이동'을 정면으로 겨냥한 기능이다.
과거에도 미리 불러오기(prefetch) 시도는 있었다. 하지만 링크마다 태그를 붙이고, 언제 얼마나 미리 받을지 일일이 관리해야 해서 손이 많이 갔다. Speculation Rules는 이걸 선언적인 규칙 한 덩어리로 바꿨다.
클릭한 뒤에 페이지를 만드는 게 아니라,
클릭하기 전에 이미 만들어 둔다.
브라우저가 사용자의 다음 행동을 예측해 미리 렌더링해 두면, 실제 클릭은 준비된 화면을 꺼내 보여주는 일이 된다. 체감 속도의 차원이 달라진다.
2모드 prefetch ·prerender |
선언형규칙 JSON 한 덩어리로 일괄 지정 |
즉시이동 클릭→화면 거의 0초 |
LCP개선 다음 페이지 로딩 지표 향상 |
prefetch와 prerender는 다르다
Speculation Rules에는 강도가 다른 두 모드가 있다. 이 차이를 모르면 자원만 낭비하기 쉽다.
- prefetch — 다음 페이지의 문서를 미리 내려받아 둔다. 네트워크 왕복 시간을 없애 주지만, 화면을 그리는 작업은 클릭 후에 한다. 비용이 낮아 넉넉하게 걸 수 있다.
- prerender — 여기서 한발 더 나간다. 다음 페이지를 백그라운드에서 아예 완전히 렌더링해 둔다. 스크립트까지 실행되므로 클릭하면 진짜로 즉시 뜨지만, 그만큼 자원을 많이 쓴다.
규칙에는 '확신도'를 얹을 수 있다. 사용자가 링크 위에 마우스를 올리거나 손가락을 대는 순간처럼 클릭 확률이 높아졌을 때만 무거운 prerender를 발동시키는 식이다. 무작정 다 미리 그리면 데이터와 배터리를 태우니, 가능성과 비용의 저울질이 핵심이다.
<script type="speculationrules">
{
"prerender": [{
"where": { "href_matches": "/article/*" },
"eagerness": "moderate"
}]
}
</script>
왜 지금 다시 주목받나
즉시 이동이라는 경험은 원래 SPA(싱글 페이지 앱)의 전유물처럼 여겨졌다. 무거운 자바스크립트 프레임워크를 얹고 라우팅을 직접 관리해야 화면이 새로고침 없이 매끄럽게 바뀌었다. Speculation Rules는 이 경험을 평범한 여러 페이지 사이트(MPA)에서도 낼 수 있게 한다. 서버가 렌더한 단순한 HTML 페이지를 쓰면서도, 이동만큼은 SPA처럼 즉각적일 수 있다는 뜻이다.
여기에 뷰 전환(View Transitions)까지 얹으면 페이지가 부드럽게 넘어가는 애니메이션까지 붙는다. "가벼운 MPA로 돌아가되 경험은 SPA급으로"라는 최근 웹 개발의 흐름과 정확히 맞물리는 이유다.
| 항목 | Speculation Rules | 과거 prefetch 태그 |
|---|---|---|
| 지정 방식 | 규칙 한 덩어리로 일괄 | 링크마다 태그 |
| 최대 강도 | 완전 사전 렌더링 | 문서 미리 받기까지 |
| 발동 조건 | 확신도 기반 제어 | 사실상 즉시 |
| 체감 결과 | 즉시 이동 | 약간 빠름 |
공짜는 아니다
강력한 만큼 조심할 지점도 있다. prerender는 페이지를 실제로 로드하므로, 사용자가 클릭하지 않은 페이지의 분석(애널리틱스) 조회수가 잘못 잡히거나 광고 노출이 어긋날 수 있다. 그래서 페이지가 '아직 화면에 안 보이는 사전 렌더 상태'인지 감지해, 그 동안에는 로깅과 자동재생 같은 부수효과를 미뤄야 한다. 데이터·배터리 소모도 무시할 수 없어서, 확률 높은 링크에만 신중하게 거는 운영이 정석이다.
정리하면 Speculation Rules는 마법이 아니라 '예측의 도구'다. 예측이 맞으면 사용자는 마법 같은 속도를 얻고, 어긋나면 약간의 자원을 버린다. 이 균형을 얼마나 정교하게 잡느냐가 실력이다.
자주 묻는 질문
prefetch와 prerender 중 무엇을 써야 하나요?
확률이 애매한 다수 링크에는 비용이 낮은 prefetch를, 사용자가 거의 확실히 갈 다음 단계(예: 상세 페이지, 결제 단계)에는 prerender를 쓰는 조합이 무난하다. 모든 링크를 prerender하는 것은 자원 낭비로 이어지기 쉽다.
SPA를 안 써도 즉시 이동이 가능한가요?
가능하다. 그 점이 이 기술의 핵심 가치다. 서버가 렌더한 평범한 여러 페이지 사이트에서도 미리 렌더링을 통해 SPA에 준하는 즉각적인 이동 경험을 낼 수 있어, 무거운 프레임워크 없이도 빠른 웹을 만들 여지가 커졌다.
분석 데이터가 왜곡되지 않나요?
사전 렌더된 페이지는 사용자가 실제로 방문하기 전까지 '숨겨진 상태'다. 이 상태를 감지해 조회수 집계나 광고 노출 같은 부수효과를 화면이 실제로 활성화된 시점으로 미루면 왜곡을 피할 수 있다. 이 처리를 빠뜨리면 통계가 부풀 수 있다.
모든 브라우저에서 동작하나요?
지원 범위는 브라우저마다 차이가 있으므로, 지원하지 않는 환경에서는 규칙이 무시되고 평소처럼 동작하도록 설계해야 한다. 즉 즉시 이동은 '있으면 더 좋은' 향상 기능으로 얹는 것이 안전한 접근이다.

댓글 0