스켈레톤 UI

불러오는 중임을 알리는 방법은 오래 돌아가는 원 하나였습니다. 화면 가운데에 원을 두고 데이터가 오면 치우는 방식인데, 얼마나 남았는지도 무엇이 들어올지도 알려 주지 않습니다.

페이지덱 문서 목록에서 그 대가가 드러났습니다. 목록을 여는 데 2초쯤 걸렸고 그동안 가운데 원만 돌았습니다. 데이터가 도착하면 목록이 한꺼번에 채워지며 높이가 바뀌었고, 그 순간 누르려던 항목이 밀려 다른 문서가 열렸습니다. 문의 내용은 느리다는 말이 아니라 잘못 눌렸다는 말이었습니다.

2초를 줄이지 못한다면 그 2초를 다르게 보이게 하고 화면이 흔들리지 않게 하는 것이 남은 방법입니다. 그 둘을 한꺼번에 하는 표현이 이 방식입니다.

들어올 내용의 자리를 회색 덩어리로 먼저 그려 두고, 데이터가 도착하면 그 자리에 그대로 채워 넣습니다. 지키는 것이 다섯입니다.

1. 실제 화면과 같은 모양과 크기로 그립니다. 뼈대가 실제보다 짧거나 개수가 다르면 채워지는 순간 화면이 또 튀어서, 원을 쓰던 때와 같은 문제가 남습니다.
2. 개수는 실제로 들어올 만큼만 둡니다. 목록에 보통 다섯 건이 온다면 뼈대도 다섯 개입니다. 화면을 가득 채우면 실제 데이터가 적을 때 줄어드는 모습이 오류처럼 보입니다.
3. 은은한 움직임을 넣습니다. 회색 덩어리가 완전히 멈춰 있으면 로딩이 아니라 빈 화면으로 읽힙니다. 밝기가 천천히 오가는 정도면 충분합니다.
4. 짧게 끝나는 데이터에는 쓰지 않습니다. 0.3초 안에 도착하는 화면에 뼈대를 넣으면 회색이 깜빡였다 사라지는 것만 보입니다.
5. 실패하면 오류 상태로 넘깁니다. 뼈대가 30초째 남아 있으면 사용자는 기다리는 중인지 고장인지 구분하지 못합니다.

이 방식이 바꾸는 것은 체감입니다. 데이터가 빨리 오지는 않으니 가장 큰 콘텐츠가 그려지기까지 걸린 시간을 재는 LCP 같은 지표는 뼈대를 넣어도 좋아지지 않습니다. 화면 구조가 먼저 보이는 덕에 같은 2초가 짧게 느껴지고 레이아웃이 덜 흔들리는 것이 얻는 것 전부입니다.

"여기 스피너 대신 스켈레톤으로 갑시다. 목록 높이가 계속 바뀌어서요."

내용이 채워질 때 화면이 튀는 문제를 막자는 제안입니다.

"뼈대가 실제 카드보다 짧아요. 채워질 때 또 밀립니다."

뼈대의 크기가 실제 화면과 달라 목적을 못 이룬다는 지적입니다.

"이 화면은 0.2초면 오는데요. 그냥 바로 그리죠."

빠른 화면에는 이 표현이 오히려 방해가 된다는 뜻입니다.

페이지덱에서는 민서가 뼈대를 시안에 함께 그립니다. 기본 화면만 넘기면 로딩 모습이 개발 단계에서 즉흥으로 정해져 뼈대 크기가 실제와 어긋납니다. 태오는 서버 응답이 0.5초를 넘는 화면에만 뼈대를 붙이고 그 아래는 그냥 그립니다.