React Native Lazy Loading으로 앱 시작 속도 개선하기

📒 React Native Lazy Loading으로 앱 시작 속도 개선하기

---

이번에 회사에서 앱 성능 개선 작업 업무를 하며 시작 속도 개선을 위해 Lazy Loading을 도입했습니다.
그 과정에서 앱 시작 속도를 2~3배 개선하는 성과도 있었고, 이걸 측정하고 분석하느라 RN 구동 방식에 대해서도 깊게 파악하며 이리저리 공부가 많이 된 것 같습니다.
그럼 react native에서의 Lazy Loading과 적용을 통한 속도 개선, 측정 방식까지 소개드립니다.

📌 React Native 앱이 실행될 때

React Native로 빌드한 앱은 기본적으로 내부에 단일 번들 파일이 존재합니다.
이 번들 파일은 앱을 실행할 때 entry point인 index.js에서부터 모든 import를 타고 들어가 전체 JS 코드를 평가하기 시작합니다.
그렇게 코드 평가가 끝났다면 그제야 멈춰있던 화면이 풀리면서 첫 렌더링이 시작됩니다.

📌 앱 시작 속도를 올리는 방법

이 번들 코드를 평가하느라 앱 시작 시간이 지연된다는 것은 알았고, 그럼 번들 코드 평가 시간에 영향을 주는 요소는 무엇일까요?
당연하겠지만 바로 번들의 사이즈입니다.
 
자바스크립트 평가와 실행 관점으로 본다면 번들 로드는 평가 단계입니다.
복잡한 연산 같은 것들은 실행 단계에 포함이 되니깐 앱 시작 시간에 영향을 주지 않고, 그저 많은 JS 코드량과 번들 용량이 평가 단계에 영향을 줘 시작 시간을 늘리는 요소가 됩니다.
 
그럼 앱 시작 속도를 빠르게 하려면 번들 사이즈를 줄이거나 평가할 코드를 줄이면 되겠죠?
 
하지만 번들 사이즈를 확실하게 줄이는 건 너무 어려운 일입니다.
애초에 Metro 번들러는 Tree Shaking을 지원하지 않기도 하고, 팀원이나 본인이 작성한 불필요한 코드를 줄이는 건 번들 사이즈에 티도 안 납니다. 결국 용량이 큰 라이브러리를 정리하는 게 가장 확실한 방법인데, 이건 또 마이그레이션 해야 하는 리소스가 필요해서 쉽지 않죠.
 
결국 코드 평가만 남게 되었는데, 이건 비교적 쉽습니다.
바로 Lazy Loading을 통해서요.

📌 React Native의 Lazy Loading

const LazyComponent = React.lazy(() => import("../Component"))

React에서는 위와 같이 React.lazy를 사용하여 해당 컴포넌트 코드의 로드를 렌더 전까지 지연시킬 수 있습니다.
이를 사용한다면 실행 시점까지 코드 평가를 지연시켜 초기 메모리 사용량을 줄이게 되어서 "앱 시작 후 첫 콘텐츠 렌더링 시작 시간"인 "First Contentful Paint(FCP)"을 개선할 수 있게 됩니다.
 
그런데 같은 React지만 웹에서 사용할 때와 RN을 통해 앱에서 사용할 때의 몇가지 차이점이 존재합니다.

• React Web (Webpack, Vite)
  
  • lazy가 적용된 코드는 번들러가 번들을 별도의 청크로 분리해줍니다.
  • 코드의 실행 시점에 네트워크 요청을 통해 청크를 불러옵니다.
  • 번들이 여러 개로 쪼개지고 번들 사이즈에 차이가 생깁니다.
• React Native (Metro)
  • lazy가 적용되어도 기본적으로 하나의 JS 번들 파일로 번들링 됩니다.
  • 실행시점에 코드를 번들에서 불러와 평가합니다.
  • 단일 번들이며 번들 사이즈에 차이가 없습니다.

사용하기에 크게 어렵지도 않으니 바로 적용 전과 후의 차이를 확인해 보시죠.

📌 Lazy Loading 전 - 후 차이 측정하기

GitHub - devlasbe/rn-lazy-loading: React Native에서 Lazy Loading을 통해 앱 시작 속도를 측정

 

react-native-performance로 앱 시작 시간 측정하기

전체 예제 코드와 시간 측정 방법은 위 링크를 참고해 주세요.
 
그럼 Lazy Loading을 적용했을 때 얼마나 앱 시작 시간에 차이가 발생하는지 예제로 살펴보겠습니다.

🔎 무거운 코드 만들기

Lazy Loading의 효과를 확인하기 위해서는 우선 정말 무거운 코드를 만들어야 합니다.
그래서 저는 2가지 방법을 사용했습니다.
 
1. 무작정 코드 양 늘리기

const NestedNavigation = () => {
  return (
    <NestedStack.Navigator>
      <NestedStack.Screen name="HeavyPage1" component={HeavyPage1} />
      <NestedStack.Screen name="HeavyPage2" component={HeavyPage2} />
      <NestedStack.Screen name="HeavyPage3" component={HeavyPage3} />
      <NestedStack.Screen name="HeavyPage4" component={HeavyPage4} />
      <NestedStack.Screen name="HeavyPage5" component={HeavyPage5} />
    </NestedStack.Navigator>
  );
};

export default NestedNavigation;

 

그냥 양만 늘리기 위해 Text 컴포넌트를 1000개가량 때려 박은 페이지를 5개 만들었습니다.
하지만 1000개 정도로는 용량에는 크게 차이가 없었고, 무작정 양만 늘렸다가 파일을 잘못 열었을 때 메모리 부족으로 IDE가 터져버려 다른 방법을 선택했습니다.
 
2. 무거운 라이브러리 설치하기

$ yarn add @faker-js/faker lodash mathjs moment ramda

용량이 크기로 유명한 라이브러리를 싹 다 설치해 준 뒤.
 

import React from 'react';
import { Text, ScrollView } from 'react-native';
// @ts-ignore
import _ from 'lodash';
// @ts-ignore
import * as Ramda from 'ramda';
import moment from 'moment';
import * as MathJs from 'mathjs';
import * as fakeJs from '@faker-js/faker';

console.log(_);
console.log(moment);
console.log(Ramda);
console.log(MathJs);
console.log(fakeJs);

const ImportHeavyPackagePage = () => {
  return (
    <ScrollView>
      <Text>ImportHeavyPackagePage</Text>
    </ScrollView>
  );
};

export default ImportHeavyPackagePage;

냅다 전체 코드를 import 해버리는 방법을 선택했고, 번들 용량을 획기적으로 늘리는 데 성공했습니다.
 

react-native-bundle-visualizer를 확인해 보니 번들의 용량과 상태는 위와 같았습니다.
용량은 7mb로 실제 프로덕트 앱 번들과는 한참 차이나지만, 이 정도만 되어도 실험하는 데는 문제가 없습니다.

🔎 적용 전 - 후 시간 측정하기

import { createStackNavigator } from '@react-navigation/stack';
import Home from '../pages/Home';
import { NavigationContainer } from '@react-navigation/native';
import React from 'react';
import { PerformanceMeasureView } from '@shopify/react-native-performance';
// import NestedNavigation from './NestedNavigation';

const NestedNavigation = React.lazy(() => import('./NestedNavigation'));

const RootStack = createStackNavigator();

const PerformanceHomeScreen = () => {
  return (
    <PerformanceMeasureView screenName="Home" interactive={true}>
      <Home />
    </PerformanceMeasureView>
  );
};

const RootNavigation = () => {
  return (
    <NavigationContainer>
      <RootStack.Navigator initialRouteName="Home">
        <RootStack.Screen name="Home" component={PerformanceHomeScreen} />
        <RootStack.Screen name="Nested" component={NestedNavigation} />
      </RootStack.Navigator>
    </NavigationContainer>
  );
};

export default RootNavigation;

무거운 컴포넌트들을 모아놓은 Navigation을 Lazy Loading 하는 방식으로 측정했으며, 결과는 다음과 같습니다.
 

• Lazy Loading 미적용

• Lazy Loading 적용

 
핸드폰이 앱 실행 시 번들을 평가하는 시간은 JS Boot Time입니다.
release 모드로 빌드한 apk 파일을 안드로이드 시뮬레이터에 직접 설치해 각각 3회씩 시간을 측정했으며, 결과는 다음과 같습니다.

	미적용	적용
1회차	578ms	123ms
2회자	501ms	88ms
3회차	540ms	84ms

간단한 실험인데도 엄청난 차이가 느껴집니다.
이번에 업무로 프로덕트 앱 로드 시간을 약 5초에서 1.5초로 줄였으니 번들 사이즈가 크면 클수록, 핸드폰 사양이 낮으면 낮을수록 적용 전 후의 차이가 확연하게 나타나게 됩니다.

📌 주의할 점

그렇지만 로드 시간이 줄어든다고 무작정 모든 컴포넌트들을 Lazy Loading 할 순 없습니다.
왜냐하면 사용하게 될 코드들은 어차피 실행 시점에 로드되기에, 화면 이동할 때마다 로딩 화면을 보여주면 사용자에게 불편함을 야기할 수 있기 때문입니다.
그렇기에 전략적으로 1회성 화면이나 사용 빈도가 낮은 페이지들을 중점으로 적용하며 점진적으로 사용해야 할 필요가 있습니다.