💫 과제 리뷰

• 요구사항 꼼꼼히 읽기 ⇒ 구현 ⇒ 제출 전 검토

• 파일 관리

  • 비슷한건 뭉치고, 나눌 수 있는 것은 나누기
  • ex) user, message를 나눴으면 좋았을 텐데 🤔

• 반응형

  • break point는 모든 페이지에서 똑같아야 한다 (컴포넌트 마다 다른 팀이 있었다)

  • 데스크탑, 테블릿, 모바일 ⇒ 보통 2개 (1024px, 768px)

  • 보통 우선순위는 768px 먼저 구현 (초기 스타트업)

    • 나중에 태블릿이 나올 것을 예상

  • 미디어쿼리를 정했으면 ⇒ 상수화 👀

    • $phone, $desktop

📎 들어가기 전에

프론트엔드 개발자의 주요 역량중 하나는
마케터와의 협업이자 SEO를 챙기는 것 입니다 👀

✨ CSR과 SSR 방식이 갖는 특성이 SEO에 어떤 영향을 미치는지 알기 ✨

🔍 검색과 SEO

:: 현재의 검색 알고리즘

• 검색 봇 ⇒ 자기만의 알고리즘으로 분석함 ⇒ 구글 페이지랭크

• 크롤러는 페이지의 신뢰성이 중요하다(실제로 클릭을 얼마나 하는지)

• 결론: 검색 결과로 초반에 나오는 사이트는 점수가 높은 사이트다 👀

  - SEO는 마케터와 프론트엔드의 합작품

  
  

:: SEO(Search Engine Optimization, 검색 최적화)

• 구글
  - 하루에도 몇만개의 사이트를 분석한다
  - 검색엔진의 최적화 효과를 보려면 시간이 4개월 ~1년 정도 소요됩니다
  
  

:: 우리가 해야할 일

1. 잘 노출되게 한다

2. 에 메타 정보를 잘 작성해야 한다
   1. OG: Open Graph ⇒ preview 뜨는 것 (공유기능에서 필수)

3. robots.txt 검색 봇 (크롤러) 약속 🚨

   1. 네이버 , 구글 클로러 다들 다르다

   2. User-agent: * 모든 페이지 다 들어와도 되

   3. Disallow: shop/admin 은 금지 ㅋㅋ

4. sitemap.xml ?? generator로 만들면된다
   
   

:: 사이트를 컴퓨터가 이해할 수 있도록 만든다.

• HTML을 semantic 하게 만들어야 한다

  • 웹 접근성 (img 태그 alt, figure)

• 페이지 이동하는 경우 ⇒ <a href=””> 무조건 사용!

• 페이지 에서 중요한 경우 => <h1>, <h2>

• header, main, footer, nav, section, aside 잘 사용하기
  
  

🗺  웹의 역사와 발전

1세대 : js조차 없는 정적 웹

2세대 : js가 추가되어 동적인 웹 (10년전)

• 클릭하면 팝업 뜨고, 등등 기능

• 백엔드랑 프론트랑 코드가 같이 있던 시절

3세대 : 요즘엔 프론트가 할일 많아짐

• SPA (Single Page Application)

• FE와 BE가 명확히 분리되었다
  
  

📎 SPA, CSR, SSR

📄 SPA

:: Static Website

• 정적 웹사이트 ⇒ gatsby 블로그, 포트폴리오, 회사 소개 페이지
  
  

:: Dynamic Website

• 디자인은 그대로인데 내용이 바뀐다
  
  

:: Multi Page Application (MPA)

• 페이지 마다 html이 여러개 있는경우
  
  

:: SPA (Single Page Application)

• 하나의 페이지로 여러 사이트를 구현
  
  

📄 CSR vs SSR

:: SPA

1. CRA 엄청 편하다 ⇒ 오 근데 검색이 안되네? ⇒ CSR 때문이구나 🤯

2. 결론: SSR로 만들어야 한다
   
   

:: SEO (Search Engine Optimization)

• 그나마 할 수 있는 것은 meta tag 넣기

• 네이버는 아직 SPA를 지원하지 않는다

  • CRA는 페이지마다 meta tag를 달 수 없다
    
    

:: SSR (Server Side Rendering)

• 사용하는 이유 ⇒ 검색 잘되게 하려고 😎

• 장점

  • 서버에서 미리 페이지를 구성하여 사용자에게 보여준다 ⇒ CSR의 단점인 ‘첫 페이지 깡통' 상태를 극복할 수 있음

  • CSR 보다 페이지 구성 속도는 늦지만, 전체적인 속도(페이지 로딩 완료)는 더 빠르다

  • 페이지 이동 간 서버 요청이 없어서 페이지 깜박임이 없다

  • 코드 스플리팅 : js 파일을 나눠서 처음 로딩을 빠르게 한다
    
    
    

:: 그럼에도 불구하고 CSR을 사용해야 하는 경우

• admin : 검색할 이유가 없다 ⇒ 관리자만 사용

• 한정된 사용자만 볼 수 있는 사이트
  
  

📄 SPA for SSR

:: SSR for MPA, SSR for SPA...?

• SPA
  • npm run build를 통해 만들어진 html 파일으로 모든 기능 작동
  • 서버로부터 html을 받아서 페이지를 바꾸는 것이 아니다 (페이지 이동시 깜빡임 X)
    
    

:: CSR + SSR? ⇒ Next.js (like CRA)

• 일부분만 CSR 사용 가능

  • 예시) 주식 사이트에서 차트빼고 나머지 SSR, 차트는 CSR
  • 처음 로딩만 SSR, 넘어갈때만 CSR 사용

:: SSR 장점 정리

• 페이지 기반 라우팅 시스템 (동적 라우팅 가능)

• pre-rendering, 페이지별 정적 파일 생성과 서버사이드 렌더링 지원
  코드 스플리팅

• CSS, Sass 기본 지원 및 다른 CSS-in-JS 라이블러리 지원
  
  

⚙️  실습

1. 설치 | Next.js 설치와 폴더구조

1. Next.js 는 정해진 폴더 구조가 있다

2. npm run dev로 시작한다

3. npm run build 하고 어떻게 구성되어있나 확인해보기

   a. 이번 과제때 시간 있으면 OG, 404 만들어보기
   

4. 라우팅 하는법

   a. pages 밑에서는 components 만들지 말기

   b. api 폴더는 서버인가요? ⇒ 프론트에서만 필요한 api를 만들 수 있다

   c. 동적 라우팅 하고 싶으면 [대괄호] 사용
   

5. 이미지 관리

   a. s3에 올리기 ⇒ 최초 로드는 느림, 관리는 편함

   b. import로 불러오기 ⇒ build 했을때 소스코드에 들어감 ⇒ 용량 커짐

   c. public폴더 /images/bg.png 루트 경로를 통해 서버 요청으로 가져오기

   1. css에서도 접근 가능

2. 초기세팅 | 공통로직을 위한 _app.js

• Next.js 초기세팅 코드에는 해당 파일이 없기 때문에, 개발자가 직접 추가해야 합니다! page폴더 밑에 _app.tsx 파일을 생성해 주세요 🙌🏻

• 예시) styled-components, 모든 페이지에 필요한 reset-css

• title 태그는 왠지 _document.tsx에서 추가해야할 것 같은데 _app.tsx에서 추가해야해서 언급했습니다.

  • 동적 title이 필요할 때는 pages 폴더 하위에 개별 컴포넌트마다 title 태그를 추가하면 overwrite 됩니다.

아래와 같은 경우에 _app.tsx을 사용합니다.

• 페이지 이동할 때마다 유지해야 하는 스타일이나 레이아웃 적용

• 페이지 이동할 때 유지해야할 state 관리

• componentDidCatch 라이프사이클로 공통 에러 처리

• 페이지에 공통 로직을 통해 데이터를 주입해야하는 경우

• 모든 페이지에 필요한 css를 적용하는 경우
  
  

3. 초기세팅 | html과 body 태그가 필요할 때는 _document.js

• font 파일을 가져오거나, script 태그로만 넣을 수 있는 라이브러리가 필요하거나, Google Analytics 같은 것을 설정할때 html의 head, body 태그가 필요합니다.

• 구글 폰트를 추가해보겠습니다. self closing 되어있는 Head 컴포넌트를 열고 구글 폰트 link를 추가합니다.

• 주의할 점은 _document.js는 서버에서만 실행되는 파일이므로 window같은 브라우저 전역객체를 사용할 수 없습니다. 또한 컴포넌트에 필요한 공통 로직의 경우 _document.js가 아닌 _app.js에서 추가해야 합니다.
  
  

6. 페이지 이동

< Link > 컴포넌트

• Next.js에서 페이지 이동은 "next/link"의'< Link > 컴포넌트로 합니다.

• < a > 태그를 대체하는 것인데 < Link >를 사용해야 CSR을 할 수 있습니다.
  
  

7. Next.js의 세 가지 렌더링

우리가 Next.js의 메서드를 어떻게 활용하느냐에 따라 빌드시점에 세가지 방식의 렌더링 중 하나로 결정됩니다

정적 생성 (Static Generation)

• 정적생성에 적합한 페이지는 회사 소개 페이지, 개인정보처리 방침 같은 설명 페이지, 정적 블로그 페이지 등이 있습니다.

• 정적 생성을 위해서는 getInitialProp 나 getServerSideProps 메서드를 사용해서 데이터를 가져오거나 가져오지 않게 컴포넌트를 만든다.

• Next.js에서 권장하는 렌더링 방식이며, 한 번 응답한 후에는 CDN(content delivery network)이 파일을 기억(캐쉬, cache)하여 응답하기 때문에 화면을 그리는 속도가 굉장히 빨라지고 불필요한 서버 요청이 줄어듭니다.
  
  

SSR(Server Side Rendering)

• SSR은 페이지 요청이 있으면 server side에서 api를 호출하고 데이터를 응답받아서 서버측에서 HTML을 완성시키고 클라이언트에 전달합니다.

• 페이지를 요청할 때마다 SSR을 하고 싶은 경우는 getInitialProps나 getServerSideProps메서드를 사용해야합니다.
  
  

CSR(Client Side Rendering)

• SEO가 필요없는 마이페이지, 관리자페이지 등은 클라이언트 측에서 데이터를 호출해도 됩니다. 이 때는 Next.js 메서드가 아닌 react에서 componentDidMount 라이프사이클이나 useEffect 훅에서 데이터를 요청합니다.

8. 렌더링 방식을 결정하는 데이터 호출 메서드

Next.js에서 CSR인지, SSR인지 판단하기?

• window ⇒ useEffect monunt 후 사용가능

Next.js에서 fetch는 사용할 수 없다.

• fetch ⇒ Axios 사용해야 함