React Lighthouse 성능 측정 | 점수보다 병목 원인을 먼저 보는 법
React 프로젝트를 운영하다 보면 한 번쯤은 “페이지가 느리다”, “클릭했는데 반응이 굼뜨다”는 이야기를 듣게 됩니다.
이럴 때 가장 먼저 열어보기 좋은 도구 중 하나가 Lighthouse입니다.
Chrome DevTools나 PageSpeed Insights에서 바로 실행할 수 있고, 성능뿐 아니라 접근성, SEO, 모범 사례까지 한 번에 확인할 수 있어서 초반 진단용으로 꽤 유용합니다.
다만 여기서 먼저 정리해야 할 점이 있습니다.
Lighthouse는 React를 직접 최적화해주는 도구가 아닙니다.
대신 지금 이 페이지가 왜 느린지 브라우저 관점에서 먼저 보여주는 진단 도구에 가깝습니다.
즉, React 성능 최적화에서 Lighthouse는 “해결 도구”라기보다
문제를 발견하는 출발점으로 이해하는 편이 더 정확합니다.
Lighthouse를 React에서 어떻게 봐야 할까
React 프로젝트에서 Lighthouse를 실행하면 점수와 함께 여러 지표가 나옵니다.
처음 보면 숫자만 눈에 들어오지만, 실무에서는 점수보다 어떤 지표가 왜 나빠졌는지를 읽는 게 더 중요합니다.
예를 들어 이런 질문을 먼저 던져볼 수 있습니다.
- 첫 화면이 늦게 뜨는가
- 클릭 후 반응이 느린가
- 화면이 갑자기 흔들리는가
- JavaScript 실행 비용이 과도한가
- 이미지나 폰트 로딩이 병목인가
Lighthouse는 이런 신호를 먼저 보여줍니다.
그래서 React에서 Lighthouse는 “컴포넌트 최적화 도구”라기보다, 성능 문제의 위치를 빠르게 파악하는 도구로 보는 편이 맞습니다.
React 프로젝트라면 먼저 봐야 할 지표
React 앱에서 Lighthouse를 볼 때는 보통 아래 세 가지를 먼저 확인합니다.
1. LCP
가장 큰 콘텐츠가 화면에 보이기까지 걸리는 시간입니다.
쉽게 말하면 사용자가 페이지를 열었을 때
“가장 중요한 내용이 언제 보이느냐”를 뜻합니다.
히어로 이미지가 크거나, 폰트 로딩이 늦거나, 초기 데이터 응답이 느리면 LCP가 나빠질 수 있습니다.
2. INP
클릭, 입력, 탭 전환 같은 상호작용 이후
화면이 실제로 반응하기까지의 지연을 의미합니다.
React에서는 이 지표가 특히 중요합니다.
버튼을 눌렀는데 상태 변경이 무겁거나, 리스트 전체가 다시 렌더링되거나, 이벤트 처리 후 메인 스레드가 오래 막히면 체감 성능이 확 떨어집니다.
3. CLS
화면이 갑자기 밀리거나 흔들리는 정도를 뜻합니다.
예를 들어 이미지 높이가 늦게 잡히거나, 광고/배너/비동기 데이터 영역이 뒤늦게 생기면 사용자가 읽던 위치가 밀리게 됩니다.
즉, React에서 Lighthouse를 볼 때는
로딩은 LCP, 반응성은 INP, 화면 안정성은 CLS라는 기준으로 먼저 읽으면 흐름이 훨씬 잡히기 쉽습니다.
점수만 올리려 하면 방향이 틀어질 수 있다
React 성능 최적화에서 흔히 하는 실수가 있습니다.
바로 Lighthouse 점수가 낮게 나오면
곧바로 useMemo, memo, useCallback부터 넣는 식의 접근입니다.
물론 이런 최적화가 도움이 되는 경우는 있습니다.
하지만 실제로 느린 원인이 이미지인지, 서버 응답인지, 무거운 렌더링인지도 확인하지 않은 채 메모이제이션부터 늘리면 오히려 코드만 복잡해질 수 있습니다.
그래서 Lighthouse는 점수 자체보다
어떤 문제가 있는지 확인하는 첫 단계로 써야 합니다.
실무에서는 보통 이런 순서가 더 자연스럽습니다.
1. Lighthouse로 이상 신호를 확인한다
어떤 페이지에서 LCP, INP, CLS가 흔들리는지 먼저 본다.
2. Chrome Performance 패널이나 React DevTools Profiler로 좁힌다
어떤 상호작용에서 렌더링 비용이 커지는지 확인한다.
3. 번들 크기 문제면 번들 분석으로 본다
무거운 라이브러리나 불필요하게 큰 의존성을 찾는다.
4. 수정 후 다시 Lighthouse로 비교한다
전후 차이를 확인하면서 개선 효과를 검증한다.
이 흐름으로 보면 Lighthouse는
문제를 처음 잡아내는 레이더 역할에 가깝습니다.
React에서 자주 만나는 실제 개선 포인트
예를 들어 상품 목록 페이지가 있다고 해보겠습니다.
처음 진입할 때 이미지가 많고,
필터를 누를 때마다 리스트 전체가 다시 그려진다면
Lighthouse에서는 LCP와 INP가 함께 나빠질 수 있습니다.
이럴 때 실무에서 자주 나오는 대응은 대체로 비슷합니다.
첫 화면에 꼭 필요한 것만 먼저 렌더링하기
처음부터 모든 데이터를 한 번에 그리기보다,
사용자가 바로 보는 영역 위주로 먼저 보여주는 편이 낫습니다.
이미지 최적화하기
화면보다 큰 이미지를 그대로 보내거나,
용량이 큰 포맷을 그대로 쓰면 LCP가 쉽게 흔들립니다.
불필요한 재렌더링 줄이기
필터 하나 바꿨을 뿐인데 리스트 전체가 다시 렌더링된다면
체감 성능은 빠르게 나빠집니다.
무거운 라이브러리 늦게 불러오기
초기 로딩에 꼭 필요하지 않은 기능이라면 지연 로딩이나 코드 스플리팅이 더 유리할 수 있습니다.
메인 스레드를 오래 점유하는 작업 줄이기
클릭 한 번에 무거운 계산, 대량 상태 변경, 큰 렌더링이 몰리면 INP가 나빠지기 쉽습니다.
이런 문제는 전부 React 자체만의 문제는 아닙니다.
큰 이미지, 늦은 서버 응답, 서드파티 스크립트, 폰트 전략 같은 바깥 요소가 더 큰 원인인 경우도 많습니다.
즉, Lighthouse 점수가 낮다고 해서 무조건 “React가 문제다”라고 보면 안 됩니다.
Lighthouse 측정은 개발 모드가 아니라 배포 기준으로 봐야 한다
여기서 많이 놓치는 부분이 하나 있습니다.
React 프로젝트는 개발 모드에서 측정하면 숫자가 왜곡되기 쉽습니다.
개발 모드에는 경고, 검사, 디버깅용 동작이 포함되어 있어서 실제 배포 환경보다 느리게 보일 수 있기 때문입니다.
그래서 Lighthouse를 볼 때는 production build 기준으로 확인하는 편이 맞습니다.
npx serve -s build
이렇게 배포용 빌드를 띄운 뒤 Lighthouse를 실행해야
실제 사용자 환경에 더 가까운 결과를 볼 수 있습니다.
즉, React 성능을 볼 때는
개발 서버 숫자보다 배포 기준 숫자를 믿는 편이 낫다고 이해하면 됩니다.
Lighthouse만으로 부족한 이유
Lighthouse는 매우 유용한 도구지만, 이것만으로 모든 성능 문제를 다 해결할 수는 없습니다.
이유는 간단합니다.
Lighthouse는 기본적으로 실험실 환경에서 측정한 값이기 때문입니다.
실제 사용자는 다양한 기기, 다양한 네트워크, 다양한 사용 흐름에서 서비스를 이용합니다.
예를 들어 이런 경우가 있습니다.
- 첫 진입은 빠른데 로그인 후 대시보드가 느린 경우
- 페이지 로드는 괜찮은데 필터 클릭이 느린 경우
- 화면 전환은 빠른데 검색 입력 반응이 버벅이는 경우
이런 문제는 단순히 첫 페이지 로드만 보는 측정으로는 놓치기 쉽습니다.
그래서 React 앱에서는 Lighthouse만 보지 말고
실제 상호작용 구간을 함께 확인해야 합니다.
특히 라우팅 이후 동작이나 사용자 행동 흐름에서 병목이 드러나는 프로젝트라면,
초기 로딩 점수보다 사용 중 반응성을 더 중요하게 봐야 할 때도 많습니다.
React에서 Lighthouse를 잘 쓰는 방법
정리하면 Lighthouse는 이렇게 쓰는 게 가장 실용적입니다.
1. 점수를 목표로 삼지 않는다
숫자 자체보다 어떤 지표가 흔들리는지 본다.
2. LCP, INP, CLS부터 본다
React 앱에서는 이 세 지표가 체감 성능과 가장 잘 연결된다.
3. React 문제인지 아닌지 구분한다
이미지, 서버 응답, 폰트, 서드파티 스크립트 문제일 수도 있다.
4. Profiler와 함께 본다
컴포넌트 렌더링 비용은 React DevTools 쪽이 더 잘 보여준다.
5. 반드시 배포 기준으로 측정한다
개발 모드 숫자는 실제보다 느리게 보일 수 있다.
이 정도 원칙만 잡아도
Lighthouse를 훨씬 덜 피상적으로 보게 됩니다.
실무에서는 어떻게 받아들이면 좋을까
개인적으로 Lighthouse는
React 성능 최적화의 시작점으로는 꽤 좋은 도구라고 봅니다.
어떤 페이지가 느린지,
사용자 입장에서 어떤 지표가 흔들리는지,
어디서부터 봐야 할지를 빠르게 알려주기 때문입니다.
다만 이 도구 하나만으로 병목 원인까지 다 찾겠다고 생각하면 부족할 수 있습니다.
특정 컴포넌트가 왜 자주 렌더링되는지,
어떤 상태 변경이 메인 스레드를 오래 막는지,
어떤 상호작용이 실제 체감 지연을 만드는지는
React DevTools Profiler나 Chrome Performance 패널까지 같이 봐야 더 정확하게 잡힙니다.
즉, Lighthouse는
성능 문제를 찾아내는 도구이고,
Profiler는 왜 느린지 파고드는 도구라고 생각하면 정리가 쉽습니다.
정리
Lighthouse는 React 성능 최적화의 출발점으로 꽤 유용합니다.
어떤 페이지가 느린지, 어떤 지표가 흔들리는지 빠르게 확인할 수 있기 때문입니다.
다만 점수 자체를 목표로 잡기보다,
Lighthouse로 문제를 발견하고
React DevTools Profiler, Chrome Performance 패널, 번들 분석으로 원인을 좁혀가는 방식이 훨씬 실무적입니다.
정리하면 이렇게 볼 수 있습니다.
- Lighthouse는 진단 도구다.
- React 최적화 자체를 직접 해주지는 않는다.
- LCP, INP, CLS를 먼저 보는 것이 좋다.
- 점수보다 병목 원인 연결이 더 중요하다.
- production build 기준으로 측정해야 한다.
- 깊은 원인 분석은 Profiler와 함께 봐야 한다.
결국 Lighthouse는
React 앱의 전반적인 상태를 빠르게 확인하는 데 좋은 도구입니다.
다만 성능 최적화의 끝이 아니라, 가장 먼저 열어볼 만한 시작점으로 이해하는 편이 가장 현실적입니다.