순수 CSR을 ISR로 변경하여 SEO 최적화 해보기

NEXT로 만들어진 프로젝트가 있는데 

가장 중요한 홈과 세 메인 페이지 모두 리액트 쿼리로 csr을 사용하고 있었다.

 

'홈'페이지에 중요한 데이터 페칭이 이루어지고 있었는데

중요한 데이터가 전혀 노출되지 않고 있었다.

실제로 구글에서 검색을 해보니 우리 서비스를 찾기 어려웠다.

이 부분을 좀 더 검색엔진 최적화하면서 좋은 성능을 유지하는데 도전해보고 싶었다.

 

이 부분에 무한스크롤이 적용되어 있으며 데이터가 꽤 많아서

매번 req와 함께 pre rendering 되는 SSR은 비효율적이라고 판단했고

한번 붙은 데이터는 꽤 긴 시간 동안 유효했기 때문에

ISR로 적절한 시간 텀을 주면서 revalidate를 시키고 cdn 캐싱을 이용할 수 있도록 구현하기로 결정했다.

 

데이터를 붙이고자 하는 페이지에서 getStaticProps를 사용하고

안에서 axios요청을 보내서 받아온 데이터를 실제 데이터가 붙는 컴포넌트까지 props로 전달했다.

그리고 리액트 쿼리에 initialData로 이 데이터를 전달했다.

그 결과 컴포넌트 랜더링 전에 data를 찍어 봤을 때 undefined가 나왔었는데

랜더링 전에도 기본적으로 initialData를 가지고 있게 되었다.

 

페이지 소스보기를 통해 중요한 데이터들이 pre rendering 되는 것을 확인했다.

 

근데 내가 만든 이게 정말 성능상 문제가 없을까?

네이버에서 개발한 nGrinder라는 오픈소스 프로젝트가 있다.

퍼포먼스 테스트를 할 수 있다고 한다. 이것을 적용해서 퍼포먼스에 얼마나 차이가 있을지 테스트를 해보자.

 

getStaticProps의 장점을 잘 살리려면 빌드한 후의 환경에서 테스트를 해야 하기 때문에

(dev에서 확인하면 새로고침 할때마다 서버에 요청, build 해서 확인하면 빌드 시에 만들어놓고 cdn캐시 활용)

두 경우 모두 빌드해서 확인을 했다.

생각으로는 ISR이 첫 요청만 조금 시간이 걸리고 그 뒤로는 캐싱되어 seo에도 더 좋으면서 성능도 더 빨라질 것이라고 예상했지만

순수 CSR을 사용했을 때는 Mean test time이 26.5ms였는데, ISR을 사용하니 86ms까지 늘었다.

약 60ms정도가 더 걸렸다. next의 SSG기능을 사용할 때 cpu를 더 많이 사용하게 되어서 그럴 수 있다는 말을 들었는데

암튼 우리 회사에서는 사용하지 않기로 했다. 역시 개발은 실전이다. 문서와는 다르다ㅋㅋ

 

근데 내 생각엔 이 테스트가 모든 네트워크가 완료되는데 걸리는 시간을 측정한 것 같다.

하지만 SSG는 html을 cdn으로 받아서 바로 보여주므로 사용자가 느끼기엔 더 빨라질 수도 있다. 

우리 서비스에서는 그 차이가 사람의 눈으로 감지하기 힘들 정도라서 측정은 할 수 없지만

60ms정도의 네트워크 시간이 더 들더라도 seo에 최적화된 페이지가 더 낫지 않을까..

생각을 하며 이렇게 마무리! 실제 배포는 못했지만 충분히 배웠으니 좋은 경험이었다.