모바일에서 홈페이지가 느린 이유와 코드블루 사이트에서 실제로 효과 있었던 개선

홈페이지가 늦게 뜨면 방문자는 기다려 주지 않습니다. 휴대폰은 PC보다 통신과 처리 속도가 느려서 차이가 더 크게 납니다. 코드블루 사이트도 휴대폰 기준으로 여러 번 측정하면서 고쳤습니다. 무엇이 무거웠고 언제 무엇을 바꿨는지, 남아 있는 기록 그대로 적어 둡니다.

측정해 보니 무거웠던 것들

1. 한글 웹폰트: 가장 무거운 파일이었습니다

한글 폰트는 1만 개가 넘는 글자를 담고 있어 파일이 큽니다. 코드블루가 쓰는 Pretendard 가변 폰트 원본은 2,057,688바이트였고, 측정해 보니 페이지에서 가장 무거운 단일 파일이었습니다. 그래서 처음 배포할 때부터 사이트에 실제로 쓰인 글자만 골라 담는 '서브셋' 파일을 썼고, 8월 19일 감사 때 이 파일은 144KB로 원본보다 93% 작았습니다.

다만 이 방식은 새 글을 쓸 때마다 서브셋을 다시 만들어야 하고, 쓰는 글자가 늘어나면 파일도 조금씩 커집니다. 가이드 글이 늘어난 지금은 202,940바이트(약 198KB)입니다. 그래도 원본의 10분의 1이 안 되니, 개선 작업 가운데 효과가 가장 컸습니다.

2. 이미지: 보이는 크기만큼만 받기

화면에 55px로 보이는 로고를 훨씬 큰 크기로 받고 있었습니다. 이미지에 '실제로 보이는 크기'를 알려 주자 로고 한 장에서만 불필요한 전송이 약 14.8KiB 줄었습니다. 포트폴리오 화면 캡처처럼 큰 이미지는 WebP 같은 가벼운 형식으로 바꿔 보내고, 화면 아래쪽 이미지는 그 위치까지 내려왔을 때 불러오게 해 두었습니다.

3. 3D와 애니메이션은 핵심 내용이 뜬 뒤에

8월 20일에는 실제 사이트를 휴대폰 조건으로 측정한 기록을 하나씩 따라가 봤습니다. 화면에서 가장 늦게 그려지는 큰 요소는 첫 화면 제목이었는데, 제목에 필요한 폰트와 화면 스타일이 열일곱 개쯤 되는 스크립트 파일과 동시에 내려받아지며 늦어지고 있었습니다. 그중 가장 큰 것이 첫 화면의 3D 모델 파일이었습니다. 3D를 브라우저가 한가해진 뒤에 불러오도록 순서만 바꿔서 해결했습니다. 그 뒤 10월에는 첫 화면을 3D 대신 글자 연출로 바꾸면서 3D 자체를 빼게 됐습니다.

첫 화면 제목은 처음부터 보이게 두는 것도 중요합니다. 제목이 투명한 상태에서 서서히 나타나는 효과는 보기에는 좋지만, 브라우저 입장에서는 가장 큰 내용이 늦게 그려진 것이 되어 속도 점수(LCP)가 나빠집니다. 코드블루도 이 부분을 먼저 고친 뒤에 위의 순서 문제를 찾았습니다.

8월 19일 감사에서 휴대폰 조건(처리 속도 4배 느리게, 통신 제한)으로 잰 결과는 첫 화면 제목이 그려지기까지(LCP) 2,188ms, 화면이 밀리는 정도(CLS)는 0이었습니다. 구글이 좋다고 보는 기준(LCP 2.5초 이하, CLS 0.1 이하) 안에 들어왔습니다.

4. 움직이는 효과는 휴대폰에서 다시 보기

속도는 처음 뜨는 시간만이 아닙니다. 다 뜬 뒤 스크롤이 버벅이는 것도 느린 사이트입니다. 코드블루는 위에 고정된 메뉴와 카드에 뒤 화면이 뿌옇게 비치는 효과를 넣어 두었다가, 휴대폰에서 스크롤이 손가락을 따라오지 못하는 문제를 겪었습니다. 10월 18일에 이 효과를 빼고 나서야 부드러워졌습니다.

속도와 화려함 사이

속도만 생각하면 아무 효과도 없는 사이트가 가장 빠릅니다. 하지만 업체의 분위기를 전하는 데 움직임이 도움이 될 때도 많습니다. 코드블루도 효과를 다 빼지 않고 순서와 방식을 바꾸는 쪽을 택했습니다. 핵심 문구와 연락 버튼이 먼저 뜨고, 장식은 그 뒤에 따라오게 하면 둘 다 챙길 수 있습니다.