본문 바로가기
2026년 8월 23일6분 읽기

Speculation Rules API — 클릭 전에 미리 그려두는 즉시 페이지 이동

YS
김영삼
조회 3
Speculation Rules API — 클릭 전에 미리 그려두는 즉시 페이지 이동

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

아직 댓글이 없습니다.
Ctrl+Enter로 등록