이제 진짜 끝을 향해 달려간다.
약 한달 반 동안 진행했던 최종프로젝트를 드디어 선보인다니 감회가 새롭다.
넉넉한 시간인 줄 알았지만, 예상치 못한 일들도 있었고 성능보다 기능 구현에 먼저 초점을 잡다보니 리팩토링할 시간도 모자랐었다. 이것저것 건드는 것도 좋지만 하나를 깊게 탐구하라는 조언이 뼈저리다.
예상 질문이 차후 면접 질문과도 많이 연관되어 있어 답변을 미리 정리해보고 그 개념에 대해서도 확실히 알아두어야겠다는 생각이 들었다.
- 작성기능에 react-quill과 hook-form 을 사용하셨는데
각각의 라이브러리를 사용하실때에 어떤 장점과 단점이 있었나요?- Next.js를 통해서 어떤 최적화를 시도해보셨나요?
- 커스텀 훅을 적극 활용하셨나요?
- 리액트 퀼:
➕ 레시피 작성에 필요한 이미지와 글을 함께 업로드하고 사용자에게 자유로운 커스텀을 제공할 수 있었다.
➖ next.js가 SSR 방식의 렌더링이기 때문에 해당 라이브러리 사용에 애를 먹었다. 리액트 퀼이 document 객체를 찾는 시점에 생성조차 되지 않아 에러를 내뿜었는데 dynamic import로 에러를 잡았다.
모든 웹 페이지의 속도를 결정 짓는 첫번째 요소는 첫 페이지를 그릴때 필요한 자원양이다.
즉, 자원이 많으면 많을 수록 초반 렌더링 속도에 영향을 준다.
웹사이트의 속도를 올리기 위해서는 큰 덩어리의 js파일 용량을 줄일 필요가 있다.
1. 코드의 크기를 줄인다.
2. 코드를 분할한다.
1의 방법: 렌더링의 불필요한 코드를 줄이기
- 불필요 공백, 주석 등 렌더링 시 필요없는 코드 제거 -> Minify
웹팩 Optimization - minimizer 추가
2의 방법: Code Splitting
- Webpack으로 빌드한 파일은 하나의 파일에 전체 페이지 내용을 담고 있다.
- 필요한 시점마다 파일을 불러온다면 렌더링 속도가 빨라질 것
웹팩 Entry와 splitChunks// webpack.config.js module.exports = { entry: { home: 'home.js', about: 'about.js', } };
📌 dynamic import: 동적 코드 분할
첫 페이지 진입에 필요한 코드만 다운.
특정한 페이지에 진입할 때마다 해당 코드를 가져오면 초기 성능을 올릴 수 있다.
➡️ lazy-load
런타임에 필요한 module을 import할 수 있다.
정적인 module import 를 필요한 시점에 로드할 수 있게 한다.
- 리액트 훅 폼:
➕ 폼 제출에 필요했던 많은 useState를 줄일 수 있었다. 유효성 검사 및 에러 체킹을 하는게 간단해졌다.
- next.js의 최적화 사례:
➕ Image태그 사용한 lazy-loading
lazy-loading: 필요한 시점까지 로드를 지연.
불필요한 대역폭 사용을 줄일 수 있다.
일반 img태그: Interection Observer 나 scroll 이벤트를 통해 로드할 Element 시점을 캐치해야 한다. -> 번거로움
Next/Image 사용으로 자동으로 lazy-loading 을 적용할 수 있다.
적용하고 싶지 않은 곳은 priority 속성을 true로.
- 커스텀 훅 활용 사례:
커뮤니티 글 조회 및 실시간 유저 컬렉션 조회
- 로그인 유지를 위해 Session Storage를 쓰셨던데 선택하신 이유가 있으실까요?
- Fuse.js라는 검색 라이브러리를 사용하셨던데 직접 구현하지 않고 사용하신 이유가 있으실까요?
- tailwind와 style component를 같이 사용하셨던데 같이 사용한 이유가 무엇인가요? css 작업 시 어떤식으로 분배를 하셨나요?
- 세션 스토리지 선택 이유
(로컬스토리지와 비교하여)
브라우저 창이 닫혔을 때 저장한 정보가 휘발되길 원했다.
- 검색 라이브러리 선택 이유
- tailwind와 styled-component 병용
자주 쓰이는 css는 tailwind의 인라인 코드로 작성하면 추후 수정이 어려워지는 단점이 있다. 프로젝트가 진행되며 스타일드 컴포넌트로 작성된 부분은 global.css에 tailwind의 @apply 속성을 이용해 작성하는 것으로 변경하였다.
- 해당 프로젝트를 구현하면서 가장 자랑하고 싶은 기술적 포인트는 뭔가요?
- next.js를 사용했는데 직접 느낀 SSR의 장점 혹은 next.js를 사용했을 때 장점이 무엇이라고 생각하나요?
- 프로젝트가 타입스크립트로 되어있던데 자바스크립트를 썼을때와 차이점이 있나요? 장단점이 뭐라고 생각하나요?
- 기술적 포인트:
- SSR의 장점 (next.js의 장점)
- SSR: Server Side Rendering
(자바스크립트를 다운받는 동안 사용자에게 화면을 보여준다.
이때 조작을 할 수는 없지만 기록되어 JS가 성공적으로 컴파일되면 기록된 사용자 조작을 실행한다.)
서버에서 렌더링 준비가 끝난 상태로 클라이언트에 전달하는 방식
➕ 초기 로딩 속도가 빠름
➖ 요청할 때마다 새로고침되어 화면 깜빡임.
💡 SSR을 쓸 때는
SEO(검색 엔진 최적화)가 필요할 때
페이지마다 데이터가 많이 바뀔 때
초기 로딩이 빨라야 할 때
상호작용이 별로 없을 때
- CSR: Client Side Rendering
서버는 요청이 들어오면 클라이언트에 보내주고 클라이언트에서 렌더링을 시작한다.
➕ 변경된 부분의 데이터만 가져와 화면 깜빡임이 없음
➖ 모든 파일이 다운되고 렌더링이 끝날 때까지 빈화면 노출
💡 CSR을 쓸 때는
네트워크가 빠를 때
사용자에게 보여줘야하는 데이터 양이 많을 때
웹 어플리케이션에 사용자와 상호작용할 것들이 많을 때 (아예 렌더링 되지 않아서 사용자의 행동을 막는 것이 경험에 오히려 유리함.)
궁극적인 차이
1. 웹페이지 로딩 시간
2. SEO 대응
3. 서버 자원 사용
- SSG: Static Site Generation
➕ 업데이트가 적거나 고정된 데이터를 사용하는 페이지에 적합
빌드 시 고정된 데이터를 모두 담은 정적 html 파일을 생성
Next.js 공식문서에서 권장하고 있다.
➕ CSR, SSR과 비교하여 렌딩 속도 빠름.
➕ 업데이트가 잦지 않다면 불필요한 통신, 리렌더링이 줄어들기 때문.
💡 SSG를 쓸 때는
- 업데이트가 없거나 다른 페이지와 비교했을 때 현저히 적을 때
- ISR: Incremental Static Regeneration
- SSG의 단점 보완, 설정한 시간 이후 자동 re-build
- getServerSideProps가 있다면 revalidate 옵션 설정 -> 서버 사이드 데이터 업데이트 가능
💡 ISR를 쓸 때는
- 페이지에 사용자 접근에 맞추어 업데이트가 필요할 때
- 타입스크립트의 장단점
- 사전에 에러를 잡을 수 있다.
- 코드 가이드와 자동 완성 - 개발 생산성이 향상된다.
- 명확한 에러 메세지를 받아볼 수 있다.
- 협업 시 유용하다.
