프론트엔드 기초 개념

1. 브라우저의 동작 순서

  1. HTML 마크업을 처리하고 DOM 트리를 준비한다.
  2. CSS 마크업을 처리하고 CSSOM 트리를 준비한다.
  3. DOM과 CSSOM을 결합하여 렌더링 트리를 만든다.
  4. 렌더링 트리에서 각 요소의 최종 위치와 크기를 계산하는 과정을 거쳐 박스 모델을 생성한다.
  5. 화면에 페인팅한다.

2. CORS

자바스크립트는 필요한 데이터를 어디서든 받아올 수 있다.
웹페이지를 만든 서버는 물론이고 다른 서버에서도 당연하게 데이터를 받아올 수 있다.
이 때, 다른 도메인으로 리소스를 요청하는 것을 교차 출처 HTTP 요청(Cross-Origin HTTP) 이라고 한다.

그런데 교차 출처 HTTP 요청은 보안 문제를 일으킬 수 있다.
악의적인 의도를 가진 사람들이 이 기능을 이용하여 사용자의 개인 정보를 훔치는 등 데이터를 훔칠 수 있기 때문이다.

그래서 브라우저들은 원칙적으로 정책을 통해 이런 요청을 제한한다.
이 정책을 동일 출처 정책(Same-Origin Policy) 라고 부른다.
따라서, 기본적으로 자바스크립트는 자신과 같은 출처에서만 데이터를 받아올 수 있다.

❓ 그럼 어떻게 다른 서버의 데이터를 받아와야할까?

이 때, 필요한 것이 바로 CORS(Cross-Origin Resource Sharing)이다.
CORS는 서버 측에서 설정할 수 있는데, HTTP 헤더 설정을 통해 특정 출처의 웹페이지가 자신의 데이터에 접근할 수 있도록 허용해줄 수 있다.

HTTP Header Description
Access-Control-Allow-Origin 접근 가능한 url 설정
Access-Control-Allow-Credentials 접근 가능한 쿠키 설정
Access-Control-Allow-Headers 접근 가능한 헤더 설정
Access-Control-Allow-Methods 접근 가능한 http method 설정

3. 서버 사이드 렌더링(SSR) vs 클라이언트 사이드 렌더링(CSR)

SPA가 등장하고 나서부터는 페이지 전체를 서버에 요청하는 것이 아니라, 변경되는 요소에 대한 데이터만 요청할 수 있게되었다. 서버는 JSON 데이터만 보내주는 역할을 하고 HTML을 그리는 역할을 클라이언트가 하게되니 효율적으로 사용자에게 좋은 경험을 제공했다. 이것을 클라이언트 사이드 렌더링(CSR) 이라고 한다.

CSR은 사용자의 행동에 따라 필요한 부분만 다시 읽어들이기 때문에 빠른 인터랙션을 기대할 수 있다.
그리고 렌더링을 클라이언트에서 전부 처리하기 때문에 코드의 일관성도 유지시킬 수 있다.

하지만 단점도 존재한다.
자바스크립트 코드를 읽어들이는 시간과 렌더링 하는 과정을 모두 거쳐야 사용자에게 화면이 제공된다는 점이다.

반면에 서버 사이드 렌더링(SSR)은 서버에서 렌더 가능한 상태로 클라이언트에 전달되기 때문에 초기 화면 출력 시간을 앞당길 수 있다.
전통적 렌더링 방식인 SSR은 메인 스크립트가 크고 로딩이 느릴 때, 인터랙션이 적을 때 장점을 보인다.

❓ 그럼 어떤 경우에 어떤 방식을 사용해야할까?

SSR CSR
네트워크가 느릴 때 네트워크가 빠를 때
최초 로딩이 빨라야할 때 서버의 부하를 줄일 때
메인 스크립트가 크고 로딩이 느릴 때 메인 스크립트가 가벼울 때
인터랙션이 적을 때 인터렉션이 많을 때
---

📂 참고자료