NEXT.js 13 PlayGround 회고록

• Vercel: 배포 링크
• Figma: 와이어프레임
• 저장소와 리드미: GitHub
• 웹 성능 지표: Mobile(모바일), Desktop(데스크탑)
• 기술스택: TypeScript, NEXT.js(app Directory), Emotion, SampleAPIs, NotionAPI, Vercel

목차

모바일 대응

• 앱 & 웹 뷰
• 사이드바 너란 녀석

렌더링 방식

• 개요
• SSR과 SSG 이야기
• 구현

성능개선

• LCP
• TTI
• CLS

UX 향상 (준비중)

• 스켈레톤UI와 Suspense
• local에서의 hydration에러

정리 (준비중)

• 내가 느낀 NEXT.js 13의 app 디렉터리
• SSR SSG CSR
• next/font, next/image, loading컴포넌트
• 마무리

모바일 대응

앱 & 웹 뷰

"오 이게 너가 만든거임? 이거 인터넷이야? 근데 요즘 앱 많이 쓰지않음?"

이전에 진행했던 '다독다독' 프로젝트를 비개발자 ISTP 친구에게 보여주고 맨 처음으로 들었던 말.

정보: ISTP는 프로 팩폭러 이다.

점점 모바일 기기를 통해 서비스를 이용하는 사용자가 늘어나고 있다고 생각되는 만큼 항상 뭔가를 만들려고 할때 고민하는게 바로 모바일 앱뷰이다.

어떻게 하면 앱과 웹, 2마리의 토끼를 한꺼번에 잡을 수 있을까? 하다가 이전 '스윗미' 프로젝트를 진행할 때 팀원들과 고생하며 와이어프레임을 짰던 기억을 돌아보며 와이어 프레임을 직접 짜보았던게 이 프로젝트의 앱뷰를 만들 때 정말 큰 도움이 되었던것 같다. 와이어프레임 보러가기

와이어프레임을 토대로 CoffeeList, CoffeeItem과 같은 컴포넌트들이 화면의 크기에따라 변화시킬 크기를 미리 생각해 볼 수 있었고 추후 미디어쿼리를 적용할때 수월하게 진행되었다.

사이드바 너란 녀석…

처음에는 간단하게 금방 뚝딱뚝딱 만들 수 있을줄 알았다. 스타일링을 끝마치고 기능을 집어 넣기 전까진…

근데 왠걸? 테스트를 해보는데 UX적으로 고려해야할 부분이 엄청 많았다.

• 닫기 버튼 눌렀을 때 clickEvent
• esc를 눌렀을 때 닫히게 하는 keyPressEvent
• 사이드바 바깥요소(background)를 눌렀을 때 닫히게 하는 clickEvent
• 사이드바 바깥요소들의(예: HeaderLogo) 클릭이벤트가 동작하지 않게 투명한 div요소로 가리기
• 다른 페이지로 라우팅 되었을 때 toggleState false로 초기화

그리고 이때 사용되는 sideBarToggleState를 적용하는 데 이전에 구현해 놓았던 컴포넌트들을 평소 습관대로 과도하게 분리해놓은 탓에 엄청난 propsDrilling이 발생했다.

사실 프로젝트 초기에 한번도 안써본 Recoil을 써볼까 하다가 이거 하나 관리하자고 Recoil쓰는건 좀 아니다 싶기도하고 처음 쓰려고하는 다른 기술스택들도 있었기 때문에 과감하게 포기하고 진행하던 중 상태관리 라이브러리를 왜 사용하는지 깨달았다. 그만큼 이후에 다른 토이 프로젝트를 해본다면 recoil을 꼭 학습해서 야무지게 활용해 보려한다!

렌더링 방식

개요

사실 렌더링에 대한 부분은 크게 신경을 안쓰고 있었는데 Data-Fetching과 관련된 docs를 찾아보다가 우연히 SSR, SSG에 대한 내용과 마주하게 되었다. 사실 이부분에 대한 생각이 너무너무너무나도 많고 궁금한부분도 정말 많지만 전부 적지는 못할것같다. (SSR 적용과 해당 프로젝트 규모가 커졌을때 서버 및 인프라구축에 대한 부담, 이러한 프로젝트 빌드시에 devOps 분야에서 기여되는 부분은?, SSR 프레임워크가 없다면 SSR은 어떻게 구현되는가? ISR은 또 뭐지? 등등)

아무튼… 이전에 진행했던 ‘다독다독’ 프로젝트에서도 NEXT.js를 썼지만 SSR에 대한 부분은 구현하지 못하여 팀원들과 이야기를 나누다가 ‘이럴거면 우리는 왜 NEXT.js를 썼는가?’ 에 대한 이야기도 잠깐 나왔었고, 상당히 헤비한 3D책 컴포넌트까지 CSR로 하다보니 로딩시간이 다소 느린편이다. 그때의 아쉬움이 남기도하고 토이 규모의 프로젝트에서 SSR구현을 연습 해본다면 분명 다른 프로젝트에 적용하는데 허들이 낮아질 수 있을것이라 생각하여 이를 구현하기로 마음먹었다. 이러한 고민과 이후 시행착오 끝에 SSR과 SSG를 구현하게 되었다.

SSR과 SSG 이야기

SSR에 관한 내용을 찾아보다가 SSG에 대한 개념도 알게 되었는데 상당히 흥미로웠다. 이 둘을 비교해서 설명하면 뭔가 더 기억에도 오래남고 읽는이로 하여금 쉽게 접근할 수 있을것 같다.

SSR(Server Side Rendering)

• 뜻: SSR을 직역하면 말 그대로 서버에서 렌더링을 한다는 뜻이다.
• 웹 페이지 생성: 요청이 들어올때 마다 실시간으로 웹페이지를 생성한다.
• SSG와는 다르게 동적이다.
• 페이지 이동시마다 서버에서 웹페이지를 생성하므로 경우에따라 로딩 속도가 빠르거나 느리다.
  • 로드되는 페이지의 크기를 고려하여, 경우에 따라 CSR과 SSR을 적절하게 구현하는게 좋을것이다.
  • 이를 고려하지 않고 무지성 구현을 한다면 사용자는…
• 서버측에서 웹페이지를 생성하므로 SEO와 친화적이다

SSG(Static Site Generator)

• 뜻: 정적 사이트 생성기 라는 뜻이다.
• 웹 페이지 생성: 웹 페이지를 빌드할 때(배포 시에)만 웹페이지를 생성(업데이트)한다.
• 완전 정적이다. 따라서 데이터가 자주 바뀌는 곳에는 적합하지않다.
• 빌드 이후(배포 이후)에 로딩속도가 아주 빠르다.
• 서버측에서 웹페이지를 생성하므로 SEO와 친화적이다

구현

사실 SSR, SSG 둘 다 구현하던 중 굉장히 많은 (긍정적인?)스트레스를 받았다. 어떻게 하면 두가지 모두 의미있게 구현해 낼 수 있을까 고민의 연속이였다.

적절하게 SSR과 SSG를 구현해야 참 된 의미가 있고 구현이후에도 보람을 느끼며 ‘나 한 단계 더 성장했다!’ 라는 느낌을 받을것 같았기에 어떻게 적절하게 두가지 모두 구현할 수 있을까 고민했던것같다.

일단 커피 메뉴 리스트를 보여주는 페이지에서는 SSR로 구현하였다. 서버측의 데이터가 변경되거나 클라이언트측에서 요청이 들어오면 pre-rendering이 진행된다. 왜 이 페이지를 SSR로 구현했어? 라고 하신다면…

SSR 구현 페이지 (카페 메뉴 리스트 페이지)

• 로드되는 데이터의 크기가 크지않다
  • 초기 렌더링의 속도에 대한 고민이 없었고 데이터가 업데이트 될때마다 혹은 클라이언트측에서 요청이 들어올 때 마다 적절하게 로딩될 수 있다고 생각했다.
• 로드되는 데이터의 크기가 커진다면 어떻게 할껀데?
  • 현 프로젝트 처럼 리스트 형태의 컨탠츠에는 무한 스크롤 기능을 넣을 수 있다.
  • 이미지 컨탠츠 크기를 사전에 정의, LazyLoading 기능을 추가, 이미지 최적화 작업을 할 수 있다.
• SEO측에서 좋다
  • 검색엔진 노출에서 이점을 갖으므로 이게 실제 서비스이고 초기 HTML생성시에 관련 컨탠츠들이 완성이 된다면 검색시에 자주 노출 될 수 있다.

SSG 구현 페이지 (기술 스택, 만든 계기 페이지)

• 페이지 대부분의 데이터가 업데이트 되지 않는다. 말 그대로 정적이다.
  • 사용했던 기술스택이 바뀌거나, 이 토이 프로젝트가 만든 계기가 바뀌진 않으므로 보여줄 데이터는 정적이라고 말할 수 있을 것 같다.
  • 그래서 SSG 구현 방식이 아주 잘 맞다고 생각했다.
• 배포 이후 로딩속도가 빠르다.
  • CSR과는 다르게 빌드시에 웹페이지를 만들어 놓은 상태이므로 페이지 로딩속도가 빠르다.
• SEO와 친화적이다.
  • CSR과 또다른 차이점이라고 말할 수 있는게 서버측에서 미리 HTML을 생성해 놓으므로 검색엔진 노출에 이점을 갖는다.

성능개선

사실 해당 프로젝트에서 데이터 혹은 컴포넌트가 많거나 로직이 복잡한것은 절대로 아니였지만 한번 쯤 시도해 보고싶었던 성능개선이였다. 그래서 Web Core Vital에 대해 찾아보고 LCP, TTI, CLS에 대한것을 알게되었고 이 3가지를 중점적으로 성능개선을 해보았다.

LCP (Largest Contentful Paint)

아무래도 LCP성능이 잘 나와줘야 TTI성능 또한 잘나오는것같다고 생각했다. 그래서 LCP를 개선하기 위해 NEXT에서 제공하는 next/image를 활용하여 이를 개선해보았다. 그럼 next/image로 나는 어떠한 이점을 얻었을까?

• 이미지 최적화, 이미지 확장자를 .webp로 바꾸어 준다
  • 현재 api측에서 보내주는 이미지 확장자는 .jpg인데 .webp로 변환함으로써 25%~34%의 용량차이를 보여준다.
• LazyLoading을 지원한다.
  • 사용자 화면에 보여지지 않는 부분의 컨탠츠는 로딩시키지 않고 있다가 화면 스크롤을 통해 컨탠츠를 보게 될때 로딩시킨다.
• 사전에 컨탠츠 사이즈 값을 optional하게 받아 서버측에서 로딩시에 부담을 줄여줄 수 있다.

위와같은 next/image가 지원하는 기술들을 이해하고 이를 적용하니 LCP성능 점수에는 초록불이 들어왔다.

TTI (Time to Interactive)

위에서 언급 했듯이 이미지 부분에서는 next/image 하나만으로 쉽게 최적화작업이 가능했다. 그 외의 부분들은 어떻게 하면 TTI성능을 높힐 수 있을까 고민해보았고 지금 프로젝트 안에서 할 수 있는걸 찾아보았다.

• 불필요한 컴포넌트 삭제 및 병합
  • 이상하게 컴포넌트를 너무 atomic하게 나누는 평소 습관이 있다. 그리고 내 코드에서 너무 세부적으로 나누면서 불필요하게 만들어진 스타일 컴포넌트들을 발견했다.
  • PullRequest 01
  • PullRequest 02

CLS (Cumulative Layout Shift)

사실 이 프로젝트에서 CLS의 성능은 컨탠츠가 많이 없기도 하고 위에서 말했던 next/image에서는 placeholder 기능도 제공하기때문에 Layout Shift 현상은 완전 회피할 수 있었다.

또한 프로젝트 시작전에 와이어프레임을 작성하고 마크업 작업을 하면서 컨탠츠가 들어갈 부분과 컨탠츠를 감싸는 컨테이너 관련 컴포넌트들의 사이즈를 미리 정의해 놓아서 Layout Shift 현상을 피하는데 도움이 되었을지도 모르겠다.

---

UX 향상

준비중입니다.

---

정리

준비중입니다.