Feat/#120: 콘텐츠 등록 화면 성능 최적화

[minjeongss]

#️⃣ 연관된 이슈

#120

📝 작업 내용

1. 접근성 향상

(1) viewport의 maximum-sacle 증가

• 기존: maximum-scale:1 (초기 scale이 1이니 zoom을 금지함과 동일한 의미)
• 변경 후: maximum-scale:10
  viewport는 모바일 장치에 최적화되지 않은 사이트를 좁은 스크린 장치에서 더 잘 보이도록 하는 방법입니다. user-calable=no를 사용하면 저시력 시각 장애인 사용자 접근성 문제 발생 가능하여, WCAG에선 2배 이상을 요구하지만, 5배 줌 가능하도록 하는 편이 좋습니다.
  현재 우리 코드에서 maximum-scale:1로 설정되어, 사용자 접근성 문제 발생하고 있는 상황이었습니다. 기본적으로 제공하는 maximum-scale:10로 scale을 증가시켜 문제를 해결했습니다.

(2) 양식 라벨 포함

양식 라벨이 포함되지 않은 요소에 aria-label를 등록하여 스크린 리더와 같은 보조 기술에서 양식을 올바르게 읽을 수 있게 향상했습니다.

2. 성능 향상

@next/bundle-analyzer로 번들 사이즈를 분석했고, app/(nav)/content/register/*가 타 번들에 비해 큰 사이즈를 가지고 있음을 확인했습니다. 추정되는 원인으로는 lottie 사용과 Google Map API 사용이 있었고, 이를 기반으로 성능 향상을 도입했습니다.

• node.js
  
• client.js
  
• 터미널(cli) 분석
  

성능에서 향상해야 하는 부분은 크게 다음과 같았습니다.

• LCP: 보여지는 화면에서 가장 큰 컨텐츠 그려지는 시점
• TBT(Total Blocking Time): FCP와 TTI(사용자 상호작용이 안정적으로 응답할 수 있는 시점까지의 시간) 사이 시간에 longtask(50ms가 초과되는 작업으로 메인 스레드 독점하는 JS 작업)를 뺀 값
• SI: 페이지가 그려지는 중 시각적으로 속도를 나타내는 지표

(1) SI 개선: lottie를 memo로 감싸서 메모이제이션

사용하는 lottie 컴포넌트를 export하는 부분을 memo로 감싸 반복된 호출을 제한했습니다.

export default memo(LottieComponent);

• page.js 호출 속도
  • 사용 전: 1.12초~803ms
  • 사용 후: 1.00초~880ms
• loading.js 호출 속도
  • 사용 전:300ms~866ms
  • 사용 후:360ms

(2) LCP 개선: lottie 관련 리소스 사이즈 절감으로 번들 사이즈 최적화

기존에 디자이너분이 전달해주신 사용자 TIP lottie의 경우, 4,700mb로 큰 크기를 가지고 있는 json이었습니다. 캐릭터를 제외한 TIP만 움직이는 경량화된 lottie로 교체해 100mb 미만의 json을 사용했습니다.
캐릭터의 경우, static한 자원이기에 lottie 제공 전 제시됩니다.

(3) TBT 개선: code splitting으로 번들 사이즈 최적화

lottie 호출을 일반 import에서 lazy load로 변경해, TBT 후에 컴포넌트를 불러오게 하여 번들 사이즈를 줄였습니다.

const PlayerTip = lazy(() => import('@/components/Common/Lottie/PlayerTip'));

🚨 TBT 측정되는 정확한 수치

• FCP~TTI(Time to Interactive) 사이 시간
• Long Task(50ms 넘는 작업)까지 시간의 합
• 즉, 사용자에게 첫 화면이 보인 시점부터 사용자가 UI를 인터랙션할 수 있는 시점 사이에 JS 때문에 메인 스레드가 막힌 시간을 계산한 것

📸 스크린샷

기존 성능 및 접근성

향상된 성능 및 접근성

💬 리뷰 요구사항

[github-actions]

🎉 Vercel Preview: https://urdego-frontend-deploy-37lwscezm-minjeongss-projects.vercel.app