하이드레이션

한동안 웹 화면은 브라우저가 전부 그리는 쪽으로 갔습니다. 서버는 거의 빈 문서 하나만 내려 주고, 브라우저가 코드를 받아 실행한 다음 화면을 만들었습니다. 만드는 쪽에는 편했지만 사용자 쪽에서는 주소를 누르고 나서 몇 초 동안 흰 화면을 보는 일이 흔했습니다. 검색 엔진도 빈 문서만 받아 가서 내용이 색인되지 않았습니다.

그래서 서버가 완성된 HTML을 미리 그려 내려 주는 방식으로 돌아갔습니다. 화면은 곧바로 떴습니다. 그런데 서버가 보낸 것은 글자와 그림의 배치일 뿐이라, 화면이 다 보이는데도 버튼이 눌리지 않는 상태가 생겼습니다.

실제로는 이런 식으로 드러났습니다. 화면이 떴으니 사용자가 로그인 버튼을 누르는데 아무 일도 일어나지 않고, 두세 번 더 누른 뒤에야 한꺼번에 반응합니다. 검수 담당자가 "가끔 버튼이 안 먹어요" 라고 제보하면 개발자는 재현이 안 돼서 한참을 찾습니다. 빠른 기기와 빠른 회선에서는 이 구간이 너무 짧아 보이지 않기 때문입니다. 하이드레이션은 이 사이를 메우는 작업에 붙은 이름입니다.

화면은 완성된 것처럼 보이는데 아직 아무것도 눌리지 않는 구간입니다. 글자도 그림도 제자리에 있고 스크롤도 되지만, 버튼과 입력창은 아직 코드에 연결되지 않은 껍데기입니다.

이 구간에서 브라우저가 하는 일은 셋입니다.

1. 화면에 필요한 자바스크립트 파일을 내려받습니다. 이 파일이 300킬로바이트면 회선이 느린 환경에서는 받는 데만 1초 넘게 걸립니다.
2. 받은 코드를 실행해 화면이 어떤 구조여야 하는지를 계산합니다. 서버가 이미 그려 보낸 것과 같은 모양이 나와야 합니다.
3. 계산 결과를 서버가 보낸 화면에 맞춰 보고, 버튼과 입력창마다 눌렀을 때 실행할 동작을 붙입니다. 이 단계가 끝나야 클릭이 먹힙니다.

그래서 구간의 길이는 회선 속도와 기기 성능에 함께 걸립니다. 최신 노트북에서 100밀리초면 끝나는 일이 3년 된 보급형 휴대폰에서는 2초가 되기도 합니다. 개발자 노트북에서만 확인하면 이 구간은 없는 것처럼 보입니다. 같은 화면을 두고 한쪽에서는 문제가 없고 다른 쪽에서는 클릭이 씹히는 제보가 갈리는 이유가 여기 있습니다.

2번에서 계산한 모양이 서버가 보낸 것과 다르면 불일치가 납니다. 서버에서 "3분 전" 이라고 적어 보냈는데 브라우저가 실행할 때는 "5분 전" 이 되는 경우가 대표적입니다. 이때 브라우저는 그 부분을 지우고 다시 그리기 때문에 화면이 한 번 깜빡입니다. 서버가 그려 보낸 화면을 그대로 쓰겠다는 전제가 깨지면 하이드레이션이 주는 이득도 함께 사라집니다.

이 구간이 끝나는 조건은 하나입니다. 필요한 코드가 도착해 실행이 끝나고, 화면 위의 조작 대상에 동작이 전부 연결되면 사용자가 누르는 대로 반응하는 구간으로 넘어갑니다.

구간을 짧게 만드는 방법은 결국 자바스크립트를 줄이거나 나누는 쪽입니다.

1. 코드 스플리팅. 전체 코드를 한 번에 받는 대신 지금 보고 있는 화면에 필요한 만큼만 나눠 받습니다. 설정 화면에 한 번도 들어가지 않는 사용자가 설정 화면 코드까지 기다릴 이유가 없습니다.
2. 조각별로 나눠 붙이기. 화면 전체를 한 번에 연결하는 대신 조각 단위로 나누고, 먼저 보이는 곳이나 먼저 눌릴 곳부터 연결합니다. 화면 맨 아래의 도움말 영역은 사용자가 거기까지 내려갔을 때 연결해도 늦지 않습니다.
3. 동작이 필요 없는 부분에는 코드를 보내지 않기. 글과 이미지만 있는 소개 영역은 눌릴 일이 없으니 서버가 그려 보낸 상태로 두면 됩니다. 이렇게 하면 받아야 할 코드 자체가 줄어듭니다.

세 가지가 겨냥하는 곳이 조금씩 다릅니다. 첫째는 받는 양을, 둘째는 연결하는 순서를, 셋째는 연결할 대상 자체를 줄입니다. 화면 하나가 느리다면 셋 중 어디가 병목인지를 먼저 보고 손댑니다.

확인은 눈이 아니라 숫자로 합니다. 화면이 보이기까지 걸린 시간과 누를 수 있게 되기까지 걸린 시간은 다른 값이고, 하이드레이션이 늘어지면 앞은 그대로인데 뒤만 나빠집니다. LCP처럼 화면이 그려진 시점을 재는 지표만 보면 이 문제가 보이지 않습니다. 느린 기기와 느린 회선을 흉내 낸 조건에서 재야 실제 사용자가 겪는 길이가 나옵니다.

"화면은 빨리 뜨는데 하이드레이션이 늦어서 첫 클릭이 씹혀요."

보이는 속도와 눌리는 속도가 갈렸다는 뜻입니다.

"서버랑 클라이언트 결과가 달라서 하이드레이션 불일치 경고가 뜹니다."

같은 화면을 두 번 계산했는데 답이 달라 다시 그리고 있다는 말입니다.

"이 영역은 동작이 없으니까 하이드레이션에서 빼죠."

그만큼 내려받을 코드와 연결할 대상을 줄이자는 제안입니다.

페이지덱의 문서 목록 화면에서 나온 일입니다. 검수 단계에서 "목록 첫 항목을 누르면 가끔 안 열린다" 는 제보가 올라왔는데, 태오가 자기 노트북에서는 재현하지 못했습니다. 개발자 도구에서 회선을 느리게 잡고 기기 성능을 4분의 1로 낮춰 보니 화면이 뜬 뒤 1.4초 동안 클릭이 먹지 않았습니다.

태오는 목록에 필요 없는 편집기 코드까지 첫 화면에서 함께 받고 있던 것을 찾아 화면 단위로 나눠 받게 고쳤습니다. 지현은 여기에 한 가지를 덧붙였습니다. 연결이 끝나기 전까지 버튼을 눌린 것처럼 보이지 않게 흐리게 두자는 것이었습니다. 시간을 다 줄이지 못하는 구간에서는 지금 누를 수 없다는 사실이라도 보이는 편이 낫기 때문입니다.

서버에서 그려 보내면 화면이 빨라진다는 말을 그대로 받아들이는 경우가 많습니다. 실제로 첫 화면이 눈에 보이는 시점은 확실히 당겨지니 그렇게 느껴집니다. 하지만 당겨지는 것은 보이는 시점이고 눌리는 시점은 그대로이거나 오히려 뒤로 밀립니다. 서버가 보낸 화면을 맞춰 보는 작업이 추가로 들어가기 때문입니다. 이 차이를 모르면 지표상으로는 개선됐는데 사용자 문의는 늘어나는 상황이 생깁니다.

하이드레이션이 화면을 다시 그리는 과정이라고 이해하는 것도 흔합니다. 이름이 무언가를 채워 넣는 느낌이라 그렇게 읽힙니다. 원래 의도는 반대로, 이미 와 있는 화면을 다시 그리지 않고 그대로 재활용하면서 동작만 얹는 것입니다. 다시 그리는 일이 실제로 벌어졌다면 그건 정상 동작이 아니라 앞에서 말한 불일치이고, 서버 렌더링을 쓴 값을 그만큼 잃은 상태입니다.