Pre-rendering

📖 사전 지식

💬 Pre-rendering

• 말그대로 페이지를 미리 렌더링하는 것
• 리액트를 예시로 들어보면 사용자가 처음 페이지에 접속하면 화면을 그릴때까지
  로딩 시간이 조금 김
• 로딩 속도 개선과 그로 인한 UX 개선을 위해 미리 렌더링하는 것

💬 TTV & TTI

• TTV(Time To View) : 화면이 그려지고 유저가 사이트를 확인할 수 있는 상태가 되는 시간
• TTI(Time To Interact) : 클릭을 비롯한 각종 인터렉션이 가능해지는 시간
• TTV보다 TTI가 늦다면 화면이 그려졌어도 유저는 페이지 내에서 아무런 활동을 할 수가 없음

💬 SEO

1. 검색 엔진은 크롤러라는 자동화된 로봇으로 웹사이트를 읽으면서 돌아다님
2. 크롤러에는 JS를 해석할 수 있는 엔진이 없어서 웹사이트 읽을 때
   JS를 해석 및 실행을 할 수 없음 (예외적으로 구글은 크롤러에 JS엔진 있음)

• Search Engine Optimization : 검색 엔진 최적화
• 홈페이지 제작 시 검색 엔진에 더 잘 노출되어 더 많은 유저들이 유입이
  될 수 있도록 하는 것이 서비스 성장에 좋은 영향을 미치기에 SEO 대응이 중요함

📖 렌더링 방식의 종류

💬 CSR (Client Side Rendering)

유저와 티키타카가 잦은 경우 적합

📌 작동 방식

• 사용자가 웹사이트에 요청(접속, 주소창 입력)하면 HTML파일과 JS파일로 접근할 수 있는
  링크를 클라이언트에게 보냄
• 클라이언트는 HTML / CSS과 JS파일을 다운로드 받음 (화면에 아무것도 없음)
• 다운로드가 완료되면 JS 실행되어 데이터들을 호출
  (이때는 아직 데이터가 없어 placeholder를 보고 있음)
• 데이터가 호출이 완료되면 placeholder 자리에 바꿔치기

📌 장단점

• 초기 로딩 속도는 느리지만 렌더링이 완료된 후에는 부드러운 UX를 제공함 (TTV 느림)
  1. URL이 바뀌더라도 기존에 받아온 파일에서 클라이언트가 처리해 보여주기 때문
• 또한 렌더링이 완료가 되었다면 바로 사용자가 인터렉션이 가능함 (TTI 빠름)
• 하지만 번들 사이즈가 커지면 커질수록 로딩 속도가 그만큼 더 느려짐
• 또한 사용자의 요청이 들어온 다음 클라이언트에서 HTML 컨텐츠을 생성하기 때문에 SEO 대응이 어려움

📜 체크리스트

1. 검색 엔진에 노출되지 않아도되는(않아야하는) 페이지인가?
2. 유저와의 인터렉션이 잦은가?
3. 화면의 업데이트 및 렌더링이 잦은가?
4. 초기 로딩 속도가 조금 느리더라도 부드러운 UX가 중요한가?
5. 네트워크가 빠른가? (느리다면 로딩속도가 더욱 느려짐)
6. 메인 스크립트가 작은 편인가?

---

💬 SSR (Server Side Rendering)

비교적 인터렉션이 적고 데이터가 요청마다 한 번만 처리되어도 충분한 경우에 적합

📌 작동 방식

• 사용자가 웹사이트에 요청(접속, 주소창 입력)하면 즉시 렌더링이 가능한 HTML 컨텐츠를
  만들어 사용자에게 전달
• HTML 컨텐츠는 이미 렌더링 준비가 되어있기 때문에 화면은 볼 수 있음(이벤트 등의 조작은 불가능)
  그동안 클라이언트에서 JS파일 다운로드
• JS가 다운로드 되는 동안 진행된 사용자의 조작(실행되지 않은 조작)은 JS가 컴파일이 되었을 때 실행

📌 장단점

• 서버측에서 HTML 컨텐츠을 만들어서 제공하기 때문 TTV가 빠름
• JS파일을 화면을 보여준 후에 받기때문에 인터렉션을 불가하여 TTI는 느림
• 또한 URL이 바뀌면 서버로부터 문서를 다시 받아오기 때문에 서버 과부하가 걸리기 쉬움
• 하지만 HTML 컨텐츠가 존재하기 때문에 SEO 대응이 가능함

📜 체크리스트

1. 검색 엔진에 노출이 필요한 페이지인가?
2. 유저와의 인터렉션이 적은가?
3. 초기 로딩 속도가 중요한가?
4. 렌더링 후 사용자와의 즉각적인 인터렉션이 중요한가?
5. 네트워크가 느린가?
6. 메인 스크립트가 큰 편인가?

---

💬 SSG (Static Site Generation)

업데이트가 적거나 고정된 데이터를 사용하는 페이지에 적합

📌 작동 방식

• build 시 고정된 데이터들을 모두 담은 정적 html 파일을 생성하여 재활용
• pre-render에 필요한 페이지의 개수만큼 정적파일이 생성
  1. 예시로 게시글이 10개 있고 각각의 상세페이지가 있음
  2. 그렇다면 build 시 10개의 HTML 파일이 생성됨
  3. 때문에 너무 많은 수의 페이지가 생성되어야하면 적합하지 않음

📌 장단점

• React framework인 Next.js의 공식문서에서는 SSG 방식을 권장
• CSR & SSR과 비교했을 때 렌딩 속도도 빠름
• 업데이트가 잦지 않은 페이지에 대해서 불필요한 통신과 리렌더링을 줄여줌

📜 체크리스트

1. 업데이트가 없거나 현저히 적은가?
2. 생성되는 정적파일의 개수가 너무 많지는 않은가?

---

💬 ISR (Incremental Static Regeneration)

SSG의 단점을 보완한 방식으로, revalidate가 필요한 SSG 페이지에 적합

📌 작동 방식

• ISR도 SSG처럼 build 시 구성된 데이터를 기반으로 페이지를 작성하고 보여줌
• 하지만 직접 build를 하지 않으면 변함이 없는 SSG와는 달리,
  ISR은 설정된 시간이 지나면 자동으로 re-build하고, 데이터를 업데이트(revalidate)함
  1. 페이지 방문자가 없으면 업데이트는 진행하지 않지만, 누구든 방문하면 데이터가 업데이트

📌 장단점

• React framework인 Next.js의 공식문서에서는 SSG 방식을 권장
• CSR & SSR과 비교했을 때 렌딩 속도도 빠름
• 업데이트가 잦지 않은 페이지에 대해서 불필요한 통신과 리렌더링을 줄여줌

📜 체크리스트

1. 페이지의 방문자의 수요에 맞추어 업데이트가 필요한가?
2. revalidate에서 업데이트 되는 데이터의 양이 너무 많지는 않은가?

💡 답변

서버 사이드 렌더링이란?

서버측에서 즉시 렌더링이 가능한 HTML 컨텐츠를 만들어 클라이언트에게 전달하는 방식입니다.
JS파일은 후에 다운로드 받기에 인터렉션이 가능한 TTI는 늦지만 TTV는 빠릅니다.
또한 즉시 렌더링이 가능한 HTML 컨텐츠가 있어 SEO 대응이 가능합니다.
하지만 URL이 바뀌면 서버로부터 문서를 다시 받아오기 때문에 서버에 과부하가 걸리기 쉽습니다.

SEO란?

검색 엔진 최적화를 말하는 것이며
검색 엔진에 노출이 잘되게하여 사용자의 유입이 늘려 서비스의 성장에 도움이 되게끔
하는 것을 의미합니다.
검색 엔진은 크롤러라는 자동화된 머신이 웹사이트를 읽으며 돌아다니는데 JS를 해석하는
하는 엔진이 없어 CSR같은 경우에는 SEO 대응이 조금 어렵습니다.