<div id="readability-page-1" class="page"><div><h2 id="-spa란">📌 SPA란?</h2>
<p><strong>Single page Application</strong>는 말 그래로 하나의 페이지로 구성된 애플리케이션입니다. 사용자가 요청한 각각의 페이지를 서버가 생성해서 전달해주는 것이 아니라, 클라이언트가 동적으로 페이지를 다시 작성하는 방식입니다.</p>
<p>첫 페이지 요청 시 단 한번만 리소스(HTML,CSS, JS)를 로딩하고, 그 이후로는 페이지 리로딩 없이 필요한 부분만 서버로부터 받아서 화면을 갱신합니다. 필요한 부분만 갱신하기 때문에 네이티브 앱에 가까운 자연스러운 페이지 이동과 사용자 경험(UX)를 제공할 수 있습니다.</p>
<hr>
<h2 id="-csrclient-side-rendering">📌 CSR(Client Side Rendering)</h2>
<p>클라이언트 사이드 렌더링은 클라이언트 사이드에서 HTML을 반환한 후에, JS가 동작하면서 데이터만을 주고 받아서 클라이언트에서 렌더링을 진행하는 것을 말합니다.</p>
<blockquote>
<p>동작 과정 : HTML 다운로드 → JS 다운로드 → JS 실행 → DATA 서버로 부터 받기 → Content 확인</p>
</blockquote>
<hr>
<h2 id="-csr의-장점">✅ CSR의 장점</h2>
<ul>
<li>클라이언트가 모든 페이지를 가지고 있으므로 앱과 같은 자연스러운 사용자 경험을 제공합니다. 사실상 로딩 이후에는 모바일 앱과 동일한 방식으로 동작을 한다고 볼 수 있습니다.</li>
<li>페이지를 이동 하더라도 필요한 (컴포넌트)만 부분적으로 교체하면 되므로 효율성이 증가합니다. 또한 SSR보다 빠른 인터랙션이 가능합니다.</li>
<li>서버가 해야 할 화면 구성을 클라이언트가 수행하므로 서버 부담이 줄어들게 됩니다.</li>
<li>모듈화 또는 컴포넌트별 개발이 용이합니다.</li>
<li>백엔드와 프론트엔드가 비교적 명확하게 구분됩니다. 서버사이드 렌더링이 필요하지 않기 때문에 일관성 있는 코드 작성이 가능합니다.</li>
<li>앱과 웹이 동일한 서버를 이용할 수 있습니다.</li>
<li>Lazy loading을 지원해줍니다.</li>
<li>PWA(Progressive Web App)과 궁합이 잘 맞습니다.</li>
</ul>
<ul>
<li>
<p><strong>Lazy loading</strong>: 페이지 로딩시 중요하지 않은 리소스의 로딩을 늦추는 기술</p>
</li>
<li>
<p><strong>PWA(Progressive Web App)</strong>: 웹과 네이티브 앱의 기능 모두의 이점을 갖도록 수 많은 특정 기술과 표준 패턴을 사용해 개발된 웹 앱입니다.</p>
</li>
</ul>
<hr>
<h2 id="-csr의-단점">✅ CSR의 단점</h2>
<ol>
<li>처음 접속시 사이트 구성과 관련된 모든 리소스를 한 번에 받기 때문에 초기 구동 속도가 느릴 수 있습니다.</li>
<li>데이터를 별도로 요청하고 받아와서 화면을 구성하므로 설계 방식에 따라서는 화면이 변하는 모습이 사용자에게 노출 될 수 있습니다. → 이는 별로 보기 좋지 않을 수 있습니다.</li>
<li>SPA 구조 상 데이터 처리는 클라이언트에서 하는 경우가 많은데, 중요한 비즈니스 로직이 존재한다면 보안상의 문제가 생길 수 있습니다. 즉 해킹 위험이 있습니다. (프론트엔드에 비즈니스 로직을 최소화 합니다.)</li>
<li><code>검색엔진 최적화 (SEO)</code> 가 어렵습니다. 검색 엔진 최적화를 하는 크롤링 로봇이 html 만 가져와서 검색에는 뜨지 않습니다.</li>
</ol>
<hr>
<h2 id="-csr의-단점-극복">✅ CSR의 단점 극복</h2>
<p>1번과 2번 단점은 lazy loading, pre-rendering 을 통해 어느 정도 극복이 가능합니다.</p>
<p>3번 같은 경우, 노출하면 안 되는 중요한 로직이 있다면 해당 기능만 API를 통해서 서버에서 처리하도록 하면 되기 때문에, 비효율적이지만 큰 문제는 아닙니다.</p>
<p>하지만 근본적인 문제는 SEO입니다. 이는 검색엔진이 크롤링할때 JS를 실행하지 않고 HTML에 있는 그대로 긁어가기 때문에 문제가 발생합니다. 즉 사용자가 인지하는 화면과 검색 엔진이 인지하는 화면이 다르게 되는 것 입니다. 이러한 부분을 보완하기 위해서 SPA 라이브러리들은 SSR 기능을 지원합니다.</p>
<h3 id="-spa-라이브러리를-통한-해결">💡 SPA 라이브러리를 통한 해결</h3>
<p>Next.js나 Gatsby를 사용하지 않는 경우, SSR 기능을 지원하는 SPA 라이브러리를 통해 해결합니다.</p>
<h4 id="react-helmet">React-Helmet</h4>
<p>react-helmet 라이브러리를 통해 동적으로 SEO에 필요한 메타태그들을 쉽게 변경할 수 있게 도와주는 라이브러리입니다.</p>
<blockquote>
<p>React를 빌드 했을 경우, HTML의 파일은 하나이고 SEO 친화적이지 않습니다. 크롤러가 웹페이지에 들어 왔을때는 하나의 html 파일만을 바라보게 됩니다. 당연히 우리가 설정한 동적으로 변경되는 메타 태그도 보이지 않습니다.</p>
</blockquote>
<h4 id="react-snap">React-Snap</h4>
<p>react-snap 라이브러리를 통해 설정을 하면 build 페이지별 index.html 파일이 생성됩니다. 각 html 파일을 실행해서 보면 실제 정적인 SSR 환경의 파일을 소스보기한 것과 동일하게 보입니다. 이 파일들을 서버에 업로드 해주면 따로 SSR을 구현하지 않고 SEO 친화적인 웹페이지를 만들 수 있습니다.</p>
<h3 id="-nextjs를-통한-해결">💡 Next.js를 통한 해결</h3>
<ul>
<li>SSR의 단점 : 불필요한 부분까지 렌더링 된다.</li>
<li>CSR의 단점: 초기 진입 속도가 느리다. SEO 취약하다.</li>
</ul>
<p>위 두가지 단점을 해결하면서, 두 방식의 장점을 살리고자. Next.js를 사용하여 첫 페이지는 백엔드 서버에서 렌더링하여 빈 HTML이 아닌 데이터가 채워진 HTML을 받아 검색 최적화 문제를 해결하고 그 다음 페이지부터 CSR방식을 적용하여 필요한 데이터 부분만 갱신해 서버의 부하도 줄이게 한 것입니다.</p>
<hr>
<h2 id="-server-side-rendering">📌 Server Side Rendering</h2>
<p>서버에서 렌더링을 작업하는 방식, 전통적인 웹 애플리케이션 렌더링 방식으로 사용자가 웹 페이지에 접근할 때, 서버에 각각의 페이지에 대한 요청을 하며, 서버에서 HTML, JS 파일 등을 모두 다운로드해서 화면에 렌더링 하는 방식을 말합니다.</p>
<h2 id="-ssr의-장점">✅ SSR의 장점</h2>
<ul>
<li>사용자가 처음으로 컨텐츠를 볼 수 있는 시점을 앞당길 수 있습니다.</li>
<li>검색 엔진 최적화(SEO) 적용에 용이 합니다.</li>
</ul>
<h2 id="-ssr의-단점">✅ SSR의 단점</h2>
<ul>
<li>모든 요청에 관해 필요한 부분만 수정하는 것이 아닌, 완전히 새 페이지를 로딩하고 렌더해줍니다.</li>
<li>전체를 로딩하다보니 CSR보다 느리고, Bandwidth를 많이 쓰며, 사용자 경험이 좋지 않게 됩니다.</li>
<li>페이지 이동시 화면 깜빡임이 생깁니다(UX)</li>
<li>페이지 불필요한 템플릿도 중복해서 로딩합니다. (성능)</li>
<li>모바일 앱 개발시 추가적인 백엔드 작업 필요(생산성)</li>
</ul>
<hr>
<h2 id="-정리">🐰 정리</h2>
<blockquote>
<p>SSR과 CSR은 상황에 맞게 사용해야합니다. <strong>SSR</strong>는 서버에서 HTML,CSS,JS 파일을 처리한 후, 클라이언트에 렌더하기 때문에 사용자가 컨텐츠를 볼 수 있는 시점을 앞당길 수 있는 장점이 있습니다. 또한 위와 같은 방식으로 SEO에 적용에 용이합니다. SSR은 모든 요청에 관해 필요한 부분만 수정하는 것이 아닌, 완전히 새로운 페이지를 로딩하고 렌더하기 때문에 대역폭을 많이 사용하며 페이지 이동시 화면 깜빡임이 생기며 사용자 경험이 좋지 않게 됩니다. 또한 모바일 앱 개발시에 추가적인 백엔드 작업이 필요합니다.</p>
</blockquote>
<blockquote>
<p><strong>CSR</strong>은 클라이언트가 모든 페이지를 가지고 있기 때문에 네이티브 앱과 같은 자연스러운 사용자 경험을 제공할 수 있습니다. 페이지를 이동하더라도 필요한 컴포넌트만 부분적으로 교체해주면 되기 때문에 효율성이 증가하며 SSR에 비해 빠른 인터랙션이 가능합니다. 앱과 웹이 동일한 서버를 사용할 수 있기 때문에 앱을 고려하는 경우 생산성이 크게 증가합니다. 또한 서버가 해야할 화면 구성을 클라이언트가 수행하므로 서버에 부담이 줄게 됩니다. <strong>반면에</strong> CSR은 처음 사이트 접속시 사이트 구성과 관련된 모든 리소스를 한번에 받기 때문에 초기 구동 속도가 느리며, 데이터를 별도로 요청하고 화면을 구성하기 때문에 화면이 변하는 모습이 사용자에게 노출 될 수 있습니다. 비즈니스 로직이 존재한다면 보안상의 문제가 발생할 수 있습니다. 검색엔진 최적화가 어렵습니다.</p>
</blockquote>
<blockquote>
<p>SSR의 CSR의 특성과 장단점을 통해 프로젝트 구성에 있어서 어떤 방식으로 해야하는 지 명확한 근거를 가지고 진행할 수 있게 된 좋은 개념이였습니다.</p>
</blockquote>
<h2 id="-레퍼런스">😈 레퍼런스</h2>
<ul>
<li><a href="https://www.npmjs.com/package/react-helmet">리액트 헬멧</a></li>
<li><a href="https://flamingotiger.github.io/frontend/react/react-helmet/">리액트 헬멧을 통한 검색 최적화</a></li>
<li><a href="https://developer.mozilla.org/ko/docs/Web/Progressive_web_apps/Introduction">PWA</a></li>
<li><a href="https://velog.io/@byseop/SPA%EC%97%90%EC%84%9C-%EC%84%9C%EB%B2%84%EC%82%AC%EC%9D%B4%EB%93%9C-%EB%A0%8C%EB%8D%94%EB%A7%81%EC%9D%84-%EA%B5%AC%EC%B6%95%ED%95%98%EC%A7%80-%EC%95%8A%EA%B3%A0-SEO-%EC%B5%9C%EC%A0%81%ED%99%94%ED%95%98%EA%B8%B0">SPA에서 SEO 최적화 하기</a></li>
<li>https://www.programmersought.com/article/57305210889/</li>
</ul></div></div>

TheJang story

📌 SPA란?
Single page Application는 말 그래로 하나의 페이지로 구성된 애플리케이션입니다. 사용자가 요청한 각각의 페이지를 서버가 생성해서 전달해주는 것이 아니라, 클라이언트가 동적으로 페이지를 다시 작성하는 방식입니다. 
첫 페이지 요청 시 단 한번만 리소스(HTML,CSS, JS)를 로딩하고, 그 이후로는 페이지 리로딩 없이 필요한 부분만 서버로부터 받아서 화면을 갱신합니다. 필요한 부분만 갱신하기 때문에 네이티브 앱에 가까운 자연스러운 페이지 이동과 사용자 경험(UX)를 제공할 수 있습니다.
📌 CSR(Client Side Rendering)
클라이언트 사이드 렌더링은 클라이언트 사이드에서 HTML을 반환한 후에, JS가 동작하면서 데이터만을 주고 받아서 클라이언트에서 렌더링을 진행하는 것을 말합니다.
동작 과정 : HTML 다운로드 → JS 다운로드 → JS 실행 → DATA 서버로 부터 받기 → Content 확인
✅ CSR의 장점
클라이언트가 모든 페이지를 가지고 있으므로 앱과 같은 자연스러운 사용자 경험을 제공합니다. 사실상 로딩 이후에는 모바일 앱과 동일한 방식으로 동작을 한다고 볼 수 있습니다.
페이지를 이동 하더라도 필요한 (컴포넌트)만 부분적으로 교체하면 되므로 효율성이 증가합니다. 또한 SSR보다 빠른 인터랙션이 가능합니다.
서버가 해야 할 화면 구성을 클라이언트가 수행하므로 서버 부담이 줄어들게 됩니다.
모듈화 또는 컴포넌트별 개발이 용이합니다.
백엔드와 프론트엔드가 비교적 명확하게 구분됩니다. 서버사이드 렌더링이 필요하지 않기 때문에 일관성 있는 코드 작성이 가능합니다.
앱과 웹이 동일한 서버를 이용할 수 있습니다.
Lazy loading을 지원해줍니다.
PWA(Progressive Web App)과 궁합이 잘 맞습니다.
Lazy loading: 페이지 로딩시 중요하지 않은 리소스의 로딩을 늦추는 기술
PWA(Progressive Web App): 웹과 네이티브 앱의 기능 모두의 이점을 갖도록 수 많은 특정 기술과 표준 패턴을 사용해 개발된 웹 앱입니다.
✅ CSR의 단점
처음 접속시 사이트 구성과 관련된 모든 리소스를 한 번에 받기 때문에 초기 구동 속도가 느릴 수 있습니다.
데이터를 별도로 요청하고 받아와서 화면을 구성하므로 설계 방식에 따라서는 화면이 변하는 모습이 사용자에게 노출 될 수 있습니다. → 이는 별로 보기 좋지 않을 수 있습니다.
SPA 구조 상 데이터 처리는 클라이언트에서 하는 경우가 많은데, 중요한 비즈니스 로직이 존재한다면 보안상의 문제가 생길 수 있습니다. 즉 해킹 위험이 있습니다. (프론트엔드에 비즈니스 로직을 최소화 합니다.)
검색엔진 최적화 (SEO) 가 어렵습니다. 검색 엔진 최적화를 하는 크롤링 로봇이 html 만 가져와서 검색에는 뜨지 않습니다.
✅ CSR의 단점 극복
1번과 2번 단점은 lazy loading, pre-rendering 을 통해 어느 정도 극복이 가능합니다. 
3번 같은 경우, 노출하면 안 되는 중요한 로직이 있다면 해당 기능만 API를 통해서 서버에서 처리하도록 하면 되기 때문에, 비효율적이지만 큰 문제는 아닙니다.
하지만 근본적인 문제는 SEO입니다. 이는 검색엔진이 크롤링할때 JS를 실행하지 않고 HTML에 있는 그대로 긁어가기 때문에 문제가 발생합니다. 즉 사용자가 인지하는 화면과 검색 엔진이 인지하는 화면이 다르게 되는 것 입니다. 이러한 부분을 보완하기 위해서 SPA 라이브러리들은 SSR 기능을 지원합니다. 
💡 SPA 라이브러리를 통한 해결
Next.js나 Gatsby를 사용하지 않는 경우, SSR 기능을 지원하는 SPA 라이브러리를 통해 해결합니다.
React-Helmet
react-helmet 라이브러리를 통해 동적으로 SEO에 필요한 메타태그들을 쉽게 변경할 수 있게 도와주는 라이브러리입니다.
React를 빌드 했을 경우, HTML의 파일은 하나이고 SEO 친화적이지 않습니다. 크롤러가 웹페이지에 들어 왔을때는 하나의 html 파일만을 바라보게 됩니다. 당연히 우리가 설정한 동적으로 변경되는 메타 태그도 보이지 않습니다.
React-Snap
react-snap 라이브러리를 통해 설정을 하면 build 페이지별 index.html 파일이 생성됩니다. 각 html 파일을 실행해서 보면 실제 정적인 SSR 환경의 파일을 소스보기한 것과 동일하게 보입니다. 이 파일들을 서버에 업로드 해주면 따로 SSR을 구현하지 않고 SEO 친화적인 웹페이지를 만들 수 있습니다. 
💡 Next.js를 통한 해결
SSR의 단점 : 불필요한 부분까지 렌더링 된다.
CSR의 단점: 초기 진입 속도가 느리다. SEO 취약하다.
위 두가지 단점을 해결하면서, 두 방식의 장점을 살리고자. Next.js를 사용하여 첫 페이지는 백엔드 서버에서 렌더링하여 빈 HTML이 아닌 데이터가 채워진 HTML을 받아 검색 최적화 문제를 해결하고 그 다음 페이지부터 CSR방식을 적용하여 필요한 데이터 부분만 갱신해 서버의 부하도 줄이게 한 것입니다.
📌 Server Side Rendering
서버에서 렌더링을 작업하는 방식, 전통적인 웹 애플리케이션 렌더링 방식으로 사용자가 웹 페이지에 접근할 때, 서버에 각각의 페이지에 대한 요청을 하며, 서버에서 HTML, JS 파일 등을 모두 다운로드해서 화면에 렌더링 하는 방식을 말합니다.
✅ SSR의 장점
사용자가 처음으로 컨텐츠를 볼 수 있는 시점을 앞당길 수 있습니다.
검색 엔진 최적화(SEO) 적용에 용이 합니다.
✅ SSR의 단점
모든 요청에 관해 필요한 부분만 수정하는 것이 아닌, 완전히 새 페이지를 로딩하고 렌더해줍니다.
전체를 로딩하다보니 CSR보다 느리고, Bandwidth를 많이 쓰며, 사용자 경험이 좋지 않게 됩니다.
페이지 이동시 화면 깜빡임이 생깁니다(UX)
페이지 불필요한 템플릿도 중복해서 로딩합니다. (성능)
모바일 앱 개발시 추가적인 백엔드 작업 필요(생산성)
🐰 정리
SSR과 CSR은 상황에 맞게 사용해야합니다. SSR는 서버에서 HTML,CSS,JS 파일을 처리한 후, 클라이언트에 렌더하기 때문에 사용자가 컨텐츠를 볼 수 있는 시점을 앞당길 수 있는 장점이 있습니다. 또한 위와 같은 방식으로 SEO에 적용에 용이합니다. SSR은 모든 요청에 관해 필요한 부분만 수정하는 것이 아닌, 완전히 새로운 페이지를 로딩하고 렌더하기 때문에 대역폭을 많이 사용하며 페이지 이동시 화면 깜빡임이 생기며 사용자 경험이 좋지 않게 됩니다. 또한 모바일 앱 개발시에 추가적인 백엔드 작업이 필요합니다. 
CSR은 클라이언트가 모든 페이지를 가지고 있기 때문에 네이티브 앱과 같은 자연스러운 사용자 경험을 제공할 수 있습니다. 페이지를 이동하더라도 필요한 컴포넌트만 부분적으로 교체해주면 되기 때문에 효율성이 증가하며 SSR에 비해 빠른 인터랙션이 가능합니다. 앱과 웹이 동일한 서버를 사용할 수 있기 때문에 앱을 고려하는 경우 생산성이 크게 증가합니다. 또한 서버가 해야할 화면 구성을 클라이언트가 수행하므로 서버에 부담이 줄게 됩니다. 반면에 CSR은 처음 사이트 접속시 사이트 구성과 관련된 모든 리소스를 한번에 받기 때문에 초기 구동 속도가 느리며, 데이터를 별도로 요청하고 화면을 구성하기 때문에 화면이 변하는 모습이 사용자에게 노출 될 수 있습니다. 비즈니스 로직이 존재한다면 보안상의 문제가 발생할 수 있습니다. 검색엔진 최적화가 어렵습니다. 
SSR의 CSR의 특성과 장단점을 통해 프로젝트 구성에 있어서 어떤 방식으로 해야하는 지 명확한 근거를 가지고 진행할 수 있게 된 좋은 개념이였습니다. 
😈 레퍼런스
리액트 헬멧
리액트 헬멧을 통한 검색 최적화
PWA
SPA에서 SEO 최적화 하기    
https://www.programmersought.com/article/57305210889/

CSR(Client Side Rendering)과 SSR(Server Side Rendering)

댓글