Nextjs - SEO를 위한 SSR / CSR / SSG

오늘은 직접 SSR과 CSR, SSG을 Nextjs에서 결과를 통해 차이점을 알아보도록 할까요?!

요즘 프론트엔드 면접의 대표 질문이기 때문에 어떤식으로 활용해야 좋은지를 제대로 아는게 중요하다고 생각해요ㅎㅎ

오늘은 CSR과 SSG만 알아보도록 할께요! (추후에 SSR / ISR 예정)

1. CSR(Client Side Rendering)

먼저 Client Side Rendering(CSR)은 말그대로 클라이언트에서 렌더링 진행한다는 뜻으로 초기 로드시에 HTML를 통해 다운받은 JS파일 빈 HTML에 DOM을 그려나간다는 특징이 있습니다.

대표적으로 Single Page Application(SPA)의 React를 통해 사용할 수 있어요.

 

그렇기때문에 초기에 그리는 시간으로 인해 초기페이지 진입에 살짝 느리다는 점이 있지만, 추가적인 HTML로드가 없기 때문에 화면 전환이 빠르다고 해요.

2. SSG(Static Site Generation)

Static Site Generation(SSG)은 정적사이트를 생성하는 방법이에요.

SSG는 CSR과 다르게 빈 HTML에서 DOM을 그리지않고 빌드시에 생성된 HTML을 가져온다는 점에서 차이점이 있어요. 이미 모두 그려진 정적페이지를 제공하기 때문에 속도 측면에서는 가장 좋은 성능을 가진다고 생각해요.

 

이미 생성된 HTML을 가져온다는 점은 SEO에 좋은 환경을 제공해요. 봇이 현재 페이지에서 제공하는 정보를 읽기가 매우 좋다는 장점이 생기는 거죠!

또한 초기페이지 진입에 빠르다는 장점이 있지만, 빌드시의 데이터에 의존하기 때문에 변경이 잦은 페이지에선 오히려 안좋은 사용자 경험을 제공해요. (몰론, ISR을 사용하여 어느정도의 해결이 가능해요!)

3. CSR과 SSG의 차이 확인

그러면 마지막으로 CSR과 SSG가 어떤 점에서 다른지를 확인해보도록 할께요!

먼저 확인하는 페이지는 저의 문제은행서비스(https://exam-bomb-service.vercel.app/)입니당

먼저 아래 사진에서 CSR 방식으로 시작하는 초기 페이지를 확인해보면 두가지의 상황이 일어나게 되겠죠?

 

1. html를 가져와서 화면을 그린다.
2. 과목을 fetch한다. (저는 SWR을 통한 데이터 상태관리를 선택했어요!)

const {
    data: subjects,
    error,
    isLoading,
  } = useSWR<Subject[]>('/subjects', fetcher);
  
  ...
  	{subjects?.map((subject, i) => {
            const { subjectId, subjectName } = subject;
            return (
                <BoxRow
                  key={'subject' + i}
                  onClick={() => setSelectedSubject(subject)}
                  selected={selectedSubject?.subjectId === subjectId}>
                  {subjectName}
                </BoxRow>
            );
         })}

보통 이런식으로..? 데이터를 표출하겠죠!!

 

그럼 이제 위에서 1번의 상황이 일어나는지를 확인하기 위해서 다운받은 html을 확인해볼께요.

이 부분을 보면 상단에 "과목을 선택하세요" 이후 '정보처리기사필기'와 'SQLD'라는 텍스트가 없는 것을 확인할 수 있어요.

다시 말해서 html을 가져오지만 (참고로 React와 다른 점은 Nextjs이기 때문에 fetch단계 이전의 html을 미리 그려줍니다.) 

fetch한 데이터는 html에 존재하지 않는 것을 확인할 수 있어요!

 

만약에 똑같은 화면은 SSG를 적용하여 만들게 되면 어떻게 될까요?

예상되는 현상은 "과목을 선택하세요" 밑으로 정보처리기사필기와 SQLD라는 데이터가 html에 그려져서 올 것이 예상되나요?

 

SSG는getStaticProps라는 예약어를 통해 사용할 수 있는데요!

아래는 subjects를 조회하여 page의 props로 전달받게 되어 위의 CSR의 useSWR과 같은 fetch 과정이 필요가 없게 돼요!

export async function getStaticProps({ params }: GetStaticPropsContext) {
  const subjects = await prisma?.subject.findMany({
    select: {
      subjectId: true,
      subjectName: true,
    },
  });
  return {
    props: { subjects },
  };
}

이제 SSG를 적용한 html을 확인해보도록 할께요!

확인한 결과 예상과 같게 나오는 것을 확인할 수 있네요!!

 

마지막으로 SSG는 빌드시에 정적사이트라는 것을 확인하기 위해선 과목을 하나 추가해서 확인해보도록 할께요!

아래의 사진에서 왼쪽은 SSG, 오른쪽은 CSR입니다.

CSR의 경우엔 새로운 과목이 반영되는 반면에 SSG는 반영이 안되는 것을 확인할 수 있어요.

 

 

이렇게 데이터의 변화에 따라서 SSG와 CSR을 언제 사용하는게 좋을지 생각하면서 개발하면 SEO에 친화적인 개발에 한걸음 다가갈 수 있지 않을까 싶어요!

 

4. 결론

저는 해당 부분에서 CSR을 사용하여 구현을 했었으니 생각해보니 과목이 늘어나는 현상이 그렇게 많다고는 생각이 들지 않았고, 정보처리기사필기와 SQLD라는 텍스트의 SEO 효과가 더 좋은 방향이라고 생각하여 SSG를 사용하는 방법으로 제공하도록 refactoring 하게 되었어요!

또한 크롤링이 서치할 수 있는 영역은 서버로부터 받아오는 영역인데 CSR같은 경우는 SSR처럼 HTML에 페이지에 대한 정보가 잘 나오지 않기 때문에 의미있는 정보를 meta 태그로만 전달할 수 있는 단점이 있어요!

이러한 관점에서 SEO에 친화적인 서비스를 만들어 갈 수 있으니 직접 적용해보세요!