[React] SPA, SSR, SEO etc.

1. SPA
2. SSR
3. SEO

---

1. SPA란 ⭐️

• SPA
  • Single Page Application의 약어로, 한 개의 페이지로 이루어진 애플리케이션이라는 의미
    
    

• 전통적인 웹 페이지는 여러 페이지로 구성되어 있는데, 사용자가 다른 페이지로 이동할 때마다 새로운 html을 받아 오고, 페이지를 로딩할 때마다 서버에서 리소스를 전달받아 해석한 뒤 화면에 보여줌
• 사용자에게 보이는 화면은 서버 측에서 준비했단 말씀! 사전에 html 파일을 만들어서 제공하거나, 데이터에 따라 유동적인 html을 생성해주는 템플릿 엔진을 사용하기도 했음
  
  
• 하지만!! 요즘엔 웹에서 제공되는 정보가 너무 많기 때문에 새로운 화면을 보여 주어야 할 때마다 서버 측에서 모든 뷰를 준비하면 성능이 엄청 떨어질 수 있음(트래픽이 너무 많이 나온다거나, 사용자가 몰려서 서버에 높은 부하가 쉽게 걸린다거나)

 

사용자와의 인터렉션이 발생하면 필요한 부분만 자바스크립트를 사용하여 업데이트(JSON 형식으로 요청)

• 그래서 리액트 같은 라이브러리 혹은 프레임워크를 사용해 뷰(view)렌더링을 사용자의 브라우저가 담당하도록 하고,
• 우선 애플리케이션을 브라우저에 불러와서 실행시킨 후에 사용자와의 인터렉션이 발생하면 필요한 부분만 자바스크립트를 사용하여 업데이트해줌
• 만약 새로운 데이터가 필요하다면 서버 API를 호출해 필요한 데이터만 새로 불러와서 애플리케이션에서 사용할 수도 있음
  
  
  
• 싱글 페이지라고 해서 화면이 한 종류인 것은 아님
  • SPA의 경우 서버에서 사용자에게 제공하는 페이지는 한 종류이지만, 해당 페이지에서 로딩된 자바스크립트와 현재 사용자 브라우저의 주소 상태에 따라 다양한 화면을 보여 줄 수 있음
• 다른 주소에 다른 화면을 보여 주는 것을 라우팅이라고 함
• 리액트 라이브러리 자체에 이 기능이 내장되어 있지 않기 때문에, 브라우저의 API를 직접 사용하여 이를 관리하거나, 라이브러리를 사용해 이 작업을 쉽게 구현할 수 있음
  
  • 리액트 라우팅 라이브러리는 리액트 라우터(react-router), 리치 라우터(reach-router), Next.js 등 여러 가지가 있는데, 이러한 리액트 라우팅 라이브러리는 클라이언트 사이트에서 이루어지는 라우팅을 아주 간단하게 구현할 수 있도록 해줌
    
    
    
• SPA의 단점
  • 앱의 규모가 커지면 자바스크립트 파일이 너무 커진다는 점
  • 페이지 로딩 시 사용자가 실제로 방문하지 않을 수도 있는 페이지의 스크립트도 불러오기 때문임
  • 근데 코드 스플리팅(code splitting) 사용하면 라우트별로 파일들을 나눠서 트래픽이랑 로딩 속도 개선할 수 있음 ~
    
    
  • 리액트 라우터처럼 브라우저에서 자바스크립트를 사용해 라우팅을 관리하는 것은 자바스크립트를 실행하지 않는 일반 크롤러에서는 페이지의 정보를 제대로 수집해 가지 못한다는 잠재적인 단점이 따름
  • 따라서 구글, 네이버, 다음과 같은 검색 엔진의 검색 결과에 페이지가 잘 나타나지 않을 수도 있음
  • 또한, 자바스크립트가 실행될 때까지 페이지가 비어 있기 때문에 자바스크립트 파일이 로딩되어 실행되는 짧은 시간 동안 흰 페이지가 나타날 수 있다는 단점도 있음
    
    
  • 그렇지만 이런 문제점은 서버 사이드 렌더링(SSR, server-side-rendering)을 통해 모두 해결 가능 ~

 

2. SSR이란 ⭐️

• SSR
  • Server Side Rendering의 약자로, 서버에서 페이지를 그려 클라이언트(브라우저)로 보낸 후 화면에 표시하는 기법
    
    
• 리액트는 대표적인 CSR(client side rendering)임
  • CSR: 사용자가 해당 도메인에 접속하면, 클라이언트 서버(사용자의 컴퓨터)가 html과 js등의 파일을 다운받아 보여주는 형식
• 이러한 리액트의 CSR적인 부분에서 SSR적으로 바꿔 주기 위해 next.js와 같은 프레임워크를 사용
  
  • SSR을 사용하는 가장 큰 이유는 효율적인 SEO를 위해서
  • SEO: google, naver와 같은 검색 엔진들이 내 웹사이트에서 html 태그 안의 내용을(title, meta-data etc.) 분석하여 사용자가 입력한 정보를 바탕으로 알맞은(사용자가 원하는) 정보를 찾을 수 있게 해주는 기능
• CSR 상태에선 사전에 html을 가지고 있지 않기 때문에 검색 엔진에 노출되는 빈도가 현저히 적거나, 브라우저에 따라 검색 엔진에 해당 정보가 노출되지 않아 검색을 해도 나오지 않을 수 있음(도메인을 통해 접속하는 것은 가능해지는 정도, 해당 사이트에 관련된 정보를 검색 엔진이 크롤링하지 못할 수 있음)
• 그래서 SSR을 통해 서버가 사전에 html과 일부 js파일을 넘겨주게 되면, 검색 엔진에서 이를 캐치해 사용자가 원하는 정보가 담긴 사이트를 보여줄 수 있는 것
  
  
  
• SSR을 지원하기 위한 리액트 API
  • renderToString
    - 리액트 컴포넌트를 렌더링하여 정적 html 문자열을 반환
    - SSR 시 가장 일반적으로 사용되는 API
    
    
  • renderToStaticMarkup
    - renderToString과 유사하지만, 일부 리액트 내부 데이터 속성을 추가하지 않음
    - 정적 페이지 생성 시 사용
    
    
  • renderToNodeStream > renderToPipeableStream
    - 리액크 컴포넌트를 렌더링하여 Node.js 스트림을 반환
    - 대용량 컴포넌트를 스트리밍하더나 프록시 서버에서 사용될 수 있음
    - React 18 버전에서 renderToPipeableStream 으로 메서드가 변경됨
    
    
  • renderToStaticNodeStream
    - renderToNodeStream과 유사하지만, 데이터 속성을 추가하지 않음
    - 정적 페이지 생성 시 스트리밍 렌더링에 사용될 수 있음
    
    
  • hydrate
    - 서버에서 렌더링된 html 코드를 브라우저에서 인식하고 이벤트 핸들러를 연결하는 역할
    - 클라이언트 측에서 서버 렌더링 마크업에 이벤트 핸들러를 연결할 때 사용
    - 이미 렌더링된 html이 있다는 가정하에 작업을 수행
    - renderToString, renderToNodeStream 등으로 생성된 html 컨텐츠에 자바스크립트 핸들러나 이벤트를 붙이는 역할

 

3. SEO란 ⭐️

• SEO(검색 엔진 최적화)
  • Search Engine Optimization의 약자로, goole, 네이버와 같은 검색 엔진들이 서버에 등록된 웹사이트를 하나하나씩 돌아 다니면서 웹사이트의 HTML 문서를 분석해줌
  • 이때 html에 사용된 태그를 바탕으로 사용자가 검색할 때, 웹사이트를 빠르게 검색할 수 있게 도와줌
    
    
• 하지만, 
  • CSR에서 사용되고 있는 html의 body는 텅텅 비어 있다가(div id="root"의 리액트 특성) 사용자가 해당 도메인을 사진 페이지에 접근하면 클라이언트 서버에서 js및 html 태그를 불러오는 형식이기 때문에 사전에 html 정보를 가지고 있지 않아 검색 엔진이 해당 도메인에 접근할 때 어려움이 있음
  • ➔ 사이트를 검색 엔진으로 다양한 키워드를 통해 유입되는 것이 힘들다 → why? 검색 엔진이 우리 html파일을 분석할 수 없기 때문 → why? CSR 형식은 사용자가 접근해야 html, js 등의 파일을 불러오기 때문
• 따라서 검색 엔진 최적화를 해주기 위해 SSR을 사용해 사전에 html 문서를 검색 엔진이 찾을 수 있도록 제공하여 SEO를 향상시킬 수 있음
  
  • SSR은 서버에서 필요한 데이터를 가져와 사전에 html 파일을 만들게 되고 이렇게 만들어진 HTML 파일을 일부 초기 세팅에 필요한 js와 함께 클라이언트 서버에 보내주게 됨
  • 그럼 클라이언트 측에서는 서버에서 만들어준 문서를 받아 와서 바로 사용자에게 보여줄 수 있게 되는 것 !
    
• SSR을 사용하게 되면 사전에 HTML 문서를 클라이언트 측으로 전달했기 때문에, 페이지 로딩이 빨라지고, 검색 엔진이 사용자의 요청에 따라 검색어를 찾을 때(데이터를 크롤링할 때), 우리의 웹사이트에 해당 검색어가 포함되어 있다면 우리 페이지를 보여주는 효율적인 SEO가 될 수 있음
  
  
  
• 하지만, 
  • SSR이 CSR의 모든 문제점에 해결책이 되지는 않음(서버에서 데이터를 사전에 받아오는 것이기 때문)
  • 첫 번째로 blinking issue가 여전히 존재(페이지가 넘어갈 때마다 깜빡임 why? html 및 js 파일을 새로 받아오기 때문에) 
  • 두 번째로 사용자가 증가함에 따라 서버는 사용자의 요청에 의해 더 많은 데이터를 가지고 와서 HTML을 만들어야 하므로 과부화가 올 수 있음
  • 마지막으로 사용자가 빠르게 웹사이트를 확인할 수는 있지만, SSR시 모든 js파일을 다운 받은 상태가 아니기 때문에, js파일이 완전히 다운로드 되지 않은 상태에서 페이지의 여러 부분을 클릭하면, 작동이 되지 않는 부분이 존재할 수 있음
• CSR은 사용자에게 보여짐과 동시에 모든 html과 js를 불러온 상태이기 때문에, TTV(Time to View, 보여지는 시점)와 동시에 TTI(Time to Interact, 인터렉션,사용자와의 통신이 가능해지는 시점) 모든 동적인 행동을 할 수 있게 됨
• SSR의 경우, html과 일부 js파일은 서버로부터 사전에 받아 놓았기 때문에 TTV 상태에서도 TTI가 전부 활성화되어 있지는 않음
  
  
• 요즘에는 SSR, CSR 뿐만 아니라 SSG(Static Site Generation)또한 렌더링 방법으로 등장함
  • SSG: 리액트를 예로 들면 'Gatsby' 또는 'Next'와 같은 라이브러리를 추가적으로 사용하여 렌더링을 하는 것인데, 웹페이지를 정적으로 미리 생성해두고, 서버에 배포해놓는 것
• SSG에서도 자바스크립트 파일을 html 파일과 함께 가지고 있을 수 있기 때문에, 동적인 요소도 충분히 추가할 수 있음.
  
  
  
• 결론, 
  • CSR를 많이 사용한다면, 내가 최종적으로 번들링하여 사용자에게 보내주는 js파일을 어떻게 하면 효율적으로 많이 분할하여 첫 번째로 사용자가 보기 위해서 필요한 정말 필수적인 html 요소만 보낼 수 있을 지 고민해야 하고
  • SSR의 경우, 사용자가 보고 인터렉션(TTI)하는 시간의 단차를 줄이기 위해서 어떤 노력을 할 수 있을지 고민해야 함
  • 어떤 것이 최고다, 제일 낫다라는 판단 보다는 내가 만들어야 하는 웹사이트 특성에 맞게 다양한 방식의 렌더링을 활용하여 페이지를 구성