📌 Next.js를 소개합니다.
☑️ Next.js는 어떤 기술일까?
리액트만을 위한 리액트 전용의 웹 개발 프레임워크
리액트보다 더 강력하고 편하게, 더 넓은 범위의 개발에 활용 가능
즉, 리액트의 확장판
- 버셀에서 개발하고 오픈 소스로 운영
- 인프런, 랠릿 등 다수의 메이저 사이트들이 활용
➡️ 현대 웹 개발 기술의 중심
☑️ 인기의 비결은?
Next.js는 라이브러리가 아닌 프레임워크임
리액트란 기술은, 자기 자신을 UI 개발을 위한 자바스크립트 라이브러리라고 소개했었음
라이브러리와 프레임워크
이 차이가 뭘까?
대략 비슷하지만 엄밀히는 구분됨
기능 구현의 주도권이 누구에게 있는가?로 구분
주도권이 개발자에게 있다? 라이브러리
- 기능 구현을 원하는 방향으로 진행
- 쓰고 싶은 도구, 쓰고 싶은 기술을 씀
➡️ 어떤 기능을 구현하는 데에 있어서 제약 없이 개발자들이 자유롭게 개발 가능
ex) 페이지 라우팅 기능을 구현해야 할 때, 리액트 라우터를 떠올리겠지만
꼭 그럴 필요 없이 Tanstack 라우터 같은 기술을 사용해도 문제 없음
즉, 자유도가 높다
주도권이 개발자에게 없다? 프레임워크
- 프레임워크가 자체적으로 제공하는 기능을 이용하거나,
허용하는 범위 내에서만 추가 도구 사용 가능
➡️ 페이지 라우팅 기능을 구현해야 할 때,
내가 원하는 라우터를 찾아서 설치하는 게 아니라
프레임워크인 Next.js가 제공하는 페이지 라우터나 앱 라우터 같은 기능만 이용해야 함
(원하는 라우터를 선택해서 할 수 없음)
즉,자유도가 낮다
자유도가 높은 게 좋은 것인가?
자유도가 너무 높아도 문제
➡️ 그만큼, 기본 기능이 적음
리액트와 같은 라이브러리는
렌더링 등 주요 기능을 제외한 모든 기능은 다 만들어서 써야 함
혹은 라이브러리를 직접 찾아서 써야 함
넥스트는 웹 개발에 있어서 모든 필수적인 기능은 거의 다 기본적으로 제공
ex) 페이지 라우팅, 최적화, 서버 사이드 렌더링 등
➡️ 따라서 가져다 이용만 하면 됨
기본적으로 제공되는 기능을 이용해서
상당히 많은 부분을 간단히 해결하기 때문에
훨씬 편하고 빠르게 웹 서비스 구축 가능
따라서,
넥스트는 기존의 리엑트에 추가적인 기능을 덧붙여둔 리액트의 확장판이기 때문에
이미 리액트를 알고 있는 사람들은 몇 가지만 배우면 쉽고 재미있게 배울 수 있음
📌 Next.js의 사전 렌더링 이해하기
넥스트의 기본적인 동작 방식은,
사전 렌더링이라는 기능 안에서 대부분 설명이 됨
☑️ 사전렌더링?
브라우저의 요청에 사전에 렌더링이 완료된 HTML을 응답하는 렌더링 방식
기존 리액트의 Client Side Rendering의 단점을 효율적으로 해결하는 기술
사용자가 브라우저를 통해 서버로 초기 접속 요청
서버는 자바스크립트로 작성해둔 모든 리액트 컴포넌트를 다 실행해서
이 컴포넌트를 HTML 페이지로 미리 다 변환 후 렌더링시킨 후
서버 측에서 렌더링된 HTML 파일을 브라우저에게 응답해주는 렌더링 프로세스
➡️ 사전 렌더링
이게 어떻게, 기존 리액트의 클라이언트 사이드 방식의 문제를 해결하는 걸까?
☑️ 리액트의 렌더링은 어떻게 전달될까?
클라이언트 사이드 렌더링이란?
✅ Client Side Rendering(CRS)
React.js 앱의 기본적인 렌더링 방식
클라이언트(브라우저)에서 직접 화면을 렌더링하는 방식
클라이언트인 웹 브라우저가,
우리가 작성한 모든 자바스크립트 코드, 즉 우리가 작성한 리액트 앱을 실행시켜서
렌더링을 직접 브라우저 차원에서 처리하는 방식
클라이언트 사이드 렌더링 매커니즘
유저, 브라우저, 서버가 있다고 할 때,
사용자가 브라우저를 통해 서버로 초기 접속 요청을 보내면,
서버는 일단 빈 껍데기인 index.html을 브라우저로 보냄
그럼 브라우저는 서버로부터 받은 이 html 파일을 일단 화면에 렌더링
그러나 사용자의 화면에는 아무것도 안 나옴
지금 브라우저가 서버로부터 받은 HTML파일은 빈 껍데기이기 때문
위와 같이 끝나지는 않고,
서버는 이어서 브라우저에게
그동안 작성한 모든 자바스크립트 코드
만들어둔 리액트 앱을 하나의 자바스크립트 파일로 묶어서(Bundling)
후속으로 브라우저로 보내줌
브라우저는 번들링된 자바스크립트 파일, 즉 리액트 앱을 직접 실행
리액트 앱이다 보니 리액트 컴포넌트들이 이떄서야 실제로 화면에 나타남
이제야 유저는 자신이 요청한 웹 페이지를 볼 수 있게 됨
리액트가 이런 클라이언트 사이드 렌더링으로 동작하는 이유는,
초기 접속 이후에 일어나는 페이지 이동을 매우 빠르고 쾌적하게 처리한다는 장점이 있음
이 자바스크립트 번들에는,
이 서비스에서 접근 가능한 모든 컴포넌트 코드가 존재
➡️ 웹 사이트에 필요한 전체 코드
따라서 초기 접속 과정 이후,
링크나 버튼을 클릭해서 페이지를 이동해도
서버에 새로운 페이지를 요청할 필요가 없음
왜냐하면,
브라우저는 리액트 앱을 가지고 있고,
리액트 앱에는 모든 페이지에 필요한 컴포넌트가 다 포함이 되어 있기 때문
페이지 이동 요청이 있어도,
브라우저가 자체적으로 아까 서버로부터 받은 리액트 앱을 실행해서
현재 이동해야 하는 페이지에 맞도록
적절히 컴포넌트를 갈아끼우면 되기 때문에
굉장히 빠른 속도로 페이지 이동이 가능
클라이언트 사이드 렌더링의 단점은?
초기 접속 속도가 느리다! <- 아주 치명적
왼쪽 위 초기 접속 요청이 발생한 시점부터,
왼쪽 아래 화면이 렌더링되기까지 오랜 시간이 소요됨
즉, 요청 시작 시점부터 실제 콘텐츠가 렌더링 되기까지 꽤 오랜 시간이 소요됨
브라우저가 화면/콘텐츠를 렌더링하기까지는
빈 껍데기 HTML도 받아와야 하고,
자바스크립트 번들 파일 즉, 리액트 앱도 받아야 하고
최종적으로 이 JS를 실행도 해야 하고,
➡️ 브라우저가 하는 일이 너무 많아서 이 과정이 너무 오래 걸림!
FCP(First Content for Paint)
요청이 시작된 시점으로부터, 콘텐츠가 화면에 처음 나타는 데 걸리는 시간
: 요청 시작 ↔ 콘텐츠 렌더링
이 FCP는 웹 페이지의 성능을 대표할 정도로 굉장히 중요한 지표
이 FCP가 조금이라도 늦어지는 경우
위 지표처럼 사용자의 이탈률이 굉장히 가파른 폭으로 크게 증가
하지만 리액트는 이렇게 클라이언트 사이드 렌더링이라는 방식으로 동작하기 때문에,
즉, 초기 접속 요청 시에 브라우저가 HTML 렌더링과 리액트 앱까지 실행해야 하기 때문에
결과적으로 컨텐츠가 화면에 렌더링된 시점인 FCP가 꽤 늦어지는 치명적인 단점이 있음
- 장점: 초기 접속 이후의 페이지 이동이 빠름
- 단점: FCP(초기 접속 속도)까 느림
☑️ 그래서 등장한 사전 렌더링
리액트의 단점인 CSR의 단점을 해결함
유저가 브라우저를 통해 서버에 초기 접속 요청을 보냄
서버가 서버 측에서 자바스크립트 코드를
리액트 앱으로 직접 실행 시켜서,
우리가 만든 모든 리액트 컴포넌트를 HTML로 변환
➡️ 즉, 사전에 렌더링 수행
이미 사전에 렌더링된 HTML 파일이 전달됨
앞서 CSR에는 HTML이 빈 껍데기 파일이었지만,
지금은 사전에 렌더링된 HTML 파일을 보내준다는 차이점이 생김
그래서 사용자는 바로 화면에 렌더링된 화면을 볼 수 있음!
➡️ FCP가 굉장히 크게 단축
📝 렌더링이란?
서버 측에서 자바스크립트 코드, 즉 리액트 앱을 실행해 HTML로 변환하는 과정도 렌더링이라고 했고,
브라우저가 컨텐츠를 화면에 그리는 과정도 렌더링이라고 했는데
... 뭐지?렌더링의 뜻은 두 개!
JS실행(렌더링)
자바스크립트 코드(리액트 컴포넌트)를 HTML로 변환하는 과정
-자바스크립트를 렌더링한다.
-JS를 렌더링한다.
-컴포넌트를 렌더링한다.화면에 렌더링
브라우저가 서버로부터 받은 HTML코드를 화면에 그려내는 작업
즉, 실제 콘텐츠를 그려내는 작업
-화면에 렌더링한다.
이제 콘텐츠가 화면에 렌더링되어
콘텐츠가 채워진 화면만 나타나는데,
이게 다 끝난 게 아님!
브라우저가 지금은 서버로부터 HTML 파일 하나만 받은 상태이기 때문에,
클릭이나 페이지 이동 같은 인터렉션, 즉 상호작용은 아직 동작하지 않음
웹 페이지의 상호작용은 자바스크립트가 처리하는 영역이기 때문에!
따라서 아직 이벤트를 처리할 자바스크립트 코드가 없어서 이 시점에는 상호작용이 불가능
➡️ 아직 완성된 건 아님
따라서 넥스트 서버가 곧바로 브라우저에게
후속으로 우리가 작성한 자바스크립트 코드,
즉 리액트 앱을 번들링해서 브라우저에게 보내주게 됨
브라우저는 서버로부터 받은 자바스크립트 코드,
리액트 앱을 직접 실행해서
현재 화면에 렌더링되어 있는 HTML 요소와 연결
기존의 HTML로만 렌더링해뒀기 때문에
아무런 상호작용도 발생할 수 없단 웹 페이지에 자바스크립트 코드들이 쏟아짐
➡️ 아주 생기 있는 완성된 페이지가 완성!
그래서 이렇게 HTML과 자바스크립트를 연결하는 과정을,
넥스트에서는 마치 메말라 있던 HTML 요소들에
자바스크립트라는 물을 뿌려주는 것과 비슷한 느낌
➡️ "수화" 또는 "하이드레이션"이라고 함
이 상호작용까지 가능해진 시점을
Time To Interactive ➡️ TTI라고 함
ex) TTI 3초: 요청부터 하이드레이션이 종료되는 시간이 3초
이 이후에 발생하는 페이지 이동 요청은?
➡️ 클라이언트 사이드 렌더링 방식으로 처리
이 과정을 간소화하고 이 다음 요청을 살펴보면,
이렇게 추가 요청이 있을 때는?
이때부터는 CSR과 똑같은 방식으로 페이지 이동이 처리됨
브라우저가 서버에게 별도의 페이지를 추가로 요청하지 않고,
자바스크립트 코드를 실행해서,
즉 리액트 앱을 실행해서
컴포넌트를 교체하는 방식으로
페이지 이동이 효율적으로 진행됨
이렇게 되는 이유는,
초기 접속 요청 과정에서 서버가 브라우저에게
하이드레이션을 위해 자바스크립트 번들을 전달했기 때문
➡️ 전달된 자바스크립트 번들 파일은 그냥 리액트 컴포넌트들이 들어있는 리액트 앱임
그래서 페이지 이동이 발생했을 때 원래 리액트 앱이 그랬던 것처럼
브라우저가 직접 자바스크립트 코드를 실행해서,
컴포넌트만 딱 교체하는 방식으로 빠르고 쾌적하게 페이지 이동 가능
그래서 그러므로,
넥스트는 초기 접속 요청 과정에서는
이렇게 서버 측에서 자바스크립트 코드를 HTML로 미리 렌더링하는 사전 렌더링이라는 방식을 통해
기존 리액트의 단점이었던 FCP를 빠르게 개선할 수 있으면서도
동시에 그 이후 발생하는 페이지 이동은, 기존의 CSR 방식을 그대로 처리해서
리액트 앱의 장점인 빠르고 쾌적한 페이지 이동은 그대로 계승해서 장점을 가져옴
