SPA로 앱 상세 페이지 성능 개선하기

안녕하세요. 와디즈 앱개발팀입니다.
와디즈 기술 조직은 과제에 따라 하나의 팀으로 뭉쳐 협업하곤 하는데요. 이번 글에서는 앱개발팀과 FE개발팀이 클라이언트개발팀으로 함께 와디즈 앱의 상세 페이지 진입 속도를 Android 약 38%, iOS 약 66% 개선한 경험을 소개하려고 해요. 

그럼 개선 전과 개선 후의 로딩 속도 차이를 보고 시작할게요!

기기와 네트워크 환경에 따라 로딩 속도는 차이는 있을 수 있어요.

도입 배경

클라이언트개발팀으로 앱개발팀과 FE개발팀은 어떤 것을 개선할 수 있을지 함께 고민했는데요. 상세 페이지는 가장 많이 탐색 되는 지면이기 때문에 그 로딩 속도를 개선하는 것을 목표로 설정하게 되었어요. 

앞서 와디즈 웹은 SPA 방식으로 상세 페이지 진입 속도를 개선한 상황이었는데요.

여기서 SPA란 Single Page Application의 약자로 최초에 한 번 페이지 전체를 로드하고, 이후부터는 Ajax를 통해 데이터를 바인딩하여 화면을 바꾸는 방식이에요.

앱에서는 상세 페이지 진입 시에 웹뷰를 새로 생성하고, URL을 로드하는 방식으로 동작해 매번 페이지 전체를 불러오고 있었어요. 그 때문에 웹에서의 개선 사항을 반영할 수 없었죠. 만약 앱에서도 상세 페이지의 웹뷰가 SPA 방식으로 동작하게 된다면 로딩 속도를 개선할 수 있겠다는 가설을 세웠습니다.

어떻게 개선했을까요?

기존 앱의 상세 페이지에서는 사용자가 닫기 또는 뒤로 가기 버튼을 누르는 등 페이지가 닫힐 때마다 웹뷰도 함께 사라졌어요. 그래서 SPA 방식을 적용하기 어려운 상황이었죠. 이 문제를 해결하기 위해 저희는 상세 페이지가 사라져도 웹뷰가 유지되는 방법을 고민했어요. 

그 결과, 아래 사진처럼 웹뷰만 별도로 분리해 유지하고, 필요할 때마다 화면에 다시 표시할 수 있도록 설계했어요. 이를 PoC(Proof of Concept)를 통해 검증했습니다.

상세 개발 방안

화면에 띄울 때

1. 앱이 최초 실행되면 재사용 할 웹뷰를 미리 생성하고, SPA 전환이 가능하도록 준비 페이지를 로드해요.
2. 사용자가 상세 페이지 진입할 때 새로운 화면을 띄우고, 미리 생성해 둔 웹뷰를 화면에 붙여요.
3. 웹에 SPA 전환을 요청하면 웹에서 데이터를 로드한 뒤 화면에 보여줘요.

화면이 닫힐 때

1. 화면에 붙여진 웹뷰를 다시 분리해요.
2. 웹뷰 외의 다른 이벤트 리스너와 객체들을 메모리에서 해제합니다.

상세 페이지에 진입할 때마다, 이 과정이 일어나고 덕분에 더 빠른 로딩으로 좋은 사용자 경험을 제공할 수 있게 되었어요.

기존에 웹뷰에서 제공하던 콜백들은?

페이지를 로드하면, 로드가 시작될 때 Android의 onPageStarted, iOS의 webView(_:didCommit:)이 호출되고 로드가 완료되었을 때 Android의 onPageFinished, iOS의 webView(_:didFinish:가 호출돼요.

그런데 SPA 전환으로 페이지가 변경되면, 위와 같은 WebView 관련 메소드들이 호출되지 않아요. 기존에 처리하던 작업을 할 수 없죠.

그 대응으로 웹과 앱 간의 통신 인터페이스로 처리할 수 있도록 정했어요.

와디즈 웹 → 앱 이벤트 정의

• accepted : 앱에서 웹으로 SPA 요청을 했을 때, 웹에서 SPA 방식으로 처리 가능하다고 다시 알려주는 이벤트
• loaded : 상세 페이지 데이터가 모두 불렸을 때
• rendered : 상세 페이지에 화면이 그려졌을 때
• failed : 로드 실패하였을 때

변경된 방식에 있어 고민한 것은?

새로운 방식이라고 해서 오로지 장점만 있는 것은 아니에요. 변경된 방식을 채택할 때 고민할 점이 많았어요. 예상치 못한 부작용이 발생할 수도 있기 때문이죠. 이에 대비해 여러 질문과 대응책을 준비했어요.

웹뷰를 미리 생성했을 때 발생하는 문제는?

미리 생성된 웹뷰는 문제를 일으킬 수 있어요. 예를 들어, 새로운 웹 페이지가 업데이트되면 변경 사항이 웹뷰에 적용되지 않을 수 있고, 로그인 세션이 만료될 수도 있어요. 이런 문제를 피하고자, 30분 주기로 웹뷰를 SPA 전환이 아닌 URL을 새로 로드하도록 했습니다. 그래서 새로운 요청이 들어오면 항상 최신 상태를 유지할 수 있게 되었어요.

웹, 앱이 이벤트를 수신받지 못하는 상황이라면?

SPA 방식으로 페이지가 전환되면, 웹뷰 콜백을 받을 수 없기 때문에 웹에서 전달받는 이벤트는 매우 중요해요. 웹과 앱이 이벤트를 수신받지 못하는 상황에서 기다리는 것 보다는 새로 페이지를 로드하는 것이 최선이라 생각했어요. 두 가지 대응책을 마련했습니다.

첫 번째로, 웹이 SPA 전환을 처리할 수 있는 환경인지 확인하기 위해 accepted 이벤트를 기다립니다. 만약 0.2초 안으로 accepted 이벤트가 오지 않으면, 처리 불가능한 환경이라 판단하여 페이지를 새로 로드해요.

두 번째로, SPA 요청에 대한 응답 값을 확인합니다. SPA 요청에 대한 응답 값이 true일 때는 정상적인 상황으로, SPA 방식으로 화면을 전환해요. 하지만 false 또는 null 일 경우에는 SPA 방식으로 화면 전환을 할 수 없다고 판단하는데요. 이때 페이지를 새로 로드합니다.

메모리 누수

안드로이드 앱의 개발 및 테스트 과정에서 재사용되는 웹뷰와 Fragment가 연결되어 있을 때 메모리 누수가 발생하는 문제가 생겼어요. 메모리 누수가 있으면 앱의 메모리 사용량이 계속해서 늘어나면서 전반적인 성능에 영향을 미칠 수 있어요.

이를 해결하기 위해, 상세 페이지가 닫힐 때 웹뷰와 Fragment를 완전히 분리했어요. onDestroyView, onDetach 에서 웹뷰의 이벤트 리스너나 WebViewClient, WebChromeClient 등을 해제했어요.

    override fun onDestroyView() {
        super.onDestroyView()
        webView?.setOnKeyListener(null) 
        webView?.webChromeClient = null 
        webView?.webViewClient = WebViewClient() 
    } 

    override fun onDetach() { 
        super.onDetach() 
        webView = null 
    }

 

메모리 누수 수정 후에는 정상적으로 동작하는 것을 확인하였습니다.

개선된 로딩 속도를 모니터링하기 위해 Firebase Performance를 활용하여 새로운 attribute를 추가했어요. 

성공, 실패, 미지원 케이스로 개선 사항을 구분하여 사용자들의 환경에서 어떤 추이를 보이는지 확인할 수 있었는데요. 모니터링 과정에서 SPA로의 전환 비율이 약 60%에 이른다는 사실을 확인했어요. 이는 사용자들이 페이지 간 이동을 더 빠르고 효율적으로 경험하고 있다는 것을 의미해요.

아래 그래프와 같이 개선 후 로딩 속도가 개선되었음을 확인할 수 있었습니다.

마치며

하이브리드 영역 개발이라는 점에서 이번 과제는 조금 어려움이 있었어요. 이슈가 발생했을 때 원인을 추적하는 등 웹과 앱 사이의 많은 소통도 필요했죠. 그때마다, 긍정적이고 의욕적으로 협업에 임해주신 FE 개발팀, QA팀께 감사의 말을 전하고 싶어요. 함께했기 때문에 프로젝트를 즐거운 마음으로 마무리할 수 있었습니다.

앞으로도 클라이언트개발팀으로 여러 팀이 협력해 와디즈 서비스를 발전하고 사용자들에게 더 나은 경험을 제공하고자 해요. 함께 발전해 나가는 과정에서 새로운 아이디어와 혁신을 발견할 수 있기를 기대합니다.

궁금한 내용이 남아 있나요? 👀

FE개발팀이 SPA 방식으로 웹 상세 페이지 속도를 개선한 이야기가 궁금하다면? 👉 클릭
앱개발팀의 Compose Multiplatform 도입기 👉 클릭