CRP(Critical Rendering Path)는 브라우저과 화면에 HTML, CSS, JS를 그리는 과정이며, 아래와 같은 과정으로 수행된다.
Dom Tree
CSSOM Tree
Render Tree
Layout
Paint(Repaint)
이때 (1)~(3)과정을 construction 과정이라 부르며, (4)~(5)는 Operation 과정이라 부른다.
우리가 작성한 코드는 렌더링에 직접적으로 영향을 미치기 때문에 알아야 한다.
예를 들어, 웹페이지에서 특정 요소를 안보이게 하고 싶을 때, display: none을 사용하면 Tree를 만드는 Construction 과정부터 Operation 과정까지 수행되어 비효율적이다. 하지만 opacity: 0나 visibility: hidden 속성을 사용하면 operation 과정부터 수행되게 되어, 같은 기능을 하는 속성들일지라도 opacity나 visibility를 사용하는 것이 효율적이다.
따라서 렌더링은 UX와 DX에 직접적으로 영향을 미쳐 올바른 렌더링 방법을 채택하는 것이 중요하다.
웹 사용자 경험에 대한 지표인 Core Web Vitals는 어떤 방식으로 렌더링을 하는지에 따라 수치가 달라지기도 한다.
01. Static Websites
Static Websites는 미리 만들어진 웹페이지인 정적 웹페이지를 요청에 따라 반환한다.
예를 들어, 1000명의 유저 정보 페이지가 필요하다면, 1000개의 유저 정보 페이지가 필요하다.
💡Static Websites 특징
- 서버 불필요 :S3와 같은 별개 저장소 사용시 서버가 불필요하다.
- 서버가 반환하고자 하는 모든 정적 웹페이지를 갖고있어야 하며, 웹페이지 버전 변경을 하려면 매번 파일을 변경해줘야 하는 번거로움이 있다.
- 서버가 가지고 있는 정적 웹페이지를 반환만 하면 되기 때문에 웹페이지 반환 속도가 매우 빠르며, 웹크롤러가 웹페이지를 수집할 수 있어 검색 엔진 최적화에 유리하다.
SSR은 서버가 요청에 따라 그때그때 동적 웹페이지를 만들어 반환한다. 즉, 사용자의 요청에 따라 서버에서 실시간으로 동적 페이지를 생성하여 반환한다. SSR은 반복되는 템플릿과 실시간 정보를 분리하여, 서버는 필요한 데이터와 반복되는 템플릿을 조합해 페이지를 구성한다.
예를 들어, 1000명의 유저 정보가 필요하면 서버는 하나의 템플릿에 1000명의 유저 데이터를 각각 적용하여 1000개의 서로 다른 페이지를 동적으로 생성하게 된다. 사용자의 검색 필터, 상품 가격 변동 등 즉각적으로 다른 결과를 보여줘야 하는 쇼핑몰과 같이 실시간성이 중요한 웹페이지에서 MPA가 유용한다.
💡 SSR 특징
- 웹 서버의 CPU와 메모리 자원 소모 : 서버는 요청에 따라 실시간으로 페이지를 생성하기 때문에 웹 서버의 CPU와 메모리 자원 소모
-> AWS 이용시 비용 부담으로 이어짐 -> 비용 감소를 위해 Serverless 적용하기도 함
- 검색 엔진 최적화에 유리 : 서버에서 미리 렌더링된 페이지를 반환하기 때문에, 검색 엔진의 웹 크롤러가 페이지 내용 쉽게 수집 가능
- 서버 반드시 필요 : 서버가 동적으로 페이지를 생성해야 하기 때문에 서버 반드시 필요
- 서버가 동적 웹페이지를 요청이 있을 때마다 동적으로 생성하기 때문에 저장 용량 효율적으로 사용 가능 => 서버가 모든 정적 페이지를 미리 저장할 필요 없음
↓
유저가 서버에 HTML 파일 요청하면 서버는 API 서버에 요청 보내서 데이터 받아와 콘텐츠를 채우고 완성된 HTML 파일 등을 웹브라우저에 보내준다.
SSR Core Web Vitals 관점 SSR이 이루어진 후 첫 바이트가 유저에게 도착 -> 유저에게 도착한 HTML은 콘텐츠를 포함하기 때문에 HTML 렌더하는 순간 FCP, LCP 동시 발생 -> 마지막으로 JS 로딩하면 유저가 인터렉션 가능한 페이지가 되므로 TTI 마지막에 발생
MPA : 사용자가 다른 페이지 이동할 때마다 서버로부터 새로운 페이지 요청하고 이를 렌더링
SPA : 하나의 HTML 로드한 후, 페이지 간 이동, 업데이트 있을 때마다 전체 페이지 다시 로드하는 것이 아닌 동적으로 내용만 변경하는 방식
#2. CSR(Client-Side Rendering)
CSR은 클라이언트(웹브라우저)에서 페이지를 렌더링하는 방식이다.
서버는 필요한 자바스크립트 파일과 데이터를 클라이언트에 전달하고, 클라이언트는 이 데이터를 바탕으로 페이지를 생성한다.
초기 로딩 시 모든 필요한 JS 파일을 한 번에 불러오기 때문에, 초기 로딩 시간이 길어질 수 있다. 이때 이 JS 파일들을 Bundle JS라 한다.
💡 CSR 특징
- 서버 불필요 : S3와 같은 별개 저장소 사용시 서버가 불필요하다.
- 웹 브라우저가 동적 웹페이지를 생성하여 반환하기 때문에, 웹페이지 전환시 깜빡임이 존재하지 않는다.
- 초기 로딩시 Bundled JS가 너무 큰 문제 발생.(초기 로딩시 필요한 모든 파일을 한 번에 불러오기 때문에)
- 검색 엔진 최적화 불가능 : 웹 크롤러가 웹 페이지를 수집할 수 없다.
04. SSR(Server-Side Rendering) with Hydration = MPA + SPA
SSR with Hydration은 MPA와 SPA의 장점을 결합한 것이다.
CSR에는 초기 로딩 시 전체 JS를 받아와야 돼서 시간이 오래 걸리는 문제점과 클라이언트에서만 렌더링되기 때문에 SEO가 불가능하다는 단점이 있었다. SSR with Hydration은 CSR의 이런 문제점을 보완하고 CSR의 장점을 유지하기 위해 등장하였다.
SSR with Hydration은 SSR을 통해 서버에서 미리 렌더링된 HTML을 클라이언트에서 받아온 후, 이 HTML에 클라이언트측의 JS 적용해 동적 기능 추가하는 과정이다.
Next.js와 같은 메타 프레임워크는 SSR with Hydration을 모두 지원한다.
Next.js의 경우 Bundled JS는 총 3가지로 나누어 생성된다.
Middleware(edge 디렉토리) : 클라리언트에서 어떤 요청이 들어왔을 때 처리할 로직을 서버에서 미리 수행. Routing(Page 혹은 API)시 적용할 미들웨어 로직은 Edge 내에서 수행. Edge는 CDN에서 정적 데이터만 캐싱하지 않고, 함수도 직접 실행하며 그 결과도 캐싱할 수 있음
CSR(client 디렉토리) : 웹브라우저에서 Hydration을 위해 사용되는 JS
SSR(nodejs 디렉토리) : 웹서버에서 페이지를 동적으로 렌더링하는 JS
#1. Hydration 개념
하나의 온전한 페이지를 유저에게 보여주는 방법은 아래와 같이 총 3가지가 있다.
SSG : 이미 만들어져 있는 웹 페이지를 웹 서버가 갖고, 바로 웹 브라우저에게 반환하여 유저에게 보여주는 방법
SSR : 웹 서버가 열심히 온전한 페이지를 만들어 웹 브라우저가 그걸 받아와 유저에게 보여주는 방법
CSR : 웹 브라우저가 열심히 빈 페이지를 온전한 페이지로 만들어서 유저에게 보여주는 방법
SSG, SSR, CSR 각각은 각자 아래와 같은 장단점을 가진다.
SSG : 이미 만들어져 있는 웹페이지를 반환해주기 때문에 속도는 제일 빠르지만, 웹페이지의 실시간성이 위배
SSR : 실시간성을 취하나, 웹 서버가 웹 페이지를 다 만드는데까지 너무 많은 시간이 소요
CSR : 페이지 전환이나 버튼에 따른 동작들이 부드럽지만, 이를 위한 Bundled JS가 너무 무거움
쉽게 말해 Hydration은 SSG, SSR 장점 위에 CSR 장점을 얹기 위한 방법이다.
SSG : 웹 페이지 내 비실시간성 요소들은 미리 준비하여 속도가 제일 빠르게 반환
SSR : 실시간성이 필요한 웹 페이지 내 부분은 웹 서버로부터 요청이 들어오자마자 만들어 반환
CSR : 모바일 앱과 같은 사용성을 제공하면 좋은 일부 요소들은 CSR로 렌더링하여 Bundled JS 경량화
Hydration을 적용하면 JS가 늦게 로드되기 때문에 짧은 시간동안 유저 사용성에 관련된 버튼 등이 동작되지 않는다.
이에 Next.js는 Streaming & Partial Rendering이라는 명칭의 렌더링 전략을 갖는다.
💡 SSR with Hydration 특징(SSR 특징과 동일)
- 서버 필요
- 서버가 동적 웹 페이지를 생성하여 반환하기 때문에, 반환하려는 모든 웹페이지를 갖고 있을 필요가 없다. 이때 웹 페이지를 만들고 사용자가 보기까지 시간이 걸릴 수 있다.
- 서버가 생성해서 반환하기 때문에 웹 페이지 반환 속도는 DB 조회 속도, 웹 페이지 생성 속도에 의존한다. 웹 서버의 CPU, 메모리 자원이 사용되기 때문에 AWS 등을 사용할 시 비용이 부담될 수 있고, 비용 감소를 위해 Serverless를 적용할 수 있다.
- SEO가 가능
Hydration을 활용하여 여전히 모바일 앱과 유사한 사용성 제공이 가능하다.
웹 브라우저가 동적 웹 페이지를 생성하여 반환하기 때문에, 웹 페이지 전환 시 깜빡임이 존재하지 않는다.
05. SSG(Static Site Generation) with Hydration
SSG with Hydration은 React와 같은 웹프론트엔드 프레임워크로 개발 및 빌드한 정적 페이지를 반환하는 웹서버를 활용한다.
웹프론트엔드 프레임워크를 통해 CSR 개발하듯이 개발한 뒤 빌드하면 정적 페이지를 생성한다.
SSG는 SEO 개선을 위해 페이지 로딩 속도를 극단적으로 줄일 필요가 있어 등장하였고, HTML, JS, CSS를 직접 생성하는 static websites와 달리 SSG는 빌드로 생성한다. SSG Hydration은 미리 만들어진 웹페이지인 정적 웹페이지를 요청에 따라 반환하는 방식인 static websites에 CSR의 장점을 누릴 수 있도록 Hydration을 추가한 것이다.
💡 SSG with Hydration 특징(Static Websites 특징과 동일)
- 서버 불필요
- 서버가 반환하고자 하는 모든 정적 웹페이지를 가지고 있어야 함
- 웹페이지 버전 변경시 개발->빌드 과정을 거치면서 static websites 보다 비교적으로 간편
- 매우 빠른 웹페이지 반환 속도 : 서버가 가지고 있는 정적 웹 페이지를 반환만 하면 되기 때문에
- 검색 엔진 최적화에 유리
- Hydration을 활용하여 모바일 앱과 유사한 사용성 제공 가능.(웹 브라우저가 동적 웹페이지를 생성하여 반환하기 때문에 웹페이지 전환시 깜빡임 존재 하지 않음)
Rendering Pattern : 웹 프론트엔드 페이지 제공 방법
렌더링은 브라우저 화면에 웹페이지를 그리는 것이다.
CRP(Critical Rendering Path)는 브라우저과 화면에 HTML, CSS, JS를 그리는 과정이며, 아래와 같은 과정으로 수행된다.
이때 (1)~(3)과정을 construction 과정이라 부르며, (4)~(5)는 Operation 과정이라 부른다.
우리가 작성한 코드는 렌더링에 직접적으로 영향을 미치기 때문에 알아야 한다.
예를 들어, 웹페이지에서 특정 요소를 안보이게 하고 싶을 때, display: none을 사용하면 Tree를 만드는 Construction 과정부터 Operation 과정까지 수행되어 비효율적이다. 하지만 opacity: 0나 visibility: hidden 속성을 사용하면 operation 과정부터 수행되게 되어, 같은 기능을 하는 속성들일지라도 opacity나 visibility를 사용하는 것이 효율적이다.
따라서 렌더링은 UX와 DX에 직접적으로 영향을 미쳐 올바른 렌더링 방법을 채택하는 것이 중요하다.
웹 사용자 경험에 대한 지표인 Core Web Vitals는 어떤 방식으로 렌더링을 하는지에 따라 수치가 달라지기도 한다.
01. Static Websites
Static Websites는 미리 만들어진 웹페이지인 정적 웹페이지를 요청에 따라 반환한다.
예를 들어, 1000명의 유저 정보 페이지가 필요하다면, 1000개의 유저 정보 페이지가 필요하다.
💡Static Websites 특징
- 서버 불필요 :S3와 같은 별개 저장소 사용시 서버가 불필요하다.
- 서버가 반환하고자 하는 모든 정적 웹페이지를 갖고있어야 하며, 웹페이지 버전 변경을 하려면 매번 파일을 변경해줘야 하는 번거로움이 있다.
- 서버가 가지고 있는 정적 웹페이지를 반환만 하면 되기 때문에 웹페이지 반환 속도가 매우 빠르며, 웹크롤러가 웹페이지를 수집할 수 있어 검색 엔진 최적화에 유리하다.
02. MPA(Multi-Page Application) = SSR(Server-Side Rendering)
SSR은 서버가 요청에 따라 그때그때 동적 웹페이지를 만들어 반환한다. 즉, 사용자의 요청에 따라 서버에서 실시간으로 동적 페이지를 생성하여 반환한다. SSR은 반복되는 템플릿과 실시간 정보를 분리하여, 서버는 필요한 데이터와 반복되는 템플릿을 조합해 페이지를 구성한다.
예를 들어, 1000명의 유저 정보가 필요하면 서버는 하나의 템플릿에 1000명의 유저 데이터를 각각 적용하여 1000개의 서로 다른 페이지를 동적으로 생성하게 된다. 사용자의 검색 필터, 상품 가격 변동 등 즉각적으로 다른 결과를 보여줘야 하는 쇼핑몰과 같이 실시간성이 중요한 웹페이지에서 MPA가 유용한다.
💡 SSR 특징
- 웹 서버의 CPU와 메모리 자원 소모 : 서버는 요청에 따라 실시간으로 페이지를 생성하기 때문에 웹 서버의 CPU와 메모리 자원 소모
-> AWS 이용시 비용 부담으로 이어짐 -> 비용 감소를 위해 Serverless 적용하기도 함
- 검색 엔진 최적화에 유리 : 서버에서 미리 렌더링된 페이지를 반환하기 때문에, 검색 엔진의 웹 크롤러가 페이지 내용 쉽게 수집 가능
- 서버 반드시 필요 : 서버가 동적으로 페이지를 생성해야 하기 때문에 서버 반드시 필요
- 서버가 동적 웹페이지를 요청이 있을 때마다 동적으로 생성하기 때문에 저장 용량 효율적으로 사용 가능 => 서버가 모든 정적 페이지를 미리 저장할 필요 없음
↓
유저가 서버에 HTML 파일 요청하면 서버는 API 서버에 요청 보내서 데이터 받아와 콘텐츠를 채우고 완성된 HTML 파일 등을 웹브라우저에 보내준다.
03. SPA(Single-Page Application) = CSR(Client-Side Rendering)
#1. MPA와 SPA 차이점
#2. CSR(Client-Side Rendering)
CSR은 클라이언트(웹브라우저)에서 페이지를 렌더링하는 방식이다.
서버는 필요한 자바스크립트 파일과 데이터를 클라이언트에 전달하고, 클라이언트는 이 데이터를 바탕으로 페이지를 생성한다.
초기 로딩 시 모든 필요한 JS 파일을 한 번에 불러오기 때문에, 초기 로딩 시간이 길어질 수 있다. 이때 이 JS 파일들을 Bundle JS라 한다.
💡 CSR 특징
- 서버 불필요 : S3와 같은 별개 저장소 사용시 서버가 불필요하다.
- 웹 브라우저가 동적 웹페이지를 생성하여 반환하기 때문에, 웹페이지 전환시 깜빡임이 존재하지 않는다.
- 초기 로딩시 Bundled JS가 너무 큰 문제 발생.(초기 로딩시 필요한 모든 파일을 한 번에 불러오기 때문에)
- 검색 엔진 최적화 불가능 : 웹 크롤러가 웹 페이지를 수집할 수 없다.
04. SSR(Server-Side Rendering) with Hydration = MPA + SPA
SSR with Hydration은 MPA와 SPA의 장점을 결합한 것이다.
CSR에는 초기 로딩 시 전체 JS를 받아와야 돼서 시간이 오래 걸리는 문제점과 클라이언트에서만 렌더링되기 때문에 SEO가 불가능하다는 단점이 있었다. SSR with Hydration은 CSR의 이런 문제점을 보완하고 CSR의 장점을 유지하기 위해 등장하였다.
SSR with Hydration은 SSR을 통해 서버에서 미리 렌더링된 HTML을 클라이언트에서 받아온 후, 이 HTML에 클라이언트측의 JS 적용해 동적 기능 추가하는 과정이다.
Next.js와 같은 메타 프레임워크는 SSR with Hydration을 모두 지원한다.
Next.js의 경우 Bundled JS는 총 3가지로 나누어 생성된다.
#1. Hydration 개념
하나의 온전한 페이지를 유저에게 보여주는 방법은 아래와 같이 총 3가지가 있다.
SSG, SSR, CSR 각각은 각자 아래와 같은 장단점을 가진다.
쉽게 말해 Hydration은 SSG, SSR 장점 위에 CSR 장점을 얹기 위한 방법이다.
Hydration을 적용하면 JS가 늦게 로드되기 때문에 짧은 시간동안 유저 사용성에 관련된 버튼 등이 동작되지 않는다.
이에 Next.js는 Streaming & Partial Rendering이라는 명칭의 렌더링 전략을 갖는다.
💡 SSR with Hydration 특징(SSR 특징과 동일)
- 서버 필요
- 서버가 동적 웹 페이지를 생성하여 반환하기 때문에, 반환하려는 모든 웹페이지를 갖고 있을 필요가 없다. 이때 웹 페이지를 만들고 사용자가 보기까지 시간이 걸릴 수 있다.
- 서버가 생성해서 반환하기 때문에 웹 페이지 반환 속도는 DB 조회 속도, 웹 페이지 생성 속도에 의존한다. 웹 서버의 CPU, 메모리 자원이 사용되기 때문에 AWS 등을 사용할 시 비용이 부담될 수 있고, 비용 감소를 위해 Serverless를 적용할 수 있다.
- SEO가 가능
Hydration을 활용하여 여전히 모바일 앱과 유사한 사용성 제공이 가능하다.
웹 브라우저가 동적 웹 페이지를 생성하여 반환하기 때문에, 웹 페이지 전환 시 깜빡임이 존재하지 않는다.
05. SSG(Static Site Generation) with Hydration
SSG with Hydration은 React와 같은 웹프론트엔드 프레임워크로 개발 및 빌드한 정적 페이지를 반환하는 웹서버를 활용한다.
웹프론트엔드 프레임워크를 통해 CSR 개발하듯이 개발한 뒤 빌드하면 정적 페이지를 생성한다.
SSG는 SEO 개선을 위해 페이지 로딩 속도를 극단적으로 줄일 필요가 있어 등장하였고, HTML, JS, CSS를 직접 생성하는 static websites와 달리 SSG는 빌드로 생성한다. SSG Hydration은 미리 만들어진 웹페이지인 정적 웹페이지를 요청에 따라 반환하는 방식인 static websites에 CSR의 장점을 누릴 수 있도록 Hydration을 추가한 것이다.
💡 SSG with Hydration 특징(Static Websites 특징과 동일)
- 서버 불필요
- 서버가 반환하고자 하는 모든 정적 웹페이지를 가지고 있어야 함
- 웹페이지 버전 변경시 개발->빌드 과정을 거치면서 static websites 보다 비교적으로 간편
- 매우 빠른 웹페이지 반환 속도 : 서버가 가지고 있는 정적 웹 페이지를 반환만 하면 되기 때문에
- 검색 엔진 최적화에 유리
- Hydration을 활용하여 모바일 앱과 유사한 사용성 제공 가능.(웹 브라우저가 동적 웹페이지를 생성하여 반환하기 때문에 웹페이지 전환시 깜빡임 존재 하지 않음)
'ASAC > 웹 기초 프로그래밍' 카테고리의 다른 글