프리페치

화면이 뜨는 데 걸리는 시간은 대개 기다린 만큼 그대로 느껴집니다. 링크를 누른 다음에 코드와 데이터를 받기 시작하면 그 시간은 사용자가 아무것도 못 하는 시간이 됩니다.

태오가 문서 목록에서 문서 하나를 열 때까지 걸리는 시간을 재 봤더니 700밀리초였습니다. 그중 500밀리초가 편집기 코드 묶음을 내려받는 데 쓰이고 있었습니다. 목록에 무엇이 있는지 보는 동안, 즉 사용자가 어느 문서를 열지 고민하는 3초 동안 네트워크는 아무 일도 하지 않고 있었습니다.

여기서 눈에 띄는 것은 자원이 무거워서 늦는 것이 아니라 받기 시작하는 시점이 늦다는 점이었습니다. 같은 500밀리초를 사용자가 고민하는 동안 써 버렸다면 누르는 순간에는 200밀리초만 남습니다.

프리페치는 이 시점을 앞으로 당기는 기법입니다. 지금 화면에 필요하지는 않지만 다음에 필요할 확률이 높은 것을 한가한 틈에 받아 둡니다. 예측이 맞으면 기다림이 사라지고 틀리면 받은 것이 버려집니다. 그래서 이 기법은 속도를 사는 대신 전송량을 거는 쪽에 가깝습니다.

무엇을 미리 받을지는 추측이 아니라 기록으로 정합니다. 목록 화면을 본 사람의 다음 행동이 무엇이었는지 세어 보는 것에서 시작합니다.

1. 다음 행동을 확률로 적습니다. 목록에서 문서를 여는 비율이 80퍼센트고 설정으로 가는 비율이 3퍼센트라면 미리 받을 것은 편집기 쪽입니다.
2. 받을 대상을 고릅니다. 다음 화면의 코드 묶음, 다음 화면이 부를 데이터, 서체 파일, 화면 위쪽에 뜰 이미지가 후보입니다. 크기가 크고 잘 바뀌지 않는 것이 값이 좋습니다.
3. 시작 시점을 정합니다. 화면이 다 뜬 직후, 링크에 마우스를 올린 순간, 목록을 끝까지 스크롤한 순간 중에서 고릅니다. 마우스를 올린 시점에 시작하면 적중률이 높은 대신 벌 수 있는 시간이 300밀리초쯤으로 줄어듭니다.
4. 우선순위를 낮춰 요청합니다. 지금 화면에 필요한 것과 같은 급으로 요청하면 현재 화면이 늦어집니다. 브라우저에 이건 나중에 써도 된다고 알리는 표시를 붙여 보냅니다.
5. 조건을 답니다. 사용자가 데이터 절약 모드를 켜 뒀거나 회선이 느린 것으로 감지되면 하지 않습니다. 쓰지도 않을 파일로 남의 데이터 요금을 쓰는 일이 되기 때문입니다.
6. 적중률을 잽니다. 미리 받은 것 중 실제로 쓰인 비율입니다. 이 값이 없으면 이 기법이 도움이 되는지 낭비인지 알 수 없습니다.

6번이 실제로 가장 자주 빠집니다. 적중률을 재지 않으면 전송량만 늘고 체감은 그대로인 상태가 몇 달 유지됩니다. 절반 아래로 떨어지면 대상이나 시점 중 하나가 잘못 잡힌 것입니다.

맞는 자리는 다음 행동이 좁게 갈리는 흐름입니다. 목록에서 상세로 들어가는 화면, 단계가 정해진 가입 절차, 다음 장으로 넘어가는 읽기 화면이 여기 해당합니다. 자원 쪽에서는 서체 파일과 코드 묶음이 좋은 대상입니다. 둘 다 크고, 한 번 받으면 오래 그대로입니다. 코드 스플리팅으로 나눠 둔 묶음과 함께 쓰면 필요한 조각만 미리 받을 수 있습니다. 코드 스플리팅은 코드를 조각으로 나눠 필요한 순간에만 받게 하는 기법입니다.

안 맞는 자리도 분명합니다.

1. 선택지가 넓은 화면 — 대시보드처럼 어디로 갈지 갈리는 자리에서는 적중률이 20퍼센트 아래로 떨어집니다. 다섯 개를 받아 하나를 쓰면 네 개분 전송량이 버려집니다.
2. 자주 바뀌는 데이터 — 미리 받아 둔 순간 낡기 시작합니다. 받아 둔 목록을 3분 뒤에 보여 주면 사용자는 없는 문서를 누릅니다.
3. 큰 이미지와 영상 — 크기가 크고 적중률이 낮은 조합이라 손실이 가장 큽니다.
4. 모바일 데이터 — 요금과 배터리가 사용자 쪽 비용으로 나갑니다.

서버 쪽 비용도 함께 봅니다. 미리 받는 요청도 서버에 도달하므로 안 쓰일 요청까지 처리하게 됩니다. CDN에 얹혀 있으면 부담이 줄어드는데, CDN은 자원을 사용자와 가까운 거점에서 내려 주는 배포망입니다.

"목록에서 편집기 묶음을 프리페치해 두면 여는 데 200밀리초로 줄어요."

누른 뒤에 받던 것을 미리 받아 기다림을 없애자는 제안입니다.

"링크 올렸을 때 시작하는 쪽으로 바꿨어요. 전부 미리 받으니 낭비가 너무 컸습니다."

적중률을 올리려고 시작 시점을 늦췄다는 뜻입니다.

"프리페치 적중률이 30퍼센트예요. 이건 그냥 전송량만 늘리는 겁니다."

미리 받은 것 대부분이 버려지고 있다는 지적입니다.

페이지덱은 문서 목록에서 편집기 코드 묶음만 미리 받습니다. 태오가 처음에는 목록에 보이는 문서 열 개의 내용까지 함께 받게 했는데, 적중률이 12퍼센트로 나왔습니다. 열 개를 받아 한 개를 쓰고 있었던 셈입니다.

그래서 내용은 마우스를 올린 문서 하나만 받는 쪽으로 바꿨습니다. 코드 묶음은 어느 문서를 열든 같으니 화면이 뜬 직후에 받고, 내용은 올린 순간에 받습니다. 두 대상의 적중률이 달라서 시점을 따로 잡은 것입니다. 민서가 데이터 절약 모드에서는 둘 다 끄자고 해서 조건도 함께 걸었습니다.

미리 많이 받을수록 빨라진다고 읽는 경우가 가장 많습니다. 받아 두는 것이 이득이니 많이 받으면 이득이 커질 것처럼 보입니다. 하지만 네트워크와 처리 능력은 한정되어 있어서, 안 쓸 자원을 받는 동안 지금 화면에 필요한 자원이 뒤로 밀립니다. 목록 화면에서 스무 개를 미리 받게 하면 목록 자체가 늦게 뜨고, 사용자는 빨라진 상세 화면을 보기 전에 느려진 목록을 먼저 겪습니다.

처음 들어온 화면도 빨라진다고 보는 것도 흔합니다. 성능 기법이니 전체가 빨라질 것 같지만 이건 두 번째 화면부터의 이야기입니다. 첫 화면에서는 미리 받을 근거가 아직 없고, 오히려 프리페치 요청이 첫 화면의 LCP를 늦출 수 있습니다. LCP는 화면에서 가장 큰 콘텐츠가 그려지기까지 걸린 시간입니다. 첫 화면을 빠르게 하는 일은 받을 것을 줄이는 쪽에서 다룹니다.