CSR/SSR

Client Side Rendering

렌더링을 클라이언트에서 하는 방식

서버가 클라이언트의 요청을 받으면 빈 HTML 파일을 보내주는데 클라이언트가 JS, CSS 같은 정적 파일을 받아서 렌더링 하는 방식

• 사용자의 행동에 따라 필요한 부분만 다시 읽어들일 수 있어서 SSR보다 조금 더 빠른 인터랙션 가능
• 페이지 로딩 시 중요하지 않은 리소스의 로딩을 늦추는 lazy loading 지원
• 서버에서 빈 HTML을 주기 때문에 응답의 첫 번째 바이트가 도착하기의 시간은 짧지만 페이지와 자바 스크립트를 읽은 후 화면을 그리는 시간까지 모두 마쳐야 콘텐츠가 사용자에게 보여지기 때문에 초기구동속도가 비교적 느림
• HTML 파일을 하나만 받아와서 작동하다보니 각 페이지에 대한 정보를 담기 힘들어 SEO에 취약

Server Side Rendering

서버쪽에서 렌더링 준비를 전부 마친 상태로 클라이언트에 전달하는 방식

서버는 요청을 받는 즉시 렌더링 가능한 HTML 파일을 만들어 클라이언트에 전달

해당 파일은 렌더링 준비가 되어있기 때문에 HTML이 즉시 렌더링

 

단,  JavaScript가 읽히기 전이라면 HTML이 렌더링 되어도 사이트 조작은 불가능하다

이벤트리스너가 할당도 안됐는데... 무슨 사이트 조작을...

• 사용자가 처음으로 컨텐츠를 볼 수 있는 시점이 비교적 빠름
• 모든 요청에 대해 부분 수정이 불가능 해 새 페이지를 로딩하고 렌더
• 전체를 로딩하다 보니 수정할 때 CSR 보다 비교적 느림
• 페이지가 미리 빌드되어 크롤러가 많은 정보를 읽을 수 있음 SEO 최적화
• 클릭할 때마다 새로운 HTML을 받아오기 때문에 깜빡임 발생

서버는 늘 요청을 받는 즉시 HTML 파일을 만드나요?

Static Site Generation

SSR처럼 서버로부터 완성된 HTML을 받아오지만, HTML 파일의 생성 시점이 빌드 타임

생성이 완료된 HTML 문서를 재활용 하기 때문에 응답 속도가 매우 빠르고, 이미 생성된 HTML 파일을 받아오니까 SEO 친화적

build 명령은 실제로 사이트를 방문하는 사람의 워크플로우를 벗어나므로 시간이 좀 걸려도 문제가 되진 않는다

다만 모든 URL에 대해 개별 HTML 파일을 생성해야 한다는 단점이 존재

URL을 미리 예측할 수 없으면 적용할 수 없음

 

미리 다 만들어두고 요청이 있으면 해당 페이지에 응답하기 때문에 업데이트가 거의 없어서 캐싱해두면 좋은 페이지에 사용

언제 사용해야 하는데?

CSR은 유저와 상호작용이 많고 검색엔진 노출보다 고객의 데이터를 보호하는 것이 더 중요한 경우

SSR은 홍보를 위해 상위 노출이 필요하고 누구에게나 같은 내용을 보여주며 잦은 업데이트가 필요한 경우

SSG는 홍보를 위해 상위 노출이 필요하고 누구에게나 같은 내용을 보여주지만 업데이트가 거의 없는 경우

 

그럼 사용자에 따라 페이지 내용이 달라지는데 상위노출도 놓칠 수 없다면...?

CSR + SSR 의 형태인 Universal 랜더링도 고려 해야 한다

---

렌더링 요청받은 내용을 브라우저 화면에 표시하는 것

클라이언트 서버 시스템과 연결하여 주된 작업이나 정보를 서버에게 요청하고 그 결과를 돌려받는 컴퓨터 시스템