CSR 렌더링 시간 최적화(with.Three.js) 13초에서 5초, 다시 2초까지

개발 프로젝트

maxwithjude 2025. 5. 12. 17:43

현재 클라이언트 렌더링 시 소요시간입니다

각 FBX 당 1초 이상 소요되고 있어 상당한 지연이 발생하고 있습니다.

평균 약 13초 소요 (고객은 3초 이상 기다리지 않는다) 최소 11.83s ~ 최대 14.26s

- 현재 fbx 파일들은 비동기로 불러오고 있는가?

비동기적 요청하고 있는 있다고 알았으나, 실제 네트워크에서 처리는 동기적으로 이루어져 있었습니다.

그 결과, fbx파일 각 렌더링 시간의 합의 시간이 걸렸습니다. → 결과 평균 13초

이 방식은 모델이 늘어날 수록, 동작이 늘어날 수록 극악의 구조

CSR 특성 상 최적화를 한다해도 최소 렌더 시간이 존재하기 때문에 고객 경험을 고려해 동적으로 움직이는 로딩을 표현해보았습니다.

Three.js도 사용하고 있지만 기본적인 이해를 못 하고 있어 공식문서도 읽어보며 최적화 방법을 찾고 있습니다.

three.js manual

threejs.org

fbx는 아니지만 비슷한 애니메이션 객체인 GLTF 확장자 파일 최적화 관련 공식문서를 확인해봅시다.

처음 렌더링 시에 모든 애니메이션 객체를 렌더링하지말고 일단 디폴트(채팅이 없을 때)의 FBX 애니메이션만 로딩 시키는 방식을 하면 훨씬 빨라질 것 이라고 판단했습니다.

다른 컴퓨터로 최초 접속 시 렌더링 시점로 인해 움직이지 않는 기본 정적 모델만 렌더링 되는 문제가 있었습니다.

모든 FBX 애니메이션을 하나로 묶고 이게 다 되어야 렌더링되도록 수정했었습니다.

병렬(비동기)로딩으로 한 결과, 로딩시간이 평균 5.35s 로 기존 약 13s 에서 약 59.23% 감소하였습니다.

하지만 네트워크가 약하거나 모바일 환경을 고려한다면, lazyloading 방식이 지금의 병렬로딩 방식보다 초기 부담이 덜하고 더 빠르기 때문에 더 적합할 것입니다.

아래 network 탭은 우선순위 & lazyloading 방식을 적용한 방법입니다.

기존과 다르게 초기 자세 Sitting.fbx만 바로 렌더링하는것을 볼 수 있습니다.

gif 참조 (강력새로고침으로 캐시 영향 없게 측정했으며 )

비동기로딩 방식(약 5.35s)

CSR 렌더링 시간 최적화(with.Three.js) 13초에서 5초, 다시 2초까지 | Notion

현재 클라이언트 렌더링 시 소요시간입니다

sugar-maple-neko2.notion.site

로 오시면 .gif로 보실 수 있습니다.

우선순위 & lazyloading 방식은 약 2.8초로 엄청 나게 단축된 것을 볼 수 있습니다.

그러나 우선순위 & lazyloading 하는 방식은 기본 자세를 빠르게 고객에게 보인 후 이후 lazyloading 동작들을 다운, 렌더링하는 동안 끊기는 현상을 보였습니다.

lazy로 로드한 FBX 파일은 내부적으로:

이런 작업을 GPU 또는 렌더링 스레드에서 동시에 처리하려 하다 보면,

저는 이 방식이 특히 클라이언트의 gpu가 약한 환경(모바일)과 네트워크가 약한 환경에서는 더 끊기고 치명적일 것이라고 판단했습니다.

lazyloading 을 우선순위 렌더링 성공 후 3초 이상 이후에 부터 렌더링하게 하고,

후순위 fbx파일도 한 번에 렌더링하는게 아니라 하나씩 렌더링하도록 바꿔보겠습니다.

+부가적으로 불필요한 조명 등 렌더 성능에 영향을 끼칠만한 요소들을 최소화하였습니다.

기존과 달리 초기 모델 생성 후 바로 끊김은 없지만 5초 이후(우선순위 fbx 렌더링 이후 순차적 렌더 시작 시간) 각 fbx 파일 렌더링 마다 끊기는 현상이 발생

이는 고객 경험 측면에서 최악일 것이고, 차라리 전 방식이 나을 것입니다.