TIL - 트러블 슈팅: 커뮤니티 리스트 최적화 - 2

TIL - 커뮤니티 리스트 최적화: 렌더링 시간 개선 시도 - 1

TIL - 커뮤니티 리스트 최적화: 렌더링 시간 개선 시도 - 1

이전 접근의 문제점

• 개발 환경(dev)과 프로덕션 환경(Vercel)의 성능 차이를 고려하지 않았음
• 환경 차이로 인해 최적화 효과가 과대 평가되었을 가능성
• 그러나 Promise.all을 통한 병렬 처리 최적화는 여전히 유효한 개선 사항

 

 

새로운 문제 상황

1. 렌더링 시간 증가 및 웹 바이탈 성능 저하

문제 상황

• 렌더링 시간이 급격히 증가
• Lighthouse 성능 점수가 크게 하락 (50점)

Lighthouse 성능 점수

시도한 방법 및 원인 분석: 

• SSR 최적화 및 코드 스플리팅
  • 초기 데이터만 SSR로 처리하고 나머지는 동적 임포트
  • 주요 컴포넌트 메모이제이션 적용
• Supabase 업그레이드
  • 무료 티어 제한 초과 인한 성능 저하 의심
  • 유료 플랜으로 업그레이드

결과

• 다음 날 Lighthouse 성능 점수 90~100점으로 대폭 상승
• Supabase가 원인이었지만 덕분에 코드 스플리팅과 메모이제이션으로 성능 향상에 기여

Lighthouse 성능 점수

학습 포인트

1. 성능 최적화는 단순히 코드 수정만으로 해결되지 않을 수 있음
2. 인프라 (예: 데이터베이스)의 성능도 전체 애플리케이션 성능에 큰 영향을 미침
3. 코드 스플리팅과 메모이제이션은 장기적인 성능 개선에 도움이 됨
4. 성능 문제 해결 시 다양한 요인을 고려해야 함 (코드, 인프라, 외부 서비스 등)

 

2. UX 관점에서의 긴 로딩 시간

문제 상황

• 성능 점수는 개선되었으나 사용자 체감 로딩 시간이 여전히 길다고 판단됨 (2.5~3초)
• 개발자(튜터님)와 사용자로부터 로딩 시간이 길다는 피드백 접수

원인 분석

• 크롬 개발자 도구의 성능 탭과 네트워크 탭을 통한 병목 지점 확인

크롬 개발자 도구의 네트워크 탭

• Next.js의 Link 컴포넌트를 사용함에도 불구하고 prefetch 후 페이지 전환 지연 발생

 

Next.js의 Link 컴포넌트를 사용함에도 불구하고 prefetch 후 페이지 전환 지연 발생

• 복잡한 API 요청 구조로 명확한 원인 파악 어려움
  • 카테고리별 첫 페이지 프리페칭(클라이언트 사이드에서 요청해서 큰 영향은 없을 것으로 판단)
  • 카테고리별 무한 스크롤 구현
  • 사용자 정보, 좋아요 여부, 조회수, 댓글 등 다양한 데이터 필요
  • 일반 게시글과 Q&A 게시글의 좋아요 로직 차이
  • 다수의 테이블 JOIN 연산
  • 텍스트 에디터(HTML 태그)에서 추출된 이미지, 제목, 내용 처리

시도한 방법

 

 

• 동일 환경에서의 테스트를 위한 setup:
  • git clone 후 Vercel 재배포
  • 문제가 되는 페이지를 복사하여 다각도로 분석 환경 구성
• 사용자 조회 최적화:
  • getUser 대신 supabase.auth.getSession() 사용
  • 근거: 개발자의 조언과 300명 이상의 사용자로 인한 조회 시간 증가 우려 -> 단순 좋아요 조회로 보안 문제가 없을 것으로 판단
• 데이터베이스 쿼리 최적화:
  • Supabase 쿼리에서 JOIN 연산 제거 및 메서드 분리
  • 근거: 여러 테이블 JOIN으로 인한 성능 저하 가능성, 이전 Supabase 업그레이드 경험 참고
• 렌더링 방식 변경 및 UX 개선:
  • SSR 제거 및 클라이언트 사이드 데이터 요청 테스트
  • 로딩 UI 개선 (스켈레톤 로딩 고려)
  • 근거: 3시간 내 개선이 어려울 경우 로딩 화면 표시가 UX 측면에서 유리하다고 판단
• 성능 최적화 기법 적용:
  • SQL 함수 중 조회수 기능을 낙관적 업데이트로 변경
  • 근거: 불필요한 데이터베이스 조회 감소로 인한 성능 향상 기대

결과

• 클라이언트에서 직접 데이터 요청 시 로딩 시간 0.49초로 대폭 개선
• 서버 홉 최소화로 인한 성능 향상 확인
• 정확한 원인은 개발자(하승우 튜터님)에게 질문을 통해 서버 홉의 문제 였던 것을 학습 및 확인 => 서울 대전 부산 경로보다 서울 부산 경로가 훨씬빠른 것과 nextjs 서버 퍼포먼스 영향,서버리스 스펙이 안 좋음

학습 포인트

1. 서버 홉 최소화의 중요성: 클라이언트 -> 서버 -> Supabase 대신 클라이언트 -> Supabase 직접 연결의 효율성
2. Next.js 서버리스 환경의 성능 영향 이해
3. 복잡한 데이터 요청 구조에서의 최적화 전략 수립
4. UX를 고려한 성능 최적화의 중요성 (수치상 개선 vs 체감 개선)
5. 다양한 최적화 기법의 실험 및 결과 분석 능력

최종 결과 차이