Speculation Rules API 실전 가이드: prerender/prefetch 전략과 안전 가드 정리

느려진 첫 클릭, Speculation Rules로 줄일 수 있을까요?

 

사용자는 링크를 누르는 순간 바로 다음 화면이 뜨길 기대합니다. 하지만 라우팅, 데이터 패칭, JS 번들 로드가 겹치면 첫 클릭 체감이 무겁습니다.

 

Speculation Rules API는 미리 불러오거나 미리 렌더링해 체감 속도를 앞당기는 브라우저 표준입니다.

 

이 글은 prerender와 prefetch를 언제, 어디에, 어떤 기준으로 적용할지 실무 관점에서 정리합니다. “무조건 다 미리 로드”가 아니라, 전환 가능성이 높은 링크만 선별하는 안전 가드까지 다룹니다.

 

왜 지금일까요? 크롬 등 주요 브라우저가 해당 API를 지원하면서, 기존 링크 프리패치 스크립트보다 설정이 단순해졌습니다.

 

반면 잘못 쓰면 불필요한 트래픽과 로그인 상태 누출 위험이 생길 수 있어 최소한의 가드가 필요합니다.

 

prerender와 prefetch, 언제 쓰고 무엇이 다른가

 

검색 결과 목록에서 상세 페이지로 이동할 때, prerender는 아예 다음 페이지를 미리 그려 두고, prefetch는 필요한 파일만 먼저 받아 둡니다. 둘 다 체감 속도를 높이지만, prerender는 클릭 즉시 화면 전환, prefetch는 네트워크 대기를 줄이는 효과에 가깝습니다.

 

전환 가능성이 높은 링크(장바구니→결제, 목록 1~2위 노출 상품 상세)에는 prerender가 적합합니다. 반면 추천 카드 슬라이드처럼 클릭 여부가 불확실한 링크에는 prefetch로 부담을 낮추는 편이 안전합니다.

 

실무에서는 화면 유형에 따라 기본 전략을 나눕니다.

 

- 로그인 후 결제/가입 완료 같은 결정적 전환: prerender
- 카테고리 이동, 다음 페이지네이션: prefetch
- 트래픽이 큰 홈 피드의 내부 링크: prefetch(오리진만), prerender는 상위 클릭 후보 1개 제한

 

한 단계만 내부 흐름을 보면, 브라우저는 rules에 맞는 링크를 감지한 뒤 `링크 인식 -> 리소스 확보(prefetch) -> 문서 격리 렌더(prerender)` 순으로 진행합니다. 격리 렌더는 현재 세션과 충돌하지 않도록 별도 컨텍스트에서 준비되며, 사용자가 클릭하면 즉시 활성화됩니다.

 

> 안티패턴: 전체 목록의 모든 링크를 prerender 대상으로 잡으면 서버·클라이언트 비용이 급격히 늘어납니다. 클릭 가능성이 높은 소수 링크만 대상으로 좁히세요.

 

바로 적용 요약: 규칙 선언 → 대상 좁히기 → 안전 장치

 

웹앱에서 Speculation Rules는 규칙을 선언하고 대상 링크를 좁혀 트래픽을 통제하는 방식입니다. 화면 유형별로 핵심만 점검하세요.

 

- 규칙 위치: <script type="speculationrules">를 공통 레이아웃에 둡니다.
- 대상 정의: URL 패턴·링크 선택자로 후보를 제한합니다.
- 방식 선택: 전환 가능 경로는 prerender, 그 외는 prefetch로 나눕니다.
- 안전 가드: 동일 출처, GET 요청, 인증 경로 제외를 지킵니다.
- 한도 관리: prerender는 동시 1개, prefetch는 핵심 리소스를 먼저 가져옵니다.

 

설정은 JSON 한 개로 선언하면 유지가 쉽습니다. 공통 레이아웃에 두고 라우트별 패턴만 조정하세요.

 

<script type="speculationrules">
{
  "prerender": [{
    "where": { "href_matches": "/checkout$" },
    "eagerness": "moderate"
  }],
  "prefetch": [{
    "where": { "href_matches": "/products/.*" },
    "eagerness": "conservative"
  }]
}
</script>

 

prerender는 결제처럼 클릭 확률이 큰 한두 경로에만 씁니다. 목록→상세는 prefetch로 넓게 처리하고, 트래픽이 빠듯하면 eagerness를 보수적으로 둡니다.

 

도입 전후 확인 포인트입니다.

 

- 네트워크: DevTools로 prefetch/prerender 횟수와 용량을 봅니다.
- 보안: 쿠키 포함 요청이 외부로 나가지 않도록 점검합니다.
- UX: 클릭 후 TTI/INP 개선을 Core Web Vitals로 비교합니다.
- 백엔드: prerender가 서버 피크와 겹치지 않는지 모니터링합니다.

 

> 안티패턴: 로그인·마이페이지 같은 개인화 화면을 prerender하면 캐시·세션 충돌이 날 수 있습니다. 개인화가 강하면 prefetch만 쓰거나 제외하세요.

 

흔한 실수와 선택 기준 한 번에 정리

 

사용 전 가장 많이 놓치는 지점은 범위를 과하게 잡는 것입니다. 전환 가능성이 낮은 링크까지 prerender/prefetch하면 네트워크가 분산되어 오히려 체감이 떨어질 수 있습니다.

 

- 전체 네비게이션 일괄 prerender
- 로그인·마이페이지 같은 인증 필요 경로 prerender
- 외부 도메인·POST 요청 대상 prefetch
- 이미지·비동기 데이터까지 무차별 prefetch

 

안전 가드를 두면 과소/과다 로드를 피할 수 있습니다. 다음 체크리스트로 간단히 거르세요.

 

- 동일 출처만 허용, 쿠키가 붙는 민감 경로 제외
- GET·캐시 가능한 정적 리소스 위주 prefetch
- prerender 동시 1개, 후보는 상위 클릭 확률 링크 1~2개
- 뷰포트 근처·포커스된 카드 등 사용자 의도 신호 활용

 

비교 관점에서의 선택 기준은 명확합니다. 클릭 확률이 높고 초기 페인트 비용이 큰 화면이면 prerender, 그렇지 않으면 prefetch가 기본값입니다.

 

- 고가치 전환(결제 확인, 가입 완료): prerender
- 목록→상세, 다음 페이지네이션: prefetch
- 홈 피드·추천 슬롯 다수 링크: prefetch만, 상위 1개만 조건부 prerender

 

> 안티패턴: “첫 방문자에게 전 페이지 prerender”는 피하세요. 초기 세션의 네트워크 여유가 적어 핵심 리소스 로딩이 지연되고, 모바일에서는 데이터 비용이 커집니다.

 

지금 적용할 한 페이지 체크리스트

 

전략은 단순합니다. 전환 가능성이 높은 링크만 선별해 prerender, 나머지는 가벼운 prefetch로 분리하면 됩니다.

 

- 공통 레이아웃에 <script type="speculationrules"> 한 번 선언
- 동일 출처·GET만 허용, 인증/민감 경로 제외
- 상위 클릭 후보 1~2개만 prerender, 그 외는 핵심 리소스 prefetch
- 뷰포트 근처·포커스 같은 사용자 신호로 후보 좁히기

 

실행 순서는 짧게 이렇습니다: 후보 정리 → 규칙 작성 → 트래픽·캐시 적중률 모니터링 → 범위 조정. 초기에는 결제·가입 완료 등 확률이 높은 경로부터 시작하세요.

 

> 안티패턴: 전역 네비·외부 도메인까지 일괄 prerender/prefetch는 네트워크 혼잡과 보안 리스크를 키웁니다. 첫 주 적용은 트래픽이 적은 시간대에 배포하고 로그를 꼭 점검하세요.

 

선택자 규칙으로 안전한 사전로딩

 

하나의 페이지에서 선택자 기반 규칙으로 후보 링크를 좁혀, 필요한 트래픽만 미리 불러옵니다. 결제·가입 완료처럼 전환 신호가 뚜렷한 링크만 prerender 대상으로 둡니다.

 

공통 레이아웃 하단에 규칙 스크립트를 넣고, 화면별로 클래스나 data 속성으로 대상을 표시하세요. 아래 예시는 최우선 1개는 prerender, 나머지는 핵심 리소스만 prefetch합니다.

 

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/checkout/confirm" },
        { "selector_matches": "a[data-intent='primary']" }
      ]
    },
    "eagerness": "moderate",
    "prefetch": "none"
  }],
  "prefetch": [{
    "where": {
      "and": [
        { "href_matches": "^/products/.*" },
        { "selector_matches": ".card a" }
      ]
    },
    "eagerness": "conservative",
    "only_same_origin": true
  }]
}
</script>

 

where로 링크 범위를 줄이고, eagerness로 실행 시점을 조절합니다. 같은 출처만 허용하고, 로그인·결제 인증 경로는 정규식에서 제외하세요.

 

> 실무 팁: 네트워크 혼잡을 피하려면 화면당 prerender 1개, prefetch는 접힌 영역 위(폴드 상단)만 지정하세요.