서버사이드 렌더링

D+44

오늘은 빠르게 글을 써본다. r3f를 하려다 next.js를 이야기하고 있는 나의 글. 언제 다시 r3f로 돌아갈지...

서버에서 HTML을 만들어줌

나의 짧은 이해를 항상 말하게 된다. 웹페이지는 html이라는 것으로 이루어져 있다. 다시 말해 화려한 자바스크립트, 타입스크립트로 코드를 구성해도 우리 눈에 보이는 페이지를 구성하는 것은 HTML이다. 이 HTML을 서버에서 만들어준 것을 다운로드할 것인가, 아니면 Client side(핸드폰 또는 브라우저)에서 HTML을 생성할 것인가 따라서 Server Side Render(SSR) 여부를 판별할 수 있다. next.js의 경우 SSR을 이용해 서버단에서 html을 생성한 후, client단에서 다운로드하는 방식을 취한다. 단순히 보내면 끝나느냐. 해당 html이 적합한 위치에 들어가야 한다. 이는 react의 hydrate(현 문서에선 hydrateRoot)를 이용해 수행하게 된다. 

SSR의 장점

Next.js는 SSR을 기본 골자로 하고 있기 때문에 SSR의 장점과 운명을 같이 한다. 그럼 장점을 살펴보면 다음과 같다.

1. 웹페이지 보안이 더 뛰어나다

웹페이지에서 API요청등을 위해 클라이언트 단에 민감한 정보를 담고 있는 경우도 있다. 하지만 SSR의 경우 모든 연산은 서버단에서 한 후 화면에는 결과만 보여주기 때문에 보안에 있어 유리하다

2. 호환성이 높은 페이지를 만들 수 있다.

html만 화면으로 내보내기 때문에 문법등에 구애받지 않고 코드를 작성하고 여러 브라우저에서 작동하는 웹페이지를 만들 수 있다.

3. Search Engine Optimization(SEO)에 유리하다

화면에는 결괏값인 html만 나오기 때문에, search engine에 쓰이는 크로울러 등이 웹페이지 로딩을 기다릴 필요가 없게 된다. 정확한 로직은 모르겠으나, 로딩을 기다리는 시간이 짧게 되면 SEO 점수가 높아져 검색 최적화에 도움이 된다

끝맺으며

오늘은 많은 내용을 다루지는 못했다. 그래도 얼추나마 SSR의 장점을 알 수 있었다. React와 결합해서 생각하면 hydrate에 대해 좀 더 공부해야겠다는 생각이 들었다. 이런 내용들만 보면, r3f에 쓰이는 부수적인 화면 조각들은 SSR을 하고 webgl 부분만 client에서 렌더링을 하기 때문에 좀 더 빠르게 화면을 표시할 수 있지 않을까 싶다.