CSR vs SSR vs SSG (+SEO)

CSR (Client Side Rendering)

말 그래도 클라이언트에서 렌더링이 일어나는 것을 의미합니다.

클라이언트가 서버에 요청을 하고, 서버가 응답을 HTML과 JS를 보내게 되면

클라이언트는 이제 렌더링을 하게 됩니다.

 

dev-tool에서 네트워크를 보면 사진과 같이 HTML이나 JS 이미지 등을 받아오는 것을 볼 수 있습니다.

 

 

 

SSR (Sever Side Rendering)

CSR과 마찬가지로 이름에서 유추할 수 있듯이 서버에서 렌더링 해주는 방식을 말합니다.

클라이언트가 서버에 요청을 하고, CSR과 다르게 서버 쪽에서 이미 HTML, JS 등을 만들게 됩니다.

완료하게 되면 클라이언트에 전달하게 되고, 클라이언트는 화면을 그릴 필요 없이 바로 뿌려주게 됩니다.

렌더링을 서버에서 한다기보다는 모든 것을 서버에서 작업한 뒤, 클라이언트는 바로 그리기만 해주는 것입니다.

그리고 클라이언트가 JS를 받고 실행하게 됩니다.

 

 

 

---

 

 

CSR vs SSR

둘의 차이점을 비교해 보겠습니다.

가장 큰 차이점으로 SEO와 속도로 볼 수 있습니다.

 

 

---

 

 

CSR의 경우,

• JS파일과 HTML을 전부 불러와서 그리기 때문에 첫 페이지의 로딩 시간이 오래 걸립니다. 하지만 페이지 전환 시에 그려지는 페이지들은 이미 다 받아왔기 때문에 빠르고, 화면 깜빡이는 현상이 없습니다. (캐싱)
• SEO에 적합하지 않습니다. CSR은 전반적으로 받아와서 그리기 때문에 동적으로 생성되고(API 포함),
  크롤링에 있어 JS가 실행되지 않는 것을 선호했는데, CSR은 JS의 실행에 의존하기 때문입니다.
• 하지만, 원래는 크롤러가 JS를 지원하지 않아서 많이 불리한 거 같은데, 구글봇 크롤러가 ES5+JS를 지원해서 많이 괜찮아진 거 같습니다. (또는 메타 태그 활용)

 

 

---

 

 

SSR의 경우,

• 서버에서 필요한 부분의 HTML과 JS를 그려놨기 때문에 첫 페이지 로딩은 빠릅니다. 하지만 페이지 전환 될 때마다 소스를 받아와 그리기 때문에 페이지 이동시에는 느립니다.
• SEO에 최적화되어 있습니다. 서버에서 메타데이터로 컴파일 후, HTML이 클라이언트로 전송되기 때문에 크롤러는 메타데이터만 읽으면 되기 때문에 검색엔진에 최적화되어 있다고 볼 수 있습니다.

 

간단히 CSR과 SSR은 서로 반대의 장담점을 가지고 있습니다.

 

 

SEO (Search Engine Optimiztion)
SEO는 검색하는 데 있어 최적화를 의미합니다.;
간단히 검색엔진(구글, 네이버 등)에서 검색했을 때, 개발한 홈페이지가 검색했을 때, 잘 나오냐 안 나오냐로 보시면 됩니다.
크롤러가 자료를 수집하고, 순위를 매겨 검색 결과의 상위에 올라오냐, 하위에 올라오냐입니다.

 

 

---

 

 

SSG (Static Site Generation)

SSG는 SSR처럼 서버에서 HTML을 완성해서 받아오지만, 빌드타임이 다르다고 합니다.

빌드할 때, 각 페이지의 HTML을 생성하고, 해당 페이지 요청이 올 경우에 이미 생성한 HTML을 반환하게 됩니다.

 

서버에서 페이지를 계속해서 재생성하는 것이 아니라 빌드에서 만들어낸 HTML을 보여주는 것입니다.

(대표적으로 Next.js가 있습니다.)

 

• 생성이 완료된 HTML문서를 재활용하기 때문에 응답속도가 빠릅니다.
• SEO에 친화적입니다.
• 하지만 페이지를 빌드했을 때 만들어 내기 때문에, 업데이트하려면 다시 빌드를 해야 합니다.

 

이로 인해 Next.js를 사용하면 CSR과 SSR의 장점을 살려 좋은 환경을 이룰 수 있게 됩니다. (물론 단점도 있지만)

 

나중에 Next.js관련된 글을 작성할 때 얘기 나오겠지만,

SSG의 특징인 빌듯이 정적으로 생성되는 점과 SSR의 특징인 서버에서 HTML을 그리는 방법 모두 사용할 수 있게 됩니다.