가격표를 보러 '요금 안내'를 누른 손님은, 그 클릭과 다음 화면 사이에서 아주 짧은 흰 공백을 마주한다. 길어야 반 박자다. 그런데 이 반 박자가 쌓이면 손님은 '이 사이트 좀 느리네'라고 느끼고, 여러 장을 오갈수록 그 인상은 굳는다. 그래서 개발자들은 오래도록 이 공백을 지우려 애써 왔다—마우스가 링크 위에 올라오는 순간을 감지해 다음 페이지를 미리 당겨오고, 받아 둔 걸 캐시에 쟁여 두고, 어느 것을 미리 불러올지 골라내는 일까지 전부 자바스크립트로 손수 떠안았다.
왜 '다음 페이지'는 늘 반 박자 늦었나
브라우저는 원래 손님이 실제로 링크를 누른 뒤에야 다음 페이지를 요청한다. 아주 정직하지만, 그만큼 굼뜨다. 이 순서를 앞당기려면 '손님이 곧 누를 것 같은 링크'를 미리 예측해서 데이터를 당겨 놓아야 하는데, 그 예측과 관리를 여태 개발자의 코드가 짊어졌다. 라이브러리를 깔고, 이벤트를 듣고, 언제 무엇을 프리페치할지 규칙을 손으로 짜야 했다는 뜻이다.
Speculation Rules가 대신 맡는 일
Speculation Rules API는 이 예측을 브라우저에게 통째로 넘긴다. 페이지에 '이런 링크는 미리 준비해 둬'라는 규칙 몇 줄만 심어 두면, 나머지—언제 당겨올지, 무엇을 캐시할지, 손님의 데이터 절약 설정을 존중할지—는 브라우저가 알아서 판단한다. 방식은 크게 둘이다.
- prefetch(미리 받기): 다음 페이지의 문서를 백그라운드에서 미리 내려받아 둔다. 손님이 누르는 순간 네트워크 왕복이 사라져 화면이 곧바로 뜬다.
- prerender(미리 그리기): 다음 페이지를 아예 보이지 않는 곳에서 미리 완성해 둔다. 클릭하면 이미 다 그려진 화면이 '즉시' 나타난다—전환이라기보단 순간이동에 가깝다.
공짜가 아니다—'열심(eagerness)'을 조절해야 한다
미리 불러오는 만큼 서버는 실제로 방문하지 않은 페이지까지 응답하게 된다. 모든 링크를 무작정 prerender하면 서버 비용과 트래픽이 새어 나가고, 조회수 집계도 부풀 수 있다. 그래서 규칙에는 얼마나 적극적으로 당겨올지를 정하는 값이 있다. 마우스가 링크에 닿거나 손가락이 눌리기 직전처럼 '누를 확률이 높아진 순간'에만 움직이도록 보수적으로 잡는 편이 안전하다. 결제·로그아웃처럼 미리 실행되면 곤란한 링크는 규칙에서 빼 둔다.
작은 회사 사이트가 지금 할 수 있는 것
반가운 점은, 이 기술이 프레임워크도 빌드 과정도 요구하지 않는다는 것이다. HTML에 규칙 조각 하나만 넣으면 되고, 지원하지 않는 브라우저는 그 조각을 조용히 무시할 뿐 사이트가 깨지지 않는다. 손님 동선이 뻔한 작은 사이트일수록 효과가 크다—'홈 → 서비스 소개 → 요금 → 문의'처럼 다음 발걸음이 예측되는 곳에 얌전한 규칙 하나를 얹으면, 손님은 페이지를 넘길 때마다 마주하던 그 반 박자의 공백을 더는 느끼지 않는다.
물론 규칙을 잘못 잡으면 서버 비용만 늘고 체감 속도는 그대로일 수 있다. 어떤 링크를 어느 정도의 열심으로 미리 준비할지는 사이트마다 다르고, 방문자 동선을 실제 데이터로 읽어야 답이 나온다. CYAN 에이전시는 작은 회사의 사이트를 만들 때 이런 최신 브라우저 기능을 '눈에 띄지 않게, 그러나 체감되게' 얹는 일을 함께 고민한다. 손님이 느끼지 못한 반 박자를 지우는 것—좋은 사이트의 속도는 대개 그런 보이지 않는 자리에서 갈린다.
