CSR(Client-Side Rendering)이 왜 SEO(Search Engine Optimization)에 취약한지 이해하려면 먼저 React의 기본 동작인 CSR로 동작하는 것을 이해하고 CSR과 SSR의 차이점에 대해서 알아보고 그 단점을 보완하려면 어떤 방법이 있는지 알아봅시다.
CSR (Client-Side Rendering)
이미지 사진은 많은 블로거들이 사용하고 있는 이미지를 가져왔습니다.
우선은 CSR의 동작원리를 알아봅시다.
1. 사용자가 Website에 요청을 보냅니다.
2. CDN이 HTML파일과 JS로 접근할 수 있는 링크를 클라이언트로 보냅니다.
"여기서 CDN이란 엔드유저의 요청에 '물리적'으로 가까운 서버에서 요청에 응답하는 방식 "
3. 클라이언트는 HTML과 JS를 다운로드합니다.
4. 브라우저가 자바스크립트를 다운로드합니다.
5. 다운로드가 완료된 JS가 실행되며 데이터를 위한 API를 호출합니다. (이때 유저들이 placeholder를 보게 됩니다.)
6. 서버가 API로부터 요청에 응답합니다.
7. API가 받아온 데이터를 placeholder 자리에 넣어줍니다. 이제 페이지가 상호작용이 가능해집니다.
즉 서버에서 처리 없이 클라이언트로 보내주기 때문에 자바스크립트가 모두 다운로드되고 실행이 끝나기 전까지는 사용자는 볼 수 있는 게 없습니다.
SSR (Server-Side Rendering)
1. 사용자가 웹 사이트에 요청을 보냅니다.
2. Server는 "Ready to Render" 즉시 렌더링 가능한 HTML파일을 만듭니다.
3. 클라이언트에 전달하는 순간 이미 렌더링 준비가 되었기 때문에 HTML이 즉시 렌더링이 됩니다.
"하지만 사이트 자체는 조작이 불가능하다 이유는 자바스크립트가 아직 읽히기 전이기 때문이다. "
4. 클라이언트가 자바스크립트를 다운로드합니다.
5. 다운로드하는 사이에 유저는 콘텐츠를 확인할 수 있지만 사이트를 조작할 수는 없습니다. 하지만 이때 사용자가 클릭하거나 행동한 것을 기억합니다.
6. 브라우저가 Javascript 프레임워크를 실행합니다.
7. JS까지 성공적으로 컴파일되면 아까 기억하고 있던 사용자의 조작이 실행되고 웹페이지 상호작용이 가능해집니다.
서버에서 이미 렌더링 가능한 상태로 클라이언트에 전달되기 때문에, JS가 다운로드되는 동안 사용자는 무언가를 보고 있을 수 있습니다.
CSR과 SSR의 차이
차이점 중 하나는 웹페이지의 로딩시간입니다.
웹 페이지의 로딩시간은 처음 홈페이지를 들어갔을 때 첫 로딩시간과 들어간 후 페이지간의 전환하는 로딩이 존재합니다.
1. 첫 홈페이지 로딩시간
- CSR의 경우 HTML, CSS와 모든 스크립트를 한 번에 불러옵니다.
- SSR의 경우 필요한 부분의 HTML과 스크립트만 불러오게 됩니다. 때문에 평균적으로 SSR이 더 빠릅니다.
2. 페이지간 전환 로딩시간
- CSR의 경우 이미 처음 홈페이지를 들어갈 때 모든 HTML과 스크립트를 받아왔기에 더 빠릅니다.
- SSR의 경우 첫 페이지를 로딩한 과정을 다시 실행하므로 더 느립니다.
차이점 중 두 번째는 UI적 차이가 있습니다.
코드로 예시를 들자면
// index.html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
</head>
<body>
<div id="root"></div>
</body>
</html>CSR의 경우 Public 폴더 안에 index.html 태그 한 개만 사용하여 페이지를 보여줍니다. 때문에 body태그 안에 root div태그 안에서 Routing과정을 통해서 페이지를 전환하기 때문에 깜빡임 없는 부드러운 전환을 보여줍니다.
SSR의 경우 각 페이지마다 html이 존재하기 때문에 페이지 전환시마다 새로고침한 거처럼 깜빡임을 일으킵니다. 단 Dynamic Import를 이용하여 단점을 보완시킬 수 있는 방법이 존재합니다.
차이점 중 세 번째는 SEO (검색엔진 최적화) 대응입니다.
검색 엔진은 크롤러로 웹 사이트를 읽습니다.
CSR은 자바스크립트를 실행시켜 동적으로 콘텐츠가 생성되기 때문에 자바스크립트를 실행되어야 metadata가 바뀝니다.
SSR은 애초에 Server Side에서 컴파일되어 클라이언트로 넘어오기 때문에 크롤러에 대응하기 용이합니다.
하지만 CSR의 경우 Helmet-Async라는 라이브러리를 사용하면 보일러 플레이트는 늘어나지만 각 컴포넌트마다 MetaTag를 달아줌으로써 어느 정도 단점이 보완이 가능합니다.
코드 예시 - 각 페이지 컴포넌트에 Helmet을 씌워줌
function MainPage () {
<Container>
<Helmet>
<title>메인 페이지</title>
</Helmet>
</Container>
}
export default MainPage;차이점 중 네 번째는 서버 자원 사용입니다.
CSR은 클라이언트에서 자원을 많이 사용하므로 서버에 부하가 적습니다.
SSR은 서버에 매번 요청을 하기 때문에 CSR에 비해 서버 자원을 더 많이 사용합니다.
사용 권장 예시
SSR을 사용할 경우
- 네트워크가 느릴 때 SSR을 필요한 부분만 각 페이지마다 나누어 불러오기 때문에 더 용이합니다.
- SEO (검색 엔진 최적화)가 필요할 때
- 최초 로딩이 빨라야 하는 사이트를 Devleop 할 때
- 메인 스크립트가 크고 로딩이 엄청 느릴 때 ( CSR은 메인스크립트가 로딩이 끝나면 API로 데이터를 요청을 보낸다 하지만 SSR은 한 번의 요청에 아예 렌더가 가능한 페이지가 돌아온다.)
- 웹 사이트 간의 상호작용이 별로 없을 때
CSR을 사용할 경우
- 네트워크가 빠를 때 HTML과 CSS 스크립트를 한 번에 불러오기 때문에 사용자 경험이 좋다.
- 서버의 성능이 좋지 않을 때 백엔드 없이 Firebase 등의 무료 서버를 이용할 때 더욱 좋다.
- 사용자에게 보여줘야 하는 데이터의 양이 많을 때
- 메인 스크립트가 가벼울 때
- SEO 검색 엔진 최적화가 중요하지 않은 경우
- 웹 어플리케이션에 사용자와 상호작용 할 것들이 많을 때 (아예 렌더링이 되지 않아 사용자의 행동을 막는 것이 경험에 오히려 유리합니다.)
결론 : CSR과 SSR은 각각의 장단점이 있어 잘 확인해 보고 자신의 프로젝트에 맞는 방법을 사용해 보도록 하자. 또한 SSR과 CSR의 장단점 등을 보완하는 React + Next.js를 활용해 보는 것도 좋은 방법인 거 같다.
'Frontend' 카테고리의 다른 글
| [React] React-hook useRef 무엇인가? (0) | 2023.03.22 |
|---|---|
| [React] File Resizer 적용기 (0) | 2023.03.19 |
| [React] 무한 스크롤 적용기 (1) | 2023.02.22 |
| React에서 Toast Editor 적용기 (0) | 2023.02.11 |
| [React] useState batching과 동기 비동기에 대하여 (0) | 2023.01.31 |
