웹 공부가 뭐라고...
프론트엔드 공부가 뭐라고, JS가 뭐라고, 웹이 뭐라고,,,,
알아야 할게 산더미이고 모르는것 투성이 인지 모르지만 웹의 아주 기본적인 특성인 '화면 띄워주기'(rendering)의 방법에는 두 가지가 있고 각자의 장단점이 있으니 알아두어야 겠다.
(이제껏 아무렇지 않게 이용하던게 상당히 복잡했구나)
1. SPA & MPA
렌더링의 이해에 앞서서 SPA 와 MPA라는 용어 이해가 먼저 필요하다.
페이지 구성방식을 의미한다.
1.1 SPA
SPA : Single Page Application
어플리케이션이라 하면 '스마트폰 어플'을 떠올리기 쉽지만,
지금부터 어플리케이션은 서비스라고 알고 가는게 좋다.
우리가 방문하는 웹 사이트도 하나의 서비스이다.
(검색 서비스, 커머스 서비스, 스트리밍 서비스 등등등)
SPA는 풀어서 쓰면 알 수 있듯이, 그러한 서비스를 하나의 페이지로 구성한 것이다.
상단 헤더부분의 메뉴들을 클릭하면 깜빡임 없이 안의 내용들만 쏙 바뀌는 형태를 떠올리면 된다.
달리 말하면, 내가 보는 화면을 통으로 바꾸는 게 아니라, 필요한 부분(바꾸고 싶은 부분)만 바꿔준다는 것이다.
이러한 페이지 구성방식의 특성상 렌더링 방식을 CSR로 채택하는 경우가 대다수이다.
1.2 MPA
MPA : Multi Page Application
MPA 역시 풀어서 보면 직관적으로 이해하기 쉽다.
하나의 서비스를 여러개의 페이지로 구성한다는 의미이다.
무언가를 클릭해서 약간의 깜빡임 이후에 원하는 화면이 보여지는 방식이다.
깜빡인다의 의미는 내가 보는 화면을 통으로 다른 페이지로 바꾼다는 의미이다.
(페이지는 곧 HTML!!!)
이러한 페이지 구성방식의 특성상 렌더링 방식을 SSR로 채택하는 경우가 대다수이다.
2. CSR & SSR
렌더링(화면 띄워주기, 화면 그리기, 뿌려주기 등)은 그 표현이 다양한데,
결국 우리가 원하는 정보를 화면상으로 보여주는 작업이다.
우리는 어떤 웹 페이지에 방문을 해서, 서버에 요청을 하고 정보를 받아내어서 내 화면에 띄워지는 과정을 매일 하고있다.
CSR과 SSR로 나뉘는 기본적인 기준은 '어느쪽에서 렌더링을 하느냐'에 달려있다.(서버에서 하느냐, 클라이언트가 하느냐)
2.1 CSR
CSR : Client Side Rendering
클라이언트 측에서 렌더링을 하는 방식이다.
기본적인 과정은 다음과 같다.
- 유저가 웹을 방문
- 웹은 서버에 콘텐츠를 요청
- 서버는 빈뼈대인 HTML을 보내줌(JS링크는 연결된채로)
- 웹은 연결된 JS를 다운
- 다운받은 JS를 바탕으로 동적 DOM생성
...빈 뼈대 HTML이 뭐지?(아래와 같다)
<html>
<head>
<title>CSR</title>
<link ...>
</head>
<body>
<div id='app'></div>
<script src='app.js'></script>
</body>
</html>정말로 이게 다인가보다.
진짜 말그대로 빈 뼈대인 HTML이고, 다운받은 JS를 바탕으로 동적 DOM이 생성 되는것이다.
놀랍게도 위와 같은 HTML이 우리가 보는 웹 서비스가 될 수 있다는 것이다.
이때 서버는 아주 단순하게도, 올려놓은 파일을 전달해주는 전달자 역할만 하게된다.
브라우저는 서버로부터 다운받은 파일을 그냥 실행 할 뿐이고,
그 과정중에 하나인 JS파일을 실행(다운 받은 뒤)하면서
DOM에 내용을 추가하면서 그리게 됩니다.
이 과정을 이해했다면 알 수 있는 사실이 생긴다.
- 위에서 기술한 기본적 과정의 4, 5 때문에 초기 로딩속도가 느리다는 점.
-> 하지만 이는 곧, 초기 로딩만 된다면 그 이후는 빠르다는 의미와 같음 - TTI == TTV (위와 동일한 의미입니다.)
- 3번 과정인 '서버는 그냥 전달자 역할'이라는 점에서 서버부하가 적다는 점.
- 연산과 라우팅 모두 클라이언트가 하기 때문에 반응속도가 빠르고 UX도 우수.
- 빈 뼈대 HTML때문에 SEO에 불리하다는 점.
2.2 SSR
SSR : Server Side Rendering
서버측에서 렌더링을 하는 방식이다.
기본적인 과정은 다음과 같다.
- 유저가 웹을 방문
- 웹은 서버에 콘텐츠를 요청
- 렌더링 준비를 마친 HTML(JS코드)
- HTML 렌더링
- JS코드 다운
- HTML에 JS로직 연결
CSR의 이해를 바탕으로 SSR 과정을 찬찬히 따라가다보면 알게되는 점
- 3번 과정을 통해 정보가 채워진 HTML을 브라우저가 받게된다.
->SEO에 유리하다. - 4번 과정까지만 이루어지는 속도가 매우 빠릅니다.
-> CSR에선 다운받은 JS를 바탕으로 DOM을 생성하기까지 기다려야 했지만,
SSR에선 그러기도 전에 HTML이 렌더링이 되어있습니다.
-> 이는 곧 초기 구동속도('내가 원하는 서비스가 보이는구나!')가 빠름을 의미합니다. - 하지만 이는 곧 단점이 될 수 있습니다.
-> 4번 까지는 구동이 빠르지만, JS로직 연결이 되기까지 걸리는 시간이 남았습니다.
-> 4번 시점에서는 뭘 클릭하거나 입력해도 반응이 없는 껍데기 웹에 불과합니다. - TTI !== TTV (위와 동일한 의미입니다.)
Time To Interaction : 상호작용 하기까지의 시간.
Time To View : 보여지는 순간까지의 시간.
웹 크롤러
(이 부분은 이해를 위한 간단한 내용만을 작성하였고, 내용이 많이 모자람)
웹 크롤러는 HTML파일을 읽어서 검색 엔진에서 해당 페이지가 검색이 될 지 말지를 결정해주는 역할을 하게 되는데, 빈 뼈대 HTML을 읽어봤자 아무런 정보가 없기 때문에 SEO(검색엔진최적화)측면에서 CSR은 불리하다.
하지만, 역으로 굳이 검색엔진에 띄워질 필요가 없다거나 띄워지는게 안좋게 작용하는 서비스라면 CSR이 오히려 좋을 수 있다.
끝으로
종종 SPA == CSR , MPA == SSR 이라는 고정관념이 생길 수 있다.
솔직히 거의 틀린말은 아니지 않나 싶지만, 이 둘을 가르는 기준은 명백히 다르다.
엄격하게 생각해보면,
렌더링의 주최자가 누구냐로 CSR, SSR을 구분지어야하고,
서비스를 구성하는 페이지가 몇 개냐로 SPA, MPA를 구분짓는다.
하지만, SPA의 특성상 CSR의 채택이 당연시 되는 분위기이고,
MPA의 특성상 SSR의 채택이 당연시 되는 분위기다 정도로 알고가자.
무엇이 더 좋다!는 생각은 이젠 접어두자.
우리가 제공하는 서비스에 따라 SSR, CSR을 달리 적용해야 된다.
- 유저와 상호작용이 많고, 대부분이 고객의 정보라 검색엔진 노출 필요없음
-> CSR - 누구에게나 같은 정보를 보여주고(정보성 페이지), 매주 업데이트 실시
-> SSR - 사용자에 따라 정보가 달라지고, 상호작용이 많으며 상위 노출을 원함
-> CSR + SSR
Reference
