[Knock/OpenMind] 3G 환경에서 2초 걸리던 렌더링을 100ms로 줄인 과정

반응형 레이아웃에서 뷰포트 너비가 바뀌는 순간, 렌더링할 요소 개수가 늦게 재계산됐다. 브레이크포인트를 넘는 순간 잠깐이지만 이전 개수의 요소가 그대로 노출되는 현상이었다.

성능 문제는 아니었다. 하지만 상태 계산 시점이 렌더링과 맞지 않는 구조적인 문제였고, 그냥 두기엔 사용자 눈에 직접 보이는 오류였다. 이 글은 그 원인을 찾고 해결한 과정을 기록했다.

문제

무엇이 문제였는가

반응형 환경에서 뷰포트 너비를 변경하면 약 0.1초 정도 요소가 추가되는데 시간이 걸렸다.

원래라면 뷰포트 786px(Tablet size)을 기준으로 보다 클 때 8개, 작을 때 6개가 렌더링 되어야하는데 아래 사진과 같이 렌더링 지연 시간이 보이는 것을 확인할 수 있다.

가설

원인을 어디서 찾았는가

가장 먼저, 네트워크 환경에 따라 지연시간이 달랐기에 API 호출을 의심했다.

네트워크 제한이 없을 때, 0.1초, 4G 환경에서 0.2~0.3초, 3G 환경에서 2초정도 차이가 나는것을 확인하고 네트워크와 직결되는 API 호출 부분을 의심했다.

개발자 도구에 나온 3G 환경에서 2초 정도의 API 호출 시간이 렌더링 지연이 발생한 시간과 일치했고, API 요청이 빠른 다른 환경에서는 지연 시간에 비례하여 렌더링 지연이 일어나는 것을 확인할 수 있었다.

네트워크 속도 즉, API 응답을 UI 상태 데이터로 바로 사용한 것을 문제의 원인으로 삼았다.

판단

UI와 데이터 페칭을 분리하기 위해 다음과 같이 가설을 세웠다.

선택지 A 반응형 환경에 맞춘 상태를 각각 선언하여 사용

선택지 B 브라우저 캐싱을 활용한 API 호출 시간 단축

최종 선택 Tanstack React Query를 활용한 데이터 관리

결론부터 말하자면 Tanstack React Query를 활용하여 데이터 페칭과 UI 상태를 분리하여 문제를 해결했다.

가장 큰 이유는 Tanstack React Query의 데이터 관리 플로우에 있다.

위 그림에서 볼 수 있듯, Tanstack React Query의 가장 큰 특징은 캐시와stale에 있는데,

가장 먼저 데이터 페칭이 일어나면 캐시여부에 따라 데이터 페칭 시간을 단축할 수 있다.

또한 stale 즉, 데이터가 신선한지 판단하여 오래된 데이터를 페칭하여 갱신할 수 있다는 장점이 있다.

물론 갱신할 때에도 먼저 사용자에게는 이전 데이터를 보여주어 UI/UX를 보장하고, 뒤에서는 페칭을 시도하여 데이터가 여전히 신선한지 판단한다.

이 장점들은 다른 가설의 장점을 모두 포함하고 있었다.

또한, 이미 팀 내에서 Tanstack React Query를 도입하는데 이야기가 나오고 있는 상황이어서, 다른 페이지에서도 활용할 계획이 존재했기에 도입하지 않을 이유가 없었다.

선택지 A 반응형 환경에 맞춘 상태를 각각 선언하여 사용하지 않은 이유

반응형 환경에 맞춘 상태를 각각 선언하여 사용하려고 한 이유는 다음과 같다.

1. 미리 데이터페칭을 시도하여 가져온 데이터를 UI에 반영하여 렌더링 지연시간을 단축.
2. 뷰포트 변경 시 데이터 페칭 제외.

직접 구현하면 페이지네이션 단위별 상태 관리와 데이터 신선도 유지를 모두 수동으로 처리해야 했지만, TanStack React Query가 이미 이를 해결하고 있기에 이 선택지는 최종 선정에서 멀어졌다.

선택지 B 브라우저 캐싱을 활용한 API 호출 시간 단축을 활용하지 않은 이유

브라우저 캐싱을 활용하면 현재 문제의 가장 큰 문제인 네트워크 환경이 사용자에게 전달되는 UI에 반영되는 점에서 네트워크 환경의 불확실성을 보완할 수 있는 가장 큰 무기가 될 수 있다.

Tanstack React Query는 메모리 캐시이기에 페이지를 새로고침하면 캐시가 없어져 초기 네트워크 속도가 유지되지만, 브라우저 캐싱을 활용하면 페이지의 새로고침과 관계 없이 데이터를 캐싱할 수 있어 메모리 캐시의 한계를 극복할 수 있다.

당장 네트워크 환경에 대한 대책을 마련할 수 있지만, 네트워크 환경과 UI가 직결된다면 너무나 다양한 네트워크 환경에 맞춰 예외처리를 해야하는 것과 다를바 없기에 관리 비용이 해결 효과보다 커진다.

하지만 가장 큰 문제는 네트워크 환경이 아닌, 네트워크 환경이 사용자에게 전달되는 UI에 직접적으로 관여되는 것이라고 생각했다.

또한, HTTP 캐시는 Client에서 직접 설정할 수 없어 서버에서 지정해야만 했기에 당장 Next.js로 마이그레이션 하는 것은 일이 너무 커지는 상황이었다. 단순히 Client Storage를 활용하여 구현할 수 있겠지만, 이 또한 선택지 A와 같은 방식이어서 큰 장점이 되지는 못했다.

결과

무엇이 달라졌는가

크게 달라진 점은 2가지다.

캐싱되는 시간동안은 API 호출이 일어나지 않아 뷰포트 변경 시, 캐싱된 데이터를 기반으로 빠르게 반응할 수 있다.
네트워크 환경이 UI와 직접적으로 연결되어 있지 않아, 3G 네트워크 환경에서도 2초이상 걸리던 요청들이 5G와 같이 100ms 내로 온 것처럼 경험할 수 있다.

회고

다음엔 뭘 다르게 할 것인가

이번 작업의 핵심은 렌더링 지연을 네트워크 문제로 보지 않은 것이다. 네트워크 상태와 UI 상태를 분리하자, 해결책이 명확해졌다.
현재 staleTime과 gcTime은 경험적으로 각각 5초, 2분으로 설정했다. 데이터 변경 빈도와 사용자 재방문 주기를 기준으로 삼아야 한다는 건 알지만, 이를 측정할 수단이 없었다. 다음 프로젝트에서는 API 응답 변경 빈도를 먼저 파악하고 staleTime을 설정하는 순서로 접근할 것이다.

저장소: https://github.com/Sprint-8-2/KNOCK

배포링크: https://codeit-knock.netlify.app/

무엇이 문제였는가

원인을 어디서 찾았는가

선택지 A 반응형 환경에 맞춘 상태를 각각 선언하여 사용하지 않은 이유

선택지 B 브라우저 캐싱을 활용한 API 호출 시간 단축을 활용하지 않은 이유

무엇이 달라졌는가

다음엔 뭘 다르게 할 것인가

티스토리툴바