브라우저 렌더링 #3

JS

프론트엔드적 브라우저 렌더링?

한창 브라우저 렌더링을 검색할때, 멘토님이 프론트엔드적 브라우저 렌더링이 무엇이냐고 물어보셨다. 프론트엔드적 브라우저 렌더링? 엄청 심오한 이야기이려나 싶었지만, 우리가 흔히들 말하는 CSR, SSR 등에 대한 고민에 대해 말씀해주셨다.

---

렌더링의 종류

정리부터 말하자면, 렌더링의 종류를 구분짓는건, 렌더링 포인트(시점)의 차이라고 말할 수 있겠다. 표시해줄 화면의 렌더링을 어디서 하느냐의 차이. 렌더링 포인트의 차이!

SSR : Server Side Rendering

• 서버에서 사용자에게 보여줄 페이지를 모두 구성해서 사용자에게 페이지를 보여주는 방식.
• JSP/Servlet의 아키텍처에서 사용.
• 모든 데이터가 매핑된 서비스 페이지를 클라이언트(브라우저)에게 바로 보여줄 수 있음.
• 서버를 이용해서 페이지를 구성하기 때문에, 클라이언트에서 구성하는 CSR 보다 페이지를 구성하는 속도는 늦어지나, 전체적으로 사용자에게 보여주는 구성이 완료되는 시점은 빨라진다는 장점이.
• SEO(search engine optimization) 도 쉽게 구성 가능
• 서버에서 html 문서를 생성. 요청이 올때마다 서버에서 생성을 해서 던져준다.

CSR : Client Side Rendering

• 초기 전송되는 페이지의 속도는 빠르나, 서비스에서 필요한 데이터를 클라이언트(브라우저)에서 추가로 요청하여 재구성해야 하기에 페이지 완료 시점은 SSR보다 느려짐.
• dom이 다 그려진다음에 요청을 해서 더 그린다 CSR

SSG : server static generation

• 한번 서버에서 만들어진 페이지. csr처럼 불러오거나 하지 않는다.
• blog. 글은 정해져있는것처럼. 페이지 하나하나를 빌드할 때 만들어 놓고, 그 이후에는 데이터가 바뀌지 않는다.

ISR : 점진적 서버사이드 렌더링

서버사이드 렌더링 + SSG --> 5분마다 , 15분마다 아니면 1시간 마다 빌드를 해준다.

hidration 에러 : 서버에서도 렌더링을 해서 보내주는데, 클라이언트에서도 렌더링을 보여줌.

화면에서 인터렉션을 아무것도 못함.

Q. S3 vs Static?

이미지가 왜 서버에 있는게 빠른가? 한번 연결된건 DNS를 안탄다. 
S3는 한번도 연결해 본 적이 없는 다른 주소.

---

 

번외 - 하이드레이션과 리하이드레이션

• 하이드레이션
  • 자바스크립트 코드가 실행되어서 해당 페이지를 완전히 인터렉티브 하게 만드는것
  • Hydrate는 Server Side 단에서 렌더링 된 정적 페이지와 번들링된 JS파일을 클라이언트에게 보낸 뒤, 클라이언트 단에서 HTML 코드와 React인 JS코드를 서로 매칭 시키는 과정

리엑트에서 서버사이드렌더링 시, 리하이드레이션 에러를 많이 만든다. 서버에서 만들어서 와보니까, 클라이언트에서 내용이 다르다.

Error: There was an error while hydrating. Because the error happened outside of a Suspense boundary, the entire root will switch to client rendering.

 

공식문서

 

애플리케이션을 렌더링하는 동안, ssr/ssg에 의해 프리렌더된 react-tree와 브라우저에 의해 처음으로 렌더링된 react-tree에 차이가 존재했다. 이러한 첫 렌더링은 react의 특성인 hydration이다.

이 경우 react tree가 dom과의 동기화에 실패할 수 있으며 예기치 못한 콘텐츠가 화면에 나타날 수 있다.

⇒ 정리해보면 이 에러는 next의 특징인 ssr 방식으로 렌더링할 경우와, 브라우저에 의해 렌더링할 경우에 서로 다른 react tree가 만들어질 때 발생한다.