[1주차 이론 study] 웹 개발의 렌더링 방식

[xeunnie]

렌더링 방식 키워드

1. CSR (Client-Side Rendering)
2. SSR (Server-Side Rendering)
3. SSG (Static Site Generation)
4. ISR (Incremental Static Regeneration)

[xeunnie]

CSR (Client-Side Rendering)

Q1. CSR을 활용할 때 SEO 문제를 어떻게 해결할 수 있을까요? 해결 방법 중 가장 효과적인 것은 무엇일까요?

Q2. 대규모 SPA에서 CSR로 인해 발생하는 초기 로딩 시간을 줄이는 방법은 무엇일까요?

Q3. CSR 환경에서 API 호출의 최적화 방법과 캐싱 전략은 뭐가 있을까요?

[thgee]

A1. SSR이나 SSG을 혼합하여 사용하거나, 검색 엔진 크롤러를 위한 프리렌더링 도구를 활용하는 것이 효과적입니다.

A2. 코드 스플리팅과 Lazy Loading을 통해 필요한 코드만 로드하도록 설정합니다.

A3. 데이터가 변경되지 않는 경우 브라우저의 캐싱 메커니즘을 활용하거나 CDN 캐싱을 이용합니다. 데이터 변경 주기가 짧은 경우 SWR이나 React-Query를 활용해 Stale-While-Revalidate 전략을 적용합니다.

[xeunnie]

A1.

CSR에서는 페이지 콘텐츠가 클라이언트에서 렌더링되기 때문에, 검색 엔진 크롤러가 페이지를 제대로 인식하지 못할 수 있습니다.

[해결 방법 1]

서버 사이드 렌더링(SSR) 사용:
CSR 대신 SSR을 사용하여 초기 HTML을 서버에서 생성하고 클라이언트에 전송하면 SEO에 유리합니다.
그러나 SSR을 도입하는 것은 특정 상황에서 복잡성을 증가시킬 수 있습니다.

[해결 방법 2]

프리렌더링(Pre-rendering):
페이지를 미리 렌더링하여 정적 HTML 파일을 생성하는 방법입니다. 이 방식은 SEO를 향상시킬 수 있습니다.

[해결 방법 3]

메타 태그 및 구조화된 데이터 추가:
클라이언트에서 렌더링할 때도 메타 태그와 구조화된 데이터를 동적으로 추가하여 검색 엔진 최적화에 도움을 줄 수 있습니다.

A2.

[해결 방법]

1. 코드 스플리팅:
필요한 코드만 로드하고, 나머지는 사용자가 필요할 때 로드하는 방식입니다. 이를 통해 초기 로딩 시간을 줄일 수 있습니다.

2. Lazy Loading:
이미지나 컴포넌트를 사용자가 화면에 보이기 전에 미리 로드하지 않고, 실제로 필요할 때만 로드합니다.

3. 최적화된 자산:
이미지, CSS 파일 및 JavaScript 파일을 압축하고 최적화하여 파일 크기를 줄입니다.

4. 캐싱 전략:
브라우저 캐시를 활용하여 정적 자산을 저장하고, 다음 방문 시 빠르게 로딩될 수 있도록 합니다.

5. CDN(Content Delivery Network):
CDN을 사용하여 정적 파일을 사용자와 가까운 서버에서 제공함으로써 로딩 시간을 줄입니다.

A3.

1. Debouncing/Throttling:
사용자의 입력에 따라 API 호출을 조절하여 불필요한 호출을 줄입니다.
예를 들어, 입력 필드에서 사용자가 타이핑할 때 일정 시간 후에 API를 호출하도록 설정할 수 있습니다.

2. Batching:
여러 API 호출을 하나의 요청으로 묶어서 전송함으로써 네트워크 요청 수를 줄입니다.

3. 캐싱:

• 로컬 스토리지 또는 세션 스토리지: API 응답을 저장하여 동일한 요청에 대해 재사용
• HTTP 캐싱: 적절한 캐시 헤더를 설정하여 브라우저가 응답을 캐시하도록 유도
• Service Worker: PWA에서 Service Worker를 사용하여 API 응답을 캐시, 오프라인에서도 사용할 수 있도록 설정

[xeunnie]

SSR (Server-Side Rendering)

Q1. SSR이 필요한 프로젝트의 요구사항을 어떻게 정의할 수 있을까요?

Q2. SSR에서 발생할 수 있는 서버 부하 문제를 해결하기 위한 방법은 무엇이 있을까요?

[thgee]

A1. SEO가 중요한 페이지나 빠른 초기 렌더링이 필요한 프로젝트에서 SSR이 적합합니다.

A2. CDN을 활용하여 정적 자산의 배포를 최적화합니다. 가능하면 SSG를 사용하는것도 좋을 것 같습니다.

[xeunnie]

A1.

SEO 최적화 필요성, 초기 로딩 속도, 대규모 트래픽 처리가 고려되는 경우 적합합니다.

A2.

• 캐싱 전략(서버 캐싱, HTTP 캐싱)
• 로드 밸런싱(웹서버 부하 분산)
• 비동기 데이터 로딩 (필요한 데이터만 비동기적으로 로드하여 초기 렌더링 속도를 개선)
• 서버 성능 최적화(서버 하드웨어 개선, 서버 소프트웨어 개선, DB 쿼리를 최적화하여 데이터 접근 속도를 개선)
• 스케일링(수평적, 수직적 스케일링 -> 서버의 용량을 늘려 부하를 분산)

[xeunnie]

SSG (Static Site Generation)

Q1. SSG와 CSR의 주요 차이점은 무엇이며, SSG를 선호해야 하는 이유는 무엇일까요?

Q2. SSG를 사용할 때 데이터를 빌드 타임에 가져오는 것이 적합할까요, 런타임에 가져오는 것이 적합할까요?

[thgee]

A1. SSG는 빌드 타임에 정적 HTML을 생성하고 CSR은 클라이언트에서 JavaScript로 빈 HTML을 채웁니다. SSG는 정적 파일로 이미 만들어진 HTML을 제공하므로 빠른 로딩 속도와 SEO 최적화가 필요할 때 적합합니다.

A2. 런타임에 가져오면 SSG가 아니지 않나요?? 모르겠습니당 🤔

[xeunnie]

A1.

1. 렌더링 시점

• SSG: 페이지가 빌드 타임에 미리 렌더링되어 정적 HTML 파일로 생성됨. 사용자가 요청할 때 이미 생성된 페이지를 제공 -> 빠른 로딩 속도
• CSR: 페이지는 클라이언트에서 렌더링됨. 초기 로딩 시 JavaScript 파일을 다운로드한 후에 페이지 콘텐츠를 동적으로 생성, 첫 로딩 시간이 길어질 수 있음

2. SEO

• SSG: 모든 페이지가 미리 생성되어 검색 엔진이 쉽게 크롤링할 수 있으므로 SEO에 유리함
• CSR: 클라이언트에서 콘텐츠가 로드되기 때문에 검색 엔진이 초기 HTML을 읽어들일 수 없어 SEO에 불리할 수 있음

3. 데이터 업데이트

• SSG: 데이터가 빌드 타임에만 업데이트되며, 콘텐츠가 변경되면 다시 빌드
• CSR: 데이터는 런타임에 API 호출 등을 통해 동적으로 가져올 수 있어 실시간으로 콘텐츠를 업데이트

A2.

빌드 타임에 가져오는 것이 적합한 경우:

• 변경 빈도가 낮은 데이터: 콘텐츠가 자주 변경되지 않는 경우, 예를 들어 블로그 포스트, 문서, 마케팅 페이지 등에서는 빌드 타임에 데이터를 가져오는 것이 적합합니다.
• SEO가 중요한 경우: 모든 콘텐츠가 초기 로드 시 미리 생성되어야 하므로, SEO에 유리합니다.

런타임에 가져오는 것이 적합한 경우:

• 실시간 데이터 필요: 사용자 맞춤형 데이터나 실시간으로 변하는 정보가 필요한 경우에는 런타임에 데이터를 가져와야 합니다. 예를 들어, 사용자 대시보드, 뉴스 피드 등에서는 런타임에 API 호출을 통해 데이터를 가져오는 것이 좋습니다.
• 자주 변경되는 콘텐츠: 데이터가 자주 업데이트되고, 최신 정보를 즉시 반영해야 하는 경우에는 런타임에 데이터를 가져오는 것이 더 유리합니다.

[xeunnie]

ISR (Incremental Static Regeneration)

Q1. ISR의 주요 특징은 무엇일까요?

Q2. ISR의 캐싱 동작 방식을 이해하기 위해 내부적으로 어떤 메커니즘이 작동하는지 설명해주실 수 있나요?

Q3. ISR이 가장 적합한 프로젝트 유형은 무엇이라고 생각하시나요?

[thgee]

A1. 빌드 후에도 특정 시간 간격으로 페이지를 재생성하며, SSG의 정적 성능과 CSR의 동적 갱신을 결합한 방식입니다.

A2. 초기 요청 시 정적 페이지를 반환하고, 지정된 재생성 주기 이후 새 데이터를 가져와 백그라운드에서 페이지를 갱신합니다.

A3. 데이터 변경 빈도가 낮으면서도 빠른 초기 로딩과 동적 업데이트가 필요한 블로그, 뉴스 사이트, 전자상거래 페이지에 적합하다고 생각합니다 !

[xeunnie]

혼합 질문

Q1. CSR, SSR, SSG, ISR 중 가장 적합한 방식을 선택하는 기준은 무엇인가요?

Q2. 완전히 CSR 기반 프로젝트에서 SSG나 ISR로 전환할때는 어떻게 할까요?

Q3. Next.js에서 각 렌더링 방식을 조합하여 사용할 때, 주의해야 할 점이나 기술적인 트레이드오프는 무엇인가요?

[thgee]

A1. SEO와 초기 로딩 속도가 중요하면 SSR/SSG를, 동적 데이터와 사용자 상호작용이 많으면 CSR을, 정적 성능과 업데이트가 모두 필요하면 ISR을 선택합니다.

A2. Next를 사용한다면 getStaticProps 함수로 해결하면 될 것 같고, React만 사용중이라면 Gatsby같은 외부 라이브러리를 사용할 것 같습니다.

A3. 데이터 충돌? 데이터 불러오는 타이밍이 다르니 그런점에 유의해야 하지 않을까요?? 코드가 복잡해질 수 있으므로 유지보수에 신경써야할 것 같아요

[junesung1004]

렌더링 방식 키워드

1. CSR (Client-Side Rendering)

• 브라우저에서 특정 주소로 요청을 하면 서버는 해당 주소에 해당하는id="root"라는 빈 컨테이너를 포함한 정적 HTML 파일을 반환합니다. 브라우저는 이 HTML 파일을 파싱하여 DOM 트리를 생성하고, JavaScript가 실행되기 전까지는 빈 화면을 렌더링합니다.
• 그 후 브라우저는 script파일을 확인하고 이 정보를 토대로 서버에 해당 script에 필요한 javascript 파일을 다시 서버에 추가로 요청한다.
• 다시 서버는 브라우저에서 요청 받은 자바스크립트 파일을 찾은 후 브라우저에 자바스크립트 파일을 넘겨주고 브라우저는 자바스크립트 파일을 파싱을 거친 후 dom을 변경하여 결과적으로 브라우저에 랜더링을 한다.
• 이 방식은 하이드레이션(hydration)으로 초기 로딩 시 느리다는 단점이 있고 초기에는 빈 화면만 랜더링해서 웹사이트에 필요한 정보 즉 SEO 정보를 받을 수 없어 SEO에 불리한 이점을 가지고 있다고 생각합니다.

2. SSR (Server-Side Rendering)

• 브라우저에서 특정 주소로 요청을 하면 서버는 해당 주소에 해당하는 모든 정보가 들어있는 HTML 파일을 브라우저에게 전송한다
• 브라우저는 서버에서 받은 HTML을 받으면 브라우저가 읽을 수 있게 파싱이 된 후 화면에 랜더링이된다.
• SSR의 장점은 초기 화면 랜더링 시 화면에 필요한 모든 정보가 들어가있어 SEO 검색엔진에 유리한 이점을 가지고 있습니다.
• SSR의 단점은 매번 요청을 할때마다앙 서버는 완성된 파일을 전달하여 페이지 이동 시 느리다는 단점을 가지고 있습니다.

3. SSG (Static Site Generation)

• 브라우저가 특정 주소로 요청을 하면 서버는 해당 주소에 해당하는 모든 정보가 들어있는 HTML 파일을 전달하기에 앞서 빌드 시점에 정적 스태틱 페이지가 생성되고 이때 컴파일 과정이 실행됩니다. 서버에 거치치 않고 미리 화면을 랜더링을 한다.
• SSG 랜더링 기법은 프론트엔드 관점에서 performance가 가장 좋게 나올거라 예상하고 있습니다.
• SSG의 단점은 실시간으로 데이터를 주고받아야 하는 동적 페이지에서는 오히려 빌드 시간도 오래 걸리고 비효율적일거라 예상합니다.

4. ISR (Incremental Static Regeneration)

• 위 랜더링 기법은 추 후 공부하여 수정해서 반영하겠습니다..!

[thgee]

ISR 동작 과정에서 특정 시간이 지나서 데이터가 업데이트 될 때 둘 중 어느 방식으로 이루어질까요?

1. 브라우저 상에서만 업데이트가 이루어진다.
2. 빌드된 정적파일 자체가 변경된다.

[xeunnie]

ISR(Incremental Static Regeneration) 동작 과정에서 특정 시간이 지나서 데이터가 업데이트 될 때, 2번. 빌드된 정적 파일 자체가 변경됩니다.

ISR 동작 과정

1. 초기 요청: 사용자가 페이지를 요청하면, Next.js가 서버에서 정적 HTML 파일을 생성 -> 클라이언트에 전달

2. 정적 파일 캐싱: HTML 파일 정적 파일로 캐시 -> 이후의 요청에서는 빠르게 제공

3. 재생성 타이머: ISR에서는 각 페이지에 대해 설정된 revalidate 시간(예: 10초)이 있어 이 시간이 지나면, 다음 요청 시 서버에서 페이지를 다시 생성함

4. 데이터 업데이트: 설정된 시간이 지나면, 사용자가 해당 페이지를 요청할 때 서버는 최신 데이터를 사용하여 새로운 HTML 파일을 생성, 이를 다시 캐시

5. 정적 파일 변경: 이렇게 생성된 새로운 HTML 파일은 다음 요청 시부터 사용자에게 제공