HOOKING팀이 최고입니다.
- Next.js 사용법을 공부해봅니다.
- Figma로 주어지는 디자인으로 스타일링 하는 방식에 익숙해집니다.
- Git을 이용한 협업 방식에 익숙해집니다.
- 2023년 5월 12일 (기한 엄수)
- 결과화면의 랜딩 페이지와 메인 페이지를 구현합니다.
- Figma의 디자인을 그대로 구현합니다.
- Open api를 사용해서 데이터 패칭을 진행합니다. (ex. themoviedb API)
yarn
,yarn berry
,npm
,pnpm
등 패키지 매니저를 직접 선택해 Next.js를 세팅해 봅니다.
- SSR(Server Side Rendering)을 적용해서 구현합니다.
- 웹 폰트를 사용합니다.
- 반응형을 고려합니다.
- 둘의 차이는 렌더링(웹페이지를 그리는 일)을 어디에서 하느냐인데요, SSR은 서버측, CSR은 클라이언트측에서 담당합니다.
CSR
SSR
초기 로딩 속도
- CSR의 경우 서버에서 빈 body 태그를 보내고, 어플리케이션 로직은 스크립트 파일 안에 담겨 있습니다. 그래서 브라우저에서는 스크립트 파일을 다운로드 받아야하므로 초기 로딩 속도가 비교적 느립니다.
- SSR의 경우 서버에서 완성된 html 파일과 이를 조작할 수 있는 약간의 스크립트를 클라이언트한테 보내기 때문에 CSR에 비해 초기 로딩 속도가 빠릅니다.
TTV와 TVI의 공백시간
- SSR의 경우 html을 먼저 가져오기 때문에 볼 수 있지만 스크립트를 받아 오기 전에는 사용자가 클릭해도 동작하지 않습니다. 그래서 사용자가 볼 수 있는 시간과 (
TTV: time to view
) 실제로 인터렉션 가능한 시간(TVI: time to interaction
) 사이에 공백이 길다는 단점이 있습니다.
- SEO는 Search Engine Optimization의 약자로 검색 엔진 사이트의 검색 결과에서 웹 페이지를 상위 노출시키는 개념을 의미함.
- 검색엔진은 크게 크롤링 → 인덱싱 → 랭킹 3단계의 프로세스를 통해 검색 결과 내 가장 랭킹이 높은 페이지를 상위노출시킴.
- 크롤링: 구글봇(웹 크롤러)가 웹 페이지 내 콘텐츠를 복사해서 모든 정보를 수집하고 수집한 정보는 검색 엔진의 DB에 저장함.
- 인덱싱: DB에 저장된 콘텐츠를 주제별로 색인해서 데이터를 보관함. 이때 어떤 컨텐츠가 중요한지를 판별할 때 시멘틱 태그가 사용됨.
- 랭킹: 검색어에 맞춰서 인덱싱된 콘텐츠에 순위를 부여한 다음, 랭킹 순서대로 결과 반환.
- SEO하는 8가지 방법
- http가 아닌 https 사용: 구글은 보안 프로토콜을 더 선호함.
- url 최적화: 서브 도메인보다 서브폴더 형식을 사용해야 함. 서브도메인 형식을 사용하면 검색엔진은 사이트가 여러 개 있다고 인식해서 도메인 점수가 분산됨. - 서브도메인 예)image.blog.com - 서브폴더 예)blog.com/image
- robots.txt 정리하고 사이트 루트에 위치해둠
- robots.txt는 사이트맵 위치, 접근 가능한 파일과 그렇지 않은 파일 등의 정보를 알려주는 중요한 역할을 하는 파일임. 그래서 robots.txt를 잘 정리해두고,
www.example.com/robots.txt
처럼 사이트 루트에 위치시켜둠. - title 태그와 meta description 태그: 기본적으로 웹사이트를 HTML 문법에 맞게 작성해야 함. 타이틀 태그는 페이지 제목을 의미하는데 이는 검색 결과에 표시되는 내용임
- canonical 태그 사용: 캐노니컬 태그는 head 안에 삽입하는 코드로 페이지 대표 url을 검색엔진한테 알려주는 역할로, 상위노출시키는데 중요한 역할을 함. - ex. 애플 공식 사이트의 캐노니컬 태그
<link rel="canonical" href="https://www.apple.com/au/">
-
이미지 alt 속성: 구글봇은 이미지를 alt에 기재된 텍스트를 통해 이해하기 때문에 어떤 이미지인지 alt에 기재해서 구글봇한테 알려줘야 함.
-
페이지 로딩 속도: SEO를 결정하는 여러 요소 중 매우 중요한 부분 차지함. 구글은 로딩 속도가 짧은 웹사이트에 더 높은 SEO 점수를 줌. - 로딩속도: 서버 속도와 데이터가 영향을 줌. 트래픽이 많아질수록 더 많은 메모리와 CPU 자원이 필요함. 따라서 호스팅 서버 자원이 충분한지 주기적으로 확인해야하며 자원이 부족한 경우 자원 추가해야 함. (AWS를 통해 배포를 한 경우 인스턴스를 더 구입하거나, 더 높은 용량의 서버를 구입해야함)
-
모바일 친화성 갖추기: 구글 SEO는 모바일 중심으로 인덱스 생성함. 따라서 콘텐츠 만들 때 모바일 중점으로 만들어야 함. 모바일 친화성 여부 확인하려면 구글의 모바일 친화성 도구를 통해서 확인할 수 있음.
- 협업 프로세스
- 주어진 피그마를 보고 컴포넌트화 합니다. 이때 중복 사용가능한 컴포넌트의 여부를 중점으로 두고 컴포넌트화 하였습니다.
- api연동을 제외한 정적인 데이터들로 컴포넌트별 프로세싱을 먼저 진행하였습니다.
- 컴포넌트들을 하나의 페이지에 모아서 렌더링하며 z-index나 position과 같은 요소들을 조정합니다.
- api를 통해 데이터를 서버에서 받아오고, 받아온 데이터를 렌더링합니다.
- 반복되는 코드가 있는지 확인하고, 리펙토링을 통해 코드를 정리합니다.
- 진행하는 과정에서 발생한 에러나, 공유해야할 내용은 notion페이지를 통해 공유합니다.
- 컨벤션
- 코드 컨벤션 : 동일한 코드 컨벤션을 적용하여 IDE의 불필요한 formatter동작을 방지하였습니다.
- 커밋 컨벤션 : [커밋타입] : [커밋 내용]의 포맷을 사용하였습니다.
- 브랜치 컨벤션 : [브랜치타입] / [작업내용]의 포맷의 브랜치를 사용하였습니다. 전체적인 브랜치는 아래의 구조로 작업하였습니다.
먼저, 주어진 피그마에서 구현 범위에서의 컴포넌트를 다음과 같이 나누었습니다. (랜딩 페이지의 splash page제외)
웹사이트에 처음 접속했을 때 나올 splash page의 기능을 하는 페이지인 만큼, 페이지의 애니메이션이 렌더링되는 동안 서버에서 데이터가 받아오고 있도록 설계했습니다. 이를 위해 Recoil
과 CSR
을 선택하였고, 고려한 사항은 아래와 같습니다.
- 따로 라우팅을 진행하지 않고 메인 페이지에 같이 렌더링합니다.
- 메인페이지에 접속할 때 마다 나오면 안되고, 웹사이트에 처음 접속한 경우(페이지를 닫았다 열거나, 새로고침하는경우)에만 렌더링합니다.
- 렌더링을 하는 동안 영화 데이터를 받아오고, 이미지 데이터 파일도 받아옵니다.
- 메인 페이지의 최상단에 렌더링되는 컴포넌트, 로고와 탭의 버튼들은 마우스와 상호작용하도록 구현하였습니다.
- Header위에 렌더링이 감지되는 기능을 가진
<div>
태그를 통해 페이지의 가장 위에서만 Header가 보이고, 스크롤을 내리면 Header가 보이지 않도록 구현하였습니다. (Next에서는 scrollHeight을 가지기 어렵더라고요 ㅠ)
- 접속시 랜덤한 이미지가 렌더링 되도록 하였습니다. (서버와 클라이언트측에서 생성한 random값이 같도록 설정)
- 10초에 한번씩 이미지가 바뀌도록 구현했습니다.
- 하단의 Control Panel과 자연스럽게 이어지도록
Overlay
를 구현했습니다.
- 동그란 이미지를 보여주는 Previews 영역와 네모난 이미지를 보여주는 나머지 영역을 type값을 props로 받아 처리할 수 있도록 하나의 컴포넌트로 제작하였습니다.
- 가로로 스크롤이 가능하도록 하였고, 미관상의 이유로 스크롤바는 보이지 않게 하였습니다.
- 다섯개의 버튼이 자식 컴포넌트의 길이에 상관없이 각각 같은 영역을 가지도록 구현하였습니다.
- 마우스를 hover하는 경우 아이콘이 확대되고 글씨가 사라지게 구현하여 사용자 UX를 고려했습니다.
- 현재 페이지에 해당하는 Navbar의 아이콘과 글씨는 흰색으로, 나머지는 회색으로 구현하였습니다.